mesh.rebase()

[Alby]

Surely Jerome, you must be a descendant of Archimede, just the context changed, no more a bathtub but  a (rocking?) chair, no more" Eureka" but "j'ai trouvé!".

I wish you a winning battle against quaternions, rotations, Euler, and cie! I'm sure you will defeat them!

[Wingnut]

Jerome, don't forget LookAt().  Once mesh#2 is positioned (possibly at sphere center to start), calling it's LookAt() will do rotation alignments to "something".  If you think about it, once you do a mesh2.LookAt(redSphere), then you have done a rotational alignment.  After that... we have all sorts of negate/cross vectors, right hand orthogs, and other toys... to play-with the initial LookAt alignment.  *shrug*

 

To reword, we could have 6-kinds of LookAt().  (Written by some cool toolbuilder wrapping LookAt in a more-powerful wrapper func).  We could have BottomLookAt, TopLookAt, RightLookAt, +3 more.  The top, bottom, right, left, front, back... are the sides of the mesh's bounding box.

 

Wait, LookAt() already has optional yaw/pitch/roll corrections/offsets allowed in its params/args!  We're fully loaded for bear!!!  Kids with power tools.  Yee haa!    I believe that gives us left-side lookAt power for Alby's text planes, which should align them to the radial.  Possible solve found!  LookAt!  errr... Look Out!  Demos ahead!

 

For those who are new to baking vertices locations, here's my un-informed explanation.  It is done with setVerticesData(positionData) or updateVertices(positionData), and it actually rotates/moves the vertices of the mesh (such as a text plane) within its un-moved localSpace.  Wow!

 

In the case of the Alby demo and the textPlanes (this is art)... the planes themselves would not set a standard mesh.rotation value, but instead, move the points of the mesh... in such a way that it LOOKS rotated.  We would move each point of the textPlanes (4 points) until they were in proper alignment with the radial/spoke. 

 

This is a fairly easy task (for the geometry Gods - which I am not).  Once those points are moved within the mesh's localSpace, the vertex positions are said to be "baked" into the mesh, and the mesh is said to have a baked rotation and possibly a baked position.  We moved the points within the localSpace (the mesh bounding box) but never touched .rotation, .rotationQuaternion, or .position values. 

 

In our case, we would probably not bake the overall mesh.position away-from its origin.  Thus we would still place the textPlane centerPoint (pivot point) onto the radial, but possibly located at one end of the radial.  We'd likely place it on the redSphere end of the radial, and then do the rotational bake, then use textPlane.x = howFarAwayFromSphere.

 

Once rotation is baked, what if Alby wants to spin the textplanes around the radial spoke?  He tries to use a standard around-x rotation, and suddenly the textplane is flipping and flopping out of control, and Alby says "What the hell?"    Baked vertices.  Screwed.

 

BUT... if Alby (and me and others) became experts in setVertices/moving points, then he might align a matrix to the radial (copy its worldMatrix), and then use transformCoordinates() within the render loop, to spin the textplane around the radial/spoke.  Real time re-baking!  Wow!

 

He says "I don't need no schtinking .rotation!  I'll transform (move) all 4 textPlane points a tiny bit... in each render loop, and make the plane spin within its own localSpace". 

 

Again, he never touches mesh.rotation.  He does it all... by moving points each frame...  in such a way as to rotate the textPlane around the radial.  Cool!

 

This is the way I understand the phenomenon of "baking", and nothing ever comes from it... that tastes good with cold milk.  Also, Santa Claus has ZERO INTEREST in things baked in this way, and don't send baked mesh to your kid's bake sale... they won't sell. 

 

Jerome, I think, wants to avoid making users do (live-) baking. (They could burn their hands on the oven). 

 

He wants to make it so... once the textplane is .position'd onto the radial, he would like the mesh.rotation to work somewhat AS EXPECTED.  A textPlane.rotation.x... would spin the textPlane around the radial.  A textPlane.position.x... moves the textPlane linearly along the radial (nearer/further from the sphere).

 

Interesting stuff, eh?  *nod*  Okay, pardon my interruption... only 158 more posts to go! 

 

PS: Alby, you COULD give us the URL to what you'd like us to read, instead of pasting-in the text.  Just a thought/option 

[Wingnut]

http://playground.babylonjs.com/#1HLSBC#5

