Procedural animation for locomotion V1

Game Engine Game Engine Support and Discussion
1

I want help

  • configuring this so its more usable.
  • redesigning for less logic -(uses about .13ms for me)
  • discussing usage cases

I think this is important…
thoughts?

Attachments

ComplicationButWorthIt.blend (465 KB)

2

by the way, this does not use physics at all :smiley:

its all rays etc

Attachments

mECHAcHICKENrIG2.blend (510 KB)

3

“configuring this so its more usable.”

remove all code and bricks that are removable.
remove all hardcode removable
follow the standard basic syntax rule (to give a aspect more readable to the code)

remove code unnecessary:
ie:
placeIk
and
placeik2

are 99% identical (except some … name … hardcode :D)

overall -> forget performances!

why premature optimization is to avoid? you know?
it increase the complexity of code

my 2 cent :wink:

4

Yeah, I was thinking, I could use offset vectors and rotations, and the properties to do the same thing,

so only ‘movment’ is 1 script,

Did you like the end effect?

I think I can ditch everything but the ‘center’ and the ik targets,

here is the current rig, it’s working pretty well, but I need another ray (from center) so falling looks better :smiley:

Attachments

ProceduralAnim4.blend (627 KB)

5

that is pretty cool (also if now the “bullets” kill the CPU … lack the self-destruction of lifetime)
but is not better use an armature? that way you have much less objects to manage (and all microanimations)
i guess a good animation can mantain the robotic appeal

6

it moves by detecting if the ray is hitting,

and yes a armature would be easier, but I was trying to go with 100% procedural generated movement and walk,

(it moves forward using the same raycast to see if it’s hitting the ground that it places the feet with)

I threw the bullets in last night right before bed,

I am thinking I could remove the ray casting placer objects, and do rayCast instead, and reduce the clutter,

and make the system more flexible somehow,

I loved mechwarrior back in the day, so this brings back warm fuzzies for me.

7

there are a number of dependences unsolvables (or hard)
i guess the ray is better that still where is

moreover you should separate well the logic of objects.

the foot run its logic, 90% or more of that is stuff internal.
(this not require even much readibility)

a little part of it (the ray info) can be a info useful (or necessary) for the “root object”
this must be instead very clear (and fews)
maybe you can write this info directly on the root object (in a property with a clear name of what contain… for example “ray_hitposition”)
in the best case the root object can also ignore the existence of foot object