Hi!
Can anyone tell me how to avoid blinking the texture in a .glb model?
Do not overlap. Increase position.y of the grass/sand planes slighty.
1 Like
That looks like you have faces very close together. As your camera distance increases, the effect gets worse due to the floating point issue. Simply push the face out a little more in the model.
2 Likes
That the model can be fixed is understandable. But what about the code? I remember there was a similar example in the documentation. But apparently it was erased by a new viewer. Or was it not about that?
1 Like
Try this? greenGrassyPlaneMesh.position.y += 0.01
3 Likes
Thank you, it could probably help. But I have too many meshes to pick them all up. Apparently, I’ll have to get into the model itself after all. It won’t affect the performance then.
Oh, this does not sound too good 
Maybe you could iterate over all meshes and compare their position.y. Then, you probably will find meshes with the same position.y, right? That is when they flicker.
From there, make sure they really overlap (mesh.getBoundingInfo()). Then, I would think, you can order meshes by surface area. Smaller meshes probably sit on top of larger meshes (otherwise the smaller meshes would be hidden under the largers ones).
Does this make sense?
Definitely alter the model, this issue is scalable. Here’s a playground for you to simulate offsetting a plane and camera:
The following causes the “z-fighting” artifacts:
- Distance between facets being small
- Camera distance from facets (the greater the distance, more precision loss)
Usually when your camera is so far away, these facets get so small, you may not actually notice. LODs may also come into play if you have a huge “map”. When I’m building models and know there is a high possibility of z-fighting (such as texture decals or text as geometry) I would always be a bit generous of increasing the offset. Generally you should understand the ultimate scale of your models and appreciate offsets while placing assets.
3 Likes
Cool stuff, thanks for the link!
1 Like
If I had thousands of meshes, I probably would have done so, thanks for the advice! So I guess I’ll do it manually)
1 Like
You can use rendering group ID, if you know that some 3d object under another - just divide objects by groups - this gives you more reliable control of which objects to render in front without needing to physically offsets the objects.
Of course, it is inconvenient that we need to put only one object in the background, but all the others need to be assigned a group higher than it, and the camera position also needs to be taken into account. So in complex scenarios, of course, it is probably easier to move objects away from each other, but this can lead to serious distortions.
I would develop a system for redefining rendering groups, without shifting objects.
What do you mean by “use rendering group ID”? Can you provide a link to the documentation page?
If this means not showing objects that flicker, then it won’t work that way. Because both the upper objects and the lower ones are partially visible.
Here:
It works similar to z-index in html/css for layers.
1 Like
This is the best way to correct 3D models which were not done correctly 
1 Like
It’s an interesting thing, I didn’t know, thanks!
It’s just that my model is a little more complicated.
The devil will break his leg there) It’s easier to manually sort it out.
And apparently it’s not for ArcRotateCamera. A great thing for magicians and thimblers.
Guess where the balloon is? ))
Babylon.js Playground
2 Likes
Haha, yes, as I say - you need to put in background 1 ground object but you need setup rendering group for all others… ahha lol, great game haha
1 Like