On 26 Sep 2013, at 07:18, Renk Thorsten <thorsten.i.r...@jyu.fi> wrote:

> Mipmaps for textures are pretty generic for the rendering process. If you 
> would not mipmap  textures, they'd create flickering Moire patterns whenever 
> the texture resolution is higher than the screen resolution as (leaving 
> antialiasing aside) the pixel color is determined from a single texture 
> lookup, and the point for that lookup is ill defined when many texture pixels 
> are mapped to a single screen pixel, i.e. the pixel color would flicker frame 
> by frame (that is a problem for procedural texturing).
> Whenever a texture is loaded into the GPU memory, it is mipmapped if it isn't 
> already.  One advantage of dds is that it can contain pre-generated mipmaps - 
> in this case the mipmaps can just be loaded with the base texture, otherwise 
> the mipmap generation is part of the texture loading process.
> If uncompressed dds is used, the final result is the same - a mipmap tower 
> resides in GPU memory, but the time to load the texture is shorter for dds at 
> the expense of having  a larger file. So non-dds textures may generate a 
> short to long (dependent on system) frame delay, whereas dds works a bit 
> smoother. dds can also be compressed, in which case it saves GPU memory, but 
> since that requires proprietary graphics drivers to work, it is not 
> considered an option for FG.
> The main difference between hires and lowers textures is not lookup speed 
> (that's taken care of by mipmapping) but memory - if the GPU memory is full, 
> system memory needs to be used (which is slower), if that overruns, virtual 
> memory must be used (which is even slower) - I have managed at some point to 
> fill the whole 11 GB of my combined GPU and system memory, and the 
> performance degradation was quite substantial.
>> Quite recently there was a discussion about 2048x2048 textures for  
>> scenery, and I'm sure they are mipmapped, otherwise it won't fly. A  
>> typical plane fits all of its exterior into at most a dozen hi-res  
>> textures, so the added cost of mipmapping those is negligible I think.
> Scenery textures are typically mapped to 2000x2000 m areas, so you get about 
> 4x4 m per pixel with a standard 512x512 terrain texture, assuming a 60 deg 
> FOV, you get a good graphical impression only for view distances of 2500 m 
> and more. That's okay for airliner cruise altitude, but really lousy for low 
> leve flight.
> Going to 2028x2048 improves the optimum view distance down to ~800 m, which 
> starts to make it okay for private aviation in single-engine planes, but 
> still lousy  for low level flight.
> So for scenery, there's not only a need for high resolution, but it's also 
> something that you tend to see quite often (almost all the time) at less than 
> optimal resolution. And the whole scenery doesn't need more than two dozens 
> of such textures at any given time - according to your calculation, that's 
> just the performance footprint of two MP planes.
> In contrast, planes typically map to areas of 10x10m, so using a 2048x2048 
> texture gives you a 5 mm resolution. Assuming a FOV of 60 deg, you need to be 
> closer to 4 m to the MP plane to actually get to see the hires texture. I 
> think it's fair to say that you'll almost never reach that distance, so 
> you're spending lots of memory on things which you'll never get to see in 
> flight. Assuming you see MP planes from at best 40 m distance, a 256x256 
> sheet is quite enough. For the same reason, it makes a lot of sense *not* to 
> render the plane interior of MP planes.
> So, not only would hires MP liveries be insanely expensive as compared to 
> scenery if you just have a few planes in the scene, they would also be 
> utterly useless because you can never get close enough. 
> Hope that answers the question conclusively.

Just to say, Thorsten has in this case saved me writing an email, thanks.

To re-iterate - GPU VRAM is a precious commodity, so we should spend it on 
texels you can actually see. While rivets on other aircraft (or static ground 
vehicles) look cool for demo screenshots, they come at a huge cost in terms of 
texels being stored. The mapped texel size calculation that Thorsten is making 
above is one every modeller should be doing, to estimate what detail is 
actually needed. Eg for a building, even an airport terminal, you're rarely 
closer than 50m, often more than 250m for a building outside the airport 
boundary (there are exceptions of course, mostly involving helicopters). 

Save the texels/VRAM for your cockpit interior models, they're much closer to 
the camera and occupy a much larger portion of your field of view :)


October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
Flightgear-devel mailing list

Reply via email to