So I have two component instances, one is has no rotation, and the other is flipped using the SU Flip command.

Exporting them in my own data, they have the same rotation, question: is there something in the transform I should be aware of for mirroring or some attribute set ?

The Transformation associated with a ComponentInstance is what determines its position, scale, and orientation. Each instance of a particular component has its own individual Transformation. Flipping amounts to scaling by -1 about the desired direction. Iâ€™m not sure what you mean by â€śexporting them in my own dataâ€ť. To export a ComponentInstance you need to export its ComponentDefinition as well as all the instance-specific data that distinguish it. These include things in addition to the Transformation, such as applied materials, name, layer, and possibly more.

Yup, already have the instances and their specific definition exported properly, thatâ€™s the clue I was searching for, -1 for scale! thanks

â€śtr.xaxis * tr.yaxis % tr.zaxis < 0â€ť will return true when the transformation *tr* is flipped.

thanks Julia (or Christina)

Youâ€™re welcome!

Both names are fine

Bad thing is, I cant get a proper decomposition of the Transformation when flipping involved,it works ok when instance has no rotation, only flipping (scale negative), does anyone have a better function or some links/hints? thanks

What do you mean by decomposition? What data do you want to retrieve from the transformations?

Translation/Rotation/Scale (and ideally with flipping taken into account).

Separating this data is quite tricky since a rotation is mathematically the combination of skewing and scaling. TIG has written some methods to retrieve rotation angles but I donâ€™t know if they are reliable when the component is skewed.

The following code can be used to test if the transformation tr is skewed.

```
![tr.xaxis % tr.yaxis, tr.yaxis % tr.zaxis, tr.zaxis % tr.xaxis].all? { |p| p == 0 }
```

The Ruby API doesnâ€™t provide support for querying these properties, so you have to do your own calculations using the matrix representation of the Transformation, which you obtain unrolled into an Array via Transformation#to_a. You will need to fully understand the math of matrix/vector representation of points, vectors, and transformations as well as the specific subtleties of how SketchUp implements them.

If the math is over your head, you will have to hope that one of our Gurus has written suitable Ruby and is willing to share it. I regret that I donâ€™t have such in my bag of tricks and donâ€™t have time just now to develop itâ€¦

Yes, when its skewed I get ruined rotation, after my quaternion is normalized.

I am using to_a to get the matrix. Works fine when flipping but no rotation used.

Sadly I cant use the matrix by itself directly, I have to set the PRS in a game engine.

Maybe that can help if you want to run into the matrix decomposition :

This does tell me if x or y has flipped but it doesnâ€™t tell me which one flipped.

Next I have the same examples but now they are also rotated.

Mathematically there is no real difference. Flipping one and rotating a certain way is identical to flipping the other.

However - if I flip Y and rotate I get the proper result. The DXF has this 41 is scale_x 42 is scale_y and 50 is rotation. The insertion point works perfectly.

41

3.0

42

-3.0

50

30.0

If I instead flip X and adjust the rotation then it does indeed work out. The problem then is to figure out how to get the proper rotation angle.

41

-3.0

42

3.0

50

210.0

Scaling x,y,z 3.0, 3.0, 1.0

xaxis 0.8660254037844388, 0.5, 0.0

yaxis 0.5, -0.8660254037844388, 0.0

zaxis 0.0,0.0,1.0

So I must be missing something.

Transformations in general are not commutative. Order matters!

If I rotate then flip and then move into position I get the exact same transformation matrix as I do when I flip first move into position and then rotate.

I then write the Block definition into the DXF and then I write The Block insert. ALL I HAVE to work with is X, Y and Z scaling plus rotation.

Iâ€™m seeing a bit of a pattern when setting up a truth table for edge conditions etc. but I am not finished. I had hoped there would be some simple logic to determine if scale_x or scale_y should be used given a specific Transformation.origin

**FYI**: A former SketchUp team programmer once advised (and mentioned that they coded the Dynamic Components extension thus,) that compound transformations always be constructed as **translation then rotation then scaling**, and deconstructed in the opposite order.

Sounds like you are talking about Scott Lininger

Iâ€™ve been creating the transformation for cabinet parts the same way for many years without any issues. I have a method place_part(â€¦) that I use which works well. Conceptually I do the following.

I always create each part at origin and then create the transformation object in this order.

- Scalling which flips door if hinged right.
- Position door at correct x, y and z
- Rotate part
- Adjust to final position.

In this example the final adjustment to the door and drawer front is simpler think about when I now need to adjust the door gap by 1/8" and push it back into the cabinet by 3/4" (Step 4) I could have omitted that step - but then I would have had to compute x and y much differently.