The basic knowledge to create animations.

Since the advent of a couple of new creating animation tools, the old issues that was discussed for Poser have been revived.
I just put the basic knowledge that the predecessors found in data here.

1. The BVH file
The BVH is the text data that is described each figure parts rotation and position along time.

2. Hip is the top
Hip is the top of the hierarchy construction of figure in BVH. So if you want to move the whole body, you have to move the hip.

3. The first frame
You can create a stationary posture just by one frame animation. But note that you cannot move the whole body and cannot give the multiple priorities. (*rf. 7. Priority) This is convenient when you want absolutely stiffened posture.
But generally, it is known that the first frame of the animation that you created on the tool is used as a reference information of the root part, that is, the hip between BVH and SL. And the first frame's posture itself doesn't appear in world at all.
So you can also create the stationary posture by two frames, and this would rather make sense. It might be recommended that set at zero on every parts' roatiton and position at the first frame because it is ease to make sure that which parts you moved and give priority. This is called the standard or default T-Pose. But this is trifles. The point that you should know that the second frame is the exact frame to start animation.

4. Spline interpolation
If the tool has the spline interpolation feature, you might be annoyed until you knew how to control it. Use the cutting spline option which must be implemented, such as "Break spline".

5. Inverse Kinematics
If the tool has the inverse kinematics feature and it turns on, you might be annoyed until you knew how to turn off. Find and learn how to turn on/off.

6. Speed of the animation
The default speed of animation is 30 FPS, that is it takes 1 second to play 30 frames. If you want 10-second aniamtion, you need to create 300 frames. But you may also be able to change FPS value on each tool if it has the feature. And note that SL allows to upload your animation upto 30 seconds.

7. Priority
7-1: The default built-in animations are always affected your avatar in world. And they have their each priorities on each keyframed parts. Unless you give the higher priority to your animations, your animations will be overriden by them in world. The priority range is from 0 to 4. 4 is the highest priority.
7-2: The prioirty is only given to the whole parts of your avatar at once on the uploading window, but unless you change the part's value a bit even at 1 degree at the latter second frame from the first frame's one, the part wouldn't get the priority because the part doesn't set keyframe. If you know this rule, it is rather usuful because you can give two types of priority on an animated figure such as the highest and the lowest by parts.
7-3: The latter playing animation is given priority over the former one when the both priorities are the exact same.

8. Optimization
SL's BVH importer does optimization of animation data prior to upload into SL. Joint rotations with very slight changes from keyframe to keyframe will be interpreted as *not* changing and thus aren't stored. This is done intentionally since custom animation data is stored on our servers and downloaded to each viewer as it is needed in real time, and needs to be fairly terse.
The potential side effect of the optomization is what you have observed; joints with very subtle movement might have their animation data dropped entirely on upload. The threshold formula is complex(at least to my non-programmer eyes) and involves comparing all three axes of data per joint, the distance moved between keyframes, as well as the joint's position in the skeletal hierachy. The design is *supposed* to allow for subtle motion to come through intact, so there may be a couple bugs.---by Xenon Linden

9. Scale of the avatars' parts
There is the difference between the scale of the figure's parts on the tool and your avatars in world. Even though you adjust the position of parts on the tool, it will show you incorrect in world. You may see the avatar sitting while hovering or sinking under ground. The hip moves by the absolute value. Meanwhile, your avatar's height depends on how you created. The length of legs is up to avatars. You cannot help but keep in mind how they are suitable for the position and go back to the tool. Then you have to tweak them again while ignoring the shape of figure on the tool.

10. Facial and Hands morph
Unfortunately, you cannot customize these animations. You can just select the built-in ones and add them to your animation on the uploading window. You can also evoke the built-in facial aniamtions by script. But speaking of hands morph, it is glitchy. It won't continue and sometimes may not appear at all. Don't expect the fingers' moving so much.

Good summary. Should be stickied.

Seagel, thanks for posting this. This should help solve a lot of issues that beginning animators have with SL no matter which tool they use.

I just wanted to add one more thing. If your animation has more than one frame, then the first frame is used as a reference (just as Seagel described). However, if your BVH file has only ONE frame in it, SL will actually import it correctly as a pose. In this case, its okay to edit frame 1 in your editor. Just make sure you save it as an animation that only has one frame in it.

　I didn't know that. I'll give it a try to make sure it. Thank you, Vince.

As much as i test it, if i have the first frame "Neutral" and start the animation "in real" with the second fram, booth keyframes, i get an avatar wich does in RL terms lethal movement, even after upload.
What i do is copy the first fram into the second fram, make booth keyframes and move each joint one degree in one axis if i want them animatet and priority on them.
As faar i am concerned the "first keyframe gets cut" is hearsay, what i have seen in uploading easily over 2000 animations now (counting the 80% wich goes straight back to the dustbin) the first keyframes remains.

I am using Poser 5

Maybe make an checkbox list at animations upload wich joints should be priorized, if you feel live gving folks writing animations a goodie make them boxes where you enter 0-4 priority for each joint, that would be SO cool, and drop the "we are using first keyframe as reference"

