Loading...
  OR  Zero-K Name:    Password:   

Walkers

14 posts, 459 views
Post comment
Filter:    Player:  
sort

GBrankLynx
11 days ago
(edited 11 days ago)

No I'm not referring to Walking Dead, I am referring to the walking exhibited by walking units in Zero-K such as commanders and rockos!

Last weekend it occurred to me that the movement of walking units appears to be somewhat unsatisfactory; the units appear to move with a constant velocity accompanied by a motion of the feet that is not in keeping with the unit motion.

Why is this? Is it because walking does not give a constant velocity but rather a more sinusoidal movement centered around a certain velocity? Is it that the movement of the feet is not synchronized well enough?

There is a kind of sliding motion. Thus unlike the zombies in walking dead, walkers in Zero-k seem to moon walk!

How about introducing a proper gait then to walking units to give a more realistic and visually appealing walking motion?

There are lots of studies on human and robotic gaits. This is far from an ideal reference and simply an example:

https://www.teachengineering.org/lessons/view/uno_walk_lesson01

+2 / -0



CYrankFirepluk
11 days ago
You need to smoke more weed to fix this issue :P
+0 / -0



EErankAdminAnarchid
11 days ago
(edited 11 days ago)

The long story is that all the fancy animation tools and techniques invented in last 20 years are mostly inapplicable to ZK (and Spring) animations, which is because all Spring animations are code that has to be written by coders in a text editor, rather than artwork created by artists in 3d animation software. This in turn leads to knock-on effects such as people skilled with industry-standard 3d art tools tending to find their skills useful elsewhere, and people with programming skills usually having more important things to deal with.

I had in the past attempted to reduce the nastiness of this situation by making a Blender addon that would have allowed people with no code skills to contribute animations. However, it was still very raw, limited, buggy and difficult to use, and only lessened the programmer work rather than eliminated it. Its adoption in ZK is minimal (one animation: strikecom death) because ZK requires slow to be supported; because it only works on Collada models and ZK is mostly stuck with s3o; and because the one person who contributed animations made with it couldn't code and i did not support them enough.

Also, that addon seems now to be bitrotten; my last attempt to use it myself (for the shieldfac candidate replacement model) quite literally exploded.

The long story short is it's work, and noone is doing it. If you want to take it up, it's yours - blood, sweat, tears, despair, everything you can take!
+7 / -0

GBrankLynx
11 days ago
(edited 11 days ago)

Thanks for that EErankAdminAnarchid. Is there not a simple modification or two that might give a more pleasing walking effect beyond fancy animation techniques however? Could the constant velocity not be replaced with an undulating velocity centered around the constant and such that maximum is in the middle of the stride? Or something like this?
+0 / -0



EErankAdminAnarchid
11 days ago
(edited 11 days ago)

quote:
Is there not a simple modification or two that might give a more pleasing walking effect beyond fancy animation techniques however? Could the constant velocity not be replaced with an undulating velocity centered around the constant and such that maximum is in the middle of the stride? Or something like this?

Depending on your definition of "simple". The best thing you could do at this point is fork the repository and see how easy this is to do for yourself.

As an example, this is the current animation script for Bandit, and what you have to work with by default.
+0 / -0



AUrankAdminGoogleFrog
11 days ago
Walk animations are time consuming to produce, although I think EErankAdminAnarchid makes them sound harder to write than they are. That said, many of the animations written by the modellers of various units were pretty bad and I've had to fix up the worst of them. Work on animations is welcome but there are much more pressing issues that would need to be addressed before I work on them myself.

One difficulty is that animations that look decent close in may look awful far away (and the reverse). Dirtbag looks ok at a distance but if you pitch down and zoom in you'll see it is just legs flapping around.
+1 / -0



AUrankAdminGoogleFrog
11 days ago
quote:
Thanks for that EErankAdminAnarchid. Is there not a simple modification or two that might give a more pleasing walking effect beyond fancy animation techniques however? Could the constant velocity not be replaced with an undulating velocity centered around the constant and such that maximum is in the middle of the stride? Or something like this?
Technically, units are always going to move with constant velocity. However you can make an animation that moves the model back and forth as it walks to get the effect you want. You may need to edit the piece hierarchy as, in my experience, it is much easier to make a new piece than to use a piece that is possibly used for other tasks. Also you would be messing with torso position so just hope that it does not break aiming.
+0 / -0


