On Mon, 29 Nov 2004 12:53:43 -0600, Curtis wrote in message <[EMAIL PROTECTED]>:
> 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 ..not 32? > 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. :-( ..you guys are aware of these guys?: http://www.gpgpu.org/developer/ http://www.cma.uio.no/conferences/2004/gpu_workshop.html http://www.sintef.no/static/AM/gpu/ http://www.sintef.no/static/AM/gpu/webreferences.html -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
