On Dec 8, 2007 3:04 AM, Maximilian Albert <Anhalter42@...173...> wrote:

I'd like to consult this omniscient list for a tiny bit of further information. :) The last thing I need to get to work right before I can merge my code into SVN is transformations for 3D boxes (haven't really gotten to touch them so far). Actually, I thought they shouldn't be hard to understand but I find myself fiddling with them and the things that happen are slightly different from what I expect. Would anyone mind giving me some hints as to what happens / should happen in an item's transform method?

The goal of this method is to embed as much of the transform as possible into the object's internal coordinates. If your object cannot embed anything, just return the passed matrix unchanged and it will be automatically written as transform= attribute. I think with 3d box you can embed all of transform, but not in the top-level g but into the paths of the box sides. So your transform method on the box should just pass its matrix down to the sides. If you embedded all of the transform, return NR::identity().

As I understand it, the transformation matrix is passed in, but what exactly is coded in this matrix?

The transform of the object, which is changed by any transformation method in the UI, such as scaling or moving.

It looks like an affine transformation, but which point is considered the origin?

Affine transformation doesn't need to have an origin if it's a pure move. If it has rotation/scale/skew component, it may be around any point. It may also be a product of any number of transformations with different origins. You don't need to worry about that at all.

If I simply multiply some corner, say, with this matrix then the image is off by a certain translation. Is this the translation occurring in the matrix?

You cannot judge by a single point. Any point multiplied by a matrix will give some other point, but it does not mean the transform was a move. It may be anything. Only if you transform all points of a path you will see visually whether it was a move, a rotate, or some combination. Again, this is not important for your code. Treat all matrices the same.

Where does it come from?

It means the user just wants to move or scale or rotate or whatever your 3D box - a very legitimate desire, you must make sure it works as expected and does not break anything!

Should I simply discard it (as seems to be done for sp_rect)?

Rect does not discard it either. It embeds the move and scale components of the transform and returns the remainder. So if you just move or scale a rect, it never gets a transform= attribute, all changes are embedded into its x/y/w/h. Only if you rotate or skew it, you get transform=. Since your box sides are arbitrary paths, you should better model it on sp_path_set_transform which embeds everything and always returns NR::identity().