setting mesh updatable property

[jerome]

Hi,

 

Something I don't get ...

When a mesh is created with updatable param set to true, its vertex buffer may be updated afterwards.

 

But if it is set to false, this means this buffer isn't taken in account once the mesh is built. Yet the mesh can be rotated, translated, scaled so the vertex positions are changed, aren't they ?

Maybe these operations don't apply to the vertex buffer... don't understand the magic under the hood.

 

 

Well, these questions are because I'm wondering if a non-updatable built mesh could be set then as updatable (so injected in the stack of stuffs to update) temporalily and then reset to its original status on demand.

Something like :

mesh.shouldUpdate();mesh.resetUpdate();

or any funny BJS term ...

[GameMonetize]

updatable means you can change the vertices.

 

rotation, translation and scaling change the worldMatrix that will be applied on vertices but do not change the vertices

 

You cannot transform a non updatable to an updatable as this is related to the inner webgl buffer

[jerome]

Ok I understand

 

So maybe it is better my upcoming rebase() function rather sets values in the world matrix better than in the mesh position instead ?

This means computing rotations what I wanted to avoid.

 

Mmmhh... In this case, maybe I won't change the world matrix and rather use the higher level BJS tools like mesh.rotation directly 

So if I use the mesh.rotation.x, y, z properties, I need to know in what order the underlying rotation matrices are applied to the mesh :

Rx * Ry * Rz ?

Rz * Ry * Rx ?

 

If I set this : 

mesh.rotation.x = rho;mesh.rotation.y = delta;mesh.rotation.z = gamma;

How is it rotated under the hood ? x first ? z first ?

 

too bad... it was so simple to do with vector scaling and adding in the positions 

[GameMonetize]

we already have a function that change the mesh internal vertices:

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/Mesh/babylon.mesh.ts#L885

 

For your rotation question: y->x->z

[jerome]

thank you

 

I want something different from bake..() method because bake() requires to pass a matrix, so, well, the HOW to transform things.

My explanation about the rebase() wasn't that clear : re-expressed here http://www.html5gamedevs.com/topic/14349-meshrebase/?p=81858.

 

Didn't get if you were talking about the rotation order or matrix order. Sorry.

So to rephrase you answer, you mean, in terms of rotation matrix (Raxis) multiplication :

 

question #1 :

 

rotatedCoords = Ry * Rx * Rz * localCoords

 

Am I right ?

or just the inverse :  rotatedCoord = Rz * Rx * Ry * localCoords ?

 

 

question #2 :

As it seems to be not that easy to find rotation Euler angles from just target and source positions, I'm looking for another way (than applying rotation.x, y, z) to set the mesh vertices final positions.

 

When the worldMatrix is applied to a mesh, this means its local coordinates are transformed into world coordinates. These world coordinates will then be transformed into view coordinates, I guess.

 

I guess also that computing the mesh world coordinates means to compute the world coordinates of each of its vertex.

 

Are these current vertices world coordinates for a given stored and accessible by a BJS low-level function ? Is there a data structure or an object storing them at any time ?

 

For a given mesh, do I have the mean to modify its vertices world coordinates ?

Unless everything is computed GPU side ... arrgh

 

 

 

question #3 :

 

In case I can't achieve it from the #1 or #2 way, maybe I could design something in the top of mesh.lookAt().

When using lookAt(), I guess the chosen axis is mesh.position-targetPoint (vector) to orientate the mesh. Am I right ?

But what original mesh axis is then aligned to this target axis ? Z ? -Z ? something else ?

And what rotation, if any, is applied then to the mesh around the target (looked at) axis ?

[GameMonetize]

q1: Correct: rotatedCoords = Ry * Rx * Rz * localCoords

 

q2: NO. All matrices computation are done on the GU (on the vertex shader). THis is the only way to achieve performance. Especially on JavaScript where we only have one thread (almost)

 

q3: Right. Axis aligned is z --> -z. no rotation around

[GameMonetize]

More info about the matrices computation:

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/Mesh/babylon.abstractMesh.ts#L437

[jerome]

ok thanks

[jerome]

@DK

back to rotation order question at property level :

 

if I set mesh.rotation.x, y, z properties, the mesh will be rotated then :

first : around y-axis

then : around x-axis

finally : around z-axis

 

Is this correct ?

[GameMonetize]

Correct:)

[jerome]

ok, I'll try to implement something to process some inverse rotation from 3 arbitrary oriented orthogonal vectors (my target) in space back to x,y,z world axis (the source <=> localSpace)

so unrotate first target around its z-axis to align target x-axis with xOz world plane => project coordinates, deduct roll angle

then unrotate target around its x-axis to align target xOz plane to xOz world plane => project coordinates, deduct pitch angle

then unrotate target around its y-axis, which now the same than world y-axis to align x and z target axis onto x and z world axis => project coordinates, deduct yaw angle

 

When saying "unrotate" here, I don't apply anything to a mesh, I just solve equations (plane equation + axis belonging + constant vector magnitude... if I'm not wrong this is solvable) giving a new constraint each step.

 

I should then be able to really rotate a mesh from its local space to a target system known only by 3 orthogonal vectors in space.

I hope ...

[GameMonetize]

Jeromekenoby you're our last hope!!

[jerome]

If can achieve it, I'll show the process demo.

