PLMXML Support

Question: What is procrastination for software developers that do geometry processing? Answer: Writing importers apparently … I had some spare time and didn’t want to tackle the next big feature so I implemented yet another format: PLMXML.

PLMXML Format

PLMXML is an XML-based assembly description which usually is used in conjunction with JT files. It does not contain any geometry but just a collection of nodes, transformations, PLM meta data and references to the parts. As such it was fairly easy to parse it except for the weird way transformations are stored.

{ R00 R10 R20 P0 R01 R11 R21 P1 R02 R12 R22 P2 T0 T1 T2 S }

I’ve found some clues on the internet that it’s apparently called “eXT format” but was unable to find any precise definition. What I found out is that its shape is like this:

R00 R10 R20 P0
R01 R11 R21 P1
R02 R12 R22 P2
T0  T1  T2  S

It might look like a column-major matrix, but you should rather think of it as four different pieces of information rather than one matrix. R is a 3×3 rotation matrix but it is transposed, P is called perspective values (and apparently can be ignored), T is the translation and S is a uniform scaling factor (some place mentioned it to be the inverse of the scaling). However, in PLMXML P seems to be zero and S 1 so it basically boils down to being a transposed 4×4 matrix.

Got to check it with more data sets but so far seems to work great. The bottleneck now becomes the JT importer which unfortunately is a bit limited right now with the multiple file format versions (8.2, 9.0-9.5, 10.0) that exist nowadays, the multiple geometry representations (JT-Breps, XT-Breps, ULP, …). But that is a task for another day…