Sign in to follow this  
skyemaidstone

3D Shadow Map Jiggling/Shimmering

Recommended Posts

Hello!

I've read MJP's great post on CSM and jiggling/shimmering and it seem to be the exact problem i'm having (I realise it's from 7 years ago or so but it seems very relevant)

I was hoping someone you had time to help me solve it or point me in the right direction. I feel like i've learned the concepts and read everything I can find on the subject but I just can't seem to solve it. I'm more than happy to pay someone for their time, I just want this solved so I can forget about it because my game is at a fun stage were I can really start adding all the good bits (combat and spell effects, dungeons, swords etc). 

Anyway..

Here is a youtube video of the problem. I turn on the render target view about halfway through so you can see the shadow map top right. I've turned off all but the closest cascade for now and stretched it rather far so the quality isn't amazing but it shows the jiggling problem nicely.

Please help :)

My method for making the projection is pretty short and is very similar to MJPs post:

        public void GenerateCSMOrthoSliceTS(float pNearClip, float pfarClip)
        {
            Vector3[] frustumCorners = new Vector3[8];

            Matrix mCameraViewProj = _Camera.CameraView;
            mCameraViewProj *= Matrix.CreatePerspectiveFieldOfView(MathHelper.PiOver4, _Camera._aspectRatio, pNearClip, pfarClip);
            BoundingFrustum oCameraViewProjFrustum = new BoundingFrustum(mCameraViewProj);

            frustumCorners = oCameraViewProjFrustum.GetCorners();

            Vector3 frustumCenter = new Vector3(0, 0, 0);
            for (int i = 0; i < 8; i++)
                frustumCenter += frustumCorners[i];
            frustumCenter /= 8;

            // don't bother recaculating the radius if we've already done it
            if (radius == 0)
                radius = (frustumCorners[0] - frustumCorners[6]).Length() / 2.0f;

            Vector3 eye = frustumCenter + (SunlightDirection * radius);
            ShadowLightPos = eye;
            Vector3 ShadowLookAt = frustumCenter;

            ShadowLightView = Matrix.CreateLookAt(eye, ShadowLookAt, new Vector3(0, 1, 0));
            ShadowLightProjection = Matrix.CreateOrthographicOffCenter(-radius, radius, -radius, radius, -radius * 8.0f, radius * 8.0f);
            ShadowLightViewProjectionMatrix = ShadowLightView * ShadowLightProjection;

            if (_nojiggle)
            {
                float ShadowMapSize = 4096.0f; // Set this to the size of your shadow map
                Vector3 shadowOrigin = Vector3.Transform(Vector3.Zero, ShadowLightViewProjectionMatrix);
                shadowOrigin *= (ShadowMapSize / 2.0f);
                Vector2 roundedOrigin = new Vector2((float)Math.Round(shadowOrigin.X), (float)Math.Round(shadowOrigin.Y));
                Vector2 rounding = roundedOrigin - new Vector2(shadowOrigin.X, shadowOrigin.Y);
                rounding /= (ShadowMapSize / 2.0f);

                Matrix roundMatrix = Matrix.CreateTranslation(rounding.X, rounding.Y, 0.0f);

                ShadowLightViewProjectionMatrix *= roundMatrix;
            }
        }

 

Edited by skyemaidstone
not really dx11 specific

Share this post


Link to post
Share on other sites

kinda looks like a bias issue. the depthmap is of limited precision, so shadow acne (shimmering), or peter-panning (shadows that are biased too much, and become dis-attached from the occluder)  are usually related to biasing.

What value do you have in your second pass pixel shader that serves as the bias? Maybe try toggling that a bit, and see what it gives you, it can be very scene dependent.

Share this post


Link to post
Share on other sites

Yes I thought that too at first so i played around with a depthbias (not going as far a slope based) but it still visibly moves/jiggles when I move or rotate the camera. Adding a bias does stop the wall (for example) flicking in and out of shadow but not the edges of the wall from shimmering. 

I've removed that (and my filtering too) for now to try and narrow down the problem.

 

Share this post


Link to post
Share on other sites

Ok I also tried simply adding a flag to stop recalculating the shadow light view and projection when I set it to true - I was thinking if it's a texel snapping issue then that would stop the jiggling/shimmering (although obviously only the area of the projection when it was last created would be shadowed). I can see my flag working because the shadow render target now remains fixed when the flag is on. 

But the jiggling remains even with that. Maybe I'm doing texel snapping and using a bounding radius correctly but the problem lies elsewhere. Do I need to some kind of rounding on the camera position for the calculation of shadows or something? I'm a bit stumped again. Or maybe my texel snapping just isn't following what MJP's post suggested somehow.

Anyone have anything else I can try or any other ideas?

Share this post


Link to post
Share on other sites

I looked through your code, and so far it seems okay. So I'm not sure where the issue is.

