TLboner - powerful skeletal animation system (help wanted)

[Taehl]

Like the title says, I've made a skeletal object and animation system. Just the thing for smoothly animating characters (indeed, it's going to be animating the protagonist in my upcoming game Underlife). Some features:
- Full tweening between all animation keyframes (and between all animations)
- Combinable sub-skeleton animation (example use: Running animation on legs combined with sword-swinging animation on upper body)
- Looping, non-looping, auto-redirect animation types
- Per-animation keyframe rates
- As gentle on system resources as possible
- Simple data format
- Can have functions on bones (intended for adding visual effects)
- Can have functions on animation frames (example use: Play a footstep sound when foot hits the ground)

Complete as it may be, I would like some help. I would like to be able to provide a skeleton and animation editor with the system, since making them by hand is so tedious. Is there anyone here who's willing to work on such a thing?

Here's a preview with an interactive example (please excuse the lameness of my wiggling cactus thing).

[GijsB]

what's with the random 'frame function called' text on the screen :O?

anyway, its pretty cool

[tentus]

I would be interested in helping as I can, but it looks like our coding styles are... fairly different. I'm not nearly as sophisticated a programmer as you are.

Still, got anything specific you would like me to do?

[vrld]

Wow, this is awesome!

[pancakepalace]

Interesting. A few questions.

1) Is your class stable, or do you plan on adding more features? I read your code and it seemed you were still pondering a few points. I think the class should be full tested and stable before making an editor.

2) I'm imagining this type of editor. Tell me if I'm way off. First, you have a drawer with thumbnails of images you can drag and drop on the main editing surface. Then you can rotate, scale, and move an image around. Once you have all the images or instances of a similar image where you want them, you save the state. A timeline at the top of the editor lets you attach the different states you created putting a dot where the instance is. You can then drag these dots around to put more or less space between each instance. You can play the animation to see if you like it. Once you save the animation, all the variables are saved in your format (hence, why the format needs to be stable, i.e. not changing). Is that the type of editor you're thinking about?

3) For portability between systems, it might be interesting to think about making it a JSON format, or some other standards. Then, something done with the editor could be used in another framework. This might be useful if you're using Love for prototyping, but then another framework for further development.

[tentus]

It seems to me that the logical way to do an editor is to focus on the bones almost to the exclusion of everything else. Some thoughts:

Always start with a root bone (represented by a hollow circle, perhaps), and then build from it. The root bone represents the origin of the figure (0,0).

Subsequent bones could be represented as a line with a circle at the outer end. To select a bone, you click the circle (nice easy collision math.) The selected bone would change color, and its properties would be show as a list on the side, possibly with buttons under/beside the values that let you change said values. Press N or some button to add a new child bone from the currently selected bone.

At the bottom of the screen could be a timeline. There would be a cursor of some kind to show you where you are in the timeline. Modifying a bone at frames other than 1 would create animation (unless the property is non-animatable).

...

I dunno, I've spent so much of my time playing around in animation software that I fear my thinking may be crystallized. I hate to think of myself as stuck in my ways, but that might be the case: the above makes sense to me, but may not be the most appropriate way to set up an editor.

[Taehl]

what's with the random 'frame function called' text on the screen :O?

Animation frames can have functions attached to any pose (analogy: a pose is to an animation frame as a bone is to a skeleton) which are called exactly once every time that frame is reached. They're passed the coordinates and angle of the bone, along with any extra parameters if desired. In the example, I had it print a little message. What I intend to use it for the most, though, is for playing sounds at certain frames (for footstep sounds and such).

Still, got anything specific you would like me to do?

Ideally, the editor would allow the user to create and edit skeletons (adding/removing bones, changing bone properties) and animations (adding/editing frames and their poses), and save them (as Lua scripts). It would be graphic-based, that is, it would show the skeleton you're working on, let you preview the animations, etc.. It would be nice if it had an ability to zoom and pan to make editing easier. Additionally, (this would be tricky), it would be good if it could preserve information like functions attached to bones and poses, so one could edit and save them without having to add that information back in by hand.

1) Is your class stable, or do you plan on adding more features? I read your code and it seemed you were still pondering a few points. I think the class should be full tested and stable before making an editor.

