Transformations
-
rrright... I'm not able to digest that comment just yet. (waiting for my dinner) ... But , about your airplane...
You're making an airplane fly around following a path?
Are you transforming the edges and faces themself to make it fly? or are you transforming a group/component containing the plane?
How do you control the plane? control path?
(Just trying to get the general scheme of what you are doing before getting into the nitty gritty coding details.)
-
@thomthom said:
rrright... I'm not able to digest that comment just yet. (waiting for my dinner) ... But , about your airplane...
Oh ! sorry
@thomthom said:
You're making an airplane fly around following a path? Are you transforming the edges and faces themself to make it fly? or are you transforming a group/component containing the plane?
How do you control the plane? control path?
(Just trying to get the general scheme of what you are doing before getting into the nitty gritty coding details.)All right, I will explain.
I don't use any transformation on edges and faces because it is really too low level for my animation, I just take the plane as a solid object and have it fly like this, without internal animation.My purpose is to have a plane flying in a close room and the camera followin it so that it is always in the field of view, from behind, in a tenth of the image maybe. I want to have a video of 25s out of it.
What I did first was to create a close loop as a Bézier spline using Fredo6's impressive tool.
Secondly I used Pixero's BZ_animator to get the camera follow the flypath and the scenes created accordingly.
You may say that it is not very convenient to have something like 600 scenes (aka frames) but as SketchUp first move the camera, THEN your object, I had to use it like this. I simply set the transition time 1/25s.Thirdly, I had to move my plane along the camera path, and I didn't find anything to do it properly so I just grab an older version of Morisdov's Proper Animation to understand the mechanism he was using. So far, I can move the plane along the spline/flypath, so it's working rather fine.
All I have to do to have something correct is to deal with the orientations: so far only the position of the plane changes.I haven't thought of my script as something that could be re-usable by other users so far, so my developments are completly focused on my goal. But once I have something decent I'll post it somewhere so that others can see what I did and may propose enhancements or other ways to do this.
-
Right. And you need the orientation of your plane group. The transformation class has an
axes
method that I think could be used to get your bearings. -
I don't really see how, TT...
In the meantime, to illustrate what I say:
-
If your plane is a component, then I believe it's orientation if constant based on how the component axes were defined originally. If your plane is not entering the model with consistent orientation, that suggest your placement transformation is rotating it rather than doing a strict translation. Once you've discerned your original orientation, it should be a simple matter of adding a rotation to orient the nose to the directional tangent to the spline then having your "up" vector rotate around the tangent until its parallel to the z-axis.
-
@cleverbeans said:
If your plane is a component, then I believe it's orientation if constant based on how the component axes were defined originally. If your plane is not entering the model with consistent orientation, that suggest your placement transformation is rotating it rather than doing a strict translation. Once you've discerned your original orientation, it should be a simple matter of adding a rotation to orient the nose to the directional tangent to the spline then having your "up" vector rotate around the tangent until its parallel to the z-axis.
Thanks Cleverbeans! Yes indeed you're right, if I have the initial orientation of my plane I should be able to retrieve the orientation at any time... And I may do this in the end but I'm not too fond of this.
First because I don't really know the place of my plane at the first frame (cause I placed the plane and scaled it in the room to fit my purpose).
And secondly, (I could but) I will not place my plane at the origin with the right orientation and put my scene around just because there is no simple way to find the actual orientation of a selected component! I feel like it's really a basic feature to be able to know the precise location and orientation (and, to be exhaustive, scale) of my component at any time. Plus I will further add other planes and may have to do more complicated things in the future.So I am really looking for a mean to find the exact orientation of a component at any time.
-
However, Cleverbeans, an idea would be to integrate my plane as an external component and tailor the parameters so that it fits in my scene... That can be an idea, but I'll look into that once I'm desesperate !
-
@zitoun said:
@thomthom said:
The transformation class has an
axes
method that I think could be used to get your bearings.As I see it,
Transformation::axes
method only enables to SET the axes, unfortunately not to GET them...
Sorry - I refereed to the wrong methods.
instead, usexaxis
,yaxis
andzaxis
http://code.google.com/apis/sketchup/docs/ourdoc/transformation.html#xaxisand of course the
origin
:
http://code.google.com/apis/sketchup/docs/ourdoc/transformation.html#originEverything is there in the transformation object.
-
@thomthom said:
The transformation class has an
axes
method that I think could be used to get your bearings.As I see it,
Transformation::axes
method only enables to SET the axes, unfortunately not to GET them...
EDIT: but maybe I should just SET the initial transformation, just like that... OK, let's try this.
But I still think it should be a standard feature to get the absolute or relative rotation matrix/quaternion for any component of the scene...RE-EDIT: I hadn't seen
Transformation::Xaxis
,Yaxis
andZaxis
method!
I have no clue what these are yet, but I guess I somehow can retrieve my rotation matrix from such component... -
@thomthom said:
In the same way my example took the local 3d position and transformed it with the combined transformation for all the containing groups/components you must apply the combined transformation to your vector of orientation/direction.
Sure thomthom, I get that. My pb is deeper... OK, I have to give the details! Here is what I understood so far:
An object has a 4x4 transformation matrix M attached that combines three parameters defining the geometrical state of the object:
- the position T in space
- the orientation R
- the scale S
Let's say I want to rotate my object (entity is the correct term I think) without changing the position: I will have to
- apply to M the inverse of the translation T (so far I use [0,0,0]-T)
Sketchup.active_model.active_entities.transform_entities(ORIGIN-fromPos,e) #puts the objet at the origin
- then apply the relative orientation dR I need
Sketchup.active_model.active_entities.transform_entities(Geom::Transformation.rotation(ORIGIN,UP,angle),e)
- and finally apply back the translation T.
You may say I should simply use the M.inverse but I think the scale factor would be a probl****em... Or not? (testing around) ... All right. Seems we can simply do :
- apply M.inverse,
Sketchup.active_model.active_entities.transform_entities(e.transformation.inverse,e)
- apply dR
- apply M back
Should be OK.
And here comes my tiny problem: current orientation R of the object is somehow melted with the other parameters T and S in global my transformation matrix M... How the hell do I get a proper orientation R?
Cause I already know the final absolute orientation R' I want my object (or entity, or, in my case, a good old german biplane) to reach: all I need is this initial orientation R to compute the difference dR.I thought to just get rid of the transformation, discard it and return to the identity and thus apply directly the wanted orientation R', then the position T. But it would be too easy: to fit in a small room, my plane had to be scaled, and I then need to know this scale factor S (that I otherwise simply ignore).
This special line is to thank the reader for the effort he put to read my reply.
And this one is for the people that would give me some clues: I owe you! -
OK, I surrender, I chose Cleverbeans method in the end, which revealed to be quite fine to do:
I re-initialized my plane transformation, then I scale it with a factor of 1/2 several time, until I had the right size (1/32 in the end). I then chose a reference rotation to position the plane as I wanted to in the first place. I then have an "initialTransformation" that I will have to apply each time BEFORE the other regular transformation.So for each frame I'll have
e.transform!( e.transformation.inverse ) e.transform!( initialTransformation ) e.transform!( transformationAtSuchFrame ) #with transformationAtSuchFrame combining a rotation and a translation
Now I am not depending anymore of a random initial state.
Of course I will rather combine all the intermediate matrices and then apply once the resulting transformation, it should be quicker.EDIT: I may have a quicker solution, that I still have to validate:
Geom::Transformation.origin
method gives the translation to put the object at the origin (and then be able to perform a simple rotation).
I might use this rather than combine several 4x4 matrix, it has to be a lot quicker ! -
@zitoun said:
e.transform!( e.transformation.inverse )
e.transform!( initialTransformation )This seems like it can be reduced to
e.transformation = initialTransformation
and that could possibly be reduced to:
e.transformation = initialTransformation * transformationAtSuchFrame
-
@thomthom said:
This seems like it can be reduced to
e.transformation = initialTransformation
and that could possibly be reduced to:
e.transformation = initialTransformation * transformationAtSuchFrame
Really?
I thought I had tested this solution and my results were not conclusive.
But maybe I was too tired: I'm gonna try again ! -
If you always calculate from one fixed state then there is no need to undo the current transformation, you just set a new transformation overriding the old one.
-
@thomthom said:
If you always calculate from one fixed state then there is no need to undo the current transformation, you just set a new transformation overriding the old one.
Yes indeed, but for some reason I thought that the method
entity.transformation=
was working differently (but I may have been really tired at the time I tested it).
It completely make sense that it works the way you describe it. -
Ahem.
Just remember:
@object.transform! @object.transformation.inverse @object.transform! @transformationAt[toPage]
@object.transform! @transformationAt[toPage] * @object.transformation.inverse
Note the order of the transformations... I had forgotten this well known pb !
-
@zitoun said:
@object.transform! @object.transformation.inverse
This just resets the transformation - same as
@object.transformation = Geom::Transformation.new
@zitoun said:
@object.transform! @transformationAt[toPage] * @object.transformation.inverse
Isn't this just the same as:
@object.transformation = @transformationAt[toPage]
? -
@thomthom said:
If you always calculate from one fixed state then there is no need to undo the current transformation, you just set a new transformation overriding the old one.
And you will end up with many problems if you build your code around inverting the CTM and multiplying by a new transform.
So if you're rotating an object, a low quality approach is to repeatedly apply a (say) 5 degree rotation rather than as Thomthom suggest, calculate the rotation at a time T and then calc what rotation you need.
The problem is that floating point does have finite precision, so if you repeatedly perform incremental transform as it seems you're doing, you'll end up with a non-orthonormal matrix. (Thats a bad thing).
-
@thomthom said:
@zitoun said:
@object.transform! @object.transformation.inverse
This just resets the transformation - same as
@object.transformation = Geom::Transformation.new
@zitoun said:
@object.transform! @transformationAt[toPage] * @object.transformation.inverse
Isn't this just the same as:
@object.transformation = @transformationAt[toPage]
?Yes, the inverse is not useful in my case.
I use@object.transformation= @transformationAt[toPage]
, as you suggest, and it works (well I still have some awkward pbs but I expect to solve them soon).The code was just for my tests, I wanted to underline here that if you wish to do
entity.transform! entity.transformation.inverse entity.transform! transfA entity.transform! transfB
you could as well do
entity.transform! transfB * transfA * entity.transformation.inverse
or even better, as you say Thomthom
entity.transformation = transf[b]B[/b] * transf[b]A[/b]
-
@adamb said:
And you will end up with many problems if you build your code around inverting the CTM and multiplying by a new transform.
Not really: it's more like reseting the transformation and set the one you like. No inverse is needed, and this solution is actually the only solution I can see so far.
But you're right, ignoring each object's current orientation is a real problem.
Advertisement