Why do you think I’m here? 
1 Like
Because you are part of the family now 
Like @potato_noob !
2 Likes
And you’re right 
But then, you cannot choose your family. However, you can choose your ‘extended family’.
I like my ‘extended family’ to be present but not intrusive; simple but not basic; reliable but not constraining… Many have failed matching these criterias.
1 Like
sorry for the delay, I’ve been slogged under all day. Let me take a look.
I gave it another shot after reading about transformation coordinates, clearly didn’t understand diddly squat. also, locking off the Y rotation might have been pure luck locally 
I’m No closer to solving this yet, but I understand that normalizing the position of both meshes and doing the dot product will tell me when they are in front of each other. Adventures in maffs continue.
You really want it perfect, do you? This is all too complex for my skills. As I said, if it was me, I would make the trigger area smaller and, when entering the area, have both the character and the chair facing each other before running the animation of ‘jump on seat’. In your latest PG, the chair rotates towards facing the character (which I think is fine) but the character doesn’t rotate on itself to front align with the chair. Is this your current issue, or is it because you don’t want to do it this way?
Edit: I believe the issue comes from the lookAt (eye) function. I have been able to get different rotations of the character towards the chair after click, simply by changing the camera position. Something might just not be entirely correct there (for the calc matrix and quartenion and camera/target). Hopefully @PatrickRyan will have a minute to check it out for you.
So, the original plan was to do an action manager interpolation on the rotation to face 180 away from the chair and then sit down.
I gave in a did the same face the avatar thing so now they face each other, but for love nor money, I cannot flip that avatar’s direction on y 180… I can make it face 180 degrees in the world… pretty constantly, but I can seem to just change the direction 180, taking into account the current direction. Soul destroying & 100% down to just a poor grasp of vectors, matrixes and trigonometry.
Urg…
If I have a vector3 for rotation, and I negate rotation.vector3.y doesn’t that flip y? isn’t that like doing a 180 from where ever it current is? How broken is my maths here?
Alright:
.addRotation(0, Math.PI, 0); got me the 180 I just need to interpolate to that or animate.
Even though I have actually done the rotation that I wanted…I didn’t actually want to do that because what I needed to was get either InterpolateValueAction to do that rotation for me or build a new Animation
let currentRotation = avatarMesh.rotationQuaternion.clone();
let futureRotation = avatarMesh.addRotation(0, Math.PI, 0).clone(“nr”, null, true);
avatarMesh.rotationQuaternion = currentRotation;
then →
new InterpolateValueAction(
ActionManager.NothingTrigger,
avatarMesh,
“rotationQuaternion”,
futureRotation.rotationQuaternion,
300)
Okie dokie, this is what I was going for, I’m 99% this is a terrible way to write it, and I saw the description on the function about it being slower because of a eular angle conversion; ironically, a guy who had hard as part of his name!
What would be a better or the Babylon way (I know the answer is always what ever works, but I’m try to grow, humour me). I feels like I needed to do was addRotation, but not to the mesh, but to a clone that retained all the current rotation data.
I have to say one thing: seeing your disposition to always improve yourself never fails to brighten up my day!
I feels like I needed to do was addRotation, but not to the mesh, but to a clone that retained all the current rotation data
Your intuition is correct again, you can create a new quaternion that represents the mesh’s current rotation with the turn-around applied, and then animate between the two One way this could be done is:
const rotation = BABYLON.Quaternion.FromEulerAngles(0, Math.PI, 0);
const desiredRot = root.rotationQuaternion.multiply(rotation);
BABYLON.Animation.CreateAndStartAnimation("rot", root, "rotationQuaternion", 60, 60, root.rotationQuaternion, desiredRot, 0);
Here you can see a neat little property of quaternions: if you multiply quaternion A by quaternion B, this is the same thing as rotating the orientation represented by quaternion A by the one represented by B! This ease of manipulation is one of the reasons they are so used in computer graphics.
And there’s another neat thing here, this time a Babylon thing: the add, multiply, etc, operations on the Vector/Quaternion types will create a new object with the result, and return it, so you can chain operations with ease and not worry about messing with existing vectors, like:
let resultVector = myVector.add(otherVector).multiply(anotherVector).scale(5)...
and myVector will stay untouched! Of course, creating new objects has a performance hit, so all these functions have inPlace variants that will alter the initial vector. But unless that’s needed, it’s super practical to not have to keep cloning vectors when doing operations with them. (I remember this was one of the first things in Babylon that caught my attention because I had been using other libraries that did operations in place by default and I ALWAYS ended up forgetting a clone somewhere and everything exploded 
)
Anyway I think I rambled for too long so here’s the complete example: Rotate character using quaternions | Babylon.js Playground (babylonjs.com) and if you’d like me to explain anything in more detail, just let me know!
Ah, Carol, you rock!
I’ve been at this all day, and I’ve spent much of the weekend on it. Microsoft used some language with windows phone that I’ve never forgotten and remain in love with. Always delightful, beautifully mine. Sitting on my chair is neither right now 
Here is a gif of where I’m at:
What needs work: @PatrickRyan mentioned an intersection between art and engineering, and I get it; I think the legs of the avatar folding can be done in Blender, to create an animation for the skeleton. Then a curved animation could be created for the vector animation onto the chair. I was a bit nervous about creating those animations, but I became more comfortable with them over the weekend.
I haven’t managed to get as deep as this guide, but the plan is to do what’s written here:
http://grideasy.github.io/tutorials/Animations
I faced a couple of things today; obviously, I parented the little dude to the chair once he was on… so an interesting thing about that is I used setParent, which I think does some voodoo to retain scaling & position.
When I did setParent null on the little dude, before leaving the scaling on z goes funny, and I know this, is because of the GLTF export, we invert Z and do a rotation so y is up, R->L handed magic.
I maintained all those root transforms, and I’m wondering if I should ditch them; I know JC mentioned doing it in the cannon tutorial, but he didn’t seem to lose the transform stuff that got applied to the root transform node when he did it, not sure if I need to do something like bake transforms and then de-parent.
//Apply god awful hack when exiting seat
this.ocupant.mesh.scaling.z = -1;
this.ocupant.mesh.rotationQuaternion.z = 0;
//Because preserve scaling when using setParent does work kind of, but the little guy is moonwalking almost like something else is flipped or a rotation and done a hatchet job. setting those two back to what they originally were on that root transform node seems to do the trick.
@carolhmj, I’m going to meditate on your wisdom and examples and see if I can’t make this more delightful; thank you again for the example.
1 Like
Example of using setParent(null,true)
Example of using setParent(null,false)
I can’t tell if I’m fighting voodoo or fighting my rotation on the chair… or the rotation is also being applied to the avatar.
1 Like
not sure if I need to do something like bake transforms and then de-parent
Yeah, if you want to take the root transforms out you’ll need to still apply its transformation somehow, either by baking the transform into the vertices, or by adding this transformation in all of its children nodes. Something I’ve done before to avoid having to deal with this was creating another TransformNode and parenting the root to it, so I could apply all the positioning, rotating, etc, transformations to that “fresh” node and not worry about the inverted scaling part.
From what I understand of your situation, you are parenting the dude mesh itself to the chair, and not the root transform node to the chair, is that correct?
I tried expanding my previous example a bit to include the “rotating to sit” part, and when I sit the character on the chair, I parent the root transform node, and when the character leaves the chair, then I revert that by calling setParent(null) on the root: Rotate character using quaternions | Babylon.js Playground (babylonjs.com)
I already know the answer, but is there a right way to do this, the path to less pain later on, will I regret leaving the GLTF root transform node as is?
So, I followed @PatrickRyan 's advice and created a transform node with a position that matches the chair and parented to the chair, and just moved and bumped the y-axis position a bit. so the dude gets parented to the transform node which is roughly on the seat.
I’m going to check out the playground now!
1 Like
What you are fighting here is the face that Babylon uses a left-handed coordinate system and glTF uses a right-handed coordinate system in the specification. So when you import a glTF file into a Babylon scene, the __root__ node has a negative scale on Z to compensate for the change in handedness.
The best practice I have found to handle this is either by using a node under __root__ for my TRS manipulation of the mesh, or like @carolhmj mentioned, create a new node above __root__ to use for TRS manipulation. Alternatively, you could set the scene to use a right-handed coordinate system, but you will likely have some trade-offs there as well. However, if the scene is set to a right-handed coordinate system, you won’t need to worry about negative scales or accidently overwriting the negative scale conversion to left-handed. It depends on how much overhead the negative scaling is going to cost you as to if you should use a different coordinate system.
Typically, I would prefer to pay the cost of an additional node above __root__ which also helps to clean up the scene explorer hierarchy a bit (so there aren’t a bunch of nodes with the same name) and leave __root__ alone.
1 Like
One thing that’s sure is I had a good laugh with your gifs, so thanks for that already 
May be you should keep it this way 
We all need a good laugh in these times of uncertainty.