On Sat, Jul 21, 2012 at 10:42 AM, Mathias Fröhlich
wrote:
>
> Hi,
>
> On Thursday, July 19, 2012 15:32:01 Tim Moore wrote:
>> The depth-pass-only pass is a well known optimization, but the fact it
>> is not helping implies that our bottleneck is not in fragment
>> processing. I've suspected for ye
Hi all!
Let me quickly introduce myself, I'm a dutch software engineering
student who has been lurking on this list for an embarrassingly long
time (think pre FG 1.0...). Anyway, I'd like to get actively involved
in FlightGear core development.
It's obviously a long time wish to get rid of the PL
Am 20.07.2012 11:10, schrieb Anders Gidenstam:
> Given that there is some risk that the behaviour of carefully tuned flight
> models change I'd suggest we only update 2.9.0 and do not update 2.8.0 as
> it is late in its release cycle.
Valid point. Can someone with more insight into the patch
(Jon
Am 21.07.2012 um 11:56 schrieb Harald Johnsen :
> Mathias Fröhlich a écrit :
>>
>>
>> ...
>> But that means we could at the point where the warning happens compute the
>> mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be
>> used to do this I think (or something s
Hi,
On Saturday, July 21, 2012 11:56:39 Harald Johnsen wrote:
> gluScaleImage does the usual job of blurring the texture to compute the
> mipmaps. The advantage of pre computed mipmaps (inside .dds or not) is
> that we can use better algorithms
> (http://en.wikipedia.org/wiki/Bicubic_interpolatio
Mathias Fröhlich a écrit :
...
But that means we could at the point where the warning happens compute
the mipmap levels on the cpu in the loader thread. osg::gluScaleImage
could be used to do this I think (or something similar not requireing
a context). This one is an imported version of
Hi,
On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote:
> I can see a number of options to resolve this (and I'm sure there are more):
Oh, I forgot in the previous mail:
There is a 5. Solution:
Provide premipmapped uncompressed dds files and compress them with something
like gzip. Osg can
Hi,
On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote:
> I can see a number of options to resolve this (and I'm sure there are more):
The 4. Method that I can imagine is to precompute the mipmaps in the loader.
IIRC tests with some of the guys suffering from this problem, providing
premip
Hi,
On Monday, July 16, 2012 07:20:32 Chris Forbes wrote:
> If DDS is not politically acceptable, there should be an alternative
> way of providing premipped textures.
> Mipmap generation is a *significant* portion of the load time,
> particularly on the nicer aircraft with large textures.
>
> E
Hi,
On Thursday, July 19, 2012 15:32:01 Tim Moore wrote:
> The depth-pass-only pass is a well known optimization, but the fact it
> is not helping implies that our bottleneck is not in fragment
> processing. I've suspected for years that it lies on the CPU, and have
> been trying to optimize our
Hi,
On Thursday, July 19, 2012 17:09:09 James Turner wrote:
> I have some plans in that direction post 2.8, especially to flatten the LOD
> quadtrees and transforms of the tiles. Each tile will get some top-level
> LOD groups for all objects (shared and static). I'm hoping in combination
> with t
11 matches
Mail list logo