LookAt that.  Planes aligned with radials (planes aimed at sphere).  They are still .positioned poorly, and still needing UP rotation... but hey, we're on the radial!  YAY! 

(no, no, we're not on the 'radio' so don't start singing)

Line 297... a highly-professional-looking lookAt(), with no yaw/pitch/roll correction args.  Yum! 

This is the best aligning of these textPlanes (grounds) that I've accomplished so far.  PARTY TIME!  I did some mods in planeBetweenPoints(), though.  More mods needed.... to get textPlane.position located at the radial's distance/2 location. 

Jerome, maybe your task just got a little easier (at least the Albyville-based tasks).

SO much to learn!  My brain is full, and it's still not very helpful to me.   

[jerome]

@Wingut

I hacked lookAt() after DK's suggestion.

Well it's quite this... but not really this. It creates a quaternion from the mesh-target axis and two angles deducted from this axis orientation and its projection onto xOz plane. Moreover it doesn't rotate around z-axis.

[Wingnut]

uhn.  But, hmm... yeah, no rollCor.  *scratch*. 

 

I saw LookAtLHToRef inside abstractMesh, too.  Wow!  That whole .computeWorldMatrix() func... is just a BUCKETLOAD of transforming juice!  And it smells like a Playdoh Fun Factory!  SO much learning is in there!  Someday... I'm gonna be a transformer...  I'll show 'em.

 

Just think... if a guy actually knew how to use those tools, eh?  (dream, drool)     BJS dataTypes (v2, v3, quat, matrix, etc) are just LOADED with toys.  Getting to know those... phew... demi-God.

[jerome]

Hi guys,

 

Back on rebase() after a long day writing much math on many papers ...

so let's see this : http://www.babylonjs-playground.com/#11PL3J

As you can see : a big box scaled in purpose with x > z > y to keep an eye opened on rotations and a target system (3 orthogonal left-handed vectors (u,v,w) u=red, v=green, w=blue)

 

I want my mesh to be set and rotated in this new system : http://www.babylonjs-playground.com/#11PL3J#1

 

As you can notice, it's rotated.

But there is still a bug (or maybe my misunderstanding in rotation order) : the box length should be aligned on the u red vector, the box height should be aligned on the v green vector and the box width should be aligned on the w=blue vector

 

Quick and dirty debug by adding PI / 2 to roll : http://www.babylonjs-playground.com/#11PL3J#2

 

Need to hack deeper to understand where is the bug... so almost done

[Wingnut]

We got no grounds, we got tiny axis lines, we got the world famous Jerome Gray background color (which tries its best to make everything hard to see), and we got a guy speaking Pythagorean in our forum.  Keep on trucking, J-Man!

 

Did you see my new Tri-Grid?  Would it be difficult to put your "tests" inside one of them?  Maybe Deltakosh will fig a way to do a type of subtle shadowing on the grid planes... without needing lights.  (maybe)

 

Later, Alby and I will write "Jerome for Dummies" tutorials and demos. 

[jerome]

in french, sorry :

 

détail du procédé pour ceux qui pourraient me le valider siouplé.

 

J'ai les 3 vecteurs sources X,Y,Z normés calés sur les axes du monde.

Je connais leurs images (target) par la rotation (yaw, pitch, roll) qui sont 3 vecteurs orthogonaux normés U, V, W orientés main gauche tout comme X, Y, Z.

 

Le but est de découvrir les angles yawn, pitch, roll (inconnus) pour passer de X, Y, Z à U, V, W (tous connus) sachant que les rotations se font dans l'ordre Ry, Rx, Rz.

 

Mon idée est la suivante :

Partir de l'état cible U, V, W et faire des rotations inverses en trois étapes pour me rapprocher de X, Y, Z.

À chaque étape, je choisis une position de l'image par la rotation en cours qui m'arrange, je calcule les coordonnées de l'image choisie et j'en déduis l'angle utilisé lors de la transformation.

 

tl;dr : GOTO #jibitrien, plus bas ...

 

Step 1

Je fais une rotation des vecteurs U, V, W selon l'axe W (W sera donc invariant) roll : équivalent de l'axe z local au système UVW.

Je choisis de placer l'image U' de U, RW(U) = U', dans le plan xOz et je donc cherche les coordonnées (x, y,z) de U'.

