Paul Surgeon wrote:
Number 2 is the route I was planning to take.
There would be no need for an unlimited set of textures and we could add the black tire marks too, not just the taxiway lines.
Clipping the lines against the underlying polygons is a bit tricky but not that hard.
I was just going to float the polygons on top of each other with a *very* small offset so that there would be no z fighting and yet no visible floating.
I'm not too sure how well this would work as I haven't reached that stage yet.
Unfortunately, it doesn't work as well as you'd like ... the z-buffer is finite resolution (usually 24 or 16 bit depth depending on how you have your card/display configured.) What this means is that a range of depths map to each possible depth buffer value. Usually the z-buffer is implemented so that there is much finer grained precision up close versus far away. Changing the near clip plane (pushing it away from you) has a big implact on z-buffer resolution. Changing the far plane has minimal impact. What you'll find then is at altitude, even a meter difference can map to the same depth buffer value, but with floating point rounding differences from frame to frame (as the view perspective moves), you'll get z-buffer fighting. You can use glPolygonOffset in some circumstances to work around the z-buffer problems but only if you are drawing polygons and only if the polygons really live in exactly the same plane factoring all floating point rounding possibilities. I.e. if the polygons don't share exactly the same verticies they likely will round different directions in some situations and you are back to having z-buffer fights. It's a nasty problem. I've seen some applications that do a good job of handling it, but they have obviously put in a *ton* of time working out the issues (and are probably only running on a single specific kind of hardware/video card.)
That's why MS use DXT texture compression.
The DXT (S3TC) texture compression formats use a form of lossy vector quantization to compress texture images by a ratio of 4:1 or 6:1. These formats are a standard part of Direct3D, and are available in OpenGL via the ARB_texture_compression and GL_EXT_texture_compression_s3tc extensions.
Texture compression works very well for color maps.
The textures are stored in compressed format which makes loading a lot quicker and saves lots of IO when being transferred to the video card.
Without texture compression technology FS2004's scenery would not be possible.
Do the textures stay compressed in video ram, does the texture render unit render from the compressed texture, or does it have to uncompress it in video ram before rendering it? If it can stay compressed all the time in video ram (I'm doubtful) then this would be a great savings. But if it is only compressed on your HD, then this isn't all that great of a thing ... good for reducing disk space and disk IO, but doesn't help the run time rendering issues all that much.
Number 4 would not be hard to implement later on.
I'm using OpenGL so it would just be a matter of rendering to a texture and exporting the elevation data.
Yes, not so hard to do a naive implimentation that assumes infinite resources. But the difficulties arise with managing *huge* volumes of texture data on the video card, and to do that on todays hardware you probably have to get extremely clever, and your nice pristine implimentation would have to be hacked all over the place to work around real world limitations. :-(
Regards,
Curt.
-- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