There are a few small tweaks and improvements I'm thinking out, but the functions, how you use them, and the data structure of skeletons and animations(i.e., the stuff an editor would be working with) aren't going to change unless I figure out some radically better way to do them (not likely).

2) I'm imagining this type of editor. Tell me if I'm way off. First, you have a drawer with thumbnails of images you can drag and drop on the main editing surface. Then you can rotate, scale, and move an image around. Once you have all the images or instances of a similar image where you want them, you save the state. A timeline at the top of the editor lets you attach the different states you created putting a dot where the instance is. You can then drag these dots around to put more or less space between each instance. You can play the animation to see if you like it. Once you save the animation, all the variables are saved in your format (hence, why the format needs to be stable, i.e. not changing). Is that the type of editor you're thinking about?

That sounds pretty much like what I want. The only difference to what I had in mind would be that instead of dragging the images around, you pose the bones (since bones' images are generally going to be rigidly attached to their bones). I'd be happy to make some interface and workflow mockups for whoever may want to help me with the editor, and am open to suggestions on them.

3) For portability between systems, it might be interesting to think about making it a JSON format, or some other standards. Then, something done with the editor could be used in another framework. This might be useful if you're using Love for prototyping, but then another framework for further development.

At the moment, my format is simply a Lua script (consisting mostly of tables) (see example.lua in the .love file). The two advantages of this are that I don't need an interpreter to read them (since the Lua interpreter is part of Love), and they tend to compress nicely (so they won't take up too much space when in a .love file). Would JSON (or LON, etc.) really be that much of an improvement?

Always start with a root bone (represented by a hollow circle, perhaps), and then build from it. The root bone represents the origin of the figure (0,0).

This is how skeletons are already structured in TLboner (or did you check the code to figure that out?). Using a simple tree data structure is part of how I can draw and control animations so efficiently.

Subsequent bones could be represented as a line with a circle at the outer end. To select a bone, you click the circle (nice easy collision math.) The selected bone would change color, and its properties would be show as a list on the side, possibly with buttons under/beside the values that let you change said values. Press N or some button to add a new child bone from the currently selected bone.

This sounds great. The only thing I would want to add is that it would be nice if you could toggle bone graphics on or off, to give a better idea of what the thing you're editing will look like in-game (especially handy for animation, to make sure stuff isn't overlapping wrong, etc.).

At the bottom of the screen could be a timeline. There would be a cursor of some kind to show you where you are in the timeline. Modifying a bone at frames other than 1 would create animation (unless the property is non-animatable).

I agree about having a horizontal timeline at the bottom (with a movable cursor and play/pause button). The way I've been envisioning it to work, however, is that there's a "add pose" button which will either:
1) If there's no frame B (the cursor is on or after the last pose in the animation), then the last pose will be duplicated.
2) If there's no frame A (the cursor is before the first pose in the animation), then the first pose will be duplicated.
2) Otherwise, it will create a new frame half way between frame A and frame B (the frames to the left and right of the cursor), posed at half-tween between them.
Frames will be equally spaced on the timeline since TLboner animations have keyframes at a constant rate (specified for each animation). Using this behaviour, I imagine it would be easy to do both forward-frame animation (pose, add frame, tweak pose, add frame, tweak further, add frame, etc.) and normal keyframe animation (make start pose, add frame, make end pose, move cursor between then, add pose, tweak to desired intermediate pose, etc. (subdivision style)).
Hopefully that makes sense?

Wow, this is awesome!

Thank you! I knew I needed technology like this for Underlife after playing the game 'LIMBO' (which is excellent by the way), and after enjoying 'Soldat' for years (also excellent, but in a very different way). I hope that TLboner will become a solid and attractive alternative to traditional animation techniques (where you have pre-drawn images of a character in various poses). It's kind of a far dream, but I'd also be joyed to see some Love games which have segmented bosses (like many Sega Genesis games boasted).

[slime]

Replace "the" and "facebook" with "TL" and "boner".

[tsturzl]

It looks like some odd sex toy o.0

dear lord...

[pancakepalace]

Why not allow frames to be separated by different distances. I think this could introduce nice rhythms.