ICE Kine - How to combat "gimbal lock"?

[Hirazi Blue]

I've got a setup which involves all kinds of constraint driven rotation. In the "old-fashioned" setup (without ICE Kinematics) I have learned to battle "gimbal lock" by changing the rotation order on the local transforms. How would I have to go about battling "gimbal lock" in ICE Kinematics?
And yes, I'm a newbie at this (but aren't we all?) ;)

[Mathaeus]

Have no idea about ICE kinematics, but in ICE, 'euler to rotation' node has built in rotation order.
You can check out this one, if you didn't yet. It has a nice explanation of rotation representations, all of them are implemented in ICE as a nodes.

[Hirazi Blue]

Thanks for your answer...
Yes, I noticed the "Euler to Rotation" node and its counterpart "Rotation to Euler". As I am using the built-in constraint compounds of ICE Kinematics I have, however, no idea how to proceed. I probably have to dig into the "Add Constraints" compound and "hijack" the Rotation value from the transformation matrix before it is set into the "kine.global", but do I simply insert a "Rotation to Euler" directly followed by a "Euler to Rotation" with the correct new "order of rotation", or how should I proceed when using the built-in ICE Kine constraint compounds?

I'm obviously utterly clueless....

[Mathaeus]

Generally, you use eulers *only* for 'human input', nothing else. I posted link to Isner's article about rotations, just to point to that. You can't blend or add eulers (and expect usable results).

Of course if you can explain what you exactly want to do, that would be nice

[Hirazi Blue]

First up: want I to do is change the rotation order of the rotation that the "Add Constraints" compound comes up with...
The pre-built ICE Kine constraint compounds like "Look At" are plugged into an "Add Constraints" compound, which sets the whole "kine.global" matrix. I am very hesitant to change anything in this compound, due to my extreme ignorance in these matters. But I could "hijack" the matrix before it gets set in the "kine.global" again, I am however unsure if that would do the trick... ;)

edit: Okay, I think I solved the problem for the specific animation at hand. It involved not just hijacking the rotation, but stripping down the pre-built constraint compounds down to the bare minimum I needed.
As this feels like a very "dirty hack" I would however still very much like to know, what would be the proper way...

[grahamef]

Okay, I think I solved the problem for the specific animation at hand. It involved not just hijacking the rotation, but stripping down the pre-built constraint compounds down to the bare minimum I needed.
As this feels like a very "dirty hack" I would however still very much like to know, what would be the proper way...

Tell us more about the exact situation, i.e., what needs to be constrained to what, and how, and what's the desired behaviour?

[Hirazi Blue]

As you already quoted, I already solved the problem at hand...
But okay, I tried to create a turning wheel influencing two bars, connected to the axis of this wheel, that needed to be kept pointing at a null, so on the two bars I started with a "look at" constraint towards the null and a "position" constraint to the wheel, but then the rotating wheel created some strange hiccup, which I diagnosed as "gimbal lock". In the original non-ICE version, simply changing the "rotation order" in the "local transforms" did the trick. So my question would be: how to proceed from this. There must be an easy, elegant way to solve this. The way I solved it in the end didn't feel that elegant (and was probably extremely "scene dependant"), so once again: how can I combat "gimbal lock" when using constraint driven animation... There must be some "scene independant" way to get this done, I would guess...

[grahamef]

As you already quoted, I already solved the problem at hand...

I know -- I was responding to "I would however still very much like to know, what would be the proper way..."

But okay, I tried to create a turning wheel influencing two bars, connected to the axis of this wheel, that needed to be kept pointing at a null, so on the two bars I started with a "look at" constraint towards the null and a "position" constraint to the wheel, but then the rotating wheel created some strange hiccup, which I diagnosed as "gimbal lock". In the original non-ICE version, simply changing the "rotation order" in the "local transforms" did the trick. So my question would be: how to proceed from this. There must be an easy, elegant way to solve this. The way I solved it in the end didn't feel that elegant (and was probably extremely "scene dependant"), so once again: how can I combat "gimbal lock" when using constraint driven animation... There must be some "scene independant" way to get this done, I would guess...

I'm having a hard time picturing this. If you are still interested, maybe you could post a pic?

[Hirazi Blue]

At the moment, I sadly can't show any image, as I was working this out for someone else using his model...

edit: and so I strongly believe, he should be the one revealing the model, not me...