On Mon, 29 Nov 2004 12:53:43 -0600, Curtis wrote in message 

> 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?:

..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

Reply via email to