Z-Fighting Fix

Please note: Should you experience issues with Enscape or your subscription, and in case of any urgent inquiries/questions (e.g. regarding our upcoming licensing changes) please reach out to our dedicated support team via the Help Center or Support button as detailed here.
    • Official Post

    As I'm playing more and more in VR, i'm seeing a lot of flickering surfaces where two planes are fighting for the same 3d space (Z-Fighting). This is really disorienting in VR. Doing some research, I found that other companies are coming up with solutions. Is there anything in the works for Enscape?


    Not at the moment, but I can gladly file it as a feature request for you. Anything else you have in mind which I shall forward to our developers? Thanks in advance!

  • That would be it. Enscape is a crucial part of our workflow, but as we start getting into VR we are experimenting with other plugins that have a more robust VR concentration.. That is one item that I noticed that would really help our Revit models in Enscape. There are a lot of circumstances----especially in ceilings that we have multiple planes in one area. Taking time to clean those up does little help to our final drawing documents and takes a lot of time.

  • I have experienced a similar situation but I have to tell you, there is no better remedy than starting a job with a precise delineation of geometric elements to avoid interference. Also very important, to separate presentation modeling from construction documentation since those have two very different purposes.

    We do a fair amount of work in multifamily and hospitality development and so there are a lot of repetitive elements like balcony slabs and exposed ceiling finishes, and it is not unusual to accidentally have a floor slab and a balcony slab occupying the same space in 3D. It pays to know where to stop one and start the other to prevent double dipping, or organize your reference geometry so you may unload the guts of the building model to avoid surfaces in close proximity for the purpose of rendering.

    I typically have at my disposal at least 3 professional level rendering packages including Enscape and they all behave the same when the base model contains interferences.

  • Agreed, but you are assuming the Enscape is being used as the our final rendering tool. It is not. It is used for coordination between disciplines and checking our models mid-design. We would never expect those models to be ready for a final render. Our clients rarely see anything in Enscape.

    This isn't an issue of laziness or sloppiness. If something like Z-Fighting is a simple fix on the programming side (I have no idea if it is or isn't), implementing it wouldn't be relying on Enscape to clean up our sloppy models. It would be a small movement towards quickly jumping into Enscape and having it look as good as possible even at the start of a project.

    And for those that are using Enscape as a final rendering tool, I would argue that anything that Enscape can provide to make the model look better would be advantageous to all. This isn't a critical---but most of these Ideas and Requests aren't. Just small steps toward making an already great product even better.

  • I learned about problems with Z fighting when I started my first renders.

    And I learned that is something that I should avoid in modeling at all.

    Not that I often had to deal with this.

    And I was always happy that Z fighting symptoms are already visible

    inside OpenGL Viewports and indicated modeling errors to solve ....

    I didn't even knew that there may had been ever any solution from software side.

    Are there any examples ?

    I mean even if there is a way that the Renderer decides to only show one of those

    faces without showing artifacts, in 50% of cases, it may show the wrong Face/Material (?)

    And honestly I think Sketchup's geometry is very bad and not compatible with

    any other Software outside when exported. At an extend that I always regret

    when a client delivered 3D Sketchup Models (It is already there and 3D ...)

    and always said I will refuse these next time.

    I mean things like non standard 3D Faces, that have a second Material at their

    back side. Basically coplanar Faces with different properties.

    But yes, there are so many SketchUp Users outside,

    if there is any possible solution from the Renderer's software side to make Sketchup

    geometries make look similar like they look inside Sketchup,

    that would be great and a great help.

  • I have never experienced those kinds of issues and typically I use and exchange geometry among various modeling programs.

    In my personal experience building complex renderings with solids, meshes or other geometric elements from Revit, Rhino, SketchUp, AutoCAD, Maya, 3DMax and several others is never a problem as long as I follow commonly accepted industry practices, that is clean geometry, free as much as possible from strenuous hidden surfaces and or artifacts, etc. Just basic common knowledge prep work.

    Maybe the Enscape programmers could shed some light on the potential capability of a rendering engine to sort out geometric inaccuracies while processing a file. Perhaps IA may some day allow for that small miracle to happen.;)

  • This isn't an issue of laziness or sloppiness. If something like Z-Fighting is a simple fix on the programming side (I have no idea if it is or isn't), implementing it wouldn't be relying on Enscape to clean up our sloppy models. It would be a small movement towards quickly jumping into Enscape and having it look as good as possible even at the start of a project.

    And how would Enscape know which of the z-fighting faces are to be shown and which ones are to be hidden?

  • As stated in the original post, IrisVR seems to do a good job. I've been playing with it on the oculus quest 2. See link below. I don't know how it is accomplished technically, but it seems to always work well in areas that Enscape flickers.


    I feel like this touched on a subject of the importance of clean models. Once again, totally in agreement. I do encounter the flashing more often than I would like to admit. Sometimes it's a linked element, sometimes it's a the vertical walls of a bulkhead interfering with the ceiling, sometimes it's the trim on a bad door family---but it happens.

  • Being a Graphics programmer Z fighting much of the time is not two planes exactly in the same place. The depth settings be it Opengl DirectX etc whatever is the culprit normally. The other is bad modeling or placement. Having access to the Z depth (Far) setting and distance along with the near setting would eliminate the problem I am having. This should be extremely easy to implement to tell you the truth.

    A simple description of how perspective projection works is say your scene is a small house then the far can be a small value thus when the planes are extremely close together they will not flicker as the math has enough space to delineate the distance, However, the clip plane will be much closer or the far items would have serious issues. Vice versa. A large scene needs a great far distance so close objects have less discernment to work with and their depth fights back and forth causing flickeing on who is in front. This can be alleviated to some extend with the near clip being farther away but items will clip out when they get close. At least that is a simple explanation of the perspective matrix and how it works clipping to screen space.

    Can we have those near and far values exposed? I would love that.