Jump to content
  • Advertisement
Sign in to follow this  
Narf the Mouse

Information on how to do texture LOD?

This topic is 2422 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm trying to do texture level of detail, as it seems like it would provide a substantial speed increase. However, about the only information I could find out there leads to this function declaration:
ret tex2D(s, t, ddx, ddy)
I have no clue how, why or what the "ddx" and "ddy" might do.

So - Any tutorials on texture LOD and what "ddx" and "ddy" do in that function?

Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Actually, the correct function would be

ret tex2Dbias(s, t)

where

float4 t = float4(tex0.x, tex0.y, miplevel, miplevel)

Haven't figured out how to correctly calculate the miplevel though, should be something with dividing the z-position of the pixel/texel in view-space, but didn't work for me. I'll keep my eye at this thread ;)

Share this post


Link to post
Share on other sites
Texture LOD is automatic as long as the texture has mipmaps. You just use tex2D in your shader, and the correct miplevel is chosen by the hardware based on how large the texture is when mapped onto the screen. So as a triangle with the texture gets further from the camera, smaller mip levels will be used which reduces the amount of texture data that has to be read from memory. This also prevents texture aliasing, since the lower mip levels are prefiltered. You can bias the mip level if you want either using sampler states or by using tex2Dbias, but doing so can lead to lower quality or performance. Using a positive bias will cause a lower-than-normal level to be used which will make the texture look unusually blurry, while using a negative bias will cause texture cache thrashing as well as aliasing artifacts (but can make the textures appear sharper). You can also completely override the mip level using tex2Dlod or tex2Dgrad, but generally these are used for special cases where normal mip selection doesn't work.

Share this post


Link to post
Share on other sites

Haven't figured out how to correctly calculate the miplevel though, should be something with dividing the z-position of the pixel/texel in view-space, but didn't work for me. I'll keep my eye at this thread ;)


Basically it takes the X and Y gradients (derivatives) of the texture coordinate, and uses that to figure out how quickly the texture coordinate is changing in screen space. Then using the size of the texture, it can figure out the mip level that best matches the number of pixels that the texture will cover. So essentially larger gradients leads to a higher mip level being used (where mip level 0 is the full size of the texture). If the size is different in the X or Y direction, the larger gradient will be used which can result in blurriness at oblique angles. If anisotropic filtering is used, then for those cases additional samples are taken along the direction with the larger gradient.

In cases where pixel derivatives aren't available (for instance, in a vertex shader) it is common to use a metric based on Z depth to select a mip level. But it's not usually done in pixel shaders for "normal" textures.

Share this post


Link to post
Share on other sites
[quote name='MJP']Texture LOD is automatic as long as the texture has mipmaps. You just use tex2D in your shader, and the correct miplevel is chosen by the hardware based on how large the texture is when mapped onto the screen.[/quote]

I tried it out, but somehow it isn't working as expected. Well it does work but it looks kind of ugly:

t9vojicv.jpg

zoomed in:

ovqidu9y.jpg

without mipmapping:

kr7u9s6c.jpg

I quess you shouldn see the effect of mipmapping on such small distances? Here is my samplerstate:

sampler DiffuseSampler = sampler_state
{
Texture = <DiffuseMap>;

MagFilter = Linear;
MinFilter = Linear;
MipFilter = Linear;
};


Anything obviously wrong?

Share this post


Link to post
Share on other sites
Those results look perfectly normal for trilinear filtering. The issue with the bluriness on the sides of the cube is exactly the problem I mentioned before about oblique angles. To fix it, you can enable anisotropic filtering. You do that by setting the min filter to "Anisotropic", and then setting MaxAnisotropy to either 2, 4, 8, or 16. Higher values will have higher quality, with more performance cost.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!