No announcement yet.

Overlapped faces render order flickering

  • Filter
  • Time
  • Show
Clear All
new posts

    Overlapped faces render order flickering


    As can be seen in the video linked to here:
    When the faces of two static meshes are exactly overlapped on a single plane, it looks like the renderer continuously changes its mind about render order, and a resulting tearing/flickering happens.

    Does anyone have suggestions on how to prevent this from happening?


    I think the term commonly associated is called Z fighting. This will happen even in high end 3D apps. Typically I just offset one face a very tiny amount. If that is not and option then I remember something in the UDN docs under hair rendering that may offer some help.


      Yes, that's z-fighting caused by precision artefacts in the depth buffer. When an opaque material is rendered to the frame buffer it will, in addition to the actual pixel colour, write a depth value. Subsequent rendering then compares any new pixel depth with the current depth to determine if it should overwrite the pixel colour.

      The precision of the buffer isn't high enough to correctly sort co-planar surfaces. The calculation is based on camera distance, which changes with angle, causing the flickering effect.

      Offsetting the meshes should be done with care because the depth buffer value isn't linear, and artefacts can still occur as distance increases and FOV changes.

      If you absolutely need co-planar surfaces you could probably build a shader that uses depth bias. This is how decals work. However, it's not recommended to do this for standard geometry. The correct way is not to overlap meshes in such a way, unless the textures line up perfectly or the result can be hidden.


        Interesting, thanks!

        For the project I'm working on the geometry is being manipulated in real-time with live sound input, so I have to find a way to deal with this problem, because I *will* get co-planar surfaces from frame to frame, depending on the input.

        I'm not quite sure how to use Depth Bias on the shader to accomplish this, as I don't want to change the opacity of the material.. I don't think? The only demonstration I saw in forums of using Depth Bias Alpha was to hook up the alpha of my vector color to the Alpha in DBA, then that into Opacity in the material. But that had the unwanted affect of making the backfaces of my cubes visible, which was unwanted.

        Linked to below is a video of what I'm doing, demonstrating the problem (sorry no sound for the moment). Hopefully that might aid toward finding a solution.


          Z fighting is usually only noticeable using textures, but your example uses a single solid colour. The flickering is white, so I'm wondering if its something to do with the lighting. Try using an emissive material on the cubes with no diffuse or specular.


            Setting the material to use just emissive does indeed get rid of the problem, interesting! However, I need this to work without glow in the dark boxes, as lighting/shadow is a huge part of the final product. Is there another way to fix besides using an emissive material?


              That could be tricky due to how UE3 handles lighting. I've noticed that when two dynamic meshes overlap they brighten up, so there's an additive process in the lighting pass. I think this is what causes the z fighting to show up in your case.

              I can only really guess at possible solutions. You could use fake mesh lighting using the emissive channel (emissive doesn't necessarily mean glow, it only glows if the linear colour values of the overall result are > 1.0). There's an example of this in the particle effects docs on UDN.

              edit: misread your note about 'glow in the dark', the above wont solve your issue.


                A fudge you can try if all else fails is for cubes to examine their neighbor's scale and add a slight bias to theirs if they're too similar. With enough space between cubes you could do this for every other cube, but your arrangement is fairly compact so it may be better to do it in a second pass for all cubes.

                The idea is simply to avoid coplanar cases by forcing adjacent cubes to not be the same size (or within an epsilon range).


                  Yeah, I'd been working on that (dictating sizes to ensure that coplanar surfaces won't happen) as a solution before I decided to come here and ask if there was an engine-based solution instead. Obviously if I adjust sizes prevent coplanar surfaces, I'm conceptually limiting the work because the relation between sound and visual is no longer exactly one to one... but conceptual fudging happens all the time :-p

                  Thanks once again for your help Spoof!