Vincent Goudard

the issue is contained in the attached patcher...

In brief, I'm getting strange results when using worldtolocal transforms on jit.anim.node.

Namely, I am expecting to get normalized coordinates corresponding to the gridshape onscreen. 

I tried using both "worldtolocal" and "worldtolocal_quat" functions but none yields what I would expect. Besides, they output different results while I would expect thos results to be the same. 

Anyone with a working example using this function?

NB : I know I could transform coordinates with hand-made trigonometry and vexpr computation but the attached patcher is a simplified situation of real-life patch, with child-transform happening around.

comment

route

prepend

message

multislider

jit.euler2quat

jit.quat2euler

toggle

jit.world

jit.gl.sketch

jit.gl.gridshape

jit.anim.node

the issue is contained in the attached patcher...
In brief, I'm getting strange results when using worldtolocal transforms on  jit.anim.node.
Namely, I am expecting to get normalized coordinates corresponding to  the gridshape onscreen. 
I tried using both "worldtolocal" and "worldtolocal_quat" functions but  none yields what I would expect. Besides, they output different results  while I would expect thos results to be the same. 
Am I misunderstanding something here ? 
Anyone with a working example using this function?
- Vincent

NB : I know I could transform coordinates with hand-made trigonometry and vexpr computation but the attached patcher is a simplified situation of real-life patch, with child-transform happening around.


Hi,
the issue is contained in the attached patcher...
In brief, I'm getting strange results when using worldtolocal transforms on  jit.anim.

need-help-with-jit·anim·node-worldtolocal-function

Another attempt to find a workaround to the problem above.

I tried to make the matrix computation out of the worldtransform matrix output by jit.anim.node, but I am facing a problem for some specific values which I feel probably related to some kind of gimbal lock. I am not very sure about what matrix is supposed to represent what, so maybe I am just missing something ?

Me again,
Another attempt to find a workaround to the problem above.
I tried to make the matrix computation out of the worldtransform matrix output by jit.anim.node, but I am facing a problem for some specific values which I feel probably related to some kind of gimbal lock. I am not very sure about what matrix is supposed to represent what, so maybe I am just missing something ?

thanks for the clear example. had to stare at it for a while to figure out what was going on, but it looks like the culprit here is the scale values, not the rotation. turns out there's a bug in the worldtolocal code with how it applies scale.

for now as a workaround, you can create two anim.nodes as child and parent, apply scale to the child, and all other transforms to the parent. send worldtolocal to the parent, and then simply divide this result by the scale values:

pain i know, but amazingly this is the first time this bug has been reported, AFAIK.

i don't understand what you're trying to do with the worldtolocal_quat stuff in your patch, but that function is unaffected by this bug, as orientations are unaffected by scale transforms.

thanks for the clear example. had to stare at it for a while to figure out what was going on, but it looks like the culprit here is the scale values, not the rotation.  turns out there's a bug in the worldtolocal code with how it applies scale.

thanks for the reply, somehow it's good to know it was a bug...

Unfortunately your workaround seems not to work in my situation (I mean, in the real patch, not the simplified example) which make use of more than 2 anim.nodes in cascade. From your explanation, I understand parent-jit.anim.nodes should not be scaled (until the bug is fixed), right ?

Since the idea was to make groups of groups (and so on) with parent anim.nodes being set on the fly, I guess I am stuck with this for now.

I couldn't investigate in depth the whole patch, but I can confirm your diagnostic that if the parent nodes are scaled to [1,1,1], the result given by the worldtolocal transform is correct.

About the quaternion, sorry I got confused with all this and somehow forgot quaternions are just 3d-angles!

Last thing : if you didn't already do it, please take a look at my 2nd post in this thread, as I suspect the output from "getworldtransform" function may be affected by the same bug.

thanks for the reply, somehow it's good to know it was a bug...

Unfortunately your workaround seems not to work in my situation (I mean, in the real patch, not the simplified example) which make use of more than 2 anim.nodes in cascade. From your explanation, I understand parent-jit.anim.nodes should not be scaled (until the bug is fixed), right ?
Since the idea was to make groups of groups (and so on) with parent anim.nodes being set on the fly, I guess I am stuck with this for now.

I couldn't investigate in depth the whole patch, but I can confirm your diagnostic that if the parent nodes are scaled to [1,1,1], the result given by the worldtolocal transform is correct.

About the quaternion, sorry I got confused with all this and somehow forgot quaternions are just 3d-angles!

Thanks again for your quick help...
Now waiting for the bug-fix :)


the worldtransform values look correct to me. my guess is there is an error somewhere along the way in the matrix math of your patch caused by polar singularities. we attempt to catch those errors in the internal anim.node calculations, but in the general matrix math operators there's not much we can do. maybe you can analyze each matrix-ops output and see where the jump occurs and handle it appropriately. or simply avoid the problematic rotations (e.g. apply a small rotation on another axis).

fix for worldtolocal with scaling will be in the next update.

the worldtransform values look correct to me. my guess is there is an error somewhere along the way in the matrix math of your patch caused by polar singularities. we attempt to catch those errors in the internal anim.node calculations, but in the general matrix math operators there's not much we can do. maybe you can analyze each matrix-ops  output and see where the jump occurs and handle it appropriately. or simply avoid the problematic rotations (e.g. apply a small rotation on another axis).
fix for worldtolocal with scaling will be in the next update.

need help with jit.anim.node worldtolocal function