TLboner - powerful skeletal animation system (help wanted)

[Taehl]

It keeps drawing more efficient by allowing the pose math to be simpler. If you really need to change the animation rate, you could either chop the animation into different, linked parts (each with the desired keyframe rate); or you could change someSkeleton.anim.t and .r (start time and rate) to different numbers mid-animation (possibly with functions within the animation itself!).

[pancakepalace]

I'm not sure if this is a good idea, since I haven't gone through all the details in my head. But, I'm thinking the editor could use box2D physics to handle the bones with rotational joints. You could have pins on the extremities of the limbs that you move around to their desired location to make the frame. By using the physics engine this way, you assure yourself that the bones and their connections are moved in a natural way. Once the frame is saved, the positions of the images are saved as well, and box2D is no longer needed. Box2d simply helps the place the images naturally. Does that make sense?

[Taehl]

I'm afraid that I can't envision what you're talking about. I don't want to dismiss it out of hand, but I can't figure out how, exactly, the Box2D stuff would enter into it. Can you give me an example (preferably a video) of this kind of physics-assisted animation creation? Does Maya or Softimage or something offer it?

Also, I've been making tiny little improvements to the system. It can now properly handle animation in reverse time, for instance.

[pancakepalace]

I haven't used any other skeletal animation systems, so I can't provide you with examples, or even know if others have done it this way. Let me try to explain my idea.

Let's say we want to make the animation of a man running. We have a head, a torso, and four limbs each divided into three parts (upperArm, lowerArm, hand / upperLeg, lowerLeg, foot). Now, in the editor we could just move these images around and save the frame when we like how they are all positioned in reference to each other. But, if we are just moving without any constraints, it becomes hard to tell if we moved all the parts correctly in reference to each other. This is where Box2D comes in, it puts restraints on each part in relation to the others. If we move the torso, the limbs will follow naturally, because they are connected to each other with rotation joints. If you have a pin on each hand and foot, then you can move these four pins around with the mouse and your skeleton puppet will automatically achieve a position in which all parts are in their correction proportion between one another. When you save the frame, the data for your system is provided, and box2D is longer needed. It's only used while creating the frames, so that your actors move in natural fashion. Like normal bones connected to each other. It has nothing to do with your format, just something for the editor. It could be an option.

[Taehl]

I think I see what you're getting at now. That isn't necessary. In TLboner, parts aren't disjointed or otherwise unconstrained. Indeed, unless you explicitly play with offsets, each bone is always connected to its parent bone with a rotating joint (no physics required). The latter part of your post begins to describe what's known as inverse kinematics which would be a great feature for the editor, but the math is over my head.

[pancakepalace]

I can see that in Tboner each bone is connected to it's parent bone, but how do you achieve this in the editor without using Box2D? If you only have images for each part of the actor, then the person editing could place them however he wishes, not doing offsets by force, but because it's really hard to place them properly! Box2D would make this easy in the editor.

[Taehl]

This is achieved in the editor by letting the user change each bone's angle, instead of offsets. So if they click'n'drag a bone, it will only change the direction it goes in, instead of pulling it off of its parent bone. The offsets could only be changed explicitly (like clicking the offset property in the properties box and typing in something new, or maybe a special "change offset tool" which temporarily changes click'n'drag behavior).

A bone consists of more than just images. Specifically, a bone has all these:

Code: Select all

bone = {
	l = boneLength, a = boneAngle,
	x = boneGlobalOffsetX, y = boneGlobalOffsetY,
	i = image,
	sx = imageScaleX, sy = imageScaleY,
	ox = imageOffsetX, oy = imageOffsetY, oa = imageOffsetAngle,
	[1] = childBone1, [2] = childBone2, -- etc.
}

So unless the user changes the offsets explicitly, nothing will get placed improperly. Constraining things with Box2D isn't needed since everything is already constrained.

[Taehl]

Here's a mockup of what I envision the editor to look like.



I'm going to be gone for a few days, but please feel free discuss, critique, offer improvements, etc..

[tentus]

Here's a mockup of what I envision the editor to look like.



I'm going to be gone for a few days, but please feel free discuss, critique, offer improvements, etc..

Mockups? I love mockups! Drinks all around!

Simple mockup with animation timeline (ignore typos please)

boner_mockup.png (36.47 KiB) Viewed 4112 times

The advantage of having hollow circles on the ends is that it is both clickable and visually informative: you can see very easily how many things are branching out (if it starts getting hard to see, then you're probably doing it wrong).

[Taehl]

Here's a mockup for the animation part of the editor (again, open to suggestions):



I should be online again within a week (hopefully).