Using BoundingBox.ByCorners, it appears that the first Bounding Box created is criss-crossing the X-values from the Min/Max point inputs. But only the first of the list; all subsequent boxes appear to be created correctly. See image below. Anything I can do for this? And anyone in particular I should report this to? (FYI, using Dynamo for Civil 3D 2025.2.5)
Hi @jameshitt,
I tried googling/ looking on GitHub but I cannot find the code within this node, so I do not know exactly why this behaviour is happening. That said, maybe you could try the following (since I see youâre making your points directly before using X- and Y-coordinates lists of doubles):
- Group your X-values, and your Y-values (separately) into lists of 2 values within sublists)
- Sort those values, per sublist, so item 0 is the lower X/Y value, and item 1 is the higher X/Y value
- Get the 0th item per sublist for the min-X and min-Y coords, and make them into points
- Get the 1st item per sublist for the max-X and max-X coords, and make them into points
- Use these point lists as the input for the node.
PS, maybe you could even do some simple DesignScript code to do the sorting/ grouping even neater, but those nodes should also do the trick.
@jacob.small previously for such cases I always went to the Dynamo Dictionary, here: Dynamo Dictionary to look for nodes and how they work, but it seems that, that page doesnât work anymore (?), FYI. At least, the page loads, but I cannot search for specific nodes anymore, has this been migrated to somewhere else?
This is correct.
The bounding box is represented by a point defining the minimum X and Y values and a point defining the maximum X and Y values, based on the expanse of the two opposing corner points provided. This doesnât necessarily mean that either of the points provided define the bottom-leftmost or upper-rightmost corners.
Think about the examples below.
PointA = (0,0) and PointB = (1,1)
PointA has both the minimum X and minimum Y values. PointB has both the maximums. The represented BoundingBox would have min and max corners (0,0) and (1,1) respectively. You just so happen to provide the âminimumâ corner and the âmaximumâ corner.
PointA = (0,1) and PointB = (1,0)
PointA has the minimum X and maximum Y values. PointB has the maximum X and minimum Y. The represented BoundingBox would still have min and max corners (0,0) and (1,1) respectively. The BoundingBox still spans both points.
Both scenarios define a 1 unit by 1 unit BoundingBox located at (0,0).
Something might be flying right over my head, but that just doesnât seem right. In image below, you see how the coordinates with the x-values swapped (the way they are in the node above) generate a completely different bounding box from the coordinates with the x-values correctly assigned to the respective Min/Max points. Additionally, why does every subsequent point after the first one have the correct corresponding x/y values going to the correct Min/Max point in the BoundingBox node? That all by itself just doesnât appear to be correct behavior.
(Iâm not sure what the takeaway from your reply is supposed to be.)
The by corners node isnât going to define the bounding box rotated as it predates non-axis aligned bounding boxes.
As such the team who built the node had a choice of two options.
Option one was having the node return null of point 1 wasnât minimum (so the X, Y, and Z value were less than point two). This option would suck as 1/2 of all possible bounding boxes would fail.
Option 2 is to extract the min point and max point between the two points given. This will always work.
Letâs take a moment to work out how this works as I think youâll understand it better this way. Grab an imaginary piece of graph paper and draw a rectangle which which (although 2d only) will represent a bounding box - weâll assume it has corner points at (-1,-1), (1,-1), (1,1), and (-1,1). Now try to work out all the ways we can pick two points on our box to return it - basically recreate the node that draws a bounding box from two of those points. You have a choice of point 1 and point 3 or point 2 and 4 (the pairs 1-2, 2-3, 3-4, and 4-1 all return lines not our bounding box). If the points you have are 2 and 4, the bounding box returned is the same as if you provided 1-3. But Dynamo only stores the 1-3 pair in the bounding box definition, though, so even if you provide the 2-4 pair youâre seeing the 1-3 pair. Fortunately it is the same
Bounding box as when you draw the box by the 1-3 pair the output is the same.
The picture definitely helps. I guess I didnât realize that the base BoundingBox.ByCorners for C3D is somehow determining local axes for the bounding box. For Revit and Sandbox, theyâre globally aligned with the base node - which is why I said order doesnât matter in my previous response. (I might be missing something here, but weird discrepancy.)
However, since you donât specify alignment with that node, Iâm guessing itâs still not a bug. That is a valid bounding box for those two points. My guess is the node defaults to âlower leftâ and âupper rightâ corners like I mentioned. Basically, the points you provide determine the draw direction of the bounding box by ensuring that the âmaximumâ point is up and to the right of the âminimumâ point.
All of your other point pairs (that we can see in the screenshot) follow the first scenario in my previous example. Both X and Y coordinates increase from the input min point to the input max point. However, this isnât the case for your first pair: your minimum point X (3461539.272) is greater than your maximum point X (3461533.888). This is essentially causing the orientation of your bounding box to âflipâ. Youâre wanting the box to be drawn âdown and to the rightâ (negative direction) but Dynamo always draws it âup and to the rightâ (positive direction). This means your pairs should always correlate to a (+,+) (or the inverse (-,-)) change in position. A (+,-) or a (-,+) change corresponds to corners 2 and 4 instead of the min and max corners 1 and 3.
The Fix: The workaround is fairly simple. You need to check your relative point locations before creating the bounding box. If your points donât correspond to the correct corners for the bounding box orientation, then you just rotate them 90 degrees first.
Summary:
- Dynamo expects the min-max corners to be bottom left to top right (
). - Inverted corners or reversed order (
) is fine since the bounding box is symmetric. - Top left and bottom right corners (
or 
) represent non-min/max corners and will orient incorrectly. Rotate to fix.
Hope that helps. Itâs late and I know that was a bit much.
I see, I think my mistake is misunderstanding that those inputs arenât correspondingly âhardwiredââ(?) to generate the BoundingBox nodeâs âMinPointâ or âMaxPointâ output values.
So, the âminâ input doesnât just get turned directly into the output âMinPointâ (and same for âmaxâ and âMaxPointâ. Thatâs the takeaway that I kept missing.
Thank you!
Dictionary works but the flag for 2.0 is removed as the 1.0 version was taken down (or so it seems). Try removing the trailing path after the domain and see if that fixes it for you.
Content there is pretty stale though and wonât be accurate forever, so you may want to start providing hot links to the in-product documentation (extended node help - right click the node and select âhelpâ). Iâve asked a few times about getting things updated but thatâs a BIG lift and the team has other priorities that have to take precedence.
Ok, I see, yes before I always used this trailing #2 because the v1 / v2 documentation often had big discrepancies, with v1 often being very outdated and v2 often having what I needed.