JPrankgajop
11 days ago
(edited 11 days ago)

EErankAdminAnarchid: What is the solution then (for ZK and Spring more generally)?

Should we:

1) Improve and support plugins that convert $EXTERNAL_EDITOR (e.g Blender) formats to Spring? I think you've used these things before for Gravitas (and other LD games?) and it worked out well as far as I'm concerned.

2) Add standard $ANIMATION_FORMAT support to the engine itself? I think this is partially useful for mesh deforms as well, and there was some work in that direction before. I don't know the limitations of this approach, and if it's related to the synced nature of the engine/aiming.

3) Create/improve in-engine tools for animating? ToolBox had one such animating software prototype (made by CarRepairer/knorke if I'm not mistaken), and I was thinking of making a more advanced version of that in SpringBoard in the future.

4) Something else?
+0 / -0



EErankAdminAnarchid
11 days ago
(edited 11 days ago)

quote:
EErankAdminAnarchid: What is the solution then (for ZK and Spring more generally)?

The approach i chose originally was based on some deliberation. I think it would go under "other: all of the above" here. It went like this:

quote:
1) Devise a way to describe animations as data rather than code. This is necessary for any i/o and to separate animation from code.

2) Provide a way to play this animation data from within spring animation script, allowing it to be arbitrarily flexible (e.g. some pieces always controlled by keyframes, others always by logic; or any mixture). This is necessary because logic is important in Spring games due to the synced nature of animations.

3) Now that you have a standardized animation format and a playback API, you can write import-export tools of any sort, including $EDITOR addons, ingame editors, or engine parsers for $ANIMATION_FORMAT.

4) Iterate to improve this format to include lacking features such as bezier interpolation between keyframes (needs engine support in Turn etc).



It worked for a while - and i guess it can still be made to work, especially seeing how most of this plan is actually done.

[Spoiler]

But it seems to me now that this is an extremely fragile approach that is prone, besides bitrot in a thousand places due to its reliance on engine bugs-as-features, to actual fragmentation with how each game trying to use this framework has to actively include it. I look at our gadget handlers as an example, and i despair. So my current thinking is that an engine parser and an API for Collada animations would be best. Just do what 0ad do.

Either way, i doubt i'll find myself working on this anytime this year.
+0 / -0


JPrankgajop
11 days ago
quote:
So my current thinking is that an engine parser and an API for Collada animations would be best. Just do what 0ad do.

OK. This, (along with appropriate API exposed to Lua) sounds like the best approach to me as well.
+2 / -0



USrankCrazyEddie
10 days ago
(edited 9 days ago)

Once upon a time you were helpful, doing things like identifying problems with the new user experience, providing information that developers could act upon.

[Edit: this was in response to a user whose posts have been deleted.]
+0 / -0

PTrankraaar
9 days ago
(edited 6 days ago)

I've complained about this before. It's one of the obvious flaws in terms of animations ZK and other spring games have.

The walk scripts should not only more accurately reflect the units' movement speeds, but they should also be flexible to change according to the each unit's speed %. Doing this can be easier than it seems:

replace

if (moving) {
[ turn pieces to pose1 with speeds x,y,z]
wait-for-turn
[ turn pieces to pose2 with speeds x,y,z]
wait-for-turn
..
}


with

if (moving) {
[ turn pieces to pose1 with speeds x,y,z * speedup_factor]
wait-for-turn
[ turn pieces to pose2 with speeds x,y,z * speedup_factor]
wait-for-turn
..
}



and have speedup_factor recalculated a few times per second.
+0 / -0


PLrankSprung
8 days ago
It's trivially easy but also a major chore which is why nobody has done it yet.
+0 / -0

ROrankForever
7 days ago
Lets just make a mode with zero-k versus the walking dead:D. Instead of chickens we will have zombies and evolved zombies ( like in resident evil 5). :D
+0 / -0