I have a question about a different version of the GN setup topic as discussed in this thread

I've been struggling to make a wheel version of this setup, unfortunately to no avail :( The ball tries to rotate around the bitangent of the forward axis which dynamically updates its orientation in space thus making the ball continue rolling around that. However, in the case of an upright disk, the disk/tire/wheel needs to align itself to the forward vector as it changes. The end result I'm after is illustrated in this gif:

Rollong disk example

I tried rolling the disc first around its axis and thought that I could then align the rolling points to the forward vector after the fact, but failed every time :( The disk is supposed to derive its translation from the translation vector delta of the empty. It's supposed to adapt also to acute angle changes in direction and 90 degree turns and to this without flipping across its roll axis (which I have miserable failed in accomplishing :() as shown in the example gif.

What would be your take on this?

Thank you so much in advance :)


PS: Here's the link to the blend file:

  • $\begingroup$ Could you provide your Blender file using blend-exchange.com ? $\endgroup$ Commented Feb 26 at 17:54
  • $\begingroup$ Sorry, I could not help as Blender 3.6.8 is crashing reading the provided file (Segmentation fault). $\endgroup$ Commented Feb 26 at 20:32

2 Answers 2


Like Nathan, I'm a big boy, so I don't pollute cache with unnecessary geometry data. I only simulate a few constants:

  • last position, in order to calculate velocity
  • last velocity, in order to compare direction change and detect when to reverse
  • "Reverse", so that I can remember the cylinder rotation has been reversed
  • distance traveled (which has been graciously abbreviated in the Group I/O so I don't have to fix the typo in my screenshot, that Firefox has detected just now)

You can notice there's a problem that I align to velocity, and so the cylinder suddenly rotates at $<0, 0, 0>$ velocity, perhaps I should maintain "Last non-zero velocity" for the direction…

Also comparing to Nathan's answer, I realize I should have limited the "Align Euler to Vector" node's Pivot to $z$ axis…

Saved in B3.6.5 so Stef can open it:

  • $\begingroup$ Thanks for the 3.6.5 file! Never played with NLA before. A chance to learn... $\endgroup$ Commented Feb 26 at 21:36
  • $\begingroup$ I did have a pre-sim setup that spews out the radius of the object to be rotated to divide with the arclength inside the sim zone. It is very easy in Houdini to construct an identity matrix and use that in a quaternion axis/angle rotation calculation. In GN, for the users' convenience of course, they are distilled into low level nodes which confused me quite a lot. And also, Markus used a conditional to control backwards and forward roll and for the life of me, I never knew that the compare node had a "direction" criteria for vector comparison. Thank you both for helping out... $\endgroup$
    – jacobo
    Commented Feb 26 at 23:59

The easiest thing to do is not even handle the geometry inside the simulation, but to just keep track of the variables that we need to put our geometry where it ought to be:

enter image description here

Which gives us:

enter image description here

I'm only using the simulation nodes to calculate what I need. I need the direction that the empty is travelling, given by my deltaPos output. I need the total length of the path that the empty has travelled, given by pathLength. And of course, I need to know where the empty actually is.

After that, I can rotate about my object origin, first rotating the wheel appropriately to the length of the path travelled, then rotating about object Z to align object +Y with the direction that the empty is travelling. After I do all that, I can set the position of the wheel appropriately. If I did it before, I couldn't rotate about object axes. That's why it's convenient to just use the simulation group to handle the variables.

There are a few things to take note of here:

  1. At our first frame, the direction of travel is undefined. Notice the location initialization to the simulation nodes: I'm using that to say, hey, before we start, I was over in -Y a bit, so that the wheel knows which way to face on the first frame. The same thing will happen if the wheel ever stops: if we need it to be able to do that, we should output our input deltaPos if the length of our simulated deltaPos is 0.

  2. Your cylinder has a radius of 1, so it rotates 1 radian every time it travels 1 unit. If you use a wheel with a different radius, divide your path length by your radius to get the rotation. A bigger wheel rotates more slowly.

  3. Notice the second transition, where the wheel completely reverses direction. I'm handling this in the simplest way: the wheel rotates to face the new direction it is travelling, and continues rolling. This is not the same thing as rolling backwards, as you can see from the fins I modelled onto your wheel so I could keep track of its rotation. If we wanted to reverse our direction of travel, rather than steer and continue, we'd need to subtract from our path length and reverse our outputted delta pos, as well as keep track of if we were travelling forwards or backwards.

  • 1
    $\begingroup$ Damn, you have beat me to it :) I also don't simulate geo. $\endgroup$ Commented Feb 26 at 20:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .