Re: [Flightgear-devel] Graphics load

[James Turner]

On 3 Apr 2006, at 09:26, Ralf Gerlich wrote: thinking more about the issue and trying to get some distance to the "whohoo!"-attitude of some of the CLOD-papers I read in the last weeks, I'm more and more coming back to the conclusion "simple is beautiful". Perhaps we'd be best off slicing our tiles into subtiles - without essentially changing the layout of scenery directories, just the format of the .btg.gz-files - and provide several statically reduced versions of these subtiles. One approach I'm tempted to view as reasonable is described in [1]. However, this would result in increased storage requirements for scenery. As it was mentioned yesterday, full scenery already takes 13Gb compressed, some of the 10x10 tiles are already well over 50MB and our detailed 3x3 degree South Germany scenery is already at over 20MB compressed. I suspect that further increasing scenery size is calling for trouble. I'm pretty convinced at this point that the long-term solution is to use impostors for tiles in the middle distance - of course this means getting the RenderTexture code working reliably. To me this has the nice property that the low-end graphics hardware with no render-to-texture support can carry on drawing the current tiles with no changes, and people with RTT simply get a higher draw distance without (hopefully) too much impact - you can almost regard the impostors as a fancy way of generation a real-time skybox, though of course they aren't arranged that way. Naturally you still pay the cost of keeping the tile geometry and textures in memory /somewhere/, so it's a good solution where performance is fill-rate or geometry-throughput limited; if the cap is memory or IO bandwidth, it won't help, whereas static-LODd tiles would, at least a bit. James -- Java is, in many ways, C++--