Skeletal animation can be implemented in various ways that would affect its usability.
The most basic implementation has to support:
posing
linking an object with a bone
More complex case of bezier path multi-bone assignment mostly requires a way to store mapping information. Otherwise, it's pretty much the same.
Additionally, a special kind of 3d skeletal animation can be implemented in the future, which would in fact combine 2d transformations with morphing.
Skeletal animation can be implemented in various ways that would affect its usability.
The most basic implementation has to support:
- posing
- linking an object with a bone
More complex case of bezier path multi-bone assignment mostly requires a way to store mapping information. Otherwise, it's pretty much the same.
Additionally, a special kind of 3d skeletal animation can be implemented in the future, which would in fact combine 2d transformations with morphing.
So, for the simple case the most challenging part is posing (linking is done via Transform node (see #18) with some kind of SkeletalTransform as transform argument).
Lets look then at degenerate case when skeleton is just a single bone.
In this case, skeletal transformation is simply "bone difference". Depending on desired behaviour, "pose" info can be either stored as transformation or as a bone. In either case, SkeletalTransform is synonymous with the pose.
So, for the simple case the most challenging part is posing (linking is done via Transform node (see #18) with some kind of SkeletalTransform as transform argument).
Lets look then at degenerate case when skeleton is just a single bone.
In this case, skeletal transformation is simply "bone difference". Depending on desired behaviour, "pose" info can be either stored as transformation or as a bone. In either case, SkeletalTransform is synonymous with the pose.
The problem with this approach is that pose definition in it is very vague. However, that may be not a problem if we add poses/actions on another level.
As for more real / complex case. Suppose this bone structure:
```
+ parent_bone
|- child_a_bone
|- child_b_bone
```
There is a tempting simple solution to store that structure inversely since we can link to one node many times. However, then what about posing?
Well, actually if we define BonePose as a node that takes two transforms and a bone, it can work.
```
+ object_a_transform
|- child_a_pose_x
|- parent: parent_pose_x
| |- parent: none
| |- bone: parent_bone
| |- transform: ..
|- bone: child_a_bone
|- transform: ..
+ object_b_transform
|- child_b_pos_x
|- parent: parent_pose_x
|- bone: child_b_bone
|- transform: ..
```
The problem with this approach is that pose definition in it is very vague. However, that may be not a problem if we add poses/actions on another level.
And another problem of course is that inserting new bones in-between existing will silently (unless additional check is implemented) break existing poses.
And another problem of course is that inserting new bones in-between existing will *silently* (unless additional check is implemented) break existing poses.
More important problem is skeleton reusing. Just importing objects with skeleton will have its pose nodes far away and not easily editable.
One solution is to use "substitution magic", i.e. context-based nodes set by wrapper ApplySkeleton node..
More important problem is skeleton reusing. Just importing objects with skeleton will have its pose nodes far away and not easily editable.
One solution is to use "substitution magic", i.e. context-based nodes set by wrapper ApplySkeleton node..
Skeletal animation can be implemented in various ways that would affect its usability.
The most basic implementation has to support:
More complex case of bezier path multi-bone assignment mostly requires a way to store mapping information. Otherwise, it's pretty much the same.
Additionally, a special kind of 3d skeletal animation can be implemented in the future, which would in fact combine 2d transformations with morphing.
So, for the simple case the most challenging part is posing (linking is done via Transform node (see #18) with some kind of SkeletalTransform as transform argument).
Lets look then at degenerate case when skeleton is just a single bone.
In this case, skeletal transformation is simply "bone difference". Depending on desired behaviour, "pose" info can be either stored as transformation or as a bone. In either case, SkeletalTransform is synonymous with the pose.
As for more real / complex case. Suppose this bone structure:
There is a tempting simple solution to store that structure inversely since we can link to one node many times. However, then what about posing?
Well, actually if we define BonePose as a node that takes two transforms and a bone, it can work.
The problem with this approach is that pose definition in it is very vague. However, that may be not a problem if we add poses/actions on another level.
And another problem of course is that inserting new bones in-between existing will silently (unless additional check is implemented) break existing poses.
Single bone transformation works.
More important problem is skeleton reusing. Just importing objects with skeleton will have its pose nodes far away and not easily editable.
One solution is to use "substitution magic", i.e. context-based nodes set by wrapper ApplySkeleton node..