I've implemented a terrain texturing algorithm described in the
chapter in the Orange Book about RealWorldz, where a 3d texture has
its z-component set by looking up a value from an 8-bit altitude/
gradient map. The code works, but for mipmapping...
The problem is that the Z axis of my 3d texture, when mipmapped,
collapses from ( in my case 4 to 1 ) levels by the second level of
E.g., if my 3D texture's 512x512x4, the reduction looks like:
I know that this just is how mipmapping works, and I accept that, but
the results are hideous! You can't see any texture variations in my
terrain for anything beyond a short distance from the camera.
Obviously, when bringing the camera close, it looks like what I want.
Here's a couple screenshots to demonstrate my point:
With mipmaps disabled: http://zakariya.net/shamyl/Screenshots/
With mipmaps enabled: http://zakariya.net/shamyl/Screenshots/
You can clearly see different textures when mipmaps are disabled, but
I get the ugly aliasing effects which mipmaps are designed to avoid
in the first place, so that's unacceptable. And when mipmaps are
enabled, I see the muddy mixture of my four original textures.
My question is if there's a way to bias mipmap generation for 3d
textures such that the reduction would look like so:
E.g., reduction along S & T, but not R.
Is there any way to do this?
I know I can simply drop 3d textures and use GLSL to look up from 4
distinct 2D textures, but the 3D texture approach is so nice, clean,
and most importantly scalable. Not to mention that the color plates
in the Orange Book didn't seem to have the ugly artifacting that I'm
"fodder for aggressive meta-lampoonery"
-- From a review on a mediocre episode of _The Simpsons_
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden