Fusion API and Scripts
Got a new add-in to share? Need something specialized to be scripted? Ask questions or share what you’ve discovered with the community.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

possible bug with area/volume of export/import to step

Message 1 of 4
159 Views, 3 Replies

possible bug with area/volume of export/import to step




Edit: darn i posted this to the wrong forum....


Im not sure if this is another issue to do with step export/import in fusion or the python api.

version: 2.0.13619


I have noticed that there is a 1-3 decimal place difference  for area and volume between exporting a fusion360 file to a step and bringing it back in again to fusion. 


to recreate the problem, new document.

In a new sketch i created a sphere, and then extruded it to make a cylinder.


In the gui, if i select the body and check its volume and area it shows me a nicely rounded up number.


In fusion via the api if i look at my current in fusion cylinder i get something like this:


object:Body1 area:172.29879618644645 volume:163.36281798666926


I then export out the file to a step file.

when i open the step file up again in fusion and run the same lookup i get this:


object:Body1 area:172.2987961864465 volume:163.36281798666934



The bit of code im running is fairly simple:


app = adsk.core.Application.get()
ui = app.userInterface
# get active design
product = app.activeProduct
design = adsk.fusion.Design.cast(product)
exportMgr = design.exportManager
# get root component in this design
rootComp = design.rootComponent
# get all occurrences within the root component
rootOcc = rootComp.occurrences

bodies = []

def get_bodies(occurrences):
        get all the bod

    for occurrence in occurrences:

        if occurrence.isLightBulbOn == False:
            # app.log(f" occurrence: {} is hidden, ignoring. \n")

        parent = occurrence

        for body in occurrence.component.bRepBodies:
            if body.isLightBulbOn == False:
                # app.log(f" body: {} is hidden, ignoring. \n")

            # do something here

        if occurrence.childOccurrences:

def get_phys_props():
    show me the physical props im intereted in the textport

    for body_obj in bodies_list:
        physicalProperties = body_obj.getPhysicalProperties(

        area = physicalProperties.area
        volume = physicalProperties.volume

        log(f'object:{} area:{area} volume:{volume}')




I have attached the f3d that has my cylinder and the step file it creates.


Let me know if there is any thing else you need to trouble shoot this issue.




Message 2 of 4
in reply to: kymC6Q8L

Hi @kymC6Q8L .


I made φ72.1110255 mmX40mm in CATIA V5 and exported in Iges for comparison.


 object:Body1 area:172.2987709014681 volume:163.36280691902698


I think it is within the margin of error.
The accuracy is better than what I machined.



The accuracy displayed in the GUI should depend on the preference setting.


Message 3 of 4
in reply to: kandennti

Hi @kymC6Q8L 


I believe the source of the difference is the number of decimal digits the radius of the circle have in the exported STEP file.


If you open the STEP file in a text editor (I have to say that I don't know the STEP specification) and look for some values related to the diameter or radius of the circle, you will find 36.0555127546399 many times (this is radius of the circle, like 72.1110255 mm / 2 = 36.05551275 mm).  Here you have an snip of it:



Based on a radius of 3.60555127546399 cm and a height of 4.0 cm, the volume of the cylinder is 163.3628179866693 cm3, which has 1 less digit than the volume you get from Fusion after importing the STEP file.


Now, if you start from the diameter of 72.1110255 mm you have in the sketch on the original file, the volume should be 163.36281794462374 cm3, which is much different than the values you have in the original post (in red the difference).


I wonder why the diameter (72.1110255092798 mm vs 72.1110255mm) or radius (3.60555127546399 mm vs 3.605551275) have that difference in the STEP file when you compare it with the value in sketch.  By the way, what is the real diameter value you supply in the design?


Also notice, that all computations I added where made in Python with float datatypes, which are implemented in 64 bits.  I believe Fusion360 internally is implemented in C++ when they can use 128-bits or above to represent long doubles datatypes, which raises the precision in the computations.


Finally, I aggree with @kandennti that the difference is between the margin of error.




Message 4 of 4
in reply to: Jorge_Jaramillo

Thanks for the additional answer, @Jorge_Jaramillo .

i used the cylinder as an example as it was easy to reproduce, but i can see it in lots of different bodies that get exported out to the step format.


I come from Working in the M&E industry, so usually when you go between packages , with alembic or usd, the number saved out and brought back in is the same,  so i thought this might be a bug. 


Thanks to you both for your answers.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th

Autodesk Design & Make Report