Q: I’m looking for a fitting boundingbox for just one FamilyInstance.
A: Okay then you can use a “element.boundingbox” node.
Q: But what if my element is rotated in the project (for example 30 degrees), it will become to large because the boundingbox is axis-aligned.
A: Okay then you can first select the FamilyType of the FamilyInstance, and then use a “element.boundingbox” node.
Q: That seems to work, no wait the builtin reference planes are are also fitted inside the boundingbox so it is to large again.
A: Okay then you can select the Solid of the FamilyType (of the FamilyInstance), and then use a “element.solids” node followed by a “Geometry.BoundingBox” node.
Q: But query a list of solids is not realy light-weigt solution, and it can possibly crash in case of complex solid shapes.
A: Okay, maybe you can ask your question in the Forum
The story above is a short version of my efforts over time.
The real question is: Dynamoteam is it possible to create a BoundingBox that is not Axis-aligned. The “Springs.Points.MinAreaRectangle” would be a very good base for this.
Thank you for your response. @Daan, @mzjensen, @GavinCrump unfortunately these methods all use the (element) solids. Usually this works well, and I’ve experimented a lot with this myself. But sometimes these (solid)methods are not stable (with complex shapes or solids with voids), and error messages arise.
@jacob.small This is why I would like to have an element-aligned boundingbox. In my opinion, this is the fastest/lightweight solution to determine the external dimensions of elements. But then this boundingbox must be aligned with the relevant element, otherwise the dimensions will not be correct. That’s why I also experimented with the boundingbox of the ElementType, then you don’t have this aligning problem. Another problem (both cases) is that nested referenceplanes (outside the element) also affect the boundingbox dimensions.
Our intention is to use the boundingbox dimensions for creating elementviews (and shopdrawings). The comments above also show that many solutions are being sought to work around the problem with axis-aligned boundingboxes. In my opinion, many prefab manufacturers think in terms of individual parts and ways to get them on shopdrawings as simply as possible.
Try considering the underlying data structure of the bounding boxes. An axis aligned bounding box is a min point and max point. It’s calculated by simple checking all points in the geometry and getting the min/max x y and z values. It’s not an actual box, it just two points. It’s used internally within revit for culling (I believe). A simple collision algorithm is to check if a point falls within the min/max range of the two bbox points
Have you tried recreating the element aligned box? My approach for this is to get the geometry of the element in question, transform it by the inverse of the element transform to get it back to origin. Get the bounding box cuboid from this, then transform it back with the elements original transform. This should work fine as long as your element is using the z axis as up.
This is well said, well outlined, and has a clear direction. You have a Revit problem, and want a Revit solution.
And I have some really good news! Unlike bounding boxes in Dynamo, Revit has the capacity to transform bounding boxes to some extent - that is rotations can be applied and orientations set. THis allows them to work as minimally sized cuboids for a given scope of work. Have a look at this link in the Revit API: Transform Property.
Now a few caveats:
These will not transfer to Dynamo correctly, as that geometry engine is not as tied to instancing as Revit does as geometry in Dynamo is recreated at run and stored in session, therefore doesn’t have a direct need for the performance hit which it would likely take by adding another 12 doubles (the current method uses 6) for use in Dynamo. As such you’ll have to stay entirely inside the API to make use of them.
I have not tested this, so it could be a complete waste of time, but based on what I am seeing it is doable if you manage your transactions and content correctly. A custom node could be created to pass a ‘minimum cuboid’ object along the element, but that is a big ask.
As per #2 above, I am not sure how the sets of BBs will interact with each other, so you will want to test carefully.
As an alternative a custom data type allowing the creation and use of an arbitrarily oriented minimum bounding box, but that is a difficult algorithm to implement. You can do some further research here: Minimum bounding box - Wikipedia
Sorry for the late response, I did some research first.
I’m not native english speaking so I find it difficult to understand your technical story. Furthermore, I don’t think like a programmer so that’s my second stumbling block. Finally, I find it difficult to understand where the boundary lies between Revit and Dynamo elements.
Dynamo makes it possible (as an end user) to automate standard tasks without programming knowledge. This is perfect.
As mentioned, one of these tasks is to make fully automated shopdrawings of our products. This process works for the most part, but I try to improve it every time. To determine the exact size of elements I now need to query the solids of each element. And given the many topics on this forum, many people try to use solids in many different ways. But this can be a heavy load for the PC with many elements. My thought was therefore that querying the boundingbox would be a much less onerous process. Unfortunately this is not possible as I would like it at the moment. Unfortunately I also don’t have the knowledge to program your suggestions by using Python. I think it has a lot in common with this topic but I wouldn’t know where to start.
So I keep hoping that in the future the boundingbox (or boundingbox+ variants of it) will have more options. Here I am thinking of a boolean option to ignore Reference Planes (this would help me a lot).
And as mentioned before the possibility to rotate with the element (non axis aligned).
For now I have chosen to include a (nested family) in my elements, with reference planes that move with the outer dimensions. I then use the intersections of these reference planes to calculate the correct dimensions.
This is a VERY good solution and could in fact help in other aspects of automation (as you now have a consistent set of well named references to dimension to!).
Another method would be to pull the primary axis (for linear elements) or coordinate system (for non linear elements) from the instance and use that in conjunction with the bounding box of the family type; That “bounding box” can be converted to a cuboid and transformed to the line/coordinate system, and then be transformed a bit further to account for your family type edits. It’d be a LOT of work, and won’t account well for shape edited objects (ie: anything which has a “join” in the object).
