Animation Upload Priority

Template:Needs Translation/de Template:Needs Translation/es Template:Needs Translation/el Template:Needs Translation/fr Template:Needs Translation/he Template:Needs Translation/it Template:Needs Translation/ja Template:Needs Translation/ko Template:Needs Translation/nl Template:Needs Translation/hu Template:Needs Translation/no Template:Needs Translation/da Template:Needs Translation/sv Template:Needs Translation/tr Template:Needs Translation/pl Template:Needs Translation/pt Template:Needs Translation/ru Template:Needs Translation/th Template:Needs Translation/uk Template:Needs Translation/zh-Hans Template:Needs Translation/zh-Hant

Uploaded animations need to match, or more commonly, exceed, the priority of built-in animations to be visible when they are played. That determines the minimum priority you could use.

Determining the priority of the built-in animations is not as straightforward as it first appears. The priority displayed by Animation Info has no apparent relation to the priority of the joints.

Built-In Animations with Misleading Priorities

Type	Visible Priority	Actual Priority
turn left	1	3
turn right	1	3
prejump	0	3
jump	0	3
hover	0	3
slow fly	0	3
fly	0	3
upward fly	0	3
downward fly	0	3
land	0	3

It's possible to mix animations by playing different priority animations at the same time, or equal priority animations in the right order, and this is a very useful feature. For instance, you could play a priority 2 standing animation while playing a priority 4 gesture animation to wave your arm. Another example would be playing a priority 4 animation to sit on a couch, and then another priority 4 animation to move your arms to hold and eat from a bag of popcorn. Using the lowest priority that will work makes mixing easier, because so long as the animations have different priorities you don't have to care about the order in which they are played.

A priority less than 2 is generally not useful. At priority 0 many built-in animations will mix with your animation. It will be obviously unusable. At priority 1 the built-in head_rot animation will always mix with your animation. This moves the abdomen too much to be usable for many animations.

At priority 2 the abdomen will constantly be moved slightly in random directions by the built-in body_noise animation. If you want to avoid this, you will need to upload at priority 3 instead.

Most animations should define chest and abdomen movement. If chest motion is not defined breathing will be added for you by the breathe_rot built-in animation, which could be a problem if you wanted to control the breathing rate, or don't want breathing (e.g. for a robot avatar). If abdomen motion is not defined the abdomen will move due to the head_rot built-in animation.

Recommended Animation Upload Priorities

Type	Upload Priority
stand	2
turn left	4
turn right	4
walk	2
run	2
crouch	2
crouch walk	2
sit	Not Applicable[1]
ground sit	4
prejump	4
jump	4
hover	4
slow fly	4
fly	4
upward fly	4
downward fly	4
fall	4
land	4
stand up	4
typing	4
floating[2]	4
swimming forward[3]	4
swimming up[4]	4
swimming down[5]	4
furniture[6]	4
dance[6]	4
pose stand[6]	4
gesture[6]	4
drink/eat[6]	4

Overriding Animations

Consider leaving the head and neck joints undefined in standing and sitting (ground and furniture^[7] included) animations. This will allow the head to follow the camera and pointer.

It's okay to upload stand, walk, run, crouch, and crouch walk animations at priority 3, instead of the suggested priority 2. That will stop the built-in body_noise animation from messing up your work, at the cost of reducing your ability to mix.

Some animation overriders (like the free and open source ZHAO-II) will allow you to play multiple animations at once. This is useful for working around several problems.

If you decide to make a standing animation priority 3 consider defining the motion of the lShldr, lForeArm, and lHand joints in a separate priority 2 animation. This will allow the left arm to aim at what is being pointed to. You may want to do the same thing, for the same reason, when making priority 4 sitting (ground and furniture included) animations that you expect to be used where people build or teach.

You may not want to define hip motion for animations where your feet touch the ground and you are upright with your hips not moving (standing and turning animations). If you don't, the angle of the hip will be matched to the terrain. You may not want to define Foot movement for walking animations for the same reason.

Flying and swimming animations that do not define hip motion will roll to follow the angle of flight. This is usually desirable.

Typing animations should only effect the arms so they can be used with other animations (like furniture animations). This is also why I suggest uploading them at priority 4, even though priority 3 is sufficient to override the built-in animation.

Animated Attachments

Attachments for drinking and eating should only effect the head, neck, and arms so they can be used with other animations (like furniture animations).

You're best off using the Linden Lab provided animations (hold_r_bazooka/aim_r_bazooka, hold_l_bow/aim_l_bow/shoot_l_bow, hold_r_handgun/aim_r_handgun, hold_r_rifle/aim_r_rifle) for projectile weapons. They have their joints adjusted to increase realism when in mouselook mode.

See Also

• BVH Reference Frame
• Internal Animations

Footnotes

1. ^ Overriding the normal sit in an animation overrider is pointless since it will almost always be overridden by pose balls. Doing so often prevents pose balls from working. Overriding ground_sit in an animation overrider is useful.
2. ^ underwater "hover"
3. ^ underwater "fly"
4. ^ underwater "upward fly"
5. ^ underwater "downward fly"
6. ^ no built-in animation
7. ^ In Second Life, many furniture items — chairs, benches, beds, etc. — will include animations appropriate for the avatar interaction with the furniture; others might use pose balls instead.