Geom::Transformation.new( Vector3d )

Jim

Except that .move! is essentially the same as .transformation= (as far as I understand), so all you have to do is provide an absolute point.

EDIT: that might also be the source of Martin's confusion.

That would explain a lot, good observation.

TIG

I think the confusion is that .new(pt) reads like it should move 'absolutely' [from origin to point]
whereas .new(vec) clearly moves by a vector from where it is by that vector...

However it's now clear that .new(pt) moves to a point from the 'origin' where the 'origin' in the transformation origin, and not the model's ORIGIN [0,0,0] - i.e. it's relative just like .new(vec) - so there is no practical difference...

To make an 'absolute' move in model-coordinates you need to work out the transformation origin relative to the ORIGIN...

It's probably easier to simply do it in two steps - transform the instance/group so it's origin is then the ORIGIN, and then apply a move! on a .new(pt) transformation that will indeed be absolute...

Here's a go...

vec = inst.transformation.origin.vector_to(ORIGIN)
tr = Geom;;Transformation.new(vec)
inst.move!(tr)
pt =  Geom;;Point3d.new(1,1,1)
### or any model coordinate point to 'move' to...
tr = Geom;;Transformation.new(pt)
inst.move!(tr)
### inst is NOW moved [transform! without undo] from wherever it was to the model point pt absolutely.
### the move is NOT immediately see as a view.invalidate is needed
### if transform! is used then you see the move straight off.

It's 2 step but you could cunningly combine the two vectors to do it in one but why hurt your brain trying ?

MartinRinehart

@tig said:

I think the confusion is that .new(pt) reads like it should move 'absolutely' [from origin to point]
whereas .new(vec) clearly moves by a vector from where it is by that vector...

Not at all. The confusion is that my result is the exact opposite of yours. Here's a set of things from my Ruby Console. sel() returns the currently selected ComponentInstance. where() returns elements 12, 13 and 14 of the instance's transformation().to_a(). GT, P3d and V3d are typing convenience classes that extend, unchanged, Geom::Transformation, Geom::Point3d and Geom::Vector3d, respectively.

TIG

Confusion piled on confusion...
I thought I had a good handle on transformations until today...
If I'm wrong, sorry...

In any case I step back for a while until this gets sorted definitively... good luck...

MartinRinehart

@tig said:

In any case I step back for a while until this gets sorted definitively

That's scary! I'm ready to write Chapter 15 (xform matrix, applied) and as stands, going to say that all these are absolute and you need this somewhat kludgy method to translate by vector:


def translate( *args ) # add a translation vector to a transformation
    ...
    # code that puts two forms of args into offsets in r, g, b
    ...
    arr = trans.to_a()
    arr[12] += r; arr[13] += g; arr[14] += b
    return Geom;;Transformation.new( arr )
    
end # of translate()

I'm not happy with this as you can rotate and scale without poking values into the transformation matrix.

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...