What's new

Transformation matrix has scaling that doesn't match the STEP file.

I want to export a STEP file then transform it according to the assembly's WorldTransform but it's including a scale factor of 2.54 (inch to cm) which makes the resulting part too big. How should I handle this reliably? Perhaps always remove scaling from the transforms because there's no valid use for them? LocalTransform is the same.

My code for getting the transformation and STEP file is:
Code:
        Dim assemblySession As IADAssemblySession = RootObj.OpenFileEx(assemblyFileName, False)

        For Each occurrence As IADOccurrence In assemblySession.RootOccurrence.Occurrences()
            For Each value As Double In occurrence.WorldTransform.Array()
                Trace.WriteLine(value)
            Next
            occurrence.DesignSession.ExportAP214("c:/users/ggpc/desktop/b")
        Next

        assemblySession.Close()

Output is:

Code:
2.54
0
0
0
0
2.54
0
0
0
0
2.54
0
-0.347747921943665
-0.00279688835144043
0
1


EDIT: I notice the STEP file it generates has GLOBAL_UNIT_ASSIGNED_CONTEXT set to inches whereas normal parts have it as centimeters. So it looks like the transform would work correctly if you ignored the units in the STEP file and assumed they were always in cm. Unfortunately, the library I'm using to read STEP files doesn't do that.
 

Attachments

  • b.AD_ASM
    220 KB · Views: 1
  • Bearing.AD_PRT
    1.3 MB · Views: 1
Last edited:

stepalibre

Alibre Super User
I want to export a STEP file then transform it according to the assembly's WorldTransform but it's including a scale factor of 2.54 (inch to cm) which makes the resulting part too big. How should I handle this reliably? Perhaps always remove scaling from the transforms because there's no valid use for them? LocalTransform is the same.

My code for getting the transformation and STEP file is:
Code:
        Dim assemblySession As IADAssemblySession = RootObj.OpenFileEx(assemblyFileName, False)

        For Each occurrence As IADOccurrence In assemblySession.RootOccurrence.Occurrences()
            For Each value As Double In occurrence.WorldTransform.Array()
                Trace.WriteLine(value)
            Next
            occurrence.DesignSession.ExportAP214("c:/users/ggpc/desktop/b")
        Next

        assemblySession.Close()

Output is:

Code:
2.54
0
0
0
0
2.54
0
0
0
0
2.54
0
-0.347747921943665
-0.00279688835144043
0
1


EDIT: I notice the STEP file it generates has GLOBAL_UNIT_ASSIGNED_CONTEXT set to inches whereas normal parts have it as centimeters. So it looks like the transform would work correctly if you ignored the units in the STEP file and assumed they were always in cm. Unfortunately, the library I'm using to read STEP files doesn't do that.
Handle the conversion yourself in code or change the unit setting in the part to cm before you run the code. I have a cm template for STEP files and work in cm which is the internal unit.
 

stepalibre

Alibre Super User
EDIT: I notice the STEP file it generates has GLOBAL_UNIT_ASSIGNED_CONTEXT set to inches whereas normal parts have it as centimeters. So it looks like the transform would work correctly if you ignored the units in the STEP file and assumed they were always in cm. Unfortunately, the library I'm using to read STEP files doesn't do that.
It's a STEP file exported or imported from your app? What library are you using? When working with Alibre I export in cm to keep things simple.

Edit:
Not all translators or software support the same features. FreeCAD support more STEP features than Alibre.
 
Last edited:

stepalibre

Alibre Super User
Handle the conversion yourself in code
Similar to this:
Code:
    Dim assemblySession As IADAssemblySession = root.OpenFileEx("C:\Users\steph\Downloads\b.AD_ASM",False)
    For Each occurrence As IADOccurrence In assemblySession.RootOccurrence.Occurrences()
        Select Case occurrence.DesignSession.DesignProperties.ModelUnits
            Case AlibreX.ADUnits.AD_CENTIMETERS
                For Each value As Double In occurrence.WorldTransform.Array()
                    Console.WriteLine(value)
                Next
            Case AlibreX.ADUnits.AD_INCHES
                For Each value As Double In occurrence.WorldTransform.Array()
                    Console.WriteLine(value / 2.54)
                Next
            Case AlibreX.ADUnits.AD_MILLIMETERS
                For Each value As Double In occurrence.WorldTransform.Array()
                    Console.WriteLine(value)
                Next
            Case Else
        End Select
    Next
    assemblySession.Close()
   
   
    1
0
0
0
0
1
0
0
0
0
1
0
-0.136908630686482
-0.00110113714623639
0
0.393700787401575
 

stepalibre

Alibre Super User
How should I handle this reliably? Perhaps always remove scaling from the transforms because there's no valid use for them?
Edit:
I normally use transform. Decompose() so my code don't use scale and shear because I never use them. When I do it's only for debugging. I was thinking about unit conversion because your files are in mm my mistake. That's why I was confused. I'll keep what I wrote below.

The most reliable method is to check the incoming type or value and decide what to do for each case. It depends on your process for reading and writing files and what features the STEP translator has built into the library.

The bearing is a SAT file:
1713213960065.png

The Alibre assembly and part are in mm and you're exporting to AP214. There may be a unit mismatch somewhere in the process, resulting in the wrong unit being return or a related issue. This might be unrelated to the code in general, but if you open the Alibre files and the measurements don't reflect your program's output, this can lead to problems.
 
Last edited:

stepalibre

Alibre Super User
Side note about transformations, my post here:


And @NateLiquidGravity had this answer about scale/shear:

 
Last edited:
I missed this. I struggle with this version it's not widely supported.
Same behavior with AP203.

The STEP file is imported into my application. There's no issue with that because other software, including in Alibre itself imports it the same size.

