From a couple of sources we have bits and pieces that suggest the Lab is looking to provide a built in viewer feature for handling avatar animation. Currently we use animation overriders (AO) to override the built-in avatar animations. Most of those are a HUD of some type.

Discussion is in progress to determine what AO feature set is needed for the Lab’s viewer. Since AO’s are basically free (only the animations cost) the user’s choice of which one to use is entirely based on features and personal preferences. Free market principals allow the best to become the most popular.

Concern is voiced by some that a built-in replacement for AO’s by the Lab may limit our freedom of choice. However such limiting would break a considerable amount of existing content. Breaking all the existing AO’s, or any content, is something the Lab is loath to do. So, I can’t image the Lab will take that path. Whatever they do, will allow users to still use their AO’s.

The Need for AO’s

When I first came to Second Life® the first things I noticed were that I looked lousy and I walked funny. Others didn’t. My first two missions were picking a skin and finding an AO with good animations.

We still have same problems with walking animations, but with the new avatars the skins are less of a problem.

AO’s Problems

An AO in a HUD is a script running to handle animating the avatar. It takes memory and resources in the viewer and to some lesser extent in the server.  There are well written scripts and poorly written scripts. One AO used 4.5 mb of memory. I think it has since been rewritten to use less. Most use very little memory and place only a minor load on the viewer and servers.

My ZHAO II uses 2 scripts and 32k of memory. The scripts create 3 to 7 events per second and uses up 0.005 to 0.035ms per frame. This is not a lot of resources. So, from a lag perspective: there is little if any reason to improve on the system. From a new user learning curve perspective: there is significant motivation to change.

You can see the affect of an AO in a place like Furball. With no scripted attachments and no one else in the area, Furball has 0 events per second (eps). Script time is 0.003ms. Add your AO to see its resource use. (Use Viewer Statistics  Ctrl-Shift-1)

If you use Firestorm remember to take off The Bridge. It creates 0 to 40 eps and uses 0.009 to 0.040ms of script time. If it is the only thing you wear into Furball or Pounce (make sure you are alone), you can see the change by taking it off. The bridge uses more resources than the ZHAO II. However, using the built-in Firestorm AO adds no eps nor does it use any script time.

None of this tells us anything about the load placed on the communication connection to the server. With AO’s, built-in or otherwise, the script you are running has to be conveyed to those around you for the shared experience. Your viewer has to send information to the server which is then distributed to the others in your region. Their viewers then have to get the animation script and render it.

I don’t know how the simulators handle this now, whether they keep the information on hand and hand out the script or all those in the region have to hit the asset server to get a copy of the animation.

The Built-in AO’s

A number of Third Party Viewers (TPV) have built-in AO’s. These are a more sophisticated versions of the HUD and attachment style AO’s. You will find them in most TPV’s now.

The biggest advantage to the built-in AO is the ease of setup. The ZHAO AO uses a note card for configuration. Plus scripts have to be dropped into the HUD. Editing HUD’s is not a simple process. One needs to rez them to the ground. Many have clear sides on all sides except the control face. This makes them invisible when viewed from any side but the front.  One has to understand quite a bit about building to set up the note card driven AO’s. Many animation makers setup AO’s with their animations installed and configured. But, if you don’t like that setup, you have to learn a lot to change it. It is a pain.

I have no doubt this setup and learning curve is a turn off to many new users and has some impact on player retention. Non-technical people likely see the task as overwhelming. I believe the Lindens recognize this problem.

The built-in AO’s are way easier to setup. Rather than rez the HUD, edit a note card, and move animation files around one can click a button to open a dialog and select what they want in their animation set. Most built-in AO’s are a simple drag-and-drop setup.

Just as the ZHAO allows us to setup collections of animations in different note cards, so too do the built-in AO’s. They use folders in inventory and the new ‘links-to-items’ that are now possible. So, No-Copy animations can be in several inventory folders, no problem. The result is I can change from my sexy female humanoid set of animations to my awesome Fae Dragon set of animations with a click.

Not having to deal with a note card setup is a big advantage. Being able to use item links with no copy animations is another huge advantage for built-in AO’s.

However, it seems that each TPV has to have their own folder for the animations to be used when running that viewer. Not much of a problem, but annoying when you use a number of different viewers. Why the TPV Dev’s didn’t settle on a standard name for the animation folders they use is anyone’s guess. I attribute it to human nature and time.

The setup folders for the built-in AO’s are protected in some TPV’s. So, one cannot edit the contents. Presumably new inexperienced users are not using TPV’s. So, that is not a confusing problem. But, such a restriction in the Lab’s viewer would be.

I still use my ZHAO because I don’t want to take the time to setup an AO in each viewer. I can just wear my ZHAO and it works no matter which viewer I use. I have no motivation/reason to change my existing setup. If I could set up one AO in Dolphin and have it work in Firestorm and Niran’s, I would be more interested.

The Lab’s AO

No one knows what the Lab is actually going to do or even when. I think we can certainly understand their likely goals. One of which is going to be simplicity. I believe the goal will be to hide the need for animation control from new users. So, we may see something tied to Outfits.

Consider. We can now have Outfits that are a collection of ‘links’ to items scattered through our inventory. These ‘Outfit’ collections are kept in a special folder. TPV AO’s are using a collection of links to animations kept in a different kind of special folder as an animation set. The Lab will likely do something similar. So, adding an animation set to the Outfit should be easy enough to do. All that is needed is a link to the folder with the animation set.

I think this would allow new users to easily have a robot-walk-animation with the robot avatar. The male and female avatars could have their unique walks too. Changing avatars would invisibly and automatically change the animation set. New users would not need to learn anything extra to deal with avatar animation. For them it would just happen.

Power users will figure out how the ‘Outfit’ animation sets work. It would seem logical that an animation set would look very much like Enhanced Avatar Physics does in Appearance. We could change animation sets and edit them as easily as we change physics layers.

The Hard Part

The biggest problem for the Lab is devising a user interface for creating, editing, and deleting animation sets. It is this area that experience with TPV’s becomes important. What is working? What is not working?

Also, there is the complication of adding more special folders to inventory that behave differently than ‘standard’ folders. That increases the new users’ learning curve. Also, it is poor interface design to have similar things behave in different ways.

So, what the Lab comes up with will be interesting. If they can get the basic operation right, the TPV Dev’s will come up with an array of user interface improvements. Niran will certainly come up with different interfaces. We’ll have the freedom to choose what we like best and use that. With any luck we will be able to talk the Lab into adopting the best of those features.