Blender Geometry Nodes: Rolling disc Simulation

Question

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:

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 :)

AJ

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

Answer 1

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:

Answer 2

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:

Which gives us:

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.