Thanks for your other suggestions. I'll look into them later on.
 
Similar to this:
Code:
...
                For Each value As Double In occurrence.WorldTransform.Array()
                    Console.WriteLine(value / 2.54)
                Next
...

I'll probably end up doing this. But it doesn't work exactly like that. The translation values are still in cm, so they shouldn't be scaled, only the first 3 rows.
 

stepalibre

Alibre Super User
I'll probably end up doing this. But it doesn't work exactly like that. The translation values are still in cm, so they shouldn't be scaled, only the first 3 rows.
What is the final unit you expect? You determine the conversion calc. I suggest creating demo projects and test cases for expected vs actual outcomes from your code and models. There are a lot of variables here.

Some notes:
The internal unit is cm. Some view the internal unit as unitless (the internal math have no knowledge of a unit system), but base/default unit in the software is cm. ACIS uses cm.

The display units we see in the GUI can vary:
1713270268967.png
If the display unit is cm then the values coming from Alibre's API would match.

When the display unit is not cm unit conversion takes place automatically in the GUI. Alibre APIs are missing complete design properties functionality. My projects include many APIs (generally filling gaps) that allow full control of display units properties and built-in unit conversion functions.

In my custom apps:
1713271704599.png
I convert to and from any unit as needed with display unit features.
The model in Alibre:
1713272084698.png
In cm:
1713272134565.png
Inch:
1713272193007.png

When working with imported and exported files it's important to match the desired units based on this in your code. Software allows changing the units on import or export. This can create scale issues when used in other software. I account for this in my projects.

I only transfer transformation results from Alibre to my projects where I do the actual work. I only apply conversion functions to transformation results essentially, they are consumed read-only in my projects. The Alibre model parameters are what change the results returned from transformations.

Alibre does not provide a complete API many features are missing. It also lacks convenience methods for .NET and C++ programming. Alibre development is by far the worst in my experience. The purpose of my GitHub repos is to improve things, I'm on my own.
 

DavidJ

Administrator
Staff member
May or may not be relevant to your issue. Alibre only uses cm as Model Units for natively created files. If files are based on an imported file, the Model Units of that file will determine Alibre's model units for subsequent activity with that file.

So whilst often true, it is not safe to assume that Model Units in Alibre are always cm.

It is possible to query the model units via the API to check what units are in use.
 

simonb65

Alibre Super User
Alibre does not provide a complete API many features are missing.
Suggest items for API improvement to the Alibre dev team.

It also lacks convenience methods for .NET and C++ programming. Alibre development is by far the worst in my experience.
I've written many API based add-ons and external productivity applications for use in my company and never found any shortfalls in accessibility to underlying model geometry in the current API ... other than lack of 2D drawing support!
 

stepalibre

Alibre Super User
Model Units
Model units = internal units in my posts.
If files are based on an imported file, the Model Units of that file will determine Alibre's model units for subsequent activity with that file.
Yes. As I mentioned other applications allow you to change the file unit on import and export. This is important in Alibre development I have seen notes in the docs. I handle this myself with my own functions. APIs can have built-in unit converters. Dynamo's SAT node and API is an example:
1713278862825.png
So whilst often true, it is not safe to assume that Model Units in Alibre are always cm.

It is possible to query the model units via the API to check what units are in use.
I call this the unit mix/match problem. It's solved by checking on import/input and ensuring the correct unit and conversions if required are done on export/output.
Suggest items for API improvement to the Alibre dev team.
I think bolsover, NateLiquidGravity and others have given suggestions. The first step would be the placeholders throughout the API. Add what's not implemented. Ideally there should be an increase in parity between the GUI and the API with every new release. I develop using paid and opensource graphics and CAD components to fill gaps. Headless mode is great and is becoming my default way of interacting with AD.
 

stepalibre

Alibre Super User
If files are based on an imported file, the Model Units of that file will determine Alibre's model units for subsequent activity with that file.
From code the unit is cm. I'm not sure how Alibre handles this for each format and format version. Is it safe to assume it's the same for all? The SAT exports don't match other SAT exports I create for particular SAT versions. The exports don't work in Dynamo, and the generated output does not seem correct. I have since built tools to make it work, but that's a long story.
 

DavidJ

Administrator
Staff member
Imported files will already have their own model units which Alibre will follow. I'm not at all experienced with the API or many of the internal workings, I've just learned things over many years (mainly from a user perspective) and have needed to be able to check what the model units are when diagnosing certain problems.

Files created wholly in Alibre will use cm as model units.
 

stepalibre

Alibre Super User
@LuminescentLoom I have projects on hold that incorporates Alibre features. One issue was related to mates breaking and other assembly issues which was fixed in build V27:29. The idea is to build models, taking advantage of all the powerfully built-in parametric and feature based tools. My apps import Alibre files with a link back to Alibre data. Rhino's 3DM format is used as the file format, program data is all stored in plain text formats. I have a related project see link below. I'm not working on assembly code to check if build V27:29 resolved my issues. Quick tests were positive, but I hesitate to comment. If I updated parameters in parts or assemblies, transformations would not all update. This is the returned transformation data in code, the actual changes were successful. If I made changes, killed and restarted the process everything was fine. My conclusion at the time was it must be a bug somewhere that was not properly fully regening. What was strange is that the updated transformations were available. I had to call into an occurrence other ways to get the updated transforms. My solution is two tasks that kill and restart the headless process.

I'll work on publishing my test data with code on GitHub. Post the CAD files on my website too large for GitHub. Here is a related project:
~roughly assemblies -> parts -> configurations -> features -> sketches -> entities -> dimensions -> parameters . That data is entities.
 
Last edited:
Top