Hey,

Has anybody came across the issue of slerp() function which is used in BlendShapes node, that it can 'cause flipping of objects i.e. the quaternion changing direction from clockwise direction to counterclockwise because of constantly rotating geometries from both streams that come into the BlendShapes node? Wanted to mix two RBD sims but couldn't get rid of the flipping on some pieces when the rotations were mixed. Thought maybe somebody came up with some solution via SOP Solver for this? Some genius person of course.

Thanks,
Vlad

If you use a Solver SOP to blend in the transforms via a slerp() over time, you're much less likely to get flipping. Let's say you have the previous state in input 0 of a wrangle and the goal state in input 1:

matrix3 m1 = primintrinsic(0, "transform", @ptnum);
matrix3 m2 = primintrinsic(1, "transform", @ptnum);
float blend = ch("blend");
matrix3 out = slerp(m1, m2, blend);
setprimintrinsic(0, "transform", @ptnum, out);

As long as your blend factor isn't terribly high (or your goal transforms aren't rotated more than 180 degrees away from the current transform in a single timestep) you're unlikely to get flipping as you blend from the existing state to the goal state.

Hey @toadstorm,

Thanks for the response, I tried some setups in the SOP Solver before but had no luck, I actually tried now with your piece of code and put 2 same wrangles for this inside it and I think it seems to be working. You can check the attachment, I have there 2 examples with the BlendShapes node and the SOP Solver, with BlendShapes node I get the flipping on the frame 115, with the SOP solver there is none. What do you think?

You're close, but with a Solver SOP you have to remember that you're now dealing with a simulation. You don't want to keyframe the blend channels from 0-1 over time, because you're not blending procedurally between the A and B poses shown in SOPs... you're blending in your goal transform with the transform of the previous timestep. So just setting a flat value of 0.2 for the blend amount on the wrangle will get you what you need fairly quickly, and you can crank that up higher as long as you don't end up blending past 180 degrees in a single step.

You could also just use a Blend Shapes SOP inside that solver if you wanted... the wrangle just gives you more flexibility. Either way should work fine.

For sure!

Seems to work well with 2 wrangles inside the sop solver too 'cause I need to blend 2 animated inputs, not just static/prev frame into the second input. So need to pull the @transform from the first input too. Works pretty good though! Thanks