Problem with rotations

[Bullit]

I am trying to rotate some cubes 180º in each state, some rotate in one direction, the others rotate in opposite direction to each side of mimic(you see the mimic.kine.global.pos), so some in 180º and the others in minus 180 - the inverted node -so far so good and in state 1 this tree attached picture works well.

Clipboard-b.jpg

But the same tree in next state - state 2- it sends everything in disarray if i put 360 or every cube rotates to same direction if i put zero. I think the reason is that the rotation values have to be 0 so there is no minus neither the invert node seems to be working.

Any idea what i should do? Or better where i am failing?

Edited for clarity.

[Mathaeus]

If you want something like clockwise and counterclockwise, you can set this at "angle" of "axis and angle to rotation", using "negate" of angle, not invert (invert in case of scalars. that's something different of usual expectation). Afaik, angle in this node definitively can go into negative. If you want to blend rotations, convert them to quaternion, use special quaternion interpolate node, convert back to rotation after blending.

All that, because "angle and axis" is some kind of Euler rotation, you can get meaningful blend only around one axis. In case of rotation, "invert" inverts everything, both axis and angle. So at some point (when direction of axis, points on 'another side of the world') entire rotation jumps to something unwanted for humans. While quaternion chooses the shortest path.

If everything is expected to happen around one axis, probably you can perform all blends on "angle" of "axis and angle to rotation", but, the blend in this case goes admirable through all values - that is, imagine rotor of helicopter, rotating backwards, once you want it to stop.

[Bullit]

My conflict with ICE terminology rises its head again

Thanks Mathaeus it works with quaternions.

[Mathaeus]

well, regarding terminology, ICE uses pretty much standard names and methods, at least when it comes to transforms. I think it's very good idea. Easy to find docs, easy to adapt from another system.
For example, in Cinema 4d, 'HPB' is a descriptive (heading, pitch, bank) name for some kind of advanced axis and angle to rotation - and it seems, not that much users, including power users, are able to understand what it's exactly doing.

In any case, once someone is familiar with one system, no big deal to switch to another. Knowledge is forever, literally. I have to admit, that, more or less, I'm still "riding" on what I had to learn in POV-Ray . This one even didn't have fixed SRT order, let's say, shear was scaling after rotation. While ICE is keeping the fixed SRT order, when it comes to particles.

Of course, one visual programming language has much lower level of protection against user errors, than standard UI of 3d app.

[Bullit]

Mathaeus it was about "negate" instead of "invert". I have it as just saying no instead of negative.