   Texture shimmering (coordinate accuracy, not sampling I don't think)...
  This is conceptually a bit of a difficult problem to get across, so please bear with me!Given a luminance map of aribtrary size (let's assume for the sake of argument it's square POW2) being used as a texture, how can I prevent shimmering and accuracy artifacts when only a part of the map is rendered over a height-field of arbitrary resolution?  Here's a diagram of the general setup I'm talking about here:http://i39.tinypic.com/1sfdia.jpgThe problem is as follows:Imagine the luminance map as a rectangular grid of dimension 1, 1 (coordinates go from 0 to 1 on both axis).  Now imagine a zoom rectangle on top of the luminance map.  This zoom rectangle is used to generate a height-field of some other resolution.  If you move the zoom rectangle, you regenerate the height-field Z and texture coordinates (the height-field resolution remains the same, so you don't need to modify the actual x, y coordinates of the field, which means whatever the zoom rectangle is you always get a grid the same size on screen). If the height-field resolution is different to the luminance map resolution and given that the zoom rectangle can be placed arbitrarily between 0 and 1, with an arbitrary width on both axis, texture coordinate interpolation accuracy seems to be limited.  In other words when you generate the coordinates, certain parts of the map will "shimmer" as you move the zoom rectangle around.  This is not the same "shimmer" you get from min/max artifacts in texture space, it's caused by the actual coordinates rather than the sampling I think, and tends to be worse where luminance gradients are greatest (the triangles there are bigger I guess, so it's more noticeable).  Sometimes the shimmer does not happen when I fiddle around with the size of the zoom rectangle.  In the monkey-typewriter school of debugging, setting my zoom rectangle to give it a width of 0.5, with a luminance of 2048x2048 and a height-field resolution of 1024x1024 vertices, moving the zoom rectangle around by 1.0 / 2048.0 per frame, gives no shimmer.  When the zoom rectangle has a width of, say, 0.9, I get shimmer.Here's an example of the shimmering in action.  The video below show the software slowly moving the zoom rectangle (width 0.9, 0.9) across the luminance by 1 / 2048.0f units per frame.(shimmering version)This doesn't happen if, say, the width of the zoom rectangle is 0.5, 0.5:(non-shimmering version)I'm thinking I may have to constrain the zoom rectangle to certain values related to the luminance texture size and the height-field resolution... but I'm not sure how they relate.  If anyone understood what the problem I described above actually is, I would appreciate your thoughts!Thanks for listening...Oh and if anyone knows how to embed pictures, or links in gamedev forums posts, I'd love to know the secret.....   
If you're using D3D9 or XNA, you've probably run into the problem of Directly mapping pixels to texels. That linked article provides some more information, but it basically comes down to having to add 0.5 / textureSize.xy to your uv coordinates to sample the center of the texels instead of the edges. If this is indeed the problem, the shimmering is caused by precission issues where the sampler will eratically switch between texels on either side of the edge.;  You mean this?Vertex VERTEXMAIN(float4 xyz: POSITION, float2 uv: TEXCOORD0){   Vertex Output;   Output.Position = mul(xyz, MyWorldViewProjection);   Output.Position.x -= 0.5;   Output.Position.y -= 0.5;   Output.uv = uv;   return (Output);}I tried it and it didn't make any difference, i.e. it still shimmered.  I think maybe I need to align the u, v with the luminance value (1 / luminance.width), or similar.  I'm groping slowly towards the answer (monkey typewriter style).   ;Quote:Original post by BurnhardYou mean this? ...It comes close, but I think that's not entirely correct. I can't be sure without seeing your entire rendering code and shader, but you seem to be offsetting the post-projection position which should be in the range [-1;1], so a 0.5 offset there shouldn't be helping much... In fact, I'm surprised this isn't causing any problems.Conceptually offsetting the position is a bit tricky in my opinion. It does work as expected most of the time, but I personally found offsetting the UVs more straightforward to wrap my head around. ;  So I need to offset pre projection? - i.e. do a world/view transform, then offset, then a view/screen transform?   ;hmmm clearly not - that just shifts the entire object ;).  So, how do you do it with the u, v then?  My pixel shader is dead simple...   ;  You probably want to minus 0.005 * width or height in pixels from your texture coords, means passing in the texture size or using a fixed value if you know all your textures sizes are the same.   ;  Width or height of what? The texture?  I tried that and it still doesn't work.  I also tried clamping the zoom rectangle to 1 / 2048.0 (width of the luminance texture).  I think I probably have to take a different approach to solving this problem entirely.  Instead of keeping a fixed height-field resolution regardless of zoom level, I have to upload the entire height-field to the GPU (potentially 2048x2048 of them - that's 96mb of vertex data, which I can decimate of course) and then fiddle about with my index buffer to only render a square patch of it (scaled and translated to the centre appropriately of course).  That way the texture coordinates are fixed and never change.  The upside is it's quicker to modify the index buffer and a few variables to render the patch than it is to modify the vertex buffer as I am at the moment.  The downside is that as you zoom the patch the geometry resolution gradually decreases.   ;What I meant was that you take your base texture coordinates (the UVs) and add 0.5 / width to U (horizontal) coordinate and 0.5 / height to V (vertical) coordinate. You need to use the width and height specific to the texture you are sampling, so if you're sampling from your 2048x2048 luminance texture, you'd use 0.5/2048 and for your 1024x1024 height field you'd use 0.5/1024. You could do this in your pixel shader and, as detailed in the linked article, it serves to make the sampler sample the center of the texel instead of the edges, which may suffer from precission issues.However, this only applies when you're directly mapping texels to pixels and re-reading your original post, I'm starting to doubt that is the case in your scenario. Unfortunately I don't have any good ideas to offer on how to fix this (mainly because I only understand the scenario vaguely), so sorry if I sent you off in the wrong direction with my guess. It just seemed to fit the symptoms.;  Well, tried what you suggested and it still shimmers.... so I guess it's plan B :/.   