I got a problem with flickering in my Babylon.js application. I made an example in https://playground.babylonjs.com/indexStable.html#B7Q62A#1. It contains of four meshes created from “.positions” and “.indices”.
The “Red T” (one of the meshes) and the “Black T-like” mesh will flicker when moving the camera, Both of them intersect the third “Plate” mesh, but the coordinates of the red and black meshes are clearly, but very few, on top of the top edge of the Plate-mesh. The fourth mesh amplifies the problem, Without it, the problem will not occur (sometimes) or will occur at greater distances (sometimes) or does not have any effect at all (sometimes).
These mesh’s data came from a foreign tool: original the model was an fbx file which was converted to json-data using the autodesk fbx sdk. So I do not have any influence to the coordinates in “.positions”
If I move the camera close to the model, everything looks fine - no flicker. When moving away, at some point flickering starts. I think, it’s a kind of z-order fighting due to numerical inaccuracy. But i do not have any idea, how i can fix the issue.
I’m sorry, if this question was answered before, but I did not find anything that solved my problem.
- use logarithmic depth buffer
- played around with camera.min?/max?
So I kindly want to ask you for some help…
Thank you in advance.
no worry we’ve got you covered
(You can use zOffset on material to fight depth fighting)
Thank you for your help.
Can you please explain in very short, what zOffset on a material is actually doing? Is it adding the material deping zOffset to the Mesh’s or face calculated depth Information? Or is it just used for a kind of logical sorting of faces with same depth?
What value must zOffset have for my position values ? Makes a zOffset of 0.001 any sense or is it an integer value?
I’m sorry, at the Moment your modified example is empty for me, therefore I’m asking this question.
Thank you again.
The zOffset is literally an offset you add the each pixel to help fixing depth fighting issues
The value is a float in the range of cam maxZ-minZ
Unforunately, in my mind, materials zOffset is not a solution for me. The scenes we want to show are triangulated CAD models. I do not have any idea, wich material is applied to what surfaces. If I use zOffset, models wich look perfect without the use of z-Offset, will look very broken. That ist, because the materials zOffset of a surface that should be in the back moves that respective surface accidently on top.
@Deltakosh - I deleted my post that you replied-to… because it was no help. But thx for info about zOffset, just the same.
I made a few playgrounds… pg #7 being my latest… and not helpful. Good flickering, though. I did some engine anti-alias tests in line 29. Nothing learned. Also added some normals in lines 12 & 17… no affect (I’ll try anything).
ok, on-with the topic.
Then you can think about increasing depth precision by reducing the distance between camera.minZ and camra.maxZ.
The smaller the distance the better. like minZ = 1 and maxZ = 100 will give you dead precise depth values
Hi there, I am having the same flicker issue when I import my meshes. I wanted to ask did you find the solution for that?
See the last answer from @Deltakosh.
You can also use the zOffset property of the materials to help with z-fighting.
Sorry, unfortunately I did not find a true solution.
When you find one, please let me know
ok, Actually I found one for me I made my camera’s minZ to 0.1. It solved my issue.
The gltf model I imported also encountered this problem. The material is PBR
@qqqzhch just change camera minz and maxz and it would not happen, this is why I create the default camera after scaling in your other post. would be great to keep the conversation there.
After I import gltf, I create environment and sky boxes and lights, but there are still sawtooth and flicker. Should Minz and maxz be changed as small as possible?
I have tried zoffset, maxz and Minz, but it still doesn’t work. After the model is changed into Texture, the flicker in the distance is more obvious
minZ must be as high as possible. Try 0.1 (or more) for eg.
The effect is limited and cannot solve the problem
Could you change the model to not have two planes fighting ? this would be by far the simplest