Procedural walk cycle with Geometry nodes?

Hi!

I would like to create a walking creature, but instead of animating all the limbs by hand, using something more flexible. So I can make its walk slower/faster (with smaller/bigger steps), in all directions (sideways, backwards, etc) without having to animate the whole scene by hand. I don’t need nice motions, the only important thing is to keep the feet from sliding on the ground, and have just a simple lift up and put down motion between the steps.
I’m thinking of something similar to those modern game characters where the walking happens somewhat automatically as we move in all directions.
There is a pumpkin sample file on the official blender website with a procedural walking action, but its legs are just snapping from grid to grid, not actually moving.

Alternatively, there’s this simple tutorial: https://youtu.be/imbIsNAvUpM
Which would be great, but not really good for all directions and changing speeds.

I’ve tried to make it with geometry nodes, but i’m probably way too dumb to make something this complicated.
Has anyone tried it before? Or can someone give me a direction to start on?
Thank you! :slight_smile:

I hate to burst your bubble here, but:

This isn’t being done with geometry nodes. It’s been done with code. Geometry nodes are essentially visual scripting, which is useful to a point, but for something like this, you’re going to have to buckle down and start writing some C++.

Here’s a paper about how exactly this is done:

Yes, that’s what i was afraid of, now i’ll go to the mountains and cry :smiley:
Thank you very much! :slight_smile:

Yeah, doing that with GN is likely to be quite difficult.
As GN only deals with geometry, what you can do with it is like automating the motion of some basic vertex / edges or faces. Then you’ll have to use them to drive an armature, and the armature will deform the character.

I think some addons already does that, try to search for auto walk or similar words on blender market. That will save you a bunch of time.

Now if you really want to do that by yourself get ready to spend some time.

Probably GN can be useful there, but half of the remaning thing will be rigging / contraints and setting things up.

For one or a few character that will work, if you need to do a lot of them I’ll keep looking for other solutions.

Good luck !

Would be better if GeoNodes allowed to tap into rigging, keyframes, actions directly at first place, without some dummy proxy object. right now it can’t.

If GeoNodes allowed to select actions for instance, it would be easy to make procedural animations based on these, make them run faster or slower, invert directions, and so on and so forth…

So GeoNodes needs more “hooks” to other blender functions.

What you’re describing is Animation Nodes:

I know of animation nodes, that’s specifically why I talked about action hooks.

Animation Nodes creator is the GeoNodes project lead by the way. That guy is phenomenal.

Geonodes were intended for making custom modifiers and generating procedural meshes, not animation rigging. Different area whatsoever

Geonodes is part of a bigger project called “everything nodes” and it is intended to do many things procedurally, that’s why there is a scene time/frame input, it’s clearly geared toward procedural animation as well, and modifiers are an entire part of the rigging process since they can hook into armatures.

Let’s not start gatekeeping what Geonodes is and what it isn’t, especially when some modifiers are specialized into rigging.

It is not gatekeeping when it is accessment of the current situation. No modifier ever controls an armature, they can only read from it. And “everything nodes” is a concept stage at best, for years. What you intend sounds like job for bone constraints and drivers, so you better look into them

Yes, it’s literally gatekeeping to gatekeep the scope of a functionality especially when you’re not in charge of its development yourself. Happened too often within this community. “You want procedural modelling? This isn’t what blender does, go use Houdini” in the past.

I never talked about modifiers controlling armatures, I talked about modifiers being able to hook into armature data, just like geometry nodes has a scene time input. Its purpose is literally procedural animation. Surely geonodes will be able to hook into action data as well in order to make complex procedural animation a breeze.

Thankfully Jacques Lucke doesn’t lack vision or imagination.

This argument is not entirely without merit. While I admit Geometry Nodes turned out useful, their development redirects dev attention and funds from other areas of Blender that are in dire need of improvement. Animation editor, texture paint, baking, particles, physics, etc.
Geonodes are not even properly integrated into regular geometry modifiers system. Try using them to edit vertex groups or UVs non-destructively: you can’t, because of “generic attribute conversion” nonsense. Yeah, it will be nice if they could read more types of data. As long as it stays read-only; I can imagine a mess that would result of trying to fully integrate them into animation editor

I get your point however as I understand things, dev contribution is purely on a voluntary basis. So you need to either commit code yourself and hope it will be merged (hard if you’re not good at math and at C++), contract someone to implement the things you want (costly) or successfully convince a core dev to work on the issue (and there are a lot of issues). Blender codebase also has a lot of technical debt which makes things even more complicated, thus your point about the mismatch between geometry node system and the rest of Blender. So any improvement in legacy code requires a lot of work.

As I understand it, Blender’s core data model is a mess and touching anything related to it can bring down the entire application, the result is that some functions have barely evolved since 2.79, for instance some of the things you’ve highlighted.

I don’t think Geonodes is to blame, no more than EEVEE next, for the lack of improvement when it comes to animation, particles or physics. You need to find someone willing to work on these and it’s no small task. While Blender gets a lot of funding, it is neither Autodesk nor Maxon who have billions available and don’t rely on volunteers to fix things.

If Geometry nodes can completely replace the need for Modifiers which latter is not very flexible, it will be a huge step in my opinion.

I was mad when the devs decided to remove the game engine but now I understand the tradeof in terms of maintenance. Blender is a big project, and do a little bit of everything, but let’s be honest, MAYA non destructive modelling system is superior to Blender, CINEMA 4D effector/morgraph system much better than modifiers, so Blender will always be “just good enough” in a lot of domains.

Ultimately, I think one thing that should take priority is the scripting API, right now it’s basicallly just UI automation and it limits significantly what addons can do, this is why Animation Nodes was never really well integrated into Blender, because it relied on way too much hacks. If the scripting API was better, Geonodes could just have been an addon.

Improving the plugin system would be a huge task but it would also allow anybody that knows Python to prototype core functions instead of relying on C++ core development.

I am trying to figure out something similar with geonodes. I used empties as rig control. Then parent each empty to a single vertice. Then animate vertices in geonodes.

Don’t let yourself discourage of the answers here. I can tell you: It is possible with GN and i already made that and saw also others successfully build it. But (and yes, there are of course disadvantages) you might have to build some workarounds e.g. move empties by drivers (or GN) and move your armature with the help of these empties, because GN itself cannot move armatures (but shouldn’t be a problem if you are moving your feet by IK anyway). Also GN might be very slow depending on your node tree. If you have a bit more experience with GN you might build a quicker one. I don’t want to go too much in detail here because i am planning to make a tutorial about it, but one thing is for sure: it is possible

It is not like it is literally impossible, the question is if it is really the best tool for the task. Compared to something like armature constraints (Action constraint in particular), and drivers with custom scripted expressions.
Personally, I am too intimidated to try either because of complexity of the math involved. One thing that I can say for sure, that Geonodes performance will be a non-issue. They are only slow when dealing with thousands or millions vertices, and for this task, you only need to animate about a dozen. I’m curious about you will come up with

After I tried hacking together some rig + geonodes examples, I have to agree that we need more integration between the two. Would be much more convenient. Drivers and expressions work only with scalar math by default, vector math requires Python, and even in that case, there is no direct way to input Vector3 into an expression (you need 3 float variables every time you add new position input). While geometry nodes solve that issue, forcing them to work together with rigging is a shitshow. Yes, you can attach empties to geonode driven vertices; but it will likely result in a dependency loop if working with armature. Unless some overly complicated setup like control armature => control mesh => empties => final armature that isnt animated directly

Yes, agree. Not that experienced in rigging but I managed to work it out for my needs. But as you said it is a bit of a shitshow. I think integration of 2 has great potential.

Simon Thommas from blenderchat said:

“yea, anything with GN currently for this purpose is definietly more of a hack. For the future I imagine rigging nodes to rather focus on setting up properties/relationships/hierarchies between bones which would plug into geometry nodes for the actual deformation and setting up weight attributes.
In theory the armature itself can be represented as a geometry type. To actually be useful we need to support things like rotation vectors/matrix multiplication/space transformation more natively which is planned for GN anyways afaik.
Just by proxy of generalizing all kinds of geometry attributes so that things are compatible, the use cases for geonodes in other aspects of Blender will get more and more. Once we’re at a point that is robust enough we can build other systems on top of that, where it makes sense to separate/abstract.
That’s just some of my personal thoughts, I’m not the most reliable source on what is actually planned. I haven’t really looked at this too deeply either. But maybe it makes sense to start thinking about how exactly we want to structure this in the future.”