I’ve often encountered this issue and wondered if there’s a solution. The problem usually stems from the element not being properly modeled initially. However, in many cases, we don’t have the time to fix the elements, especially when we’re only looking for an approximate analysis or estimation. Is there a way to approximate these solids so they work? Bounding isn’t a good choice since it’s always aligned with the axis and doesn’t work for elements angled to the axes. Has anyone tried using external packages, tessellation exercises, etc., to resolve this? Just to clarify: the elements aren’t super complex, just a rectangular column divided into parts.
Yes, I have. It’s not easy, slow as can be, and heavy. But tessellating the geometry using Revit’s toolset and converting to a Dynamo mesh works. If you need a solid you can also tesselate and convert to a PolySurface and convert that to a solid, though I haven’t tried it myself.
The number of edge case failures you’ll run into is VERY high unfortunately. Garbage in will result in garbage out 100% of the time, so the more shortcuts which are taken in earlier phases (i.e. modeling) the more garbage you’ll get at the end of the job. Best bet is to go do the modeling correctly.
1 Like
understand but want to dig a bit deep, How could the same element have a valid geometry for revit solid and invalid for dynamo solids ?
Revit geometry has a LOT of rules to it which Dynamo does not. One of these rules is the geomtry precision is limited to between 1/32 of an inch (0.8 mm) and 22 miles (35.4km). Anything smaller or bigger than those will cause issues.
However things still need to work - case in point your stairs need to have equally spaced risers which means that we’re apt to have fractions of a mm involved.
To deal with this the ‘unclosed’ geometry is often ‘forced’ to close by way of rounding the values before building the shape. This means that when building the display things have to shift by a distance of up to 4 sheets of paper in any direction for really small stuff. Really big stuff also shifts, but in other ways (which we’ll ignore for now). And so when the geometry of the stairs is calculated (when you call e.get_Geometry(Options()) or when Revit generates the display) there are unconnected faces.
Dynamo doesn’t have a ‘round to a dimension which I can work with’ as it’s geometry engine (ASM) is the same as that used by AutoCAD. The precision floats (to a point - how it’s displayed is another thing entirely). So it does it’s best to ‘reconfigure’ things but sometimes stuff gets lost in translation.
Let’s consider this in a hypothetical and overly simplified case. Imagine one corner of a cuboid at a location of (1.0005, 1.0005, 1.0005) Revit might round the values of the position to (1.001, 1.001,1.001) due to how it handles floating point precision, but in Dynamo we might get the top face at (1.001, 1.001, 1.001), the right face to (1.000, 1.000, 1.000) and the left face to (1.001, 1.000, 1.001). All three vertices are located at the same point in Revit (due to the rounding mechanisms), but in Dynamo each is at it’s own location - this results in a failure in generating the solid as the shape is no longer closed, nor could faces simply be added (you’ve got to connect the edges in matching direction loops after all).
This is getting more and more rare as the Dynamo and Revit teams alter the way the handle things (the .NET updates in 2025 should help further), but in the end every geometry engine in existence is just a endless series of exception handling to deal with the endless number of edge cases.
Now linear shapes are mostly well handled, but curving ones… well the math behind them is inconsistent between tools so we get inconsistent results (ask a roadway designer about the difference in spirals for roadway or rail design and how they differ oh so slightly between applications some day - but brace yourself first as there is apt to be something thrown). We also have voids to consider - you can parse a Revit Solid from a void - it’s negative but still a solid. We also also have invalid Revit solids to consider - there is such a thing as a solid with zero volume thanks to the aforementioned voids. And we still haven’t talked about large coordinates…
3 Likes
wauuu great explanation,thanks 
and so long i even could translate in google, so i was sure i understand
You can filter parts by nulls and try to get solids by Element.GeometryFast from the Synthesize package (it uses SAT export and is very precise). But we can have more than one solid per one Revit object. So we can make DYF node to process the list of Revit objects. Than we can use Union to get final solids.
1 Like
Doesn’t the SAT export tesselate the geometry?
No, it will return the Dynamo solids.
Hmmm… I recall that SAT tesselates, but I could be backwards on that. However I do not see Element.GeometryFast in Synthesize Toolkit…
Interesting… I do t even see SythesizeLegacy… what package version are you on?
I would prefer you re-install it completely, Synthesize is now version-less, and practically the installer is shipped to the package manager only, as it gets the last compatible version externally based on the Revit version it detects, and practically auto-updates it self when needed.
SynthesizeLegacy are practically older .dyf files created back in the days with Python.
New nodes are being carefully maintained and created in C#, and eventually all of Synthesize will turn like this.
The node in question it self is soon going to be re-created in C# to be more stable and consistent, expect to see it during next month.
2 Likes