Ampere K. Hardraade wrote:
On June 7, 2004 09:56 pm, Curtis L. Olson wrote:
Mipmapping does this for you automatically. The system stores several
versions of the texture at reduced resolution. If the original texture
is 256x256, then the system will also build a 128x128 version, 64x64,
32x32, 16x16, etc. Then the driver selects the texture resolution that
best matches the screen resolution of each polygon it renders.
This is great news.
There are cases where this doesn't work as well as you'd like (nearly edge onWould you mind explaining what anisotropic texture means?
polygons get a much lower res texture than you'd hope for) but there are
often work arounds such as anisotropic texture filtering (which is
probably a driver option for most cards/drivers.)
Hold on, I'm right in the middle of ripping off all my toe nails and dipping my feet in paint thinner.
This is a slightly complicated thing to explain and I don't have the energy to really go into detail. I don't claim to be an expert here so my explanation is probably half fantasy and half my own imagination, but here is how I understand it at a conceptual level.
Imagine some triangle (part of the scene) that when drawn on your screen consumes about 4 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably pick the 4x4 pixel texture. This is a perfect match for the onscreen size of the triangle and gives you great visual results and minimizes any sort of texture aliasing. (Remember the horrible pixel swimming of MSFS 5.x and other early 3d video games? This is what mipmapping fixes.)
Now imagine some triangle (part of the scene) that when drawn on your screen consumes about 40 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably again pick the 4x4 pixel texture. But, this means that 4 pixels of your texture get stretched across 40 pixels of your screen which makes the result look really blurry.
I doubt this is how anisotropic texture filtering is specifically implimented in the driver, but conceptually, anisotropic texture filtering makes additional versions of your texture that are wide and short as well as tall and narrow. This way it can often find a much better match for most/many situations.
Now observe that when you view a runway it is almost always as you take off or land or taxi. This means it is almost always nearly "edge" on. These runway triangles end up being drawn short and wide on your screen which makes the runway texture blur out really quickly.
Try turning on anisotropic texture filtering in your driver (under linux/nvidia there is an environment variable to set.) You will find that your runway textures look *much* sharper and nicer ... you can probably now pick out the markings at the opposite end where as before they were probably a big blurry mess.
Here's a link, but it angles towards the technical side of it:
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