Si W a pour coordonnées (a, b, c), ceci donne les équations suivantes :

• U' appartient à xOz => y = 0
• U' appartient au plan orthogonal à l'axe de rotation W => a * x + b * y + c * z = 0
• U' est normé => x² + y² + z² = 1

On résoud, on évite les cas particuliers et on obtient un jeu de coordonnées pour U' dans le plan xOz

On en déduit avec le produit scalaire U.U' l'angle roll entre U et U'

Le système obtenu (qu'on ne calcule pas)  par cette rotation s'appelle U', V',W' avec W' = W

 

Step 2

On applique maintenant une rotation exactement de la même façon à U', V', W' mais autour de l'axe U' (pitch : le x local au système U'V'W') pour obtenir une image nomée U", V", W".

On choisit de placer W" dans le plan xOz, c'est à dire d'amener W' sur xOz par une rotation autour de U' (qui est déjà lui dans xOz... l'idée est tout ramener dans xOz avant de finir par une rotation Ry). Donc RU'(W') = RU'(W) = W".

Si maintenant (x, y, z) de W" sont les coordonnées à trouver et (a', b', c') les coordonnées précédemment trouvées de U', on a :

 

• W" appartient à xOz => y = 0
• W" appartient au plan orthogonal à U' => a' * x + b' * y + c' * z = 0
• W" normé => x² + y² + z² = 1

Résolution, choix de solution, on obtient les coordonnées de W".

On en déduit par un produit scalaire l'angle pitch entre W' (=W) et W".

 

Step 3

Maintenant nous avons W" et U" dans xOz, donc V" est égal à Y (si on a bien choisi les sens des solutions précédemment, et à -Y sinon).

Il ne reste plus qu'à faire la rotation autour de Y d'angle yaw de U" vers X (ou de W" vers Z, c'est la même chose).

U" = U'

Il suffit donc d'un produit scalaire U'.X pour déterminer le dernier angle yaw.

 

Nous avons ramené en trois rotations (et deux états intermédiaires) la cible U,V,W à sa source X,Y,Z

 

 

#jibitrien

 

Bon, comme ça, ça parait abstrait.

Prenez votre smartphone, posez le sur la table devant vous, l'écran vers le plafond, le haut du smartphone vers la droite : c'est l'état d'origine X, Y, Z (X = longueur, Y = épaisseur, Z= largeur du smartphone).

Prenez le en l'air dans votre main maintenant, dans n'importe quelle position et fixez cette position.

Puis faites des rotations selon les axes u,v,w locaux (*) au smarphone en suivant la démo précédente, c'est à dire :

• D'abord autour de w pour placer le u (la longueur du smartphone) parallèle au plan de la table
• Puis autour de u pour placer tout le dos du smartphone parallèle au plan de la table, l'écran face au plafond
• Enfin autour de v pour replacer le smartphone dans le même état que l'état initial

 

 

(*) u, v, w sont liés au smartphone :

u est l'axe qui passe par le centre du smartphone et parallèle à sa longueur, qui va du bas vers le haut du smartphone.

v est l'axe qui passe par le centre du smartphone et parallèle à son épaisseur, qui va de l'arrière vers l'écran

w est l'axe qui passe par le centre du smartphone et parallèle à sa largeur, qui va du côté droit au côté gauche du smartphone

 

tourner autour de w, c'est tourner le smartphone uniquement par l'axe le traversant sur sa largeur et passant par son centre

 

x,y,z sont liés à la table devant vous :

x est la longueur de la table

y l'axe vertical parallèle aux pieds de la table qui va du sol au plafond

z est la largeur de la table qui va de vous vers le fond de la table

[jerome]

bad automatic translation (I really need a validation from some math guru please) :

 

I have 3 sources vectors X, Y, Z axes normalized keyed onto the world.

I know their images (target) by the rotation (yaw, pitch, roll) which are three orthogonal vectors normalized U, V, W oriented left hand as X, Y, Z.

 

The goal is to discover the yawn angles, pitch, roll (unknown) to switch between X-Y-Z, U-V-W (all known) knowing that the rotations are in the order Ry, Rx, Rz.

 

My idea is this:

From the target state U, V, W, and make reverse rotations in three steps to get closer to X, Y, Z.

