Switch off local axis update?

repro: Babylon.js Playground

I have done an align to view option for trailmesh. It was tested against a trail orbiting around the world Y axis. When testing against trails orbiting around the other axes, I realized that the local axes were switching, presumably due to upVector update. Is there a way to switch off a mesh’s rotation to prevent local axes from switching?

Are you trying to make the cubes as billboard like this ?

Nope, not setting billboard on the cubes, just want to have them lookAt forward vector. User do not need to set billboard on the generator to use them with trailmesh. The red cube is my control set, each trailmesh’s roll angle is computed against local x-y plane of respective cube.

The green and blue cubes are behaving differently from the red’s in that the local axes keep switching around, ie, there seems to be a rotation.y on them due to the setDirection from lookAt. If it could be cancelled out, I’d have stable local x-y planes for computing the roll angle, but the axes keep twitching. so close…hmm… :frowning:

I (kinda) did something like that for track computation in zero-gravity racing demo. I used to compute the up vector as the cross product of previous forward and new forward vectors.
if both forward vectors are colinear, then I don’t compute the new up vector and reuse the one from previous frame.

1 Like

I need to think of a way to either compute the roll

a) independent of the generator’s local coordinate frame or
b) regardless of how the local coordinate frame changes

without bloating the class. The more stuff to track, the less performant it gets…

Gonna sleep on it. :sleepy:

@Cedric, I fixed it. Do you think it can go into a PR? Need more eyes to chk my math.

PG: https://playground.babylonjs.com/#RKQBKG#1

It might go into a PR. Before that, I must admit the PG is a bit difficult to understand. I’m not really sure what I should expect and compared without your change.
Before doing a PR, can you update or create a new PG that shows 2 ribbons: 1 with and 1 without your change? so it’s easy to understand what the change is improving/fixing.
It will also be nice for the documentation.

oops! My apologies, below is PG where the trailmesh was flipping due to the local axes update when green cube crosses y=0.

PG: https://playground.babylonjs.com/#RKQBKG#2

My fix is below, code diff are in the update loop, lines 356-379.

PG: https://playground.babylonjs.com/#RKQBKG#3

I first find the large change in quaternion by comparing across frames, which is then used to cancel rotation.y by Math.PI and compose a new matrix with the new quaternion. Downstream operations to compute the roll are per standard coordinate maths.

edit: I did not explain on the align to view option since that wasn’t the point of this thread, I think…but if you feel you need to know that as well, feel free to ask away.

I found a proper solution! No idea how robust, will need more testing. But as far as this thread is concerned, I’m gonna mark it solved. Many thanks to Cedric for all the help as well.

For posterity: If you need to negate a roll flip in local axis for the trail mesh when your mesh crosses y=0 and it has non-zero rotations, just negate the roll with Math.PI, qed!

quat.multiplyInPlace(BABYLON.Quaternion.RotationYawPitchRoll(0,0,Math.PI));

Hope it helps, cheers! :slight_smile:

1 Like