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?
Z-Fighting Fix
- aaronnordstrom
- Thread is marked as Resolved.
-
-
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.
-
Yes - I would like to say Enscape is not a getaway or excuse for model managment.
I wouldn't expect Enscape to "clean up" geometries for me
-
It's not the Renderer's job to clean up your messy file. Don't work sloppily and you won't get sloppy results.
-
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.
https://help.irisvr.com/hc/en-us/articles/115001732928
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.