Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.

Programmatically access dimensions of parts by pulling BRep 2D info?

drew
Advocate

Programmatically access dimensions of parts by pulling BRep 2D info?

drew
Advocate
Advocate

Fusion's included BOM script/plug-in uses the dimensions of the bounding box to report the dimensions of the object.

 

Other user-created scripts/plug-ins also seem to be using the bounding box to derive measurements presented in the BOM output.

 

But the bounding box is not reliably the size of the part - which matters if you are trying to generate a BOM for use in manufacturing:

To cut parts from stock you need to know the size of the part to know how much material of any given thickness you will be using.

 

I have dug into the documentation available via the Fusion/Autodesk website about how the actual measures might be pulled out of Fusion, and it seems like the best approach may be to access the bodies themselves - specifically to pull out the BRep information on the bodies.

 

If this is a valid approach, it might be the BRep 2D information that is the true target?

 

Since I am NOT a programmer, I am way in over my head here - and can only grasp the structures of the data from a 'somewhat competent layperson' point of view.

 

I wanted to ask those here in the API section of the community what their thoughts are regarding this issue, and their thoights on whether writing code to access the BRep 2D information is a sensible idea...

 

I do know that there are a lot of users searching for ways to get a 'shop floor usable' BOM out of Fusion, and I am hoping to find a path forward that provides solutions to that user segment.

 

Please chime in!!!

0 Likes
Reply
903 Views
4 Replies
Replies (4)

drew
Advocate
Advocate

Here is a sample design I created for use in this post thread, and an image of the current BOM output. 

 

It has examples of the basic situations that present challenges for end users when they try to use BOM or CSV-BOM (a user-created plugin) as they currently work.

CSV-BOM link: https://apps.autodesk.com/FUSION/en/Detail/Index?id=2857656002406992603&appLang=en&os=Win64

 

Running either tool against this design will create dimensions that do not reflect the actual sizes of the components.

 

 

0 Likes

ekinsb
Alumni
Alumni

As far as I'm aware, what you want doesn't currently exist.  However, the needed functionality exists in the API so that someone could write an add-in that does this. One of the issues is getting an accurate overall size of a model.  I wrote the blog post below to describe the process, which is a piece of the entire puzzle.  Someone still needs to put it together although the pieces are all there.

 

http://modthemachine.typepad.com/my_weblog/2017/06/getting-the-overall-size-of-parts.html


Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
0 Likes

Anonymous
Not applicable

Ive seen other CAD APIs overcome the BoundingBox issue by generating the box based on a local coordinate system to the part. This allows for the limits to be more accurate as they are not projected onto an existing XYZ plane.

 

I looked at the existing Fusion API to see if they have similar functions but seems like you would have to code the coordinate translations manually. 

 

Here is the pseudo code and some of the issues I am seeing. Would love any inputs or direction on where their might be Fusion APIs that Im not aware of.

 

1. Get the part

2. Align a local coordinate system to the part ( The other API I looked at let you directly get a coordinate system from the part API. Fusion doesnt appear to have this function so Ive come up with this heuristic )

2.1 Get largest area plane on part

2.2 Get the longest side of the plane. This becomes one of the axis

2.2 Get the normal to the plane. This becomes the second axis

2.3 Use 1st and 2nd planes to determine the 3rd axis

3. Calculating bounding box of vertices and project them onto the local coord system

 

I think this will give you a more accurate bounding box. For simple parts it should be very accurate. More complex might give you more mixed results. 

 

 

0 Likes

ekinsb
Alumni
Alumni

Actually it is possible to get the bounding box in the local coordinate system.  It all has to do with the "context" that the object represents.  Here's an example.

 

If you have a design that has the structure represented below there are four components represented; TestDesign (which is the root component), Part1, Sub1, and Part2.  Part1 is visible 3 times in the design and is represented by the occurrences Part1:1, Part1:2, and Sub1:1/Part1:1.  To make it simple, lets say that Part1 contains one body which is represented by a BRepBody in the API.  I can have a reference to the BRepBody with respect to any of the three representations that you see.  These are referred to as proxies since the BRepBody object is acting as a proxy of the real body and will return information as if the body exists in that location and orientation.  So, getting the bounding box for each of those representations will return a different result based on the position and orientation of the occurrences.  However, I can also access the real BRepBody in the Part1 occurrence.  This will return the bounding box in the local coordinate system of the component. There's a better description of components, occurrences, and proxies in the API User's Manual

 

TestDesign

    Part1:1

    Part1:2

    Sub1:1

        Part1:1

        Part2:1

 

If you compute the bounding box relative to the local coordinate system of the component then it will need to be returned in some other way besides a Box because the bounding box can be oriented.  This can easily be done but there isn't anything in the API today that represents an oriented bounding box so you will need to create your own data structure to represent this.

 


Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
0 Likes