Easy way to get mip level used when sampling a texture (ps3.0)

Started by
7 comments, last by Rompa 16 years, 11 months ago
Hey all, I'm wanting to render colours based on the mip level used when sampling a texture, blended with the texture so I can determine which textures are too large and which are potentially too small. I know I can modify the textures at load time to have these colours, but its not something I can toggle on and off like a pixel shader. I guess I'm supposed to use the ddx and ddy intrinsics and it will depend on the size of texture and number of mip levels, but I'm not sure of the details. Has anyone got any specific pointers on how to calculate the mip level that may help? Thanks!
Advertisement
Bump. So no-one knows how to do this?
I would have avoided to post this but since no one goes for it, here's my weak opinion.
IMHO you cannot.
On GPU GEMS 2 chapter 28 they used a special calibration texture for this. If there would be another way on current hw I'm sure they would have used it. This provides coherent results with actual texturing and doesn't look tremendously complex to implement.

Previously "Krohm"

If this is the case, then what use is tex2Dlod where you specify the lod manually (except for trivial cases)? I appreciate you taking the time to respond.
Mh, I think I have misunderstood something here.
I believed you wanted to "guess" the mip slice being used.
For rendering colors, simply using derivatives will cut it in most cases but I'm not really aware of the involved issues with different poly orientations, edges and movements in a dynamic scenario.
A calibration texture takes very little. I'm not sure it's a good idea to replace it with derivative instructions - you end up switching render mode anyway, I don't see much good reasons to not change an extra texture and go with lower shading models.

I am rather sure tex2dlod isn't really meant to be used in "standard" texturing (I originally believed you was searching for a function which returned the lod as a pass-out or return value) - i believe it was meant to be used with other effects like render-textured-reflections on a variably-bumpy surface or stuff like that.

Previously "Krohm"

I'm essentially looking for a function or snippet of code to give me the mip level of a particular texel. A calibration texture only works, as far as I understand it, when the resolution of the calibration texture exactly matches that of the one used in the scene (otherwise the mip levels will differ). Of course, the easiest thing is to tint each texture, as its loaded from disk, with the mip level colour but this can't easily be toggled on or off and will make loading take longer. I was hoping for a more dynamic solution. Seeing that no-one seems to have an answer I'll have to go for the texture solution :-( Thanks for your suggestions.
A separate texture does seem like a good option. Assuming you're mainly using standard texture sizes (powers of 2), you just need one coloured texture per size, and to sample and blend it with whatever texture you're using for the object.
Surely this is a debug-only feature? If so, production usage won't have to worry about increased memory usage or loading times incurred by manually tinting the mip-slices..?

This code in ATI's 'ParallaxOcclusionMapping' sample in the DirectX SDK might be of interest:

float4( dxSize, dx ) = ddx( float4( fTexCoordsPerSize, i.texCoord ) );   float4( dySize, dy ) = ddy( float4( fTexCoordsPerSize, i.texCoord ) );                     float  fMipLevel;         float  fMinTexCoordDelta;   float2 dTexCoords;   // Find min of change in u and v across quad: compute du and dv magnitude across quad   dTexCoords = dxSize * dxSize + dySize * dySize;   // Standard mipmapping uses max here   fMinTexCoordDelta = max( dTexCoords.x, dTexCoords.y );   // Compute the current mip level  (* 0.5 is effectively computing a square root before )   fMipLevel = max( 0.5 * log2( fMinTexCoordDelta ), 0 );
They use it to scale between POM and Normal Mapping - effectively extending the Mip-Map LOD scheme to include the pixel shader computations. A very nice trick I might add!

Not entirely sure if it'll identify the exact level as you want it as their main shader doesn't interpret the results in this way. Would be worth checking it out - including the rest of the .fx file as there are numerous other references to the fragment I included above...

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

Thanks Jack, very interesting. Sorry 'bout the late reply.

This topic is closed to new replies.

Advertisement