At each stage, I chose a position of the image by the current rotation that suits me, I calculate the coordinates of the selected image and I take the angle used during processing.

 

 

Step 1

I rotate the vectors U, V, W along the axis W (W is therefore invariant) roll: equivalent to the local z axis UVW system.

I choose to place the image U', RW(U) = U', in the plane xOz and I seek the coordinates (x, y, z) of U'.

If W has coordinates (a, b, c), this gives the following equations:

• U' belongs to xOz => y = 0
• U' belongs to the plane orthogonal to the axis of rotation W => a * x + b * c * y + z = 0
• U' is normalized => x² + y² + z² = 1

Is solved, special cases is avoided and a set of coordinates is obtained for U' in the plane xOz

We deduce from the dot product U.U' the roll angle between U and U'

The resulting system (figure not calculated) by this rotation is called U', V', W' with W' = W

 

Step 2

Now we apply a rotation exactly the same way to U', V', W' but about the axis U' (pitch: the local x axis in the system U'V'W ') to obtain an inmage called U"V"W".

We choose to place W" in the plane xOz, ie to bring W 'on xOz by a rotation around U' (which is himself already in xOz ... the idea is to bring everything onto xOz plane before  a last rotation Ry). So RU'(W') = RU'(W) = W ".

If now (x, y, z) are the W" coordinates to find and (a ', b', c ') previously found coordinates U', then:

 

• W" bleongs to xOz => y = 0
• W" belongs to the plane orthogonal to rotation axis U' => a * x + b * y + c * z = 0
• W" normalized => x² + Y² + 1 = z²

 

Resolution choice of solution gives the coordinates of W".

It is deduced by a dot product between the pitch angle W' (= W) and W".

 

Step 3

Now we have W" and U"  both in xOz plane, therefore V" is equal to Y (if one has selected the solutions previously defined, and -Y otherwise).

It only remains to rotate around yaw angle Y from U" to X (or from W" to Z, it is the same thing).

U"= U'

So just a dot product U'.X to determine the last yaw angle.

 

We brought thus in three rotations (and two intermediate states) the target U, V, W at its source X, Y, Z 

[jerome]

seems quite un-understandable to everyone, I guess 

(just followed RaananW's advice about abstract explanations  )

 

Anyway, it sounds like I did a mistake somewhere in this process, in this implementation or in the math solving ...

Maybe in the shortcuts I did to select quickly one of the solution each step (2 degrees polynomial equations )

[jerome]

calculus re-done and re-checked

process validated by a first math prof today (seems encouraging),

I'm waiting for another one tomorrow

 

 

It seems my current mistake is in the implementation somewhere and/or some angle sign checking (arg CCW and CW orientation both in the same system)

I've got a lead ... for tomorrow

[jerome]

process validated by the second math prof

seems my angles lack signs, so the result is wrong...

I need to solve this (quite complex because of the two different orientations in the same system : counter clockwise and clockwise) before I can introduce a working version.

[Alby]

Well thank you again, Jerome, for you hard work trying to find the solution, hope you don't feel too dizzy with all those rotations, quaternions and other joyfull stuff!

 

Next time, when you will see a little light candel in the darkness, surely you will  be more carefull to agree to answer someone request !

 

Be well.

[GameMonetize]

You rock!!!

[jerome]

Well, some days of 3D trigo fighting and I'm about to achieve it (tomorrow, I hope... unless I'm too optimistic about last angle signing ans particular case treatment) ...

 

I wish I can code a PG proto tomorrow                                                                                                                             (si personne ne vient me péter les rouleaux au taf)

 

I think I will rename it into AxisToEuler(axis1, axis2, axis3) -> Vector3(yaw, pitch, roll)

rebase() would then just be a call to AxisToEuler() and a setting of mesh.rotation + mesh.position

 

I really hope I can achieve it soon because my brain is fusing on this stuff for a week now

[Temechon]

Jerome, your French comments make me laugh each time xD

[RaananW]

In that regard, I just wanted to comment that to non french speakers (ahm ahm), it looks like this : "if no one comes to farting me the rolls taf" 

[Temechon]

Almost that xD It means "If nobody comes and annoys the shit out of me at work" But I like your version

[jerome]

:D

@Raanaw : this seems to be some automatic translation

so funny to read this !

 

because I just used some french slang words and they give so weird translation

 

