Transformations

Jim

Is it correct that each of these forms creates the same Transformation?


tr = Geom;;Transformation.new(Geom;;Point3d.new(1, 0, 0))
p tr.to_a
tr = Geom;;Transformation.new(Geom;;Vector3d.new(1, 0, 0))
p tr.to_a
tr = Geom;;Transformation.translation(Geom;;Point3d.new(1, 0, 0))
p tr.to_a
tr = Geom;;Transformation.translation(Geom;;Vector3d.new(1, 0, 0))
p tr.to_a

TIG

I would expect so...

Chris_at_Twilight

According to the documentation, yes, they should all be identical. Though the 3rd form isn't in the docs...(I'm looking at the old ones, not the latest).

Jim

Well thanks guys - I wanted to start at the beginning.

MartinRinehart

If one of you who has figured on transformations could write a little article for those of us who haven't, it would be a GOOD THING!

TIG

This is the basic transformation stuff... TransformationMatrix.pdf

MartinRinehart

@tig said:

This is the basic transformation stuff... [attachment=0:3e59iit0]TransformationMatrix.pdf[/attachment:3e59iit0]

That confirms my worst fears.

TIG

There are several good methods for getting and changing transformations - relatively easy when you've done it a few thousand times... However, some simple ones are missing - for example if would be nice to be able to get just the angle of rotation out of an existing transformation and then reuse use it in Geom::Transformation.rotation(point,vector, angle)... As it is you can 'clone' the transformation of one thing and apply it to another but that could scale or move it too...

MSP_Greg

TIG,

@tig said:

if would be nice to be able to get just the angle of rotation out of an existing transformation

I think the below might help. I haven't tested it that much, and never with 'stretched' trans...

suATan just returns the arctan of the two numbers (x,y), x=0 => +/- 90


aT = e.transformation.to_a
  # aT[12], aT[13], aT[14]           x, y, z offsets from component origin
  # suATan(aT[0], aT[1])             xy plane angle
  # xy = (aT[8]**2 + aT[9]**2)**0.5
  # suATan(xy, aT[10]) - 90          rise angle, check this one

HTH,

Greg

chrisglasier

Can I add this topic and particularly this post, to make this topic more complete, even if duplicated in parts.

Thanks

Chris

MSP_Greg

Jim,

Can you post the file that you used for import shown?

Thanks,

greg

Jim

Here it is.

LDraw part No 3001

CPhillips

Jim, what is the problem with the brick? The axis look ok to me. Is it that the brick isn't upright?

Jim

@cphillips said:

Jim, what is the problem with the brick? The axis look ok to me. Is it that the brick isn't upright?

Yes that is all. One option would be to flip the SKetchUp axes to match the LDraw axes before inporting. But I just want the bricks to be imported using the SU axes instead of the LDraw axes - including the sub-components.

I thought it would simply be a matter of performing an axes transformation on import - but so far the solution has been evasive.

CPhillips

Looks like LDraw uses Y is up instead of Z. You could just swap the Y and Z elements when you build the points for the faces. And also swap Y and Z in the translate part of the transform. That will change the axis.

CPhillips

I tried out what I suggested and it totally didnt work. I think it is because of the way scaling is being used. Flip Y and Z and you also need to flip ScaleY and ScaleZ. That is surely possible, but I dont know how to do it.

avariant

Have you tried the Transformation.axes method? It sounds like you should be able to "remap" the standard axes using this transform. Something like Transformation.axes(ORIGIN, X_AXES, Z_AXES, Y_AXES). Just a thought, I have no idea if it will work.

Jim

That is what I tried to use, but got some crazy results. My initial reaction is to assume I am not understanding how to use them. But if Chris had a problem, I might be inclined to think it's not just me.

jessejames

@martinrinehart said:

If one of you who has figured on transformations could write a little article for those of us who haven't, it would be a GOOD THING!

What do you mean exactly Martin?

How do Transformations work on a mathematical level and all the boring details that go along with it?
How do i use the Geom::Transformtion class to trans, rotate, and scale stuff in SU?

A huge part of understanding Transformations in a mathematical sense is getting past the cryptic syntax. The good thing about a Transformation class is that you don't need to know crap about advanced math and even some basic college math principals to use the Transformation class quite easily.

Thats one thing i love about programming, code up a class that abstracts away all the details and forget about it! I'll leave the asinine number crunching to my processor!

MartinRinehart

@jessejames said:

What do you mean exactly Martin?

How do Transformations work on a mathematical level and all the boring details that go along with it?

How do i use the Geom::Transformtion class to trans, rotate, and scale stuff in SU?

2

I love those very smart people who can do #1, so the rest of us don't have to.