Andy Ross writes: > 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.
My understanding of systems that impliment these basic ideas is that step 1) is to give up the idea of seamless, non-blurry textures in the distance. Every system I have seen blurs the textures excessively as you go further in the distance ... that also yields a corresponding texture blurry->sharp "popping" effect as you get closer to a new area. And because the system typically has to do this stuff in a low priority thread to keep up rendering rates, you can see by the popping that the detail texture loading often lags and doesn't pop into full detail until you are right over it. Just for fun, sit down and assume 1 meter texture resolution, assume you are flying at 500 kts, and assume something like 20 mile visible radius. Now crunch the math on how much data you have to flow in from your HD per second or per frame, and you will see that it is a *lot* of work. There is a reason that high end graphics computers often have 4 or more cpus, multiple scsi busses, and all sorts of other fancy, high bandwidth gizmos (and cost upward into the millions.) PC's just can't compete in this arena (yet) which is why sgi hasn't completely tanked (yet). :-) > > 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. Yes, good luck on doing the rendering in real time with a single CPU. :-) If you worked up a well functioning demo, I bet it would be quite popular and get you large quantities of geek points. Everything's possible, and one of the goals of FlightGear is to provide a forum and a structure where people can develop and plug in new ideas to see how they work, without needed to also develop the entire application. It's easy for us to sit here and say it can't work (at least not very well), but the hard headed ones will forge ahead anyway, attack the problems and issues head on, and a few of those people will find successful solutions and a place in the geek hall of fame. :-) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