Do you ever use ShadowLightProjection again anywhere outside of the code that you posted? Because you've applied the rounding offset to ShadowLightViewProjectionMatrix, but not to the matrix containing only the projection.

Share this post


Link to post
Share on other sites

You're spot on. For some reason I was redoing ShadowLightViewProjection = ShadowLightView *ShadowLightProjection just before I passed it to the shader. Which explains why it made no difference entirely.

I thought it was finally solved... but no, although when I turn the snapping on my shadow mapping changes a little (so it's doing something). But it still jiggles around a lot.

Curse of the Jiggles (The green true false top left is texel snapping enabled or not).

I feel like I must be doing something else stupid elsewhere then.

When render the models to my map/rendertarget I can just use the normal way i'd render a model can i? ie Make a local matrix for them using their scale, rotation and world position then use that * the shadowLVP.

And when I look up the position in my pixel shadow i just use (this is the basic version with no filtering to keep things simple until I solve this):

float4 lightScreenPos = mul(worldPos, ShadowLightViewProjection);

//find sample position in shadow map
float2 lightSamplePos;
lightSamplePos.x = lightScreenPos.x/2.0f+0.5f;
lightSamplePos.y = (-lightScreenPos.y/2.0f+0.5f);

float realDistanceToLight = lightScreenPos.z;

distanceStoredInDepthMap = tex2D(ShadowMapSampler, lightSamplePos);
shadowCondition = distanceStoredInDepthMap <= (realDistanceToLight - 0.00035f);
             

Does that all make sense or do I need to apply rounding somewhere else too?

Edited by skyemaidstone
typo

Share this post


Link to post
Share on other sites

Yeah, you don't need to account for the rounding and snapping when sampling the shadow map in your shader . The shader code that you've posted there looks fine to me, as long as you're always using an orthographic projection for your shadow map projection.

Perhaps you should try visualizing the resulting shadow map in real-time. As you move the camera, the geometry should always "snap" a full pixel at a time. If you see any crawling edges that indicate sub-pixel movement, then somehow things aren't snapping correctly when you render to the shadow map.

Share this post


Link to post
Share on other sites

Thanks,

I found an old test harness for trying out shadows and lights on my models in an old version of my engines. The shadows are rock solid for point lights or directional . So I've introduced this jiggling somehow, somewhere along the line

At least I know where to look now. 

Thanks for your help guys.

Share this post


Link to post
Share on other sites

Well texel snapping is working great. Rock solid shadows at last (this is just one cascade)

No more jiggling

After much fiddling and comparing my test harness the only difference seemed to be the huge numbers my game was using for the coordinates in game. If i reduced everything by say 100 it all looks the same but the shadows no longer jiggle at all.

I don't quite get why that is. Depth map precision? Is it because my huge numbers (the centre of my map was 50000,0,50000 and the bounds were at 1024000. My near/far clip were at 5, 200000.

I thought these kind of numbers would be ok in a 24bit depth map or is it because all the precision is near to the camera and you can't use those kind of high numbers?

I happy I fixed it in the end but I don't quite get why. Could someone explain it to me if possible?

 

Edited by skyemaidstone
typo

Share this post


Link to post
Share on other sites

Thanks again but what i'm asking is if the problem i was experiencing could be caused by using huge coordinates (and therefore causing a lack of depth precision). I have solution, i'm just trying to make sure understand it.

Thanks for the link. I will have a read of that in depth later tonight :)

Share this post


Link to post
Share on other sites
1 hour ago, skyemaidstone said:

the centre of my map was 50000,0,50000 and the bounds were at 1024000. My near/far clip were at 5, 200000

This may be very bad, yes.

Assuming we have 6 digits of floating point precision, the next possible number from 50000 is 50000.1

If you have a ratio of 1 unit == 1 meter, then you have not enough precision to for small details at the scale of centimeters, but you would have had enough if you center your world to the zero point.

Even if you have a ratio of 1 unit = 100 meters, you still waste precision. Assuming your world's bounding box corners the zero point, you waste one bit (because the sign is unused). If the world bounding box is far away from zero however, you do it very wrong: The larger the distance, the bore bits get wasted for nothing.

So you should have your origin close at (0,0,0) in any case. I'm no floating point expert, but it is said the best precision is between -1 and 1, so you should also use a scale that makes sense here, e.g. 1unit = 1meter for FPS or 1unit = 100meter for large open world. (for very large open world like space game you may need even need to translate the whole world so the player is at the center to avoid  precision issues).

... not sure how this affects your graphics issues, but you can try out various scales and center offsets.

 

 

 

Edited by JoeJ

Share this post


Link to post
Share on other sites

Sorry a couple more questions.

How is reversing the depth generally done? Can i literally just set my cameras far/near in reverse (for the projection matrix) when rendering everything (including models to shadow map)? Do i need to do something different with storing the depth in the buffer? I'm just writing out z/w for everything right now (except linear for mist particles)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this