[GLSL] Rotating a SOP in relation to World Space axis to avoid Gimbal Lock

I need to stick with SOPs because in the end this gets used in Vincent’s Flex Chop as a SOP collider. I was initially creating a grid of Box SOP colliders with a Copy SOP, and used stamping to reference a Transform SOP upstream to rotate boxes individually (the stamps had references to a CHOP that had r[xyz] channels with multiple samples, sample per box). However I discovered this had a gimbal lock issue, and I’m not sure of any SOPs that can use rotation matrices or quaternions.

So now I’m trying to rebuild that Copy SOP method except with GLSL → CHOP → DAT → SOP. I solved this through accumulating and multiplying matrices (I have a second color buffer output the matrix and feedback into the glsl top). My first concern is this isn’t the proper way to solve this issue, because it leads into my second issue of my feedback loop.

The second color buffer gets converted to CHOPs and fed into the Matrix parameter page on the GLSL Top. This works fine for a single cube, but once I want to start doing multiple cubes, I’m pretty sure the Matrix input does not take multi-sample CHOPs. So I want to keep it as a TOP and each row/v represents another cube. But when I tried to use top feedback in this way, the rotation wouldn’t accumulate. Is this where I need to use multiple passes, or split it up between two shaders, or does my entire approach need to be reconfigured?

Here’s my .toe which works with a single cube: cube_rot.toe (26.7 KB)

I’m able to do multiple boxes if I use an array input instead of a matrix input, but I still can’t figure out why my TOP input isn’t working. If I convert it to CHOP and then back to TOP it works, so something about my pure TOP feedback loop isn’t correct.

In my new .toe, if you change the Mode to “TOP” and then enter in values in the two main cube_rot CHOPs, see how the boxes hold their rotation when the Switch TOP is on index 1 (the top>chop>top chain), but don’t hold them when it’s on index 0 (only top).

cube_rot.toe (25.1 KB)

How can I get the pure top chain to work?

Hi there,

That’s some weird behaviour indeed. The feedbackTOP doesn’t seem to reflect the pixels of the switch1 TOP it’s pointing to. After some playing around I realized it’s coz of the feedbackCHOP you’re using.
You can use a slopeCHOP there, then it seems to work. It seems like the feedbackCHOP interferes with the feedbackTOP. I’ve no idea how that’s possible though :slight_smile:

Cheers,
tim

here’s a working version: cube_rot.toe (73.9 KB)

Just change the Mode from RESET to SPIN

Here’s a pretty much final version. It has an example for SOPs and one for Instancing (which can support a lot more cubes). I also added parameters for:

  1. Choosing which axis can be rotated on, how much optical flow affect rotation (1 optical flow unit = rotation mult) and the rotational lag.
  2. A snap function that gets triggered after a certain amount of time where no optical flow is detected. So the rotations can be snapped to a specific angle (or in the case of cubes, probably snap to a cube face)
  3. A rotation lock function, that can limit how much the cube rotates. So if you just want to switch between two sides, you can limit the y-axis rotation to only happen between 0 to +90*. It’s kind of a bad implementation because clamping quaternion rotations is strange, and even harder with two axes (so my version can only lock a single axis of rotation and the other axis does not move at all)

To use, just turn off the Reset toggle: cube_rot.toe (53.0 KB)