What is the best way to set camera's near plane as far as possible without clipping the scene?

I have a scene with flickering issues. Adjusting the near plane seems to be the best approach for fixing it. Hence, I want to set the near plane as far as possible so that it fixes the flickering but doesn’t clip the scene.

The best approach that I can think of is setting the minZ = nearest point to the camera. To search of the nearest point, I project several (100?) rays from the camera in different directions and compare all the picked points.

Is there a better way to appraoch this problem? What number of rays would be suitable?

How large is your scene? I have a scene with a maxZ distance to the skybox of 50k.
I set both minZ and maxZ for the cam view. Then, for the remaining flickering issues, I also work them from the material zOffset. This way, I have some planes that are offseted just the tiny-mini and do not flicker at any distance. Unless your scene is a lot bigger than mine, you should be able to fix it this way and not change it dynamically by casting hundreds of rays which I believe will also affect performance.

1 Like

Thanks for the quick reply! Its not an issue with scene size (whichi may be of variable size though) but the mesh itself. I have a box with negligible height which is flickering. Changing the material’s zOffset is not an option for me right now :frowning:

I’m not sure to understand the issue. May be you could share a PG?
Did you set a maxZ for the camera and what is your minZ value?
Clearly, the PG would be the best if by any means possible…

As @mawa mentioned a PG would be great, if you can share :slight_smile:

As in this scene, setting camera.minZ = 10 fixes the flickering, but it starts again once I zoom out. So, I just wanted to know if there’s a feasible way to dynamically adjust minZ as close to the visible scene as possible on every pan/zoom/orbit!

I do understand that there are better approaches to this problem (using plane / log depth buffer / is a 64bit depth buffer possible?) but wanted to investigate if dyanmic minZ could be a solution too.

Some ways to solve the problem and avoid z-fitghting:

  1. groundMaterial.backFaceCulling = true; - https://playground.babylonjs.com/#XXIZL1#1
  2. Use plane instead of the box since the height of the box is not seen anyway.
1 Like

groundMaterial.backFaceCulling = true seems to do the trick, thank you so much! Why does it work though, isn’t the cuboid’s front face still fighting with the cuboid’s back face?

that’s because your box doesn’t have enough depth when looked at from the camera.
Since you didn’t set a size, the default is 1 (BJS unit). Then you scale it to a value that makes the backface too close to the front face. The culling ignores the back face and this way, fixes the issue.
Another solution, since there’s barely a volume with a scaling of 0.0005 on unit 1, would be to create a plane as @labris suggested. If you want the tiny-mini offset volume at close range, you can use the material zOffset. The other solution is to make a cube with more volume so that the back of the cube does not z-fight with the front when viewed from the camera (minZ) and during depth calc. Something like this:

In fine, the choice is yours :smiley:

3 Likes

Awesome, thanks @mawa! These solution were really helpful :innocent:

1 Like