aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/docs/ClientHamr
diff options
context:
space:
mode:
authorDavid Walter Seikel2016-02-20 12:31:37 +1000
committerDavid Walter Seikel2016-02-20 12:31:37 +1000
commit080e27a38c508b2370cfe7f0152183f99a17131a (patch)
tree7a153d59ce96915416e4788b73554e1e7739230d /docs/ClientHamr
parentRun the docs through a spell checker. (diff)
downloadSledjHamr-080e27a38c508b2370cfe7f0152183f99a17131a.zip
SledjHamr-080e27a38c508b2370cfe7f0152183f99a17131a.tar.gz
SledjHamr-080e27a38c508b2370cfe7f0152183f99a17131a.tar.bz2
SledjHamr-080e27a38c508b2370cfe7f0152183f99a17131a.tar.xz
Rearrange the docs.
Diffstat (limited to 'docs/ClientHamr')
-rw-r--r--docs/ClientHamr/BVJ.html175
-rw-r--r--docs/ClientHamr/ClientHamr.html11
-rw-r--r--docs/ClientHamr/InworldAnimationEditor.html111
-rw-r--r--docs/ClientHamr/README.mumble5
4 files changed, 297 insertions, 5 deletions
diff --git a/docs/ClientHamr/BVJ.html b/docs/ClientHamr/BVJ.html
new file mode 100644
index 0000000..d01f234
--- /dev/null
+++ b/docs/ClientHamr/BVJ.html
@@ -0,0 +1,175 @@
1<html>
2<title>BVJ</title>
3<head>
4</head>
5<body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
6<p>BVJ is extensions to the BVH animation format used by SL technology.
7It's in the ClientHamr section coz on the server side, they are just
8dealt with as blobs to be sent to the viewers. This may change if we
9implement animating link sets, and interaction with the sim physics.</p>
10<h2> Syntax </h2>
11<p>This example BVH is 20 lines 505 characters, and defines a pointless animation on a trivial skeleton.</p>
12<pre> HIERARCHY
13 ROOT Hips
14 {
15 OFFSET 0.00 0.00 0.00
16 CHANNELS 6 Xposition Yposition Zposition Zrotation Xrotation Yrotation
17 JOINT RightUpLeg
18 {
19 OFFSET -3.91 0.00 0.00
20 CHANNELS 3 Zrotation Xrotation Yrotation
21 End Site
22 {
23 OFFSET 0.00 -3.46 0.00
24 }
25 }
26 }
27 MOTION
28 Frames: 2
29 Frame Time: 0.033333
30 8.03 35.01 88.36 -3.41 14.78 -164.35 13.09 40.30 -24.60
31 7.81 35.10 86.47 -3.78 12.94 -166.97 12.64 42.57 -22.34
32</pre>
33<p>&nbsp;</p>
34<h3> JSON </h3>
35<p>First the syntax is changed to be JSON. The sample above is transformed to 19 lines 715 characters:</p>
36<pre> {
37 "HIERARCHY":{
38 "NAME":"Hips",
39 "OFFSET":[0.00,0.00,0.00],
40 "CHANNELS":["Xposition","Yposition","Zposition","Zrotation","Xrotation","Yrotation"],
41 "JOINTS":[
42 {
43 "NAME": "RightUpLeg",
44 "OFFSET": [-3.91, 0.00, 0.00],
45 "CHANNELS": ["Zrotation", "Xrotation", "Yrotation"],
46 "JOINTS": [
47 {
48 "END": true,
49 "OFFSET": [0.00, -3.46, 0.00]}]}]},
50 "MOTION":{
51 "Frame Time":0.033333,
52 "Frames":[
53 [8.03,35.01,88.36,-3.41,14.78,-164.35,13.09,40.30,-24.60],
54 [7.81,35.10,86.47,-3.78,12.94,-166.97,12.64,42.57,-22.34]]}}
55
56</pre>
57<p>or equivalently to 5 lines 469 characters:</p>
58<pre> {"HIERARCHY":{"NAME":"Hips","OFFSET":[0.00,0.00,0.00],"CHANNELS":["Xposition","Yposition","Zposition","Zrotation","Xrotation","Yrotation"],
59 "JOINTS":[{"NAME":"RightUpLeg","OFFSET":[-3.91,0.00,0.00],"CHANNELS":["Zrotation","Xrotation","Yrotation"],
60 "JOINTS":[{"END":true,"OFFSET":[0.00,-3.46,0.00]}]}]},
61 "MOTION":{"Frame Time":0.033333,"Frames":[[8.03,35.01,88.36,-3.41,14.78,-164.35,13.09,40.30,-24.60],
62 [7.81,35.10,86.47,-3.78,12.94,-166.97,12.64,42.57,-22.34]]}}
63</pre>
64<p>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.</p>
65<p>&nbsp;</p>
66<h2> Semantics </h2>
67<p>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.</p>
68<p>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.</p>
69<p>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.</p>
70<p>&nbsp;</p>
71<h2> Attachment points </h2>
72<p>The hierarchy portion of a BVJ is a fine place to express attachment points.</p>
73<p>&nbsp;</p>
74<h3> Syntax </h3>
75<pre> ...
76 {
77 "NAME": "RightUpLeg",
78 "ATTACH": [12],
79 "OFFSET": [-3.91, 0.00, 0.00],
80 ...
81</pre>
82<p>&nbsp;</p>
83<h3> Semantics </h3>
84<p>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.</p>
85<p>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.</p>
86<p>Q: How to define the zero rotation at the attachment point? Need to match what is done now.</p>
87<p>&nbsp;</p>
88<h3> Multi-attach </h3>
89<p>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:</p>
90<pre> ...
91 {
92 "NAME": "RightUpLeg",
93 "ATTACH": [12,99]
94 "OFFSET": [-3.91, 0.00, 0.00],
95 ...
96</pre>
97<p>&nbsp;</p>
98<h3> Still More Attachments </h3>
99<p>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.</p>
100<p>&nbsp;</p>
101<h2> Animating Prims </h2>
102<p>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.</p>
103<p>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.</p>
104<p>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.</p>
105<p>&nbsp;</p>
106<h2> Animating Attached Prims </h2>
107<p>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.</p>
108<p>&nbsp;</p>
109<h3> Yet More Attachment Points </h3>
110<p>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.</p>
111<p>&nbsp;</p>
112<h2> Sampling and Keyframing </h2>
113<p>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.</p>
114<p>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.</p>
115<p>&nbsp;</p>
116<h3> Keyframe Syntax and Semantics </h3>
117<p>I propose adding keyframe syntax as an alternative to the existing "MOTION" section of BVH files.</p>
118<pre> {
119 "HIERARCHY":{...},
120 "KEYFRAMES":[
121 {
122 "AT":0.00,
123 "Hips":[8.03,35.01,88.36,-3.41,14.78,-164.35],
124 "RightUpLeg":[13.09,40.30,-24.60]},
125 {
126 "AT":0.033333,
127 "Hips":[7.81,35.10,86.47,-3.78,12.94,-166.97],
128 "RightUpLeg":[12.64,42.57,-22.34]}]}
129</pre>
130<p>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.</p>
131<p>&nbsp;</p>
132<h2> Animations, Not BVH Files </h2>
133<p>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.</p>
134<p>I favor this placement</p>
135<pre> {
136 "priority":3.5,
137 "looped":false,
138 "HIERARCHY":{ ... } ...}
139</pre>
140<p>But can see arguments for this instead</p>
141<pre> {
142 "HIERARCHY":{ ... }
143 "MOTION": {
144 "priority":3.5,
145 "looped":false,
146 ...} ...}
147</pre>
148<p>&nbsp;</p>
149<p>&nbsp;</p>
150<h2> At This Time </h2>
151<p>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 <strong>after</strong> animation time 0 and ends <strong>before</strong> 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.</p>
152<p>&nbsp;</p>
153<h2> Tools to Make BVJ Files </h2>
154<p>Currently there are none, but see <a href="InworldAnimationEditor.html">InworldAnimationEditor</a> 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.</p>
155<p>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.</p>
156<p>&nbsp;</p>
157<h2> Client to Client </h2>
158<p>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.</p>
159<p>&nbsp;</p>
160<h3> Changing Poses </h3>
161<p>Fang Said: See the very last paragraph of <a href="../SledjHamr.html">SledjHamr</a>, the "random notes from my old Web 3.0 document " section at the bottom, to see one suggested method of moving your hand.</p>
162<p>Alice Replied: Looks cool, but requires Inverse Kinematics (if you mean the touch commands), or some puppeteer protocol that I know nothing about.</p>
163<p>What I imagine right now is <a href="InworldAnimationEditor.html">InworldAnimationEditor</a></p>
164<h2>links</h2>
165<p>Some useful links for actually writing animation code -</p>
166<a href="https://en.wikipedia.org/wiki/Portal:Computer_graphics">Portal:Computer_graphics</a>
167<a href="https://en.wikipedia.org/wiki/3D_computer_graphics">3D_computer_graphics</a>
168<a href="https://en.wikipedia.org/wiki/Skeletal_animation">Skeletal_animation</a>
169<a href="https://en.wikipedia.org/wiki/Morph_target_animation">Morph_target_animation</a>
170<a href="https://en.wikipedia.org/wiki/Inverse_kinematics">Inverse_kinematics</a>
171<p>&nbsp;</p>
172<a href="http://bvhacker.com/">bvhacker.com</a>
173<a href="http://www.character-studio.net/bvh_file_specification.htm">bvh_file_specification</a>
174</body>
175</html>
diff --git a/docs/ClientHamr/ClientHamr.html b/docs/ClientHamr/ClientHamr.html
new file mode 100644
index 0000000..f77279c
--- /dev/null
+++ b/docs/ClientHamr/ClientHamr.html
@@ -0,0 +1,11 @@
1<html>
2<title>ClientHamr</title>
3<head>
4</head>
5<body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
6<p>Consider your inventory. A mess huh. Well, what is it really, especially in a world like <a href="../common/NGIW.html">NGIW</a> / <a href="../index.html">OMG</a> describes? It's just yet another hierarchy of folders and thingies. We are probably wasting our time writing any code for it. Why not leverage the users favourite hierarchy browser/editor. Maybe it's called FileDamager made by MicroCruft in Redstone Wishangton. Maybe it's called Netscape, or Nautilus. Many of the modern file browser tools will talk a protocol named WebDAV. If the asset server spoke WebDAV, then we could perhaps rip the inventory code clean out of the client.</p>
7<p>This little fantasy points in a really blue sky direction. Use existing protocols and tools to remove stuff from the client. Make it easy for tools that already exist to interact with the 3d world.</p>
8<p>That's the Client Hammer. ClientHamr is the concept that we can apply the unix philosophy to the viewer. Use individual tools that are good at their job to split off bits of the big bad blob that is the viewer. Using standard protocols and tools where we can.</p>
9<p>Note - The simian grid has a WebDav front end to inventory. <a href="http://code.google.com/p/openmetaverse/">http://code.google.com/p/openmetaverse/</a></p>
10</body>
11</html>
diff --git a/docs/ClientHamr/InworldAnimationEditor.html b/docs/ClientHamr/InworldAnimationEditor.html
new file mode 100644
index 0000000..82da594
--- /dev/null
+++ b/docs/ClientHamr/InworldAnimationEditor.html
@@ -0,0 +1,111 @@
1<html>
2<title>InworldAnimationEditor</title>
3<head>
4</head>
5<body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
6IAE is an idea to put an animation editor in world, much like the link set editor.
7<h2> Normal Editing </h2>
8<p>Step 1: right click avy &gt; edit pose &gt; a list of currently playing animations displays and you can choose one. Or right click avy &gt; new pose</p>
9<p>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.</p>
10<p>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.</p>
11<ul>
12<li>It has a help button</li>
13</ul>
14<ul>
15<li>It has a first use dialogue</li>
16</ul>
17<ul>
18<li>It includes a numbers area
19<ul>
20<li>channel values for the current joint</li>
21<li>you can type in numbers</li>
22<li>you can hit a spinner to increase/decrease</li>
23</ul>
24</li>
25</ul>
26<ul>
27<li>It has meta info edit boxes
28<ul>
29<li>animation name</li>
30<li>UUID (if it lives on a server)</li>
31<li>File path (if it lives on your hard drive)</li>
32<li>save to inventory/disk button(s)</li>
33<li>priority</li>
34<li>loop points as numbers</li>
35</ul>
36</li>
37</ul>
38<ul>
39<li>It has a time graph
40<ul>
41<li>showing which frames have animation information</li>
42<li>what the 'current time' of the animation is</li>
43<li>play button</li>
44<li>pause button</li>
45<li>step forward button</li>
46<li>step backward button</li>
47<li>set the current time</li>
48<li>loop points as marks on the time line</li>
49<li>click a frame mark, highlights joints with animation information</li>
50<li>can delete the keyframe</li>
51<li>can add/update a keyframe</li>
52<li>indication of unsaved changes near/on
53<ul>
54<li>the step/play/pause buttons and the close button</li>
55</ul>
56</li>
57</ul>
58</li>
59</ul>
60<ul>
61<li>It has a skeleton editor
62<ul>
63<li>acts a lot like a hierarchy browser</li>
64<li>can move rename add and delete joints</li>
65<li>/me hand waves about selecting new things for new joints</li>
66<li>includes place to change meta data about a joint
67<ul>
68<li>name</li>
69<li>channels</li>
70</ul>
71</li>
72</ul>
73</li>
74</ul>
75<ul>
76<li>It has a bunch of new keyboard short cuts when the GUI is focused
77<ul>
78<li>u/o rotate about X</li>
79<li>i/k rotate about Y</li>
80<li>j/l rotate about Z</li>
81<li>y move up the joint hierarchy</li>
82<li>h move to a sibling/cousin at the same level. I.e. flip from right foot to left foot.</li>
83<li>n move down the joint hierarchy</li>
84<li>p play/pause</li>
85<li>&lt;space&gt; step forward</li>
86</ul>
87</li>
88</ul>
89<p>&nbsp;</p>
90<h2> Inverse Kinematics </h2>
91<p>The GUI I imagine for IK, perhaps a tab on the animation editor?</p>
92<ul>
93<li>something to lock/unlock joints</li>
94<li>a standard edit control on the selected joint
95<ul>
96<li>dragging the joint makes IK do it's magic to compute angles</li>
97</ul>
98</li>
99</ul>
100<p>&nbsp;</p>
101<h2> Edit Multiple Animations </h2>
102<p>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.</p>
103<p>Most importantly, if you are granted permission, you should be able to right click on another avy, and choose edit pose.</p>
104<p>&nbsp;</p>
105<h2> Animate other stuff </h2>
106<p>Now, I described all this as if <a href="BVJ.html">BVJ</a>'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.</p>
107<p>&nbsp;</p>
108<h2> Possibilities </h2>
109<p>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.</p>
110</body>
111</html>
diff --git a/docs/ClientHamr/README.mumble b/docs/ClientHamr/README.mumble
deleted file mode 100644
index 1010f18..0000000
--- a/docs/ClientHamr/README.mumble
+++ /dev/null
@@ -1,5 +0,0 @@
1Viewer integration with mumble and whisper, and using it for as many
2audio services as it can.
3
4Mumble is a voice system designed for networked 3D game usage. Sounds
5perfect, just what we need. B-)
generated by cgit v1.1 at 2024-07-06 14:32:08 +0000