Inverse Kinematics animations for Spring in Blender

[Beherith]

Here we are, dragging BOS/COB animations into 2020 with a set of plugins that allow the following:

1. Import an S3O model directly into Blender
2. One-click convert the s3o into an animateable skeleton with Inverse Kinematics
3. One-click export into a BOS file for variable speed animation

https://github.com/Beherith/Skeletor_S3O

Full documentation available on the github link as well!

Using this tool is an easy and powerful way to create very pretty walk, idle, death animations for units!

Link to tutorial video: https://www.youtube.com/watch?v=DaMLNfOR6KU

skeletor_s3o.png

(760.44 KiB) Not downloaded yet

[FLOZi]

Awesome.


Why the hell BOS?

[Beherith]

Cause i'm used to it. You can change out the lines to lua, or just convert it, or even submit a PR

[FLOZi]

I imagine there are lots(!) of lines generated which would be tricky to convert by hand. Got a sample of exported bos?

[Beherith]

Walk(), Stopwalking() and Unitspeed() are straight up auto generated by the script:


https://github.com/beyond-all-reason/Be ... 67591e6a3

[FLOZi]

Relatively clean output. I'm guessing that each 'if bMoving' section is a frame of the animation?



p.s. Why not using signals?

[Beherith]

Yep, its clean as a whistle. Each bmoving is a frame.

Note how animspeed uses integer division to always have perfectly smooth interpolation.

On signals, why use them when they are not needed? Could you elaborate on why they would be a good thing here?

[FLOZi]

IMO an approach using signals is better than OTA style 'if bMoving' for getting smooth transitions and avoiding 'walking on the spot when stopping'.

I suppose it's because it can kill a thread instantly rather than waiting for a frame to complete. I took the approach with MCL and again, IMO, it works better. My frame of reference was previous S44 and IW bos walk scripts and OTA 3rd party ones so ymmv. It was common to see 'ice skating' / 'walking on the spot at end of stop moving' type errors in scripts of that era with the bMoving approach. Probably it depends on the play duration of the keyframe; with an automated process you can have many, short frames and might not see any problems.

https://github.com/SpringMCLegacy/Sprin ... /Atlas.lua
https://github.com/SpringMCLegacy/Sprin ... h.lua#L424 to 473 relevant.


What's great about your tool (as opposed to Anarchid's table-heavy approach) is that it is easy to adapt to any animation control logic.

[Beherith]

On the 'wait for the frame to complete' part:

I think my current implementation of bMoving with StopWalking () being called from StopMoving() also does not wait for a frame, since:
StopWalking() commands all pieces to return to their default state immediately, and this overwrites any previous commands from Walk().

I'm trying to avoid many short frames, and use good interpolation because:
1. longer frames are easier to scale with unit movement speeds
2. Less frequent frames = better performance?

Am I thinking correctly here?

Is there any guarantee what order threads will be executed in? Because I was thinking along the following:

Code: Select all

UnitSpeed(){
	set-signal-mask SIG_WALK;
	while(TRUE){
		set animspeed;
		sleep animspeed;
	}
}

StartMoving(){
	start-script UnitSpeed();
	start-script Walk();
}

StopMoving(){
	signal SIG_WALK;
	call-script StopWalking();
}

The key here being that animspeed would thus be updated exactly on time. Or should I just update animspeed from Walk() as it doesnt matter?

[FLOZi]

It is quite some time since I did the motion control logic for MCL, so my arguments may be from incorrect recollection of the problems I had, but note the total absence of the MotionControl function you are using (Which is a decompiled version of an OTA script, hence the terrible variable names!).

I'm not convinced that your StopWalking will immediately terminate any animation and reset to default but I am quite willing to be wrong as I assume you tested it pretty thoroughly. You use only Sleep and not WaitFor so perhaps that was my problem with animations interfering with one another.

On paper #2 is correct but there are so many confounding variables I wouldn't expect a huge difference in performance.

I wouldn't bank on their being a a guaranteed thread order but I don't know.

A quick glance at my own code suggests it probably isn't accounting for speed modifiers correctly though I would have thought someone might have noticed.

[Beherith]

I've had no issues with bMoving even without signaling terminating anims on time, and I look very closely at them.

Thanks for the help, i was just trying to avoid function calls from Walk() (for clean looks), which is why I didnt want to UpdateSpeed from it.

Wait-for-x should be reserved for truly variable thing like heading.

[SpikedHelmet]

Getting an error trying to import any of my s3os:

Traceback (most recent call last):

File: ..."s3o_import.py", line 501, in execute if not context.scene.objects.active:
AttributeError: 'bpy_prop_collection' object has no attribute 'active'

location <unknown location>:-1

It also happens if I don't even select an .s3o file and just hit Import. Line 501 is also empty.

[Beherith]

Which blender version? this is for 2.82

So you cant even import a model with the Spring ZY import?

[SpikedHelmet]

Oh, it's 2.83 I have. Any idea where I can get 2.82?

It happens with any .s3o i try to import using s3o_import.

EDIT: It seems it was the location of my file. I moved it to the desktop and it now loads. Dafuq.

Of course, I've never used Blender before in my life. Where are the "Correctly rotate s3o" and "Create skeleton" buttons? Lol

[PtaQ]

Top right corner of the viewport. Don't use "correctly rotate .s3o btw" - its deprecated.

[Beherith]

Just an example of what this can do for you:

corcat_v2.gif

(2.64 MiB) Not downloaded yet

[9heart]

in terms of a pure performance gain, would it be worthwhile to remake my mod's animations with this tool?

[Beherith]

You will likely not gain any performance with this tool, but that depends (a little bit) on your mod. What you will gain is responsive, accurate, smooth and perfectly speed scaling animations every time!

My ballpark estimates of performance with walking robots using these animations is, about 1% CPU load per 100 (moving) units for the animations.

[9heart]

could one script some kind of an "anim LOD"? where units off-screen only receive major sim-frame updates every 30 frames or something

[FLOZi]

Scripts are synced for the simulation (consider weapon emission points) so no.