[starlingAS3] External scale OR adding bone programmatically

ilya.denisov

Hi everyone.

TL; DR Is there any elegant way to manage external transformations (scale) with respect to bone 'inherit*' properties?

Long version:
In my game characters of different level should have different size, so I need to apply this scale to spine animation. On the other hand there are some other objects in animations that character interacts with (e.g. boxes) which should not be scaled with character itself. So I decided to use editor feature 'Inherit scale' and disabled scale inheritance for bones that are related to non-character objects. But then I need to apply scale to SkeletonAnimation instance and I see following choices:

Apply scale property of DisplayObject (starling) but that will not respect 'intehit scale' feature
Set skeleton.rootBone.scaleX/scaleY programmaticaly but if root bone is animated then these values will be overwritten.

So effectively I have to have another root bone which will only be used for that purpose and will never have scale timeline. I could ask artist to add it but he will eventually forget to do that + it will make animation harder to work with in editor as another hierarchy level will be added. Next thought was to inject this 'super-root' programmatically but here I faced problem as bones vector doesn't live in isolation - other members of SkeletonData depend on bone indices (e.g. skinned meshes) - so I would have to patch whole SkeletonData object which is difficult to implement and also difficult to maintain as spine releases new version of runtime.

ilya.denisov

Pharan

For most runtimes, the best practice is to NEVER animate the root bone. I'd say it's generally a good idea in any case, even from an animator's perspective, since you never know when you need things to move independently. It's certainly how I construct and animate all my skeletons. One level lower is not a big deal.

Some runtimes (and use cases) rely too much on being able to manipulate it programmatically, especially for scaling and rotation.
For your case, it seems like you need to manipulate it so you shouldn't be keying it.

So adding that extra bone in Spine editor is what I recommend.

ilya.denisov

If that's ideologically implied solution then root bone animation should be disabled on editor level I think. Which also implies that root bone is useless on editor level and should not be visible at all. So why to put it there in the first place?

Pharan

I dunno. I didn't the design the thing. :rofl:
But you could say the same for all other 3D game animation imports (which is what Spine is patterned after).

Maybe it's actually a good feature to have root bone editing disabled by default.
Like gray it out, but make it unlockable of the user wants.

BinaryCats

Root is only really ever used in root motion. which looks great! (even if spine doesn't really support it)

Pharan

If you're after automatic processing without needing to use Spine editor (at least for the time being), you could run a find-and-replace process in the json instead.
Instead of adding a super root, add an interveneing bone (let's call it a subroot) so that your original root becomes the super root. and the subroot becomes the child of the root and the parent of all other bones.
And move the setup pose of the root to the subroot too.
Then change all the animation keys target from the original root to the subroot.

You could even have that json reimported back into Spine for further updates.

ilya.denisov

Pharan wrote
If you're after automatic processing without needing to use Spine editor (at least for the time being), you could run a find-and-replace process in the json instead.
Instead of adding a super root, add an interveneing bone (let's call it a subroot) so that your original root becomes the super root. and the subroot becomes the child of the root and the parent of all other bones.
And move the setup pose of the root to the subroot too.
Then change all the animation keys target from the original root to the subroot.

You could even have that json reimported back into Spine for further updates.

If you suggest to append subroot to bones list - AFAIK it won't work since parent should be placed before children. But if you suggest to insert new bone right after root then all issues with indicies I mentioned earlier are relevant.

Pharan

Oh, you're right. You'd have to add 1 to all the indices.
Just finding the right array entry per vertex is a pain. Definitely not something you can just do in notepad.

ilya.denisov

Pharan wrote
Oh, you're right. You'd have to add 1 to all the indices.
Just finding the right array entry per vertex is a pain. Definitely not something you can just do in notepad.

It's not about being able to manually fix something. It's about automated pipeline because I have a lot of animations that are often updated/created. Creating script to fix JSON after exporting it from Spine editor is doable but it will heavily depend on animation format which could (and will) change with new spine runtime releases. There's simplier solution in that direction - hacking a single line in SkeletonJson to fix index on parsing. But still it means that modified spine runtime is used and that this change should be maintained with new releases which is wrong thing to do.

So it seems that best solution is to follow convention not to animate root bone which could be somewhat forced with auto-check after export/on game load (at least I won't need to actually play the game to test that every time).