Hi Jakob,
I fear the term 'animation' is a little bit confusing in this context, because there are a number of different use cases for "movement tree structures", and the game industry already uses them with a very specific meaning and calls it "animation".
I think here are a few separate problems here:
We can take a big pile of bricks and group them into rigid groups. We can also define how the rigid groups are constrained (e.g. this point rotates relative to this group).
There are two very different approaches to this.
- Physics engines define the linkage between rigid groups via _constraints_. The constraint indicates what relative motion of the rigid groups are legal and illegal. Imagine a crane with a pneumatic cylinder that "lifts" an arm by changing the length of one side of a triangle. The cylinder doesn't lend itself well to a parent-child relationship. Rather the cylinder has two constraints - each constraint ties one end of the cylinder to a fixed point on some part of the crane - the two ends of the cylinder are not connected to the same group.
- Animation engines typically just define the hierarchic relationship, e.g. the hand is a child of the arm, the arm is a child of the body, etc.
Physics engines need the more complex constraint network so that they can -determine- what motion is possible from first principles by applying forces.
Animation engines typically have all legal motion _pre-calculated_. In a game animation engine, if you want to animate the crane, one end of the cylinder is a child of the crane, and then an animator creates the data to manually "pose" the other end of the cylinder so that it looks like it is attached.
(In real life the guy doing your animator may have a very expensive 3-d program that will do the physics for him and save the results as an animation. The animator describes the cylinder as connected on both ends, and the animation program calculates the poses so that the model "stays together". The game engine then just repeats the animation that was saved.)
The problem we face as app developers is that users almost certainly want the first functionality, but the second functionality is much, much easier to implement.
A few comments on both problems...
PHYSICS
From what I have researched, if you want to be able to derive the possible motions of a model completely from modeling, you would need:
1. Connectivity data on parts. This has been done by several models already and I think a "snapping" system is adequate. Bounding boxes for collisions are also needed if you want to block illegal motion. Your app would have to use the connectivity to build:
- The rigid groups and
- The constraints that link them. (E.g. if two groups are linked by a 1x2 hinge, you can build a constraint to solve this).
2. A physics engine to help derive legal motion. The good news is that there are several open source options here. I looked briefly at bullet and ODE (open dynamics engine) - there are others too but I was lazy and only looked at the ones with the best web docs. :-) Anyawy, they all let you do more or less the same thing:
- model your rigid bodies.
- model constraints between them.
- apply forces.
- time step a simulation to "see" what happens.
If your goal is to simulate robots, this might be everything you want to do - e.g. the physics engine is going to drive your robot.
ANIMATION
If the goal is to make "playability" of models, it would be useful to be able to _save_ the derived motion that the physics engine "figured out". Here the game industry provides some standard solutions. This is a summary of the common features of model animation from a bunch of 3-d game engines.
1. The "rigid bodies" in the system are called bones - think of the bones in a skeleton.
2. Bones are organized in a tree structure so that bones moving relative to bones 'just works'.
3. The relationship between bones is described by a transformation matrix, so that combinations of rotation and translation are possible. The fine print of the 3-d engine describes what interpolation will be used (interpolating between matrices isn't necessarily as simple as interpolating each of 12 components).
4. Each vertex of the model is attached to one _or more_ bones. (This last feature is called "skinning" - by having a vertex that follows an average of multiple bones, soft mushy features like skin on people can be modeled cheaply. I think this feature is relatively unimportant for legos, particularly since we do not have -deformable- parts.*) In our case, we could live with each rigid group being attached to a bone.
5. A "pose" is a set of specific values for the transformation matrix that "moves" the model (or _part_ of the model) into a certain position. For a game, a monster model might have a "sitting" pose and a "standing" pose.
6. A time-based sequence of poses is an animation - thus the animator can model walking by specifying 5 or 6 poses and letting the engine fill in between them.
7. The engine typically has some logic for blending between poses, e.g. if the game engine wants to have the monster walk AND swing its sword, those can be two animations - the blending logic decides (for each bone-to-bone matrix) which animation sequence overrides. Blending of animations gets pretty specific to the particular engine.
Reading some of the proposals here, a lot of them look like the animation system we have in X-Plane. This is a little bit scary to me because I built that animation system 10 years ago, with no awareness of what the rest of the game industry was doing, and we've really its limits. At a minimum please consider:
- Separating the bone hierarchy from the model itself - "attach" the model to the skeleton, don't built the skeleton _out of_ the model.
- Keep the representation of animations relatively generic, e.g. key-framed transform matrices, rather than inventing an operation for every kind of motion we want.
These things would keep the _data representation_ very generic. Apps that play back animation can implement the spec once and apps that -create- the animation can do whatever they want and then save in this representation.
I hope that made some sense!
Jakub, for what it's worth, I'm starting to look at motion in Bricksmith and, like you, I'd like to see something that has wider scope than "app-specific".
Cheers
Ben
* E.g. there's no information in the sail parts describing how the interior of the part moves as the corners are pulled in different directions.
I fear the term 'animation' is a little bit confusing in this context, because there are a number of different use cases for "movement tree structures", and the game industry already uses them with a very specific meaning and calls it "animation".
I think here are a few separate problems here:
We can take a big pile of bricks and group them into rigid groups. We can also define how the rigid groups are constrained (e.g. this point rotates relative to this group).
There are two very different approaches to this.
- Physics engines define the linkage between rigid groups via _constraints_. The constraint indicates what relative motion of the rigid groups are legal and illegal. Imagine a crane with a pneumatic cylinder that "lifts" an arm by changing the length of one side of a triangle. The cylinder doesn't lend itself well to a parent-child relationship. Rather the cylinder has two constraints - each constraint ties one end of the cylinder to a fixed point on some part of the crane - the two ends of the cylinder are not connected to the same group.
- Animation engines typically just define the hierarchic relationship, e.g. the hand is a child of the arm, the arm is a child of the body, etc.
Physics engines need the more complex constraint network so that they can -determine- what motion is possible from first principles by applying forces.
Animation engines typically have all legal motion _pre-calculated_. In a game animation engine, if you want to animate the crane, one end of the cylinder is a child of the crane, and then an animator creates the data to manually "pose" the other end of the cylinder so that it looks like it is attached.
(In real life the guy doing your animator may have a very expensive 3-d program that will do the physics for him and save the results as an animation. The animator describes the cylinder as connected on both ends, and the animation program calculates the poses so that the model "stays together". The game engine then just repeats the animation that was saved.)
The problem we face as app developers is that users almost certainly want the first functionality, but the second functionality is much, much easier to implement.
A few comments on both problems...
PHYSICS
From what I have researched, if you want to be able to derive the possible motions of a model completely from modeling, you would need:
1. Connectivity data on parts. This has been done by several models already and I think a "snapping" system is adequate. Bounding boxes for collisions are also needed if you want to block illegal motion. Your app would have to use the connectivity to build:
- The rigid groups and
- The constraints that link them. (E.g. if two groups are linked by a 1x2 hinge, you can build a constraint to solve this).
2. A physics engine to help derive legal motion. The good news is that there are several open source options here. I looked briefly at bullet and ODE (open dynamics engine) - there are others too but I was lazy and only looked at the ones with the best web docs. :-) Anyawy, they all let you do more or less the same thing:
- model your rigid bodies.
- model constraints between them.
- apply forces.
- time step a simulation to "see" what happens.
If your goal is to simulate robots, this might be everything you want to do - e.g. the physics engine is going to drive your robot.
ANIMATION
If the goal is to make "playability" of models, it would be useful to be able to _save_ the derived motion that the physics engine "figured out". Here the game industry provides some standard solutions. This is a summary of the common features of model animation from a bunch of 3-d game engines.
1. The "rigid bodies" in the system are called bones - think of the bones in a skeleton.
2. Bones are organized in a tree structure so that bones moving relative to bones 'just works'.
3. The relationship between bones is described by a transformation matrix, so that combinations of rotation and translation are possible. The fine print of the 3-d engine describes what interpolation will be used (interpolating between matrices isn't necessarily as simple as interpolating each of 12 components).
4. Each vertex of the model is attached to one _or more_ bones. (This last feature is called "skinning" - by having a vertex that follows an average of multiple bones, soft mushy features like skin on people can be modeled cheaply. I think this feature is relatively unimportant for legos, particularly since we do not have -deformable- parts.*) In our case, we could live with each rigid group being attached to a bone.
5. A "pose" is a set of specific values for the transformation matrix that "moves" the model (or _part_ of the model) into a certain position. For a game, a monster model might have a "sitting" pose and a "standing" pose.
6. A time-based sequence of poses is an animation - thus the animator can model walking by specifying 5 or 6 poses and letting the engine fill in between them.
7. The engine typically has some logic for blending between poses, e.g. if the game engine wants to have the monster walk AND swing its sword, those can be two animations - the blending logic decides (for each bone-to-bone matrix) which animation sequence overrides. Blending of animations gets pretty specific to the particular engine.
Reading some of the proposals here, a lot of them look like the animation system we have in X-Plane. This is a little bit scary to me because I built that animation system 10 years ago, with no awareness of what the rest of the game industry was doing, and we've really its limits. At a minimum please consider:
- Separating the bone hierarchy from the model itself - "attach" the model to the skeleton, don't built the skeleton _out of_ the model.
- Keep the representation of animations relatively generic, e.g. key-framed transform matrices, rather than inventing an operation for every kind of motion we want.
These things would keep the _data representation_ very generic. Apps that play back animation can implement the spec once and apps that -create- the animation can do whatever they want and then save in this representation.
I hope that made some sense!
Jakub, for what it's worth, I'm starting to look at motion in Bricksmith and, like you, I'd like to see something that has wider scope than "app-specific".
Cheers
Ben
* E.g. there's no information in the sail parts describing how the interior of the part moves as the corners are pulled in different directions.