• 9
• 9
• 10
• 9
• 10
• ### Similar Content

• By lxjk
Hi guys,
There are many ways to do light culling in tile-based shading. I've been playing with this idea for a while, and just want to throw it out there.
Because tile frustums are general small compared to light radius, I tried using cone test to reduce false positives introduced by commonly used sphere-frustum test.
On top of that, I use distance to camera rather than depth for near/far test (aka. sliced by spheres).
This method can be naturally extended to clustered light culling as well.
The following image shows the general ideas

Performance-wise I get around 15% improvement over sphere-frustum test. You can also see how a single light performs as the following: from left to right (1) standard rendering of a point light; then tiles passed the test of (2) sphere-frustum test; (3) cone test; (4) spherical-sliced cone test

I put the details in my blog post (https://lxjk.github.io/2018/03/25/Improve-Tile-based-Light-Culling-with-Spherical-sliced-Cone.html), GLSL source code included!

Eric

• I am developing a mini golf game in Scenekit. I have applied dynamic physics body to the ball and static physics body to the grass surface and the brick walls show in this image.
Issue:
When I apply the force to the ball, the ball’s linear and angular speeds change as shown in the graphs.  The ball’s speeds don’t reduce to zero (so that the ball can stop) but remains constant after certain value.
Ball linear speed graph
Ball angular speed graph
Analysis Tests:
When I increase the values to both the rolling friction and the friction, the ball speed is reduced quickly but remains constant after certain value (similar to the above graphs). When I increase the values of the linear damping and the angular damping, the ball speed behavior is same as the point #1. When I set the gravity value to -9.8 m/s2, the ball’s linear speed remains constant after 0.1 m/s. If I reduce the gravity value to -5 m/s2, the ball’s linear speed remains constant after 0.05 m/s. The friction, linear friction, linear damping and angular damping are same throughout the motion of the ball.
There is 1 millimeter overlapping between the ball and the surface of the golf course.
Questions:
From the analysis test #3, I think the gravity is causing the constant ball speed issue. Is my assumption correct? If yes, how can I fix the issue? I can’t remove the gravity field as without the gravity field the ball will not roll along the grass and it will slide. Why the friction and the damping properties are not affecting the ball speed after certain value?
Are there any other physics properties can cause such issue?
From the analysis test #5, are there any chances that the ball is receiving upward push to correct the position of the ball?
Solutions:
If I increase the physics timestep from 60 FPS to 200 FPS, the issue is resolved. I am not able to understand how this change can fix this issue? After reducing the gravity value to -1 m/s2 and physics simulation speed to 4 (4 times fast physics simulation), the issue is fixed. Again, I am not able to understand how this change fix the issue? I would appreciate any suggestions and thoughts on this topic. Thank you.

• I'm having a weird issue with detecting a collision. I've tried everything I could find online but nothing seems to work. I have a brick object. It has a 2D Collider attached and I have also attached a 2D Rigidbody on it. I also have an EndScreen 2D Collider. The EndScreen 2D collider is tagged with "EndScreen". I am trying to detect when a brick collides with the end screen collider and simply print "game over" in the console.
This is my current code for this part of the program, it is attached to the bricks:
void OnCollisionEnter (Collision2D collision) { if (collision.gameObject.tag == "EndScreen") { Debug.Log("Game over"); } } Several things have happened depending on the set up. If I have the rigidbody 2D set as static, my ball object can still collide with the bricks, but I get no Log message. If I set it to Kinematic or Dynamic, I get absolutely no interaction between the ball and the bricks, and nothing when the bricks pass through the collider. I have tried to set the collider to a trigger and use OnTriggerEnter2D, no change. I have tried to put the rigidbody on the EndScreen object and tried to set it's body type to all 3 settings, no change. The only thing I can think of that I have not done is put the script on the EndScreen object and switch the tag to the bricks. The reason I have not done this is because I will have several types of bricks, some of which will have different tags.

Please tell me somebody can see what I'm doing wrong here, because I'm losing my mind over something I feel should be ridiculously simple. Thanks.

## 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

" rel="external">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.

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;
frustumCenter /= 8;

radius = (frustumCorners[0] - frustumCorners[6]).Length() / 2.0f;

Vector3 eye = frustumCenter + (SunlightDirection * radius);

if (_nojiggle)
{

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

}
}

Edited by skyemaidstone
not really dx11 specific

##### 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 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 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 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 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.

" rel="external">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;

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 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 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.

##### Share on other sites

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

" rel="external">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 on other sites
4 minutes ago, skyemaidstone said:

Could someone explain it to me if possible?

Read this excellent post by NVidia: Depth Precision Visualized (https://developer.nvidia.com/content/depth-precision-visualized)