Using the 1st frame as reference and cutting it then is for my opinion anyways an hack and not clean programming, it makes it extremly hard to get smooth looping animations by using 1st and last frame in a sequence to loop, if you try to make a someway decent walking animation like for an battle mech suit for example you will see the problem, plus you cant simply go 1:1 from poser to SL, you have to use workarround for an problem wich could be easily solved with an better upload UI (check/numerical boxes for each joint) than using an hack and workarround.

I tried to create 1-frame animations. I knew much about it and got confused.
Although I thought that the first frame was the references of all parts, it was just the reference of the root part, that is, the hip positon and rotation. So I couldn't make its hip rotate.
And you'll get the posture of other parts on the first frame when you create only one frame as Vince said. And the whole parts got the priority.

Then, I wonder where the parts' postures on the first frame are gone when I create multiple frames animation.

hmm... Is it something to do with Ease In value? I noticed that the multiple frames aniamtion's default Ease In value was 0.3, but the 1 frame animation's one turned to be 0.02. So if you changed the value 0.02 when you created even multiple frames, you might see the first frame. Ooops time out. I have to sleep.

Position and rotation are keyframed seperately. Keyframing position is rother staight forward. Keyframing rotation requires calculating the angle between rotations, a little quaternion math. First the rotations are converted from Eulers to Quaternions, a proceedure that results in inaccuracies being introduced. Then the changes between quaternions are compaired (rot_1/rot_2) / (rot_2/rot_3) ~~ ZERO_ROTATION. If they are within tollerances of each other the middle one is removed (rot_2 is removed). I will speculate that LL stores the data as floats (or signed shorts) after the Euler conversion. I'm pretty sure that Poser also uses Quaternions, and i know for a fact thier Quaternion -> Euler equations are... lacking. So by the time the compiler does it's comparisons, you've accumulated quite a bit of error. This error has to be accounted for in the tollerance of the comparison, and is what eats fine movements.

It's very hard to get it to loop exactly on the second frame unless you patch upload window. Then you can enter in decimal values.
See this thread.

As it is it drops to the user (the one uploading the animations) what could be solved rather easily inside the upload ui (setting of joints priority)

when i make a loping animation i copy the first keyframe (frame one) to the last fram wich is a keyframe too.

This means follwoing frames owuld be keyframes in a loop wich make next to no skipping in the animation.

Now SL uses the first frame as referenxe and drops all joints to lowest priortiy wich dont move at least one degree at one axis, AND doesent really cut the first frame.

I testet this by having the first and the second frame of a 30 frame animatin keyframes, the animation faar of the Micheangelo pose wich is recomended for keyframe.

The result is not good.

So i copy the first frame to the second frame, make booth keyframes (first is by default anyways a keyframe) and move ieach joint numerical one degree in one axis (each joint i want to have animatet)

that means i sit prior upload easily 20 minutes doing something one skilled programmer would write down in a upload ui with checkboxes for each joint, but i do this for EVERY animation i uppload.

Maybe i miss her something very basical, but so far i dont see that SL "cuts out the first frame and uses it as reference"

not having 2 keyframes in the first two frames means as long the animatiuon is not very radical that joints stay not animatet, having the first frame "neutral" means VERY odd movements, only work arround is moving each joint in one axis one degree, yuck

other thing is the "floating limbs", the optimising of SL seems to drop fine movements wich keep for example a foot on the ground immobile in regard to the hipps and ground, very annoying because you have to upload and use the animation to figure it out, go back to poser add a few degree (wich means it will look odd in poser), upload, test, rinse and repeat, one animation wich works perfect and smooth gets uploaded into SL working someway good and the costs are about 100L per animatiuon.

Absolutly not funy.

Strife, although I'll think what you mentioned later, speaking of looping, it is the story on the Poser.

Pounce, I'm afraid I don't understand you. I guess you're saying the first frame's posture remains on most of your animations. I remember one person suspected it here. But even she told it looked fine individually and it happend just when she used AO. So I've never heard such complaining. And when you have to test your animation so much, I recommend you do it on the preview grid when it opens as much as possible.

Strife, while it is true that Quat<-->Euler conversion introduce errors, I doubt it is significant enough to cause the frame droppage problems we are seeing in SL. Sometimes, even when there is motion up to 5 or 6 degrees, the frame still gets dropped. Having written my own Quat<-->Euler conversion function, I can tell you that the errors I see are below 1 degree (even when using floats instead of doubles) as long as you stay away from regions of gimbal lock. This isn't a problem since the axis rotation order in the poser2 BVH files are chosen to avoid gimbal lock for normal human motion (in most cases).

I'm not willing to write it off as floating point error intrinsic to Quat<-->Euler conversions since the errors are WAY too large. I believe it is some other bug or flaw in the optimization algorithm that can be overcome with proper analysis. I wish I had the source to look at...

This is before your time but there was a time in SL's history where LL screwed up the Euler<-->Quat functions to such a degree they were unusable..

Just report that I was wrong. I could never see the first frame at all. It is definitely lost in world.
Now I can only say that it is as such...

And I add and correct the top of this thread.

Ahh.. I didn't realize that. I guess that would explain a lot then...