I’m running into a problem when creating Dimensions in a Section view where the dimension gets created, but is not visible in the view. I’ve read through a number of posts reporting a similar behavior, but none of them explain the issue or point at a solution that makes sense to me.
I extract the references from the element and calculate the placement line perpendicular between the reference surfaces. I use Genius Loci nodes to extract the references and construct the dimension. The way the API describes it seems pretty straightforward. I’ve attached the script.
test_constructDimension_try-again.dyn (104.0 KB)
a weird thing that stands out is that the BoundingBox property of the created Dimension is empty, but it registers on the active view’s workset.
I compared the snoop against a manually created dimension and the stable representations of the references look right, but the positioning information is off by quite a bit. I tried transforming the lines into the crop box CS, but that didn’t resolve the issue.
I’ve seen a couple of posts reference having to set the sketch plane, but this doesn’t seem to be supported in the API documentation? I tried it and it didn’t seem to have an effect.
What am i doing wrong?
Digging a bit further, i guess it’s somehow an issue with the specific families i’m trying to use this on. The ‘view x’ and ‘view y’ dimensions of Generic Model as desired:
I reworked some elements to more generically pull ‘furthest’ references according to view orientation, and changed to OOTB node because the GL one was failing to construct references from surfaces.
This functions as expected with Generic Models, but fails on the Windows i was trying to build this script for. I guess this technically works (?) but Revit prompts the dimension construction with a warning
The visual inspection in Dynamo looks as expected:
i guess i need to check the stable representations, but it looks like ElementFaceReference doesn’t convert with UnwrapElement(?). I guess i need to figure out why these collections of references are invalid
following up: i ended up just porting this all to python. Managing surfaces and reference objects seems a bit more straightforward just using the API.
I did identify some odd behavior involving the map between ProtoGeometry Surfaces generated from Face classes in the API, and the References they’re supposed be associated with. In my test case i was considering this window family:
Inspecting the Dimension’s References, we expect to find these two references as the references required to construct the overall height:
- 1ed7dd28-adf3-4e26-8664-7e00cc0b5fd7-0023209c:0:INSTANCE:f3d45ece-f0d0-4661-a3c0-f67ded99c031-0023093c:86:SURFACE
- 1ed7dd28-adf3-4e26-8664-7e00cc0b5fd7-0023209c:0:INSTANCE:f3d45ece-f0d0-4661-a3c0-f67ded99c031-0023093c:82:SURFACE
so, surface Id 82 and 86.
I use either the node Surface Reference from Genius Loci, or RevitFaceReference.FromDynamoSurface from Clockwork to get the Reference associated with the ProtoGeometry Surfaces, then get the stable representation using python. We can see the references of interest in positions 13 and 15.
But when I get those indices, these are the ProtoGeometry surfaces we see in Dynamo:
So this would explain why Dimensions are not able to be constructed, but I’ve very curious if this is intended behavior? I’ve looked at extracting geometry with Element.Geometry > Explode > Filter instead of Element.Faces. It’s possible that the nodes that fetch the References don’t function, but they both give the same result.
I did try using the Reference classes from Dynamo Core using ElementFaceReference.BySurface, but I didn’t find a way to check the stable references from those objects.
Thoughts?
test_constructDimension_try-again.dyn (162.8 KB)