Working on it on paper today.

 

[EDIT ] explanation here (in french) : http://www.html5gamedevs.com/topic/14349-meshrebase/?p=82643

validation welcome

 

Another question to be sure ...

In the BJS left-handed system, we've got an orthonormal set with this angle orientations :

 

from Ox to Oy : + PI / 2

from Ox to Oz : + PI / 2

from Oy to Oz : + PI / 2

 

am I right ?

[GameMonetize]

Correct

[jerome]

mmh... something I don't get

here, my cam is set z = -40 and the world axis are displayed : http://www.babylonjs-playground.com/#11PL3J#3

 

if I rotate the box around y axis for, say, PI / 3, I get this : http://www.babylonjs-playground.com/#11PL3J#4

I was expecting the box to move from the x red axis towards the z blue axis for PI / 3

 

It looks like the PI / 3 is applied from "-x" towards z

 

In other terms, according to what I understood from your former post about orientations ("from Ox to Oz : + PI / 2"), I would believe a rotation of - PI / 3 is then applied : http://www.babylonjs-playground.com/#11PL3J#5

 

 

unless rotation direction are :

from Ox to Oy : anti-clockwise

from Oy to Oz : clockwise

from Ox to Oz : clockwise

because of the left-handed system ? 

[GameMonetize]

Crap you're right:

 

ox->oy : CCW

oy->oz: CW

ox->oz:CW

[jerome]

aarrggg ... it promises headaches for cross, dot products and angles

 

well, for cross product Ox ^ Oz :

(1, 0, 0) ^ (0, 0, 1) = (0, 1, 0) and not (0, -1, 0), right ?

but there is - PI / 2 from Ox to Oz.... so I can't really rely on cross product only to know the sign of an angle between two given arbitrary vectors, can I ? 

 

More generally :

if I've got two normalized vectors u and v. I've got a plane defined by a normal vector

I want to know the angle a from u to v

dot product : u.v = cos(a) => a = acos(u.v) or a = - acos(u.v)

 

but I don't know then if I can rely on normal with cross(u, v) comparison to get the sign... because of the CCW/CW different orientation.

 

Any idea ?

[Wingnut]

Dk, was that a large "crap"?  As in... BJS emergency refactor-grade "crap"?  Let's hope not.  But I'm ready with the drums of coffee and donuts... as needed. 

 

Are we going flying on "To Hell With Backward Compat" airlines?  C'mon, let's gooooo!    (I want sphere's params reversed, still.  How trivial, eh?  Sorry.)

 

I'm ready for a week of all-nighters!  I got a sleeping bag, and I'm a great go-fer.  (go-fer food, go-fer pixel ink, etc).  I gotz a new Dell i7 comin' in the mail ANY DAY NOW... look out!  Somebody who knows what they are doing.... can use it as a BJS refactoring workstation.  I'll be their butler!

 

C'mon, BJS v3... in 2 weeks, no compat guaranteed!  Ready?  GO!    (I'm excited!)

[JCPalmer]

I had not been paying much attention to this thread (know how to update verts already), but it seems to no longer be about its title.  Wonder now if that very late attempt to add a similar method to Quaternion.RotationYawPitchRoll() right before 2.0 was released might have been correct.

 

I am really glad that I expressed my args for POV rotation in non-technical terminology.

/** * Perform relative rotation change from the point of view of behind the front of the mesh. * Supports definition of mesh facing forward or backward. * @param {number} flipBack * @param {number} twirlClockwise * @param {number} tiltRight */public rotatePOV(flipBack: number, twirlClockwise: number, tiltRight: number): void {

[jerome]

mmhh.. seems I spoke too fast, as usual, since (1, 0, 0)^(0, 0, 1) = (0, -1, 0)

 

This doesn't really change the question :

 

Imagine I have an axis vector called A.

Now I rotate a U vector around A for an angle theta. I call V the rotated U.

So theta = acos(U.V)  or theta = -acos(U.V)

 

If I want to sign theta I could calculate cross = U^V which is a vector collinear with A.

If cross is the same direction than A, so theta is the same sign than the arbitrary chosen angle orientation (CW or CCW) in the plane orthogonal to A.

 

If all orientations are the same in the whole system (x->y,  x->z, x->z), it is easy to choose the same orientation for every other plane in the space then. Example : if this plane (orthogonal to A) is then rotated onto the world x0z plane, the formerly angle between U and V remains the same (same sign) on xOz.

But in the case, BJS case and maybe other 3D engine, the world system embbeds both orientations (CW and CCW), I guess we have to choose by ourselves an arbitrary angle orientation (CW or CCW) on our own planes and convert it if these planes (or angles) should be rotated onto one of world system planes : xOz, xOy, yOz.

 

Am I right ?

 

not that easy ... ourg

[jerome]

Arg, I really feel stuck with all those angle signing...

 

So let me please rephrase once more my question to be really² sure:

 

xOy : CCW  looking from negative or positive z ?   (seems to be CCW, seen from negative z)

yOz :  CW looking from negative or positive x ? (seems to be CCW, seen from negative x)

xOz :  CW looking from negative or positive y ? (seems to be CCW, seen from negative y)

 

I don't understand which side of the plane of rotation we need to be on the rotation axis to determine the orientation (CW or CCW)