Just trying the primer code for the Python and noticed a major Bug with bounding box (bbox) if you input Surfaces/Polysurfaces or Solids it does not return a true bounding box. This is worrying for 2 reasons, one, because the box does not have a preview and as unless the script had output something wrong I may have used this on other projects like a do in Grasshopper with major errors as the box dims would be different. As well as the fact that I only found the bug because I thought I would review the primer for anything different from working in Grasshopper etc with Python
It says in the primer to extract the edges as there is a bug the bounding box but if I had not done the primer page I would not have known. This seems quite a big bug to not have fixed before releasing the primer and still a major bug in the latest primer.
Also, why does the bounding box require so much extra code just tp preview the bounding box in Dynamo/ Revit, etc? Personally I think the bbox components should have a preview, either wireframe or ghosted so you can review the box.
Addition request, Can we have an option to align the bounding box to a plane/coordinate system. so the BBox is not just XY.
ERROR Code:
BBOX BUG.dyn (38.5 KB)
It might be cased by the polysurface being treated as untrimmed (which is a major flaw in the ASM) and the bb is therefore displaying larger than the BREP (so the problem is not the bb, but an underlying issue with Autodesk’s lacklustre geometry engine). OR, if the geometry entities are rotated to the world XYZ axis, the bb is simply inscribed around those elements but remains aligned to the global axes, hence if you are translating the surfaces of the bb relative to your geometry, then there’s your answer (i.e. its 100% correct).
You cant create an axis aligned bb as this defeats the whole purpose of a bb. They play a fundamental role in computer graphics/geometry engines and are primarily used for performing rapid geometric functions (hence why in the Revit API they are used an inputs to quick filters) which can then be used to inform and reduce the processing time of other more geometrically expensive functions like geometry intersection or culling information from a view. All this magic comes from the fact bb’s are axis aligned, which means calculating whether a bb intersects or is inside another can be computed using simple evaluations of its min/max points - or more specifically, number calculations using the fastest parts of your computers memory (the stack). If they were rotated etc, then it would either require significantly more processing or the use of higher-level objects both of which would hinder performance because then you’ll be relying on the slower parts of your computers memory (the heap!).
Anyway, with all of that said, you can ‘rotate’ a bb via the Revit API abstractly, just use its transform property and understand that is only applicable for certain functions, like cropping views. It has no affect on the location of the bb itself or any functions which test for containment for example.
4 Likes
I think you may have the answer for this bug with the untrimmed surface issue answer, shame that’s a much bigger issue than just Bounding Boxes. As when i only plug the lofted edges in and not the patches it works as expected.
ONLY edges and not Surface Patches.
Next question is can you shrink trimmed surface to its closest edges. This may not solve the BBox bug mind but would be a good start, it should also be possible to know if a surface is trimmed or not and to untrim it.
As for rotation i am only going off what is possible in Rhino/Grasshopper. But for some new projects i will need to be using Dynamo in Revit / Civil 3D etc. Thanks for the detailed answer regarding axis alignment I had not consider the code would be so much faster/ computationally quicker if its not possible to align the bbox to a custom coordinate system not just XY. As BIM model may have many thousands of elements you want to check in various ways as its built differently to a Rhino/ Grasshopper model.
@Thomas_Mahon thank you for posting the detailed breakdown on why BB are useful as is. 
Bounding boxes are part of the abstract section of the geometry engine, which by definition are not previewed, with the one exceptions I can think of offhand being coordinate systems and planes. Generally speaking the more you can do with the abstract data types the faster your graph will execute. This relates not only to what @Thomas_Mahon stated above, but also due to the frequent lack of preview (which is a hit for any program). The primer section on geometry has a handy chart a little bit down this page - try and stay left as much as possible for increased runtimes.
https://primer.dynamobim.org/05_Geometry-for-Computational-Design/5-1_geometry-overview.html
The biggest difference between the ASM engine and the one you sound as if you are used to, is that ASM is built for highly accurate solid modeling, where as the Rhino engine is built for surface modeling, which is by definition a bit looser with its initial shapes but faster for surfaces. One thing you could try in order to reduce the untrimmed nature of those surfaces is convert them into a solid using a Solid.ByJoinedFaces node. No clue if this would work in your case, but I have had success in the past and it would put you into the strength of ASM. There is a drawback though, as you can see solids are further up the scale of complexity, so you will take a performance hit, likely similar to one in rebuilding the surface accurately as an in trimmed surface, which will likely require a series of isocurves, some intersections, then parameters along lines, and a bunch more depending on how accurate you want to be, some list management and finally moving onto rebuilding the surface by points. And even then I am not sure it would completely work. Way more compute then you want to spend at this stage though.
As a heads up, the other aspect of trimmed surfaces new users often struggle with is PointAtUVParameter, where you may get results outside of your initial geometry’s extents. This can be quite useful in some cases with both design and analysis. However most who are getting started find this frustrating as it is unintuitive. This can be overcome by asking if the resulting point intersects with with the surface or not, and filtering or adjusting accordingly.
4 Likes
Tried the Solid.ByJoinedFaces node as that was what was in the primer, just did not have it attached in the graph, but this also has the same issue with the BoundingBox. As its a standard 4 sided surface built from edge curves using a patch, as there is not an option, I have found to create it from the only edge curves such as Rhino’s EdgeCrv Command . Also with a little more digging, I can see why the BBox outline is confusing as the patch is made not aligned to the edges but containing all 4 corner points.
I think I am just used to see BBoxes previewed in other programs. Nice break down on the primer page that is very similar to how I currently work and also how I teach visual & written computational design. If i can write it as pure maths to calculate something I will try and then work up in levels of computation using solid booleans etc as the last option.
Good to know about PointAtUVParameter and then checking if it intersects with what visually remains of the surface shown, I am also used to using UVPt Trim inclusion and other on UV surface calculations in other software just not much in Dynamo lately yet.
I find its usually the same as you transfer between geometry engines/ script languages. Somethings work differently than your used to, sometimes better, sometimes not as well as hoped/ worse. Just trying to help develop the software further from a geometry side.
