Some of the default animations and their base priorities
The ideal is something like this:
- p0, p1 – ‘body noise’ (small twitches and movements to add some realism) and background animations.
- p2 – AO and long running animations. Apart from a few special cases, what you want to override in an AO is just the background.
- p3 – Any temporary animation that should make the character do something – gestures, poseballs etc. Again all you really want to do is play the animation over the characters defaults.
- p4, p5* – Things that should override everything else including situational animations such as poseballs. Ideally this would only affect a few bones and only for a short time.
- p6* – This should be reserved for only the most mission-critical animations, such as locks that hold certain bones in place to prevent a character from deforming. (ie: Folded Tinies and High Heels.)
(* These priorities are only available if you are using the native .anim format. They are not available for .bvh files.)
Always think about what a character will be doing when running your animation (both your intentions and how your animation could get used out of context). Construct likely scenarios, then choose the lowest priority you can get away with so your animation will play nicely with others.
Unfortunately, animators tend to not follow this rule, and even the internal animations break it.
For example, “walk” and “turnleft” are listed as priority 0 and 1, but some of the bones in the animation are actually priority 3. This means that AO animations must be priority 3 or even 4.
Take a look at Animation Upload Priority for more details. To complicate matters further, animations can have priorities on individual bones that are higher than the base priority that is reported, and the animation priority is immutable – once uploaded it can’t be changed.
There is one partial help for this: using the llSetAnimationOverride command, you could load the viewer AO with a set of p0 animations, and run an AO script without interference from the default animations. Or, if you are doing a simple one-for-one animation substitution, you could just set your animations as the new defaults. (Note: this command does not support multiple stands.)
However, the SL client also runs a bunch of internal default animations (“viewer generated motion”), and the priorities of these can also be as high as p3 (see Internal Animations). There is no option to turn these off. (See the image on the right; note that the reported priority is the base priority only).
And so we are stuck using p3 and p4 animations for AOs. Then some of the default sitting animations are priority 4, which leads to conflicts with furniture that has poses.
Therefore, animation creators are constantly having to make their animation priorities higher and higher. Customer A complains that their AO sit is overridden by their furniture. Customer B complains that their furniture animation is overridden by their AO sit.
Many scripted AOs have an on/off switch, and many objects in Second Life can not function properly unless the user’s AO is turned off. (Vehicles, rideable horses, certain games, carnival rides, etc.)
Setting Priorities in Avastar
Priorities in SL can go higher than p4, but creators cannot access p5 and p6 with the default SL BVH uploader.
Use the .anim format for export, and set the base priority in the export options.
NOTE: When you upload an .anim file in SL, there will be no preview window. Use the Beta Grid for testing.
Bento Animation Priorities
Since the default animations were created before the Bento skeleton existed, there are NO background animations for wings, tails, hind legs, fingers, or faces. This should leave us with the ability to use p0 or p1 for default positions and background animations, with p1 for action and incidental animations, while leaving p2 and up for third-party animation add-ons.
The problem here is, people have created non-human AOs and incorporated the wings and tails, etc into their p3 and p4 stands and sits.
The solution for this lies in Avastar’s ability to set per-bone animation priorities.
Setting Per-Bone Priorities
Each Avastar animation bone* has a Custom Property called ‘priority’ that is set to -2 by default.
A value of -2 is interpreted by the exporter as ‘take the base priority’. Any value (0-6) will override the base priority for that bone. This only works for .anim export.
NOTE: The COG will always use the priority set in the export settings.
TIP: If you want to change multiple bones to a certain priority: select all the bones you want affected. Make sure one is ‘active’ and change its Priority, then right click the Priority setting and select “Copy to Selected.”
WARNING: There is no note or visual indication that a rig has multiple bone priorities set, and the bone priorities will apply to every animation exported for that rig. If you have changed individual bone priorities and forget, you may get unexpected results from your animations.
TIP: You can keyframe the bone Priority, and have a default action saved that has them all set back to -2.
* The deformation rig also has the Custom Property Priority. If you set these bones to 0 or a positive value, they will override the Priority setting on the animation bones. It is more practical to set Custom Priorities on animation bones, but if you need to remove the animation rig for some reason you will still have access to bone priority settings.
Previous Version of document (for reference)
Avastar Animation Priorities
Which animation will play out of several is determined by two rules:
- The animation with the highest priority wins
- and amongst the ones of equal priority which one was started last wins.
But which animation priority to choose?
The Situation
Which animation will play out of several is determined by two rules – the animation with the highest priority wins, and amongst the ones of equal priority which one was started last wins.
But which animation priority to choose? It seems the ideal is something like this:
- p0,p1 – ‘body noise’ (small twitches and movements to add some realism) and background animations.
- p2 – AO and long running animations. Apart from a few special cases, what you want to override in an AO is just the background.
- p3 – Any temporary animation that should make the character do something – gestures, poseballs etc. Again all you really want to do is play the animation over the characters defaults.
- p4 – Things that should override everything else including situational animations such as poseballs. Ideally this would only affect a few bones and only for a short time.
Some of the default animations and their base priorities
For example: an animation of drinking from a cup of coffee. You could imagine someone drinking a coffee while sitting at a table, or a similar animation while standing around, or even drinking and walking. Really, all you need to animate is the arms and head and you want to do this regardless what else the character is doing. Think about it – if you have a hot cup of coffee in your hand I bet that will be foremost in your mind! So it makes sense to set those few bones to p4. If the sitting animation is at p3 from a poseball it would override the AO as expected, and the coffee animation would override the arms and head and everything would mesh nicely. It would also work with standing and walking and everyone is happy.
So much for good intentions. There are two problems that have left animation priorities in a complete mess. One is that there has been very little guide as to what priority to choose and there is a tendency to think higher is better.
The other problem is that SL runs a bunch of internal default animations (“viewer generated motion”) and the priorities of these can be as high as p3 (see here), and you have no option but to run these (see the image on the right, note that the reported priority is the base priority only). There is also a whole lot of built in animations that can be triggered via scripts too and these have various priorities. Take a look here for more details. To complicate matters further, animations can have priorities on individual bones that are higher than the base priority that is reported and the animation priority is immutable – once uploaded it can’t be changed.
Through ignorance or in attempts to override the base and other animations, many animations are now set way too high. The situation today is that even large reputable animators sell AO standing animation at p4. In the coffee example this would be an idiot that is so obsessed with how they are standing that they would prefer to scald themselves than break ‘the look’ :). The result is that to interact with the rest of SL you have to constantly switch off your AO, to the point that the AO on/off switch is usually the most prominent UI element in any AO.
It gets worse. The other rule is that the last run animation will beat other animations of the same priority. So what are you to do if everything is already at p4? Simple! Create a script that continually refreshes your animation. So what do you do if you want to override that? Again easy – create a script that refreshes your animation faster than the other one. So now you can have a situation where your character gets jerked around crazily while animations battle for supremacy, and the most lag-inducing scripts get rewarded.
What can you do? Create animations at a sensible level! Use the guide above and think carefully about what you are doing – play a few scenarios through you mind and see how various animations would mesh together. Sometimes there are tricks you can play like killing a default animation via a script in a pose ball. Consider creating sets of animations at different priorities for your customers, this way the choice is up to your customers. Put the priority as part of the name so people are more aware of the priority and how different animations will play together. If you are designing an AO, why not build in a ‘mutable’ priority by using multiple animation at different priorities and a UI element that can switch between them? Finally you can requesting that LL make animation priority changeable, or to lower the priority of the default animations. There’s no reason a non-user controlled animation has to run at priority lager than 1 (this gives two layers to the defaults, ta take care of unusual cases). Or at the very least to improve the default animations which are awful.
Priorities in Avastar
Priorities in SL can go higher than p4. This limitation is imposed by the default BVH import routine not by what SL can support. So what does Avastar bring to the table? If you are exporting via BVH then it’s the usual story – you get base priorities 0-4 and no bone priorities. However, if you are exporting animations via the anim format then we support SL’s animation format to a much greater degree. You can use per-bone priorities, and the priorities can be from p0 to p6.
Per-bone priorities
Each SL and rig bone has an attribute called ‘priority’ that is set to -1 by default. The exported bone priority will be the SL bone’s priority if that is higher than -1 otherwise it will be the rig bones priority. This means you can ignore the SL bones and just set the bone priority on the rig bones, but if you need to remove the rig for some reason you will still have access to bone priorities.
A value of -1 is interpreted by the viewers as ‘take the base priority’. Any other value (including 0) will override the base priority for that bone.
Priorities higher than 4
Thinking of uploading a priority higher than p4? Think carefully about this and if you can get away with a lower priority. You are more likely to annoy your customers that help them with a high priority animation. In general, p5 animations should only be temporary and for a few specific bones, and p6 should be considered only for very extreme situations. Read the rant above again, on the mess we’ve gotten into. Now read it once more. Still happy? Go for it.
Note that the avatar posture when editing your shape is a p5 animation. If you are running a p6 you will not see a change of posture.