Paul Surgeon wrote: > Think along the lines of about 57MB for 400 km2 with the terrain > directly under the aircraft at 1 meter/pixel resolution and then > gradually tappering off to 8 meters/pixel in 5 steps to a distance > of 10 km in all directions from the aircraft.
That was my thinking when I started, too. But your math is a little off. Getting to a worst case resolution of 1 texel per screen-space pixel with unique texturing requires *vast* amounts of memory. The anisotropy kills you; far-away texels might typically be rendered at an aspect ratio of 10:1, forcing you to "waste" most of your card memory on useless information. The newer anisotropy controls might help with that, but coding the management intelligence for that is very non-trivial. Think of a texture that is viewed diagonally: anisotropy won't help; you need to rotate it to match the "texel grain" to get anything better than a factor of two benefit. > Then we haven't even started to discuss stuff like S3TC texture > compression which can drop the texture size down to about 10MB. :) This part I actually got working, sort of. Dynamically generated 256x256 textures take about 1/30 second to generate on my GeForce3 (the limiting factor is the DMA to and from the card; the compression itself is done on the CPU). Using ATI's drivers, it was 1/3 of a second or worse. That just isn't useful for realtime stuff; the driver would spend all of its time compressing textures and have no time left for rendering. Like I said; it ain't easy. I tried, and failed. I'm not saying it won't work, mind you; I might pick up the problem again if I'm feeling adventurous. Ideas are free, and designs are cheap. Code is all that matters. Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
