BVJ is extensions to the BVH animation format used by SL technology. It's in the ClientHamr section coz on the server side, they are just dealt with as blobs to be sent to the viewers. This may change if we implement animating link sets, and interaction with the sim physics.
This example BVH is 20 lines 505 characters, and defines a pointless animation on a trivial skeleton.
HIERARCHY
ROOT Hips
{
OFFSET 0.00 0.00 0.00
CHANNELS 6 Xposition Yposition Zposition Zrotation Xrotation Yrotation
JOINT RightUpLeg
{
OFFSET -3.91 0.00 0.00
CHANNELS 3 Zrotation Xrotation Yrotation
End Site
{
OFFSET 0.00 -3.46 0.00
}
}
}
MOTION
Frames: 2
Frame Time: 0.033333
8.03 35.01 88.36 -3.41 14.78 -164.35 13.09 40.30 -24.60
7.81 35.10 86.47 -3.78 12.94 -166.97 12.64 42.57 -22.34
First the syntax is changed to be JSON. The sample above is transformed to 19 lines 715 characters:
{
"HIERARCHY":{
"NAME":"Hips",
"OFFSET":[0.00,0.00,0.00],
"CHANNELS":["Xposition","Yposition","Zposition","Zrotation","Xrotation","Yrotation"],
"JOINTS":[
{
"NAME": "RightUpLeg",
"OFFSET": [-3.91, 0.00, 0.00],
"CHANNELS": ["Zrotation", "Xrotation", "Yrotation"],
"JOINTS": [
{
"END": true,
"OFFSET": [0.00, -3.46, 0.00]}]}]},
"MOTION":{
"Frame Time":0.033333,
"Frames":[
[8.03,35.01,88.36,-3.41,14.78,-164.35,13.09,40.30,-24.60],
[7.81,35.10,86.47,-3.78,12.94,-166.97,12.64,42.57,-22.34]]}}
or equivalently to 5 lines 469 characters:
{"HIERARCHY":{"NAME":"Hips","OFFSET":[0.00,0.00,0.00],"CHANNELS":["Xposition","Yposition","Zposition","Zrotation","Xrotation","Yrotation"],
"JOINTS":[{"NAME":"RightUpLeg","OFFSET":[-3.91,0.00,0.00],"CHANNELS":["Zrotation","Xrotation","Yrotation"],
"JOINTS":[{"END":true,"OFFSET":[0.00,-3.46,0.00]}]}]},
"MOTION":{"Frame Time":0.033333,"Frames":[[8.03,35.01,88.36,-3.41,14.78,-164.35,13.09,40.30,-24.60],
[7.81,35.10,86.47,-3.78,12.94,-166.97,12.64,42.57,-22.34]]}}
or equivalently 1 line of 461 characters, which I won't include in this document. I have worked though larger examples and this is a very typical compression ratio. A BVJ file (using sampling) is about the same size as a BVH file.
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 visualised.
The hierarchy portion of a BVJ is a fine place to express attachment points.
...
{
"NAME": "RightUpLeg",
"ATTACH": [12],
"OFFSET": [-3.91, 0.00, 0.00],
...
The semantics are that an attachment point can be created for each item in the hierarchy at the midpoint between its parent's position, and the end of it's offset.
When a client rezzes in, they could parse and read their current skeleton's BVJ, and use that to tell other clients what attachment point 103 means. No more prims stuck in your crotch floating in space as you walk away.
Q: How to define the zero rotation at the attachment point? Need to match what is done now.
If I want to attach two things to my pelvis, say a skirt and a tail, I should be allowed to. There are two ways the client could communicate this to a server, depending on the servers rules. A nice server says "Sure, attach your whole inventory to your head, what do I care?". A mean one says "That attachment point is in use." For mean servers the client can just make a new attachment point at the same place. It would update it's skeleton BVJ to include:
...
{
"NAME": "RightUpLeg",
"ATTACH": [12,99]
"OFFSET": [-3.91, 0.00, 0.00],
...
I would like to further enhance the client to add attachments *at* the joints themselves with the semantics that they average (in some sense of the word) the directions of the two segments from the joint to the beginning of the parent segment and from the joint to end of child segment. The motivation is to have kneecaps/kneepads that move reasonably without special attention from an animator.
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 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 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.
Keyframing is cool because it uses the computer to compute all the between states. We tell the computer at time T0 arm is at 13 degrees rotation, and at time T10 it is at 23 degrees rotation, and the computer figures out where the arm needs to be rotated at all points in time between T0 and T10. This can result in smaller animation files and lower CPU usage.
I propose adding keyframe syntax as an alternative to the existing "MOTION" section of BVH files.
{
"HIERARCHY":{...},
"KEYFRAMES":[
{
"AT":0.00,
"Hips":[8.03,35.01,88.36,-3.41,14.78,-164.35],
"RightUpLeg":[13.09,40.30,-24.60]},
{
"AT":0.033333,
"Hips":[7.81,35.10,86.47,-3.78,12.94,-166.97],
"RightUpLeg":[12.64,42.57,-22.34]}]}
The semantics are that the value of any channel is the linear interpolation of it between the two closest keyframes in time. Though maybe should support other interpolation schemes such as quadratic, and cubic. I think it's obvious that this will often result in much smaller animation files. My example above is fairly pointless since it is just changing every sample in the BVH into a keyframe. As a result it is bigger, but a possible benefit is that it slightly better supports playback at frame rates other than that specified in the BVH.
Another enhancement I want to add is to capture all the elements of an in-world animation in the format. In world animations have things like priority, looped or one shot, loop start/end points, ease-in and ease-out etc.. There is no place for them in a BVH, but not much creativity is needed to put them in a BVJ file. Then we can edit those parameters, set them in the file before import, and save them in a file on export.
I favor this placement
{
"priority":3.5,
"looped":false,
"HIERARCHY":{ ... } ...}
But can see arguments for this instead
{
"HIERARCHY":{ ... }
"MOTION": {
"priority":3.5,
"looped":false,
...} ...}
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 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.
There are use cases where it makes good sense to communicate an animation between clients with almost no server interaction. Why pay 10 Bogus-Bucks to adjust the position of my hand as we sit next to each other. I'll just edit my avatar to move my hand and the client will make a BVJ file ship it to your client which will show it to you.
Fang Said: See the very last paragraph of SledjHamr, the "random notes from my old Web 3.0 document " section at the bottom, to see one suggested method of moving your hand.
Alice Replied: Looks cool, but requires Inverse Kinematics (if you mean the touch commands), or some puppeteer protocol that I know nothing about.
What I imagine right now is InworldAnimationEditor
Some useful links for actually writing animation code -
Portal:Computer_graphics 3D_computer_graphics Skeletal_animation Morph_target_animation Inverse_kinematicsbvhacker.com bvh_file_specification