Geom::Transformation.new( Vector3d )

Chris Fullmer

I have notlooked into this yet. I wanted to play with this topic extensively last night, but did not get a chance. Maybe today I will have a chance.

Chris

Chris Fullmer

I think Chris Thompson nailed it when he noted that .move! is actually equal to the .transformation = method, not the .transform! method. So the docs are wrong on that. That is why it moves to a given point, and it resets the scale and rotation - exactly how .transformation = does because it entirely resets the object's transformation object.

So far I think all your observations are accurate Martin. .move is moving to a specific point (again, because it is reseting the objects transformation) and none of the Transformation.new (pt) or (vec) or translate(vec) are going to move an object to a specific point, but rather move by a vector. But that is because of the transform! method. It is merely multiplying the objects existing transformation by the new supplied one. So first moving the object to 0,0,0 then transforming (as in TIG's example) is the way to get to a specific point. Or you could determine the vector from your object's current origin to the desired point and transform by that vector in a single transformation.

There would need to be a .translate_existing_transformationmethod implemented to make it work to move an object to a given point by only specifying a point and providing an existing transformation object.

All in all, this is interesting. I had not noticed there was no way to move an existing transformation to a specified point using the existing methods. I've always done it the way I noted, by finding the vecftor that I want to move to, then move by that vector. It would be a nice new method for them to add. Feature request?

Chris

thomthom

So the .move! is pretty if you want to preserve rotation and scaling..?

Chris Fullmer

@thomthom said:

So the .move! is pretty if you want to preserve rotation and scaling..?

is pretty...? Did you skip a word, "useless"?

You can still use the .move! method and preserve scaling and rotation. Like this works:

my_comp = Sketchup.active_model.selection[0] t1 = my_comp.transformation.to_a pt = [10,10,10] #This is a desired xyz coordinate location. t1[12] = pt[0] t1[13] = pt[1] t1[14] = pt[2] t1 = Geom::Transformation.new( t1 ) my_comp.move! t1

It just requires that you first get the original transformation from the group, then change the xyz position of that transformation manually, then use the .move! method. At least that is what I am finding.

thomthom

@chris fullmer said:

is pretty...? Did you skip a word, "useless"?

uuuh... it was the forum gnome... ...you know, them little naughty devils!

MartinRinehart

move!(xform) and its cousin transform!(xform) take the location from the new xform, but they multiply the 3x3 rotation/scale matrices of the old and new xforms.

SketchTalk examples (sel = model.selection[0], o = sel.transformation.origin):
q sel, o, 'rg', 180 # rotate selection 180 degrees
q sel, o, 'rg', 1, 180 # animated: 1 degree, 180 times

The make_normal() method returns [0,0,1] if called with 'rg'. draw() invalidates the view. This is the code that SketchTalk calls for q ... commands:


def qrotate( *args ) # ( comp, pt, plane_or_normal, angle[, ntimes] )
=begin
Qrotate component around axis set by pt plus plane_or_normal, by angle degrees.

"comp" is any ComponentInstance. 
"pt" is an [r,g,b] array. 
"plane_or_normal" is "rg", "gb", "rb" or another [r,g,b] array. 
=end

    if args.length == 5
        ntimes = args.pop()
        id = UI.start_timer( 1.0/$sketch_talk_fps, true ) {
            qrotate( args[0], args[1], args[2], args[3] )
            ntimes -= 1
            UI.stop_timer( id ) if ntimes == 0
        }
        return
    end
    
    comp = args[0]

    unless comp.is_a?( Sketchup;;ComponentInstance )
        UI.messagebox( 
            'Qrotate; first argument must be a Sketchup;;ComponentInstance' )
        return
    end

    normal = make_normal( args[2] )
    angle = args[3] * $radians_per_degree
    
    trans = Geom;;Transformation.rotation( args[1], normal, angle )
    comp.transform!( trans )
    draw()

end # of qrotate()

There is a warning box in the text that looks like this:

MartinRinehart

If you use any of the three methods for creating a new, absolute location ( xform.new( Point3d ), xform.new( Vector3d ), xform.translation( Vector3d ) the 3x3 portion of the returned xform is the identity matrix. When comp.move!() (or transform!()) is called, the existing rotation/scaling is nicely preserved.

Please be very careful about agreeing with me as I am disagreeing with TIG. The smart money is almost always on TIG.

TIG

@martinrinehart said:

If you use any of the three methods for creating a new, absolute location ( xform.new( Point3d ), xform.new( Vector3d ), xform.translation( Vector3d ) the 3x3 portion of the returned xform is the identity matrix. When comp.move!() (or transform!()) is called, the existing rotation/scaling is nicely preserved.
Please be very careful about agreeing with me as I am disagreeing with TIG. The smart money is almost always on TIG.

Oh no it isn't
I am getting totally bamboozled by this transformation stuff - which I thought I understood quite well - till last week !
It doesn't matter who's right and who's wrong - let's just get the definitive answer and the right/simplest way to do what we want...

MartinRinehart

TIG, as always, was right. If you transform!() the translation is relative to the current location.

I was right, too. If you move!() the translation is to the specified point (or to origin + vec, if you specify a vector, which comes out to the same thing).

The doc, which says the two are the same, is dead wrong. (Or the doc is right and the code is wrong. We'll never know.)

TIG

@martinrinehart said:

TIG, as always, was right. If you transform!() the translation is relative to the current location.

I was right, too. If you move!() the translation is to the specified point (or to origin + vec, if you specify a vector, which comes out to the same thing).

The doc, which says the two are the same, is dead wrong. (Or the doc is right and the code is wrong. We'll never know.)

A relief to know that neither of us was going mad
I'd never use move! anyway - unless in an animation...