The semantics are that the "Hips" and the "RightUpLeg" of something are animated. The mapping from the BVJ file's "NAME" fields to the avatar skeleton is straightforward, the names in the BVJ are matched against the names of the skeleton components. Then the appropriate rotations and translations are applied frame by frame.
The point of the hierarchy is so that when a joint moves or rotates, it's children get carried along for the ride. When you turn the hips left in the sample BVJ, the whole body turns left.
-Note that the "offset" value isn't actually used when animating avatars. The position of the hips and the angles are all used, but no attempt is made to match the skeleton bone lengths to the BVH segment lengths. So I propose that we can eliminate them or make them optional to reducing lag and file size. The offsets are useful in other tools because they define a skeleton that can be visualized.
+Note that the "offset" value isn't actually used when animating avatars. The position of the hips and the angles are all used, but no attempt is made to match the skeleton bone lengths to the BVH segment lengths. So I propose that we can eliminate them or make them optional to reducing lag and file size. The offsets are useful in other tools because they define a skeleton that can be visualised.
The hierarchy portion of a BVJ is a fine place to express attachment points.
@@ -101,13 +101,13 @@ implement animating link sets, and interaction with the sim physics.BVH was defined with skeletons in mind. But, at first glance it seems that if there were some two (or more) prim object with a root prim named "Hips" and another prim named "RightUpLeg" we should be able to animate that link set using this same BVH/BVJ file.
The one issue is that segments in the BVH model are like vectors, they have a near end, a far end, a length, and they rotate about their near end. In particular bones have no width or depth, only length.
-So I propose adding "PIVOT":[x,y,z] to define about what part of a prim the prim rotates when being animated. When omitted the center of the prim is used, and is equivalent to "PIVOT":[0,0,0]. The pivot ranges from -1 to 1 on each axis with -1 meaning the small end and 1 the large end. For example consider a cylinder, "PIVOT":[0,0,0.5] would rotate about the point midway between the center of the cylinder and the +Z face of the cylinder, i.e. half way up to the top. "PIVOT":[0,0,1] would make the cylinder act like a normal bone making up a skeleton.
+So I propose adding "PIVOT":[x,y,z] to define about what part of a prim the prim rotates when being animated. When omitted the centre of the prim is used, and is equivalent to "PIVOT":[0,0,0]. The pivot ranges from -1 to 1 on each axis with -1 meaning the small end and 1 the large end. For example consider a cylinder, "PIVOT":[0,0,0.5] would rotate about the point midway between the centre of the cylinder and the +Z face of the cylinder, i.e. half way up to the top. "PIVOT":[0,0,1] would make the cylinder act like a normal bone making up a skeleton.
Things are interesting when I want to define an animation of my avy and an attachment to my avy. Suppose when applying an animation from a BVH or BVJ that I get to a joint named "tail" with a defined attachment point 103. If my avatar is wearing something at point 103, then search that object for a prim named "tail". If I find a prim named "tail" in the attachment then this joint's animation applies to that prim. And all the children of the "tail" joint in the animation are sought in the link set of the attachment.
Why yes, that *does* mean attachments can have attachments, glad you asked. Suppose my tail has three bones, and the attachment point defined for the last bone is 104. I could attach the tail to point 103, and a pretty bow to point 104. The data model would be avy attachment point 103 has "thin neko tail with pink tip" attached, and avy attachment point 104 has "pretty bow" attached. But because point 104 is defined on a child joint of the joint with atachment point 103, the object "Pretty Bow" would move with a part of the tail, not with some random part of the avy.
+Why yes, that *does* mean attachments can have attachments, glad you asked. Suppose my tail has three bones, and the attachment point defined for the last bone is 104. I could attach the tail to point 103, and a pretty bow to point 104. The data model would be avy attachment point 103 has "thin neko tail with pink tip" attached, and avy attachment point 104 has "pretty bow" attached. But because point 104 is defined on a child joint of the joint with attachment point 103, the object "Pretty Bow" would move with a part of the tail, not with some random part of the avy.
The BVH file format was originally created for motion capture. So it defines animations by means of sampling. The same way a motion picture film samples the world 24 times a second making still photographs, the BVH captures the values on all the channels at regular points in time. But not all animations are created by motion capture, perhaps most are made with a keyframing animation system.
@@ -148,10 +148,10 @@ implement animating link sets, and interaction with the sim physics.
The last enhancement I want to make is to add absolute time references. Consider using the BVJ file to define the animations of the hands on a analog clock. I would like to be able to express "At noon, all hands are pointing up." What this means is when invoking an animation we need to map from the Unix time to the animation's time. This is a linear mapping so two numbers are required, one expresses how many animation seconds elapse for each Unix second, the second specifies at what Unix time at which the animation time 0 occurs. There is a third number implied by looping animations. How long the animation is. Note a looping animation often begins to loop at some point after animation time 0 and ends before the largest animation time in the file. This is due to the types of interpolation used when keyframing. Linear interpolation requires two keyframes before a position can be known, quadratic 3, and cubic 4.
+The last enhancement I want to make is to add absolute time references. Consider using the BVJ file to define the animations of the hands on a analogue clock. I would like to be able to express "At noon, all hands are pointing up." What this means is when invoking an animation we need to map from the Unix time to the animation's time. This is a linear mapping so two numbers are required, one expresses how many animation seconds elapse for each Unix second, the second specifies at what Unix time at which the animation time 0 occurs. There is a third number implied by looping animations. How long the animation is. Note a looping animation often begins to loop at some point after animation time 0 and ends before the largest animation time in the file. This is due to the types of interpolation used when keyframing. Linear interpolation requires two keyframes before a position can be known, quadratic 3, and cubic 4.
Currently there are none, but see InworldAnimationEditor for my ideas. It should be obvious how to transform a BVH into a BVJ file that uses sampling. By looking at the rates of change of channels it is possible to discover inflection points and use them to synthesize a keyframe representation that is a close match to a set of samples.
+Currently there are none, but see InworldAnimationEditor for my ideas. It should be obvious how to transform a BVH into a BVJ file that uses sampling. By looking at the rates of change of channels it is possible to discover inflection points and use them to synthesise a keyframe representation that is a close match to a set of samples.
And, of course, I want to make this file format editable in-world using nice GUI and 3D editing tools. Basically a clone of QAvimator in the client.
Step 1: right click avy > edit pose > a list of currently playing animations displays and you can choose one. Or right click avy > new pose
-Step 2a: big edit style arrows sprout from the current joint (last edited, or hips by default). You can interact with it in all the standard ways users already know about with the build window. Move? Drag an arrow. Rotate? Drag a ring or the gray ball.
+Step 2a: big edit style arrows sprout from the current joint (last edited, or hips by default). You can interact with it in all the standard ways users already know about with the build window. Move? Drag an arrow. Rotate? Drag a ring or the grey ball.
Step 2b: The edit window opens to the animation tab, or perhaps a whole new GUI. As a first approximation, imagine grabbing all the stuff from qavimator, squishing it into one or two 'floaters' windows inside the client.
To take advantage of the 'absolute time' feature, you need to edit multiple animations at one time to make them interact well. Each animation could sprout a new line in the time line window. Would need some indicator which is the current animation and way to switch so the numbers boxes and meta info displays make sense. Time between the many animations is synchronized, so stepping a frame forward, steps all animations forward.
+To take advantage of the 'absolute time' feature, you need to edit multiple animations at one time to make them interact well. Each animation could sprout a new line in the time line window. Would need some indicator which is the current animation and way to switch so the numbers boxes and meta info displays make sense. Time between the many animations is synchronised, so stepping a frame forward, steps all animations forward.
Most importantly, if you are granted permission, you should be able to right click on another avy, and choose edit pose.
Now, I described all this as if BVJ's only applied to avatars. They don't. But the commands and behaviors are the same when editing animations for a door, an avatar, or an attachment (to an attachment to...) to an avatar.
+Now, I described all this as if BVJ's only applied to avatars. They don't. But the commands and behaviours are the same when editing animations for a door, an avatar, or an attachment (to an attachment to...) to an avatar.
If you edit your pose, and the animations of 3 small balls, you could make a juggle animation with balls and hands synchronized. You can make "play catch" animations for two people and a ball. Be a multi-legged creature: add bones, attach prims, animate, enjoy.
+If you edit your pose, and the animations of 3 small balls, you could make a juggle animation with balls and hands synchronised. You can make "play catch" animations for two people and a ball. Be a multi-legged creature: add bones, attach prims, animate, enjoy.