Solving for rotation values

[Wells]

Hey Everyone,

I was wondering if anybody could help. Attached is a file of network. The fk_null(in green) has key frames. I am trying to match those rotations with the node named follow_fk. I'm looking to do this in an expression if possible. Currently I have a mlookatup expression which visually matches correctly but as you see the rotation values calculated are extremely different.

Any ideas?

Sincerely,

Mark

[Wells]

Attached The File....

test_rotation_file_nc.hipnc

[michael]

can you describe what you're trying to do?

vrorigin would be simpler but will give you the same values....

[graham]

Such is the nature of trying to calculate rotations.

Running tests using HOM as well as the Object CHOP yield different results. The Object CHOP gave better results, but not the same in all cases. HOM gave similar results to vrorigin and what you are doing already.

I would probably attempt to handle it all using a Python OBJ where you can just deal with the rotation matrix straight up and not have to deal with extracting Euler rotations.

[Wells]

First of all thanks for the posts,

Michael, vrorigin will return a similar problem. In the example file if you use the root and the goal you in vrorigin you'll see the 360 in the y rotation value from 90 to -270.

I'm trying to extract numbers from automated systems(like lookat, result of blending, mlookat, mlookatup, objlookat) that make sense for the animators when snapping or blending automated and hand animated rotations.

I thought that by using the explodematrix expression and inputting the root, goal, up vector, and rotation order I could get a cleaner solve. That doesn't seem to be the case.

Graham, I haven't used a python OBJ before. I'll take a look into it.

I'm definitely looking for the fastest way to do this outside of VEX, also outside of python, because we interface with Touch Designer.

I feel like there should be some super fast way to calculate rotations and vary the result until you get the desired numbers. Going from 90 to -270 seems odd I feel like a more desirable jump would be 180 to -180.

I don't know how fast this would be, but doing a lookup curve or set driven for solved normalized vector from the root to the goal.

Maybe it's just an if statement in with the solve.

What ever I do, it needs to be a fast solution because I can see using this solve a lot. Any other ideas.

Thank you,

Mark

[edward]

I vote for the Object CHOP.