I’m trying to rotate a sphere in a plane procedurally, similar to BB-8 from Star Wars, using geometry nodes. I got X and Y axis right but when moving in other directions I got some weird rotations. Anyone knows how to solve this using **geometry nodes**?

Looks like you’re trying to “mix” Euler-rotations… that never works as expected.

The reason is the maths of rotation…

The Hand-wavey explanation is to imagine a ball at the position (x:10,y:10)… now imagine the many ways you could have arrived at the position (x:10,y:10) and by altering the path at any point you would end up with a completely different rotational configuration.

This is why quaternions are used for rotational interpolation… you need that extra “dimension” of information to encode “where the rotation came from”.

That is why I think a geometry-nodes solution to your problem may be possible but will probably require a lot more effort than just using a follow-curve modifier or follow-path constraint. And I hope someone can correct me and that it is just as simple as using the axisAngle setting.

Good luck.

This is not so easy…

This is the best I could do for now. It works around the origin 0,0. But you would have to “reset” each part of a roll in an animation. Each keyframe would have to be reset to the origin.

BBroll.blend (934.2 KB)

Thank you for trying.

I figured that out, I’m looking for a practical solution. Thank you.

I don’t understand. What did you figure out? I’m saying that a practical solution may not be possible in geometry nodes (in its current state) and that the “practical solution” requires something else, like scripting or the follow-path constraint… so it seems there was a misunderstanding.

Clarity: A 3D ball rolling on a 2D plane is a *dynamics* problem (i.e. it is non-linear by nature). To solve for the ball’s rotation you need to keep track of the ball’s position in time… i.e. you need to know the path. The coordinates of the ball is not enough, because there are a infinite amount of paths that could have resulted in those coordinates, which means the solution space for rotational configurations is also infitine… i.e. no solution.

When simulating a system system like this you would store the delta-position of the ball to give you the velocity vector, and then your system knows to rotate about that axis. Geometry nodes has no mechanism yet for storing things like the delta-position… this is why you still need curve data or simulation data or something similar for Blender to know how to animate motion.

Geometry nodes is still quite limited in 2.92, but even with 2.93 the workflow is more one of “synergy”… i.e. Geometry Nodes is to be used in conjunction with other modifiers… it would be rare to use it to solve all problems by itself.

Have fun experimenting with geometry nodes and good luck.

That’s the problem I came across. I had to use the delta from the origin to the current position, so it was limited.

The other thing was the Align Rotation to Vector node only works for Points / Point Instances. I couldn’t find the equivalent to do an axis/angle rotation for the overall geometry.

Yeah, the *Geometry->Transform* node is Euler only, so that’s a non-starter.

Hey! That’s pretty decent for short linear “dashes”!

Slippage is only apparent in the 2nd example.

Probably if I made it linear interpolation it would help. The slippage makes it fell sorta like a screeching tire.