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
premipmapped but uncompressed dds files had helped to get a fluent viewer.
The argument against providing these dds files in general was that these files
are really huge because of not including any compression and having all the
mipmaps.
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 the original glu function that is included in
osg for running on an EGL stack which no longer provides GLU.
That is take the image scale this to the 1st mipmap, take the 1.st mipmap and
scale this to the 2. mipmap and so forth.
This would have the advantage that the png's do not deviate from the dds files
over time.
> 3) Add a "/sim/rendering/use-dds" property, drop the file extensions
> from the effects files (and possibly
> materials.xml entries?) and add some logic to check this flag and
> search for .dds extensions, and failing
> that .png for images.
Hmm, I could think of both solutions. Both have pros and cons.
Greetings
Mathias
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