<cultural instant>

well...

"taf"  is slang for "travail" => "work"

"péter" isn't "to fart" here, but the same meaning than "to explode", "to break down" something

"rouleaux"... ahemm... these are "rolls"... this doesn't have any literal sense in this expression

so "me péter les rouleaux au taf" would be something slang like "to mess me up at work"

</instant>

[RaananW]

Yes it is - google translate. Bing, surprisingly, provides the same! if no one comes to fart me the rollers in the taf.

My french is as good as your Hebrew (probably!). Maybe I should start learning... It seems it is required by a high amount of members in this community. I wonder where all of the German speakers are! Wo seid ihr denn ?!?!?

[jerome]

I guess your french is far better than my hebrew as I just know "shalom".

Wir sind herein !

[Temechon]

Was ist das ? I don't speak german at all :/

[jerome]

I'm afraid the proto won't be for today

still stuck in angle orientations

 

 

for now, I'm stuck here : http://www.babylonjs-playground.com/#149PJC

 

 

line 228 :

you give 3 angles values and an origin => it sets a target system according to these 3 angles

 

then rebase is called and it doesn't know anything about these 3 angles : it tries to rebase the model mesh along the target system

display console to see real (given) angles compared to computed (with rebase) angles

 

for now, it works unless I give a negative yaw (y rotation angle)

 

don't care about the intermediate tiny objects and plane ... the spheres are the last step before the y rotation (from target back to world system)

[jerome]

I'm turnin crazy with this stuff... more than a full week and not yet solved

 

As I can't achieve the last angle sign solving for days, I changed my mind and opted for the angle approach (instead of vector coordinates approach as I did so far) as suggested by a math prof here. This is the same process (from target back to source in 3 steps) but we just focus on angles unknow values, instead of rotated vector coordinates.

This means many atan2 to compute.

Well, calculations are more complex than in my former method but it avoids my solution selection problem each step (2 solution vectors and 2 angle signs => 4 possibilities ... with dependency to previous step, arg).

A computer is good at ... computing and bad at making choices, isn't it ?

So the angle approach should be better.

 

For interested people, here is an short and simple article about this approach : http://geom3d.com/data/documents/Calculation=20of=20Euler=20angles.pdf

PG implementation : http://www.babylonjs-playground.com/#UAHY7

 

A model mesh is created at the world origin.

 

Line 106 : you give angle values and a target system is set according to this angles.

Then axisToEuler() is called. It doesn't know anything about the given angles but only the target system. It tries to deduct the angles and then sets a rotated mesh with these deducted angles.

Won if it matches the target system.

 

As you can see, it works ... almost.

If you give negative or superior to PI  angle values, it doesn't work.

And, even in the working case, if you display the console, you can see the given angle values compared to the computed angle values : the approximation errors aren't insignificant.

 

So I feel puzzled...

I really dislike to give up.

 

My initial process is headaching and I can't go on further for now.

The angle approach (this one, got on the shelf) isn't better in term of results.

[jerome]

phheeww ..

at last : http://www.babylonjs-playground.com/#DUOXP#1

 

from line 42 :

  rotX = Math.PI + 0.5;  rotY = Math.PI / 4;  rotZ = Math.PI  / 3;

You can change these values as you want, make them negative, etc.

 

This will set and visualize the target system orientated into space as you specified.

Meanwhile the coordinates (axis1, axis2, axis2) of this target will be computed from world axis (source) with classical BJS rotation functions.

 

Then the axisToEuler(axis1, axis2, axis3) function will be called knowing only these coordinates and ignoring the angles you've given.

It computes back the yaw, pitch, roll angle result values.

 

Finally the mesh is given the result rotation.

 

If it fits the red/green/blue target system just like its model set at the world origin, the job is done .

 

If you want to give directly an arbitrary system, you can uncomment lines 213-215 and just give your own values to var axis1 :

  var axis1 = new BABYLON.Vector3(90, -300, 2);  var axis2 = BABYLON.Vector3.Cross(new BABYLON.Vector3(0, -1, 1) , axis1);  var axis3 = BABYLON.Vector3.Cross(axis1, axis2);

This will set a target left-handed system for you.

 

 

I still need to check particular limit values and to stress the function but I believe it finally works now.

 

[EDIT] : seems to be OK with limit values so far ...