Steve Bennett from Taylor-Design had some great criticisms for this workflow posted on LinkedIn, copied below:
Pretty nice to have in a render? yes.
Great idea to have in a project? no.
Easy to get into project? yes.
This sort of workflow has me equal parts terrified and curious at the same time. I would be ok if these types of render assets were loaded into an ArcViz model that links in the main model, but when will designers take the time to do this right when a manager is standing over their shoulder waiting for a render?
This particular Porsche model results in a 5MB revit family. Now imagine a parking lot full of these cars. If you wanted 100 cars for reference, you are potentially looking at a 500MB Revit file (you know those designers want every car to be unique).
…and don’t get me started on the family name that was auto-generated…
As a former BIM manager I have the same concerns! As a developer on Helix, I see opportunities to address these issues:
Revit ArcViz Model Link
If users would want to load high poly contextual models in Revit, they should be in a linked file to keep the project file nimble. With the current Helix offering, it’s easiest for designer to just load these models in the main Revit project.
We could add a feature that automatically places these models in a linked Revit model instead of the main model! This way designers don’t need to switch models for sending the mesh objects over.
5MB Family Size Bloat
This is an existing problem with bad families that can be found online from random sources. These large families can be composed of strictly native geometry. The issue is with the discernment on what geometry was modeled that should not have been modeled. The same issue applies to the Helix mesh. We are showcasing the Porsche model, to demonstrate the capability of handling complexity. However, if this car would be instanced on a site multiple times, a lighter model would suffice: one that does not have the interior car geometry perhaps. Selecting the appropriate model needs to be intentional.
We have an idea in our backlog that would report when a model being converted has a high poly count. This is directly correlated to the family size. Perhaps this setting is exposed, and users could receive a warning when a family is above 2MB.
Another idea we have to address this issue, is to run a poly reduction post process on the mesh to simplify this geometry. It can be tailored to keep families below a certain poly count or family size.
Revit Performance Bloat
Here are some tests with arraying this model to 250 instances with the Helix mesh versus the Revit built-in SketchUp importer.
When importing and instancing the same model 250 times without Helix, Revit locks up when panning/zooming around. The evident takeaway is that the visible polygon mesh lines are the main culprits to slowing down Revit’s model navigation performance. Helix hides these mesh edges, hence the great performance.
We also ran a test with this model arrayed 250 times in SketchUp to compare it with the Revit performance. The Helix Revit equivalent is more performant in terms of displaying a higher poly count. The navigation smoothness is the same, with SketchUp having a more aggressive low LOD bound box display of the geometry.
This goes to show that 22,2336,000 polygons can be challenging for SketchUp. The main takeaway is that: if the model performs slowly in SketchUp it will perform better in Revit when using Helix DXF meshes.
I should note that the SketchUp profiles are turned off (show element outline) where in Revit they are always displayed (no option to remove them). When profiles are ON in SketchUp, the performance for this model array slows to a crawl.
The gif below has SketchUp profiles enabled, and I had to reduce the instance count to 50 from 250 so that I can navigate the model. At 250 instances, the model locks for a few minutes when trying to navigate.
Revit Family Name
Yes - not proud of that one. Plenty of room to improve there!
Helix expands the set of tools available at your disposal. With more tools, you can do more, but it also introduces more ways to make mistakes. Placing high poly geometry and arraying it hundreds of times across your project is not recommended. If objects need to be instanced many times, lower poly count components are more appropriate for converting to Revit families. If the objects are not instanced many times, you can have a lot more detail.
Below are some example use cases with this mesh based workflow: