Texture flicker if 2 objects are too close together.

#1 Btw, this flicker happen only when my camera move away from the character. If close to the character, it wouldn't happen.

#2 Is this what you are experiencing? Z-Fighting. If so, you may want to raise the mount point of the hat slightly.

#3 This does sound like z-fighting - especially since you mention it only happens when farther way.
The precision of the Z-buffer drops significantly as you get farther from an object.

#4 I tried using the model inside the example project. The model is not flicker inside the example. I suspect is something to do with the lighting. Still no luck on searching any solution.

#5 I would suggest eliminating Z-Fighting before you go digging into your shaders/lighting code. Make the hat on your model slightly bigger than the characters head. Normally epsilon (0.0001) is used because it will provide just enough offset to eliminate it. It's an east trial and error and could save you hours of debugging and a day of headaches.

#6 Thanks for all the reply. I tested the same project using TGEA 1.7.1 with the same sets of 3D models, no flicker at all.

For the epsilon, i saw splashVelEpsilon = 0.60 inside player.cs in the scripting file. James, is this the one you talk about ?

#7 Just found out something, when I rotate my camera (at the same position) to certain angle, the polygon flickering gone. But most of the rotated position shown the polygon flickering.

Not the whole model flickering, just a small part of the polygon is flickering.

#8 My experience with Z-Fighting and Torque is none of my 'play testers' mentioned it as a distracting quality from game play. I notice it more in some hardware setups then others. I expect once you have more details in your game, you may not find it as bothersome.

#9 Haider, your problem may have something to do with your bounding box. make sure your characters animations dont go outside the model's bounds.

#10 Sean, that might be the problem. I will make the bounding box bigger then update the result here again later.

Thanks for all the help.

#11 Sean, it doesn't seems to work, still having the same problem. The polygon of the head is render on the "hat" when the camera rotated to certain angle or the character moves.

Even after I make the "hat" bigger than the player's head, the polygon of the head still showing on the "hat". Is not about how big the "hat" is, i think the renderer getting the previous render pass to the current render pass that makes part of the head polygon with lights render on the "hat".

Continue to search for more information.......

Thanks guys.

#12 This is starting to sound like more then a simple Z-buffer precision issue.

Could you provide some examples, screenshots or video?

#13 Hi Caylo,

Here is the video of the flickering texture problem.

http://thehobbystation.com/flickering_texture.mp4

The video is a bit blurred but still can see the problem.

Thanks for the help.

#14 Wow, neat looking game.

And yup, thats an annoying amount of flickering, very distracting from game play. Thats the worse I have ever seen it in TGEA. It is a Z-buffer precision issue.

Im just brain storming here...
But what if you tried a unnoticeable amount of alpha transparency setting on the 'hair' parts material? The idea is to trick the 'hair' mesh to render absolutely last.

Also question on this part:

Quote:
Just found out something, when I rotate my camera (at the same position) to certain angle, the polygon flickering gone.

Would this angle be the extrema edges of the view frustum? As in positioning the camera right near the edge of the screen?

#15 For the camera rotation question, it is not at the edge of the screen. From what we seen in the video, if i rotate the camera a bit to any angle. The flicker doesn't happen that much. Some time it even not flickers at all.

Any idea ?

#16 Only a few theories. If camera angle is contributing by a large factor, have you modified the default camera behaviors at all? Changed the FOV, that type of thing?

If the alpha transparency trick do not appearer to alleviate the noticeable flicker, a fix I am more confident should work, would be adding depth to the hair/hat mesh parts. Extrude the hair/hat INTO the skulls of the 'people', this may add unwanted polygons. The idea here would be a mesh that is not hollow/open and is not a deformed plain.

I need to research my other theory, but it involves changing the TGEA lighting settings for none static mesh types, I recall there being two pref settings that should accomplish this. The idea here is to lower how noticeable the Z-buffer precision issue appear.

#17 Hi Caylo,

I'm current using the FOV of 25 for the project. We need to change it to FOV 25 because of the design issue.

The problem is fixed now. I changed the camera near plane from 0.1f to 1.0f inside gameFunctions.cpp

//--------- GameProcessCameraQuery function -----------------

query->nearPlane = Con::getFloatVariable("$pref::Video::nearPlane", 1.0f);

//-----------------------------------------------------------

I'm not sure whether doing this is a good idea, but it fixed the problem. No more flicker. It is working fine in the First Person View.

Caylo, thanks for all the helps. You gave me a lot of idea. For the time being, i think i will stick to this fix first. I will test the game and see if there is any side effect from this fix.

#18 Oh ya, another thing. The setting for the near plane is 0.1f in TGEA 1.7.1 and this doesn't make the texture flicker with the same project.

So i guess something inside TGEA 1.8.2 changed and make the precision of the z-buffer not accurate.

#19 I can not think of anything that modifying the camera near plane would noticeably harm.

TGEA 1.8.2 might as well be a separate engine from TGEA 1.7.1, so much was changed and modified.

It is great you got it working! And i hope this thread stands the test of time, for other who may have the same type of problem.

#20 I examined this in more depth and think I have a plausible explanation for why this happened. Using TGEA 1.8, changing the FOV from a crazy 180 down to 25 (as your project is using), it is quite easy to exaggerate the Z-buffer precision issue.

The FOV as Torque is using it, is NOT as much simuler to a wide angle view lens found on nice expensive imaging cameras (hence Field of View as defined by the world of cinema and photography). But more a modification of the view frustum size itself. This may seem like the two are the same thing in concept, but in practice modifying the view frustum is changing the amount of screen space being considered by TGEA, the added benefit of Torques FOV definition is better dynamic optimized view frustum occlusion. But as noticeable from FOV of around 37 and lower the precision of the z-buffer seems to truly spiral out of mathematical probability; whatever mathematical formula is effecting the z-buffer seem in error with regards to such a tight FOV. This may be the exact reason for a $pref::Video::nearPlane. What truly have my curiosity peaked is the possibility of using a logarithmic calculation to auto set the nearPlane optimally according to FOV settings (If indeed nearPlane could have an optimal setting).

I am not as clever a C'code monkey I wish I were, because I can not seem to find the Source Code locations to support and confirm my hypothesis.

But at the end of a hard day of debugging this oddity, it truly is only a annoying factor for a very small number of practical FOV usage scenario. Interesting from a curiosity perspective, but well solved according to practicality of time spend pondering over it. If any one who know C'code better and have the time to wast to test my ideas here, that would be rather neat.