I know what cause’s it. Does anybody know a fix for it? Just moving Objects further apart is totally impractical. If I have a player,car, house or any object sitting on the ground and I fly up in the air all I see are flicking objects on the ground. I can’t move them apart because they would have to be 30 BU’s above the ground for the flickering to stop. Is there a way to tell Blender to always draw one object behind another?
Try increasing your cameras near clipping point, having that too close can cause issues.
4 Likes
In my game I’m flying over large terrain, so my far limit is 10,000. and my near limit is just 1. I’ve tried many vaiations with the same Z fighting. I think default is .001.
Thanks for the suggestion. I just tried setting it out to 10, 20 and 50 BU’s and still have Z ifghting when i’m flying over. If you get down very low it mostly goes away. Is there a node that can control which material is drawn first?
Have you tried using an orthographic camera? It will remove the perspective, but see if that works.
Well thanks for the suggestion. Just trid it and I can’t see thru the sky dome to see the player and other objects. So I hid the dome but eveything is so distorted the game is unplayable in ortho.
I’m not sure if this is what Mattline mentioned, but I think Z-fighting can happen if the distance between the minimum and maximum values for the camera are too far apart. So, push them closer together (i.e. minimum of 1 BU and maximum of 100 BU). If you’re making a game where you never get close to the ground, then you can just push all game objects closer to the camera and make them smaller (in other words, fake it).
Otherwise, you might want to look into Python and using background and foreground scenes to prioritize drawing (i.e. make objects that are far away visible in the ‘furthest back’ scene, and make objects that are close visible in the ‘closest’ scene).
Orphographic mode will not work for a flight game like yours because you meant for it to be a 3D game while the primary purpose for that mode is to either allow better looking overlay scenes for interfaces or for 2D games.
I believe there is some code buried in the BGE resources forum relating to a logarithmic Z-buffer, which should solve the issue for long-distances and Z-fighting (using the GLSL API).
Thanks everybody for the tips. I’ll try them all. I’d still like to find the real cure. Some of the other forums suggest that LUX render elinates the problem for rendering. but of course I’m doing a game. Wiki says" This problem is usually caused by limited sub-pixel precision and floating point and fixed point round-off errors. Z-fighting can be reduced through the use of a higher resolution depth buffer, by z-buffering in some scenarios, or by simply moving the polygons further apart. Z-fighting which cannot be entirely eliminated in this manner is often resolved by the use of a stencil buffer, or by applying a post transformation screen space z-buffer offset to one polygon which does not affect the projected shape on screen, but does affect the z-buffer value to eliminate the overlap during pixel interpolation and comparison.
And someone else said blender uses a 24 bit Z buffer and maybe it shuold be 32 bit to eliminate round off errors. Just throwing it out there what do you think?
Could there be a scipt that says to always draw obj A behind obj B ? Or always draw material A behind Material B?
Just want to add that the suggestions above have preety much solved the problems for me in my space game. I have vast distances that are in view all the time and I still had the camera near clipping set to default settings of something like .001 but I had moved the end clip out to 500,000 to get planets and backdrop in. When I landed on a planet and approached a structure the Z fighting was terrible.
My camera clipping setting are set near at 5 and far still at 500,000. in the big space scenes and pretty much on the planets too. But I’ve learn to be a little less ambitious and scale things down and split them up into seperate scenes. Where cameras can have different clipping accouding to how large he scene is. Thanks again all.
You should not have a tree and a whole planet at the same scene. The differences in dimensions are simply to large.
Think about this:
You have a landscape with some trees and houses. How would you model the moon?
As a sphere with a diameter of 3500 km at a distance of 380.000 km?
Wouldn’t it make mores sense to place a small flat circle near the end of the camera range? If you really need 3D (for a usually not visible rotation) you can even use a small sphere at a small distance ;). Indeed you have to correct the distance when moving the camera. But this is easy by (vertex-)parenting to small moon to the camera.
With that in mind, it might be a good idea to have distant objects as background image.
You can even have a background scene.
1 Like
Thanks Monster. I totally agree that i have to be smarter about using the game resources wisely. I preety much started out modeling a solar system with all the planets and the landscapes on those planets. Now I’m breaking thing up into scenes and using background images for the more distant plants etc. Then when I have to go to one of them i using a scene switch to a more close up detailed planet model. And finally, a close in landscape model for being on the ground. I guess I can’t create a whole universe at once but have to create smaller chunks of it and sitch it together. But you never know until you try. So thanks again everyone for the help.