Procedural Animation

[snow horizon]

Hey all!
I'm trying to recreate the animation code seen in this video (written for unity in C#)

https://youtu.be/KPoeNZZ6H4s

Thus far, I've got the second order dynamics code nailed out, but have come down with some issues and can't seem to wrap my brain around this, been stuck for a few days, maybe fresh eyes would help clear things up?

The first image is my code, second is the code from the video I'm trying to replicate.

My code returns an Array [new_position:Vector3,Velocity:Vector3]
The new_position, or [0], is then assigned to an object's global_transform.origin

The purpose of this code is to allow for dynamic procedural animation, by calculating a Vector3, and applying that to a transform.origin

[frosty vale]

bluh, I'm pretty sure I tried to implement this exact tutorial somewhere, can't remember where, lemme see if I can find it

[snow horizon]

If you happen to find it and it's in working order I'll cry lmao.

[frosty vale]

ah poop, it's also in Unity

[snow horizon]

Dang, is it more understandable than the video at all?

[frosty vale]

as the person who wrote it and is now staring at it

nope

[snow horizon]

🥲

[frosty vale]

tbh when I did procanim stuff I just used springs

there's a few equations around for stable spring solving

and they give you all the smooth in/out and overlapping action stuff you'd need

some ik to find foot positions and some springs to make the motion more natural when you're moving the feet, you're basically set

[snow horizon]

Yeah, I know that would be the easier route, but I feel it won't be a flexible enough system for some of the things I've been wanting to try.

Here's a question, when you implemented the tutorial, did you use a Vector for the velocity?

Or maybe I should ask is the object you're moving physics based?

[frosty vale]

in the tutorial, can't remember

when I did procanim stuff otherwise, they weren't physics based

I used a verlet solver approach where the velocity is implicit

means you can slap on constraints much, much easier

(so you have the current position and also store the previous position, with the velocity implicit as (previous->current / deltaTime))

main problem I had doing procedural physics animation - this was in Unity at the time - was figuring out how the hell inertia and tensors worked to give enough angular momentum to reach a desired angle =-=

[snow horizon]

Oh yeah.

I was trying a similar system once, gave up on it 😂

[frosty vale]

yeaaaaah

it's way simpler to proc-anim points

and then derive rotations from there

[snow horizon]

Mhm.

[frosty vale]

(either as the rotation from point A to point B, or using the points as part of an IK chain etc)

https://i.imgur.com/z3cEfBJ.mp4 <- this procedural boss was having navigation problems but hopefully you get the idea

one fun trick with large scale bosses and foot placement tho

abuse the navigation system to find valid foot locations :'D

godot and unity's navigation apis are similar enough in structure it should work for both

[snow horizon]

That's actually super smart.

[frosty vale]

unfortunately I've only switched over to godot fairly recently so my godot project isn't nearly as far along compared to where I used to be

[snow horizon]

Tbh I haven't messed with Godot's Nav. API.

What caused you to switch?

[frosty vale]

instability in Unity and it's animation API for one

[snow horizon]

For me it was the dismally poor performance of Unity on Linux systems.

[frosty vale]

(had a really weird, inconsistent and impossible to track down bug that made animation controllers sometimes just... not animate at all for some reason)

[snow horizon]

Gross

[frosty vale]

and then discovering the CEO was three rats in a trenchcoat

[snow horizon]

LOL

[frosty vale]

escaping from the EA sewers

[snow horizon]

😂

That made my night.

[frosty vale]

yeaaaah

fuck owing money to that guy

godot is open source and has come a long way

[snow horizon]

And improving with every release. I'm running Godot 4 now, or at least converting my projects.

[frosty vale]

aye

I'm using GodotSharp because I prefer c#

[snow horizon]

I used to really like C#

But not having {} all over is nice.

[frosty vale]

better type safety tho

I initially tried in gdscript

but type safety there is harder + you have the issue with no reciprocal relationships between named classes that is an absolute pig to work around

[snow horizon]

I wish that the Shader code had followed GDScript syntax though.

And how's that difficult to work around?

[frosty vale]

it's mostly frustration with 3.4, which had a number of bugs that caused it to claim there were reciprocals in cases where there genuinely wasn't

and there are a lot of cases where you do want two different scripts to be able to refer to one another by type

losing type safety also means losing intellisense :<

(for example if you're setting up some sort of graph or state-machine structure, you generally want the nodes and the graph to be aware of one another's types)

[snow horizon]

Ah yeah.

I have some similar systems for my Items, Stats, and Spells in my game.

Definitely wouldn't have been possible in 3.x

I'm gonna get some rest, I'll probably ping the help channels again later and see if I can pick anyone else's brain on the matter.

Nice talking w/ ya btw, appreciate the help

[frosty vale]

np!

best of luck!

[snow horizon]

No luck thus far

[snow horizon]

Wanted to give you an update, finally figured it out.

[frosty vale]

ey, congrats!

[distant dune]

hey! do you still have this?