Here is one thing to consider when dealing with texture files, OpenGL, and
scene graphs (like OSG or PLIB.)
OpenGL has a concept called mip-mapping. When a texture is loaded,
successively smaller versions are generated automatically using a simple box
filter. So if you start with a 256x256 original texture, the system builds
a 128x128, 64x64, 32x32 ... etc. down to a 1x1 I believe. For each smaller
version, 1 pixel is the average of 4 pixels in the next size up. This
scheme works pretty ok for most picture type textures and it happens
automatically so artists don't have to worry about it.
Then when rendering a scene, the opengl system automatically chooses the
mipmap level (texture size) that best fits the triangle it is getting
applied to ... has a closest to 1-to-1 match with screen space pixels. This
helps prevent aliasing artifacts or "texture swimming" effects that you
might remember from older games.
Where this can lead to problems is with textures that have transparency
(i.e. an alpha channel.) The box filter scheme of generating successively
smaller versions of the texture doesn't work well with the alpha layer. The
transition from fully opaque to fully transparent gets wider and wider
relative to the overall texture and can lead to problems.
More generally, the default box filter scheme of generating the smaller
versions of the texture files is very simple and usually not quite optimal,
and is definitely non-optimal when working with textures that have a
transparency layer. In addition, the mipmaps are generally computed in
software when the texture is loaded which takes some time.
I suspect that some of these fancier formats might have the mipmap layers
pre-computed using a more sophisticated size reducing scheme -- thus
producing slightly better visual results in the end.
Regards,
Curt.
On Mon, Mar 21, 2011 at 9:14 AM, <thorsten.i.r...@jyu.fi> wrote:
> > Maybe you already did this, but this needs a 'average of 3' (or 5)
> > tests, because I would be very surprised if the input file format
> > changes the final frame-rate after loading - it's all uncompressed to
> > the same format in GPU memory, as far as I know.
>
> Yes, I checked it (I couldn't believe it...).
>
> Just *maybe* the conversion by gimp screwed the pnd file and altered the
> texture somehow, so that all derived from the png is then problematic (?).
> But the effect as far as my procedure is described is real.
>
>
> > The PNG loading time also seems suspicious - decompressing a PNG is
> > certainly more work than RGB or DDS, but decompressing a 1MB PNG
> > shouldn't take even one second on a computer of the past few years.
>
> Yes - now multiply this by 2500 since it's done for every cloud being
> loaded, and you get a large number. Of course the system *should* realize
> that it has the texture loaded already and doesn't need to load it any
> more, but evidence suggest that it actually decompresses 2500 times.
>
> Cheers,
>
> * Thorsten
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
