-
Objective: Currently, when sending all elements of a building project from Revit to Speckle, this causes Z-fighting due to non-rendered components being shown. So, for instance, for a room, if you have a space or room definition in Revit in Speckle model rendering view, the room volume is also rendered, causing the rendered object’s Texture to look glitchy.
-
Issue: Ideally, I would like to have these elements as non-renderable elements within the speckle model. That can be enabled to be renderable. Besides manually filtering objectIDs on load, is there another approach to having elements just load as non-viewable elements?
-
Example: For instance, this is the Revit starter project with all elements of a 3D view, and if you look at this comment view, it’s clear that the floor and walls have tons of overlapping 3D components that are being rendered, causing this problem.
An issue as old as time… </MorganFreemanVoice>
Do you have a good reference example of another viewer that handles this well?
Not viewer per say but using Omniverse Revit Connector to do object conversion to USD handles this by assigning a visibility flag to each object component. Opening this converted USD in omniverse code or viewer, rhino 8,etc, all achive the same rendering effect.
This way the rendered view only displays the same elements as what is shown in Revit but still contians the space abstraction present in revit as hidden element in the USD. I was hoping to have the same behavior here. I can provide an example of this workflow in couple of hours if that would be helpful.
If I understand correctly, in Omniverse, objects are converted and sent even if they are not visible, and then these can be toggled on in the viewer?
If so, when toggled on, do these exhibit z-fighting?
Regardless, you can replicate this workflow by not restricting yourself to one model per Revit file. Send Rooms separately from context and federate back together at will.
This is a workaround more than a fix.
Alternatively, as this is a ViewerAPI discussion, you could filter on objectload those element types you want toto toggle as hidden before passing to the viewer.
I’ll experiment with pre-processing objects to be hidden on load, which should be a suitable workaround for now. I want to avoid handling this as multiple speckle model instances whenever possible.
From a graphics point of view, z-fighting is an umbrella term. It can mean different things, it can have different causes but still look the same.
From what you are describing here, the particular z-fighting scenario most likely is happening because of perfectly overlapping surfaces. A common misconception here is that it can be fixed by changing the order in which objects get drawn, which of course will not help. As long as your geometry will generate equal-ish depth values when it gets rasterized, no ordering will matter.
There are ways to circumvent this issue, most of them involve altering the generated depth values for the rasterized fragments, however there is no universal solution, but rather various situational solutions. Because the speckle viewer needs to handle geometry that is massively general purpose, it has no notion of walls, rooms, floors like other specialized viewer, tools or applications out there.
Like Jonathon suggests here, this is an issue better fit in the application specific space, rather than in the viewer library.
The current z-fighting issues personally bother me as well, and maybe in a future iteration we will come with a complete or partial solution.
Cheers