Mipmap transition distance.

Problems building or running the engine, queries about how to use features etc.
Post Reply
User avatar
ChocoboInbreeder
Kobold
Posts: 38
Joined: Thu Jun 30, 2005 10:55 pm
Location: Boston, MA

Mipmap transition distance.

Post by ChocoboInbreeder »

Hi,

So, my mipmap transitions seem to happen way too agressively, and textures get too blurry too soon. Overall, worse than it should be without anisotropic filtering. However, I can't for the life of me figure out how to get the mipmapping transitions to occur further away either through the api docs or the trusty forum search. The transitions are normal in other 3d apps, so it doesn't seem to be a driver setting issue. Note that I don't mean the lod bias between material transitions. Can anyone point me in the right direction?

Much appreciated,

-Eric

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

You can't control this, it's built into the hardware. Use trilinear or anisotropic filtering to reduce the effect.

Remember that since isotropic mipmap filtering compares the projected screen size of the texels equally in all directions, tris at acute angles to the camera (like floors and walls parallel to the camera direction, unfortunately) will drop mip map levels faster since the texels get squashed more quickly in one direction when looking 'into' the screen. Anisotropic filtering removes this problem by compensating for the triangle angle to the camera. This is most obvious when running Demo_BSP and pressing 'T' repeatedly to cycle through the filtering options. There really is a big quality difference when aniso kicks in.

User avatar
ChocoboInbreeder
Kobold
Posts: 38
Joined: Thu Jun 30, 2005 10:55 pm
Location: Boston, MA

Post by ChocoboInbreeder »

Thanks for the response Sinbad. I was afraid that would be the answer.

I was wondering though. I thought I had seen certain apps "control" this to an extent. Are they tinkering with the projection matrix, using the graphics card drivers in some way, or is some combination of filtering and anisotropy just fooling my eyes into thinking that the transition still exists but is just further away?

Thanks.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

They're just making good use of filtering (even trilinear hides the transition better), using high resolution textures, choosing their textures well, and possibly using custom mipmaps (DDS). In any case, it's not distance directly that determines the transition, it's the screen size of a texel. Therefore the larger the area that the texture is stretched over, the further away the geometry can be before a mipmap transition happens.

User avatar
ChocoboInbreeder
Kobold
Posts: 38
Joined: Thu Jun 30, 2005 10:55 pm
Location: Boston, MA

Post by ChocoboInbreeder »

I was finally able to find the functionality that I was looking for (mipmap/texture lod bias is how I should have described it, since I don't actually want to change the distance between transitions but rather the overall bias), and I was wondering if it's actually exposed at all by ogre.

I've pasted some links with descriptions of the functionality and the actual OpenGL and Direct3D calls to set it accordingly.
http://oss.sgi.com/projects/ogl-sample/ ... d_bias.txt
http://www.gamedev.net/community/forums ... 1&#2312237
http://www.microsoft.com/games/trainsim ... vanced.asp
http://xengine.sourceforge.net/docs/cla ... DBias.html

So basically, Mipmap lod bias is exactly what I want to change, and it seems to have been done before. Ideas anyone?

Thanks!

-Eric

User avatar
:wumpus:
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3067
Joined: Tue Feb 10, 2004 12:53 pm
Location: The Netherlands
x 1

Post by :wumpus: »

Yeah, it's not currently exported as a material attribute, but I guess you could add it to texture unit state. Provided it's both supported by D3D and OpenGL, of course.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Ah, ok - I'll put this on the Dagon list then.

User avatar
ChocoboInbreeder
Kobold
Posts: 38
Joined: Thu Jun 30, 2005 10:55 pm
Location: Boston, MA

Post by ChocoboInbreeder »

Excellent! I may try to hack together something in the meanwhile, but it's nice to know it'll be supported officially at some point soon.

Thanks guys.

-Eric

User avatar
vastor
Halfling
Posts: 62
Joined: Wed Jun 08, 2005 10:23 am
Location: Germany

Post by vastor »

has this feature been implemented already?
job: coder
project: twilight
Twilight Website

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

No, it got bounced to Eihort due to lack of time.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

I just committed an implementation of this to Eihort.

User avatar
AekMuldoon
Halfling
Posts: 74
Joined: Mon Sep 25, 2006 3:44 am
Location: Perth, Australia
Contact:

Post by AekMuldoon »

This is a good feature for us as well, as our artists are accustomed to tweaking the LOD bias to get the best results on different display devices

Post Reply