Geom::Transformation.new( Vector3d ) resolved!

MartinRinehart

xform = Geom::Transformation.new( Geom::Vector3d.new(...) )

If you ComponentInstance.transform!( xform ) a translation is performed moving the component by a vector from its current location.

If you ComponentInstance.move!( xform ) your component is moved to the absolute location origin+vector.

The doc is dead wrong when it says of move!(): "This method is the same as the transform! method except that it does not record the move in an undo operation."

If you wish to translate relative to the current location in an animation, convert the existing transformation to an array; add the translation r, g, b to the existing xform[12], xform[13] and xform[14], respectively; create a new transfomation from the array and move!() to the new transformation.

These remarks also apply to groups.

Chris Fullmer

Why refer to it as r,g,b? I have not noticed that syntax elsewhere. Is it standard?

TIG

@chris fullmer said:

Why refer to it as r,g,b? I have not noticed that syntax elsewhere. Is it standard?

rgb is xyz in 'color of axis' BUT it's also rgb in any color definitions BUT xyz is always coordinates ? so I get confused too...

Chris Fullmer

Yeah, to me it is always a color. And I see now how color relates to the xyz position in SU, since the axial vectors are associated with r,g, and b. Add that to my brain's real time Martin interpereter - its my MVM, or Martin Virtual Machine.

MartinRinehart

@chris fullmer said:

Why refer to it as r,g,b?

I prefer r, g, b to x,y,z (they're identical, of course) because the ability to orbit, spinning the r and g axes every which way but loose, destroys the traditional meaning of x and y. You can have g horizontal, r vertical, for example. The steady thing about the g axis is that it's green.

Jim

And don't leave out the BoundingBox .width, .depth and .height.

A cookie to the first person to correctly match the method to the axis.

Chris Fullmer

red, x, r = width
green, y, g = height
blue, z, b = depth

That has gotten the better of me a few times in the past..... Now its finally stuck in there. I think of it as a graph on a piece of paper lying flat on a desk. Width and Height exist on the flat piece of paper, the x and y plane. Depth is coming up off the paper, or the z axis.

I like chocolate chip.

TIG

A you say, the writer of the bounding-box methods used the "classic" approach to describing 3D objects - where Z comes out of the screen = depth and x/y are width/height 'flat on the screen... This goes against every other SUp convention ! It's usual to assume you are looking at the 3D object 'in 3D' where up (Z+) is 'up in the real world = up the screen', and not looking 'from above' as if the 'ground' is the screen's surface