Going mad over texture addressing

posted in On the path with a ramblin' man

Published January 18, 2008

Right, I've had it with bloody look-up textures.

I've been staring at debug output for hours this evening (yes, I know its Friday night [headshake]) and its not making any more sense.

I seemed to get a good lead on texel addressing though. They moved the texel 'centre' with D3D10, but I thought that should really match up fine with my CPU-generated look-up texture.

Then I hit on some obscure fringe cases where it was wrapping around and pulling in completely incorrect values. Clamping appears to have eliminated those, but the overall result is still not sufficiently good for my liking.

My first task tomorrow is going to be to rewrite my look-up texture code to use render-to-texture instead. I can easily rewrite my shader(s) so that the exact same code is used in the non-lookup versus the lookup paths, and if that still generates different results then I think I might actually scream [smile]

Previous Entry Untitled

Next Entry Kick me. Please.

0 likes 3 comments

Comments

Jason Z

Yes, render to texture has always given me good results for replacing pixel shader functions. Even so, it shouldn't be too difficult to actually generate the textures on the CPU - I've not delved into the details on DX10 texturing, but a texture is a texture, right?

Good luck!

January 18, 2008 08:07 PM

Ysaneya

There are two other tricks you can use to debug your lookup tables, but maybe you've already tried them:

- change the resolution of your lookup table to something incredibly big (4096) or incredibly small (16), and check how the incorrect results you get get affected. If this is indeed a texture adressing problem, going to larger resolutions should make the problem become less noticeable, as 0.5/16 is much bigger than 0.5/4096.

- set the filtering to closest/none (no filtering) and check that you now get the correct (but blocky) results..

January 19, 2008 06:27 AM

LeGreg

They didn't change the "texel center", that's a common misconception.
The texel center is still at its expected position (first texel at half interval from coordinate 0) else mipmapping wouldn't work as well, etc.

What they did is change is the pixel center (in screen coordinates). If you're rendering without any form of supersampling, or centroid deviation, then your pixel center will be at a half integer value (it was at an integer value in d3d9).

That way if you have a 1:1 mapping, you don't have to do some extra math to match pixel center and texel center. (you still need to do the extra math for anything more complicated than a 1:1 mapping obviously, like a look-up table with interpolation for example).

LeGreg

February 13, 2008 03:19 PM

You must log in to join the conversation.

Don't have a GameDev.net account? Sign up!

jollyjeffers

Author

Going mad over texture addressing

Comments

jollyjeffers

Latest Entries

AWOL Update

Windows 7

SlimDX11 and stuff

Windows 7

Another stab at Manged DirectX?!

More Compute Shader Goodness

Improved LOD algorithm

Compute Shader seeded Terrain Tessellation

Compute Shader for Terrain Rendering

Two new YouTube videos

Going mad over texture addressing

Comments

jollyjeffers

Latest Entries

AWOL Update

Windows 7

SlimDX11 and stuff

Windows 7

Another stab at Manged DirectX?!

More Compute Shader Goodness

Improved LOD algorithm

Compute Shader seeded Terrain Tessellation

Compute Shader for Terrain Rendering

Two new YouTube videos

Reticulating splines