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

[stepalibre]

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.

Thanks, David. This is all related it's the same underlying system.

 

[LuminescentLoom]

Thanks for your help everyone. I've had clarification from Alibre directly and my conclusion is:

Part transformation matrices transform from part space in whatever its model units are to assembly space which is always cm, so they include scaling to convert from part model units to cm.

The translations in the matrices are always cm, regardless of the model units of the part (or anything else since assemblies are always cm). I guess that's because translation is applied after scaling to cm.

 

[stepalibre]

Great you got a solution. With limited information I tried to share ideas. @Max dev team it would be great if we could have a statement directly from you. Do I need a support ticket?

 

[LuminescentLoom]

Oops, I was wrong, but it still seems to make the same sort of sense. Assemblies can be in non-cm units if they were imported. This is what I've found from testing:

Assembly (inch)
├── Part1 (inch)
└── Part2 (mm)

The WorldTransform for Part1 has:
- No scaling because it's scaling from inch to inch.
- Translations in inch because the root assembly is inch.

The WorldTransform for Part2 has:
- Scaling of 1/25.4 because it's scaling mm to inch.
- Translations in inch because the root assembly is inch.

In all cases, the STEP file for a part is exported the correct size and doesn't require any scaling.

 

[stepalibre]

What I was explaining is regardless of the unit of the Alibre file imported or natively made your program should verify the unit and do conversions (as needed) before any work is done, before transform.WorldTransform is called. You can call transform.WorldTransform first to verify the returned values, as a checking step, not as the final step.

 

[LuminescentLoom]

What I was explaining is regardless of the unit of the Alibre file imported or natively made your program should verify the unit and do conversions (as needed) before any work is done, before transform.WorldTransform is called. You can call transform.WorldTransform first to verify the returned values, as a checking step, not as the final step.

I don't really understand. Verify units against what? I don't have any reason to suspect Alibre is ever wrong so why not just trust it to behave consistently? Are there some known bugs that need to be guarded against?

What my program does is opens arbitrary user-supplied Alibre assemblies and exports their parts in their assembled positions to STEP files.

 

[stepalibre]

What my program does is opens arbitrary user-supplied Alibre assemblies and exports their parts in their assembled positions to STEP files.

No bugs related to this. This was key.
I asked if it was an import or export from your app or Alibre, I wasn't sure and you didn't answer.

It's a STEP file exported or imported from your app?

 

[LuminescentLoom]

Sorry. Since I found out, I might have neglected questions in the other posts.

I was ambiguous about perspectives. Let me try again: My application tells Alibre to open an assembly and export its parts to STEP files. My application then reads those STEP files (using a library that converts them to triangulations and meshes) and transforms those meshes into their assembled positions using the matrices it got from Alibre.

 

[stepalibre]

I give examples and ideas that might be unrelated to the core question, but they are better than nothing I hope. I can't let the Add-on Development forum die while I drive a V27.

 

[DavidJ]

I give examples and ideas that might be unrelated to the core question, but they are better than nothing I hope.

Please tread carefully - a response which is not relevant to the original question might be confusing and hence create extra difficulty. As a minimum perhaps add some extra context if straying from the subject, so everyone is clear what is happening.

 

[stepalibre]

As a minimum perhaps add some extra context if straying from the subject, so everyone is clear what is happening.

Agreed. I continue to forget Alibre's forum is different. The solution is what should be important. My license was originally for personal projects since ~7-9ys. I've decided to open source some of them. Since I'm not restricted by an employer or an NDA, I can share examples and ideas. I'll be waiting for your email in the meantime.

 

[stepalibre]

Oops, I was wrong, but it still seems to make the same sort of sense. Assemblies can be in non-cm units if they were imported. This is what I've found from testing:

Assembly (inch)
├── Part1 (inch)
└── Part2 (mm)

The WorldTransform for Part1 has:
- No scaling because it's scaling from inch to inch.
- Translations in inch because the root assembly is inch.

The WorldTransform for Part2 has:
- Scaling of 1/25.4 because it's scaling mm to inch.
- Translations in inch because the root assembly is inch.

In all cases, the STEP file for a part is exported the correct size and doesn't require any scaling.

No bugs related to this. This was key.
I asked if it was an import or export from your app or Alibre, I wasn't sure and you didn't answer.

For the record, I wasn't sure if you had imported the STEP file and changed the unit during the import process. Sorry for the mix up.

 

[LuminescentLoom]

For the record, I wasn't sure if you had imported the STEP file and changed the unit during the import process. Sorry for the mix up.

OK. That makes sense what you meant about verifying the unit now.

This experience has changed my view of Alibre units from "almost always cm" to "anything, anywhere". You can have whatever mixture of units you like all up and down the assembly tree and cm might as well not be special if there's any chance of a user importing their own step/sat/etc. file.