The Tao of AO

Hi! I just posted a new entry in the Tips and Tricks section of my blog: The Tao of AO (a general introduction to using animation overrides). Have fun reading!

http://drickenbacker.wordpress.com/2007/09/17/the-tao-of-ao/

Good one Dylan

To be fair, I think you might add that AO's are one of the biggest causes of the dreaded SL-laaaaaaaag!!!! So if you are in an area where there are lots of avatars - at an event maybe - the courteous thing to do is to take your AO off.

(Please note that I make avatar animations in SL - so I do not saying this lightly and am by no means anti AOs.)

I would also encourgage people to download Quavimator - it's a good free package - and have a go at doing their own poses and animations. It's good to learn.

So vote for an alternative way to make an AO =)
http://jira.secondlife.com/browse/SVC-91

There are a few others which may be better specifically in the case of AO's (e.g being able to set the animations rather than having to override them) but that JIRA issue can help in a whole range of scripted applications.

Excellent! I voted. Maybe post this as its own topic so people know about it?

Thanks Dylan

Please point us to some proof of this assertion. 80 avies in a sim with 80 AO scripts running seems as nothing compared to the hundreds--even thousands in someplaces--of vendor scripts running around them. It also seems as nothing to the burden of keeping up with the constantly changing motions of those same avatars, even if they were not dancing and had no AO operating. My experience is that stuff, any stuff of any kind, contributes to lag. Fingering anything as being exceptional in that regard needs proof.[/INDENT]

So it's true, yes, that in order to reduce lag, people should not only turn their AO's OFF, but actually DETACH them as well? Isn't the AO still basically running a script while it's attached to your body? Just curious.

[/INDENT]

No statistical data has been collected. If you feel froggy, feel free. AO's are well known to cause "noticable" lag. It's a fact of how they operate. While no one on the forums may have "proof" of the sort you want to see, we, who have been around for a bit, do know it as fact. Use the knowledge as you will or won't.

~Jessy

I think Govindira has been here a little longer

For you to consider it as a fact, you must either have an idea of the mechanism which makes AO's disproportionately large contributors towards 'lag' ,or you must have (or seen) some empirical evidence to lead you to that conclusion. I'd be interested to know myself!

Doesn't something have to go through Hypothesis, Testing, Theory, Testing, etc before it can become a "fact?"

I mean, I can believe that AO's contribute to lag, but has it ever actually been proven?

Everything contributes to lag. The question is, are AOs laggier than, say prim hair? I suppose if you went onto an empty island (is Crash Me completely empty?) and looked at script performance naked, then adding different scripted attachments, one would find out.

a poorly written script, be it an AO or what will cause considerable lag. A well written script is the opposite. I for one have never seen proof that a specific script causes huge lag. Blaming a AO script is like blaming LSL.

I'm curious as well, as I've heard conflicting things about lag from timers (the part of the AO that is causing lag, as well as any listens). Someone told me once (yes, hardly definitive proof!) that it's not as bad as it used to be, and a .1 sec timer is not that heavy a drain on sim resources.

I don't know how the ZHAO (for example) is set up, but I'm guessing it hasn't any listens as it uses a clickable HUD (which would use messages). Presumably, the timer event goes to 0 when it's off. If that's the case, when off, HUD based AOs would cause no lag, correct?



Haravikk, great JIRA suggestion!

The mechanism of an AO is that it overrides that from the Linden server. As it is not client-side only, it has to poll the main server every time your avatar does something in which your AO overrides the standard animation. The complete technical aspect of this is something I have no wish to delve into.

I know for a fact that AO's cause lag. At weddings, and other such events with large numbers of avatars, AO's have been requested to be removed, or turned off, which resulted in a notable lessening of lag.

Is there a difference between well written AO's and those not so well written? Obviously.
How much does an AO impact lag and performance? While I can't give you a quanative number, I'd say more than your average poseball, much more than prim hair, less than an avatar scanner.
As with all LSL related devices, milage may vary depending on the vehicle and road.

They don't bring a sim to a halt, but they do have a "noticable" effect. So do a lot of things. I use an AO, and will continue to use one. I only take it off if the landowner requests it.

I've found that testing such, even in a blank sim, is a futile effort as LL can not keep their end stable enough to make the data worthwhile. Possibly if someone is determined enough to do such testing over a long enough period. I'm not *Grins* I'll simply go with what I know.

~Jessy

This might be of interest:

/54/8f/145472/1.html

Disclaimer: I created ZHAO, and it's based on Francis Chung's Franimation. I recently released ZHAO-II, which has lower sim impact than the original (among other changes), so if anyone's using the original, I'd recommend you try out the new one.



And I've seen anecdotes where someone brought 40 people to a sim, and had them all wear/turn off/detach their AOs, and no one noticed any difference in lag at all. So... *shrug*

ZHAO-II checks the state of the av 4-5 times a second. Even multiplied by 80-100, this is really not a lot of work for the kind of hardware that sims are running on, where script impact is measured in millionths of seconds.

Also, AOs have been getting better since they were first introduced. And LL significantly changed how sims handle scripts some time back. Earlier, a busy script would affect everything in the sim, but today, the sim will slow scripts down in order to keep the physics engine running as fast as it needs to. So yes, you'll experience 'lag' in the sense that your scripted gadgets will respond more slowly, but the overall experience of walking around in the sim shouldn't change. Read the link at the top of this post, it goes into this stuff in more detail.

So... (and this is IMO) a lot of what used to be true of scripted gadgets in general, and AOs in particular, isn't really true any more. But people who've formed their opinions years ago, will generally stick to those opinions



I'm not sure I agree with the prim hair Especially at the kind of event where lots of avs are arriving and leaving. You have 60-80 people wearing attachments with hundreds of prims with complex geometry and multiple hi-rez textures, and all that information has to be sent to every new av who arrives at that event. If it's a static group of people and everyone has rezzed everyone else's hair and clothes... then you're right, at that point, scripts will have more impact than texture and prim downloads. So... it depends on the circumstances.



The link has results of some tests on this subject. The tests give us a basis to compare different scripted objects, if nothing else. Fuschi checked each gadget over several minutes and reported the highest number he observed, and that's a pretty decent test IMO.



Correct. Some of the actions use dialog menus (ZHAO-II uses dialog menus for pretty much everything). When the AO needs input from the user from a dialog menu, a listener is opened before the menu is displayed, and closed after the user clicks a button.



Correct. A ZHAO that's turned off is an idle script. No listeners, no timers, no polling the state of the av. All it's doing is passively waiting for the person to touch the on/off prim again.



Note that idle scripts do take up *some* sim time, so the impact of a ZHAO that's turned off isn't zero. But it is very small.

I always comply with any request to help with lag in a crowd. However, in situations where it has been a suggestion rather than a requirement, I have kept on my AO and seen no ill effects compared to --for examples-- walking across the area or the arrival of a new person.

In a situation that is already at the ragged edge of system viability (such as a wedding of 80 persons), removing any server burden will help. Any server burden. Asking one or more persons to leave would probably work as well as removing AOs, but that is obviously unacceptable (unless they're griefers!).

So, does anyone have any proof that one kind of AO causes more lag than another or that AOs cause more lag than other items normally worn by a skilled and developed avatar? In my erstwhile professional life, when arguing about complex real world system control software, we always tried to develop facts. Usable facts were the hardest things to develop, too, for a complex system. [/INDENT]

Sorry for a stupid question:

How do I know what my new AO is? It's got a HUD that I click on for a menu, or to turn off and on. Is this a ZHAO? How can I tell if it's a ZHAO or ZHAO-II?

Thanks!

Don't all scripts reside server side? The mechanism you have offered doesn't differentiate between AO's and any other scripted object.

That's your perogative, but you seem to be ok at taking the time to give anecdotal evidence

But then I see a lot of behaviour that goes on in SL as a result of general perceptions that are either incorrect or misguided. I don't know if this is the case here, as I really don't know if AO's are disproportionately resource intensive or not, but the likes of the behaviour that you descibe here is not enough to convince me alone. I would just like to see a logical explanation - does anyone have one?

I've been using Zhao, and it's great! Where can I get a copy of Zhao-II?

I really don't think we can directly compare the effect scripted objects with those of prim hair. The former is server side and so any 'hit' on the sim is experienced by all, where as the effect that the rendering of objects has on performance will vary from one resident to another according to their set up.

Trout and Oryx, check my profile in-world.



I think I know what Jessica is talking about. LSL has no events that tell a script when an av changes state (walking, standing, etc.). So, every AO has to periodically check the state of the av to detect if a different animation needs to be played. This is inefficient, and ideally LSL would have events for these animation state changes, so the script could just sit and wait for these events.

But like I said, ZHAO-II runs this check a few times a second, so the impact on the sim from this periodic polling is fairly small.



True, but there is a sim impact in downloading geometry and texture data to the clients, especially if there are a lot of avs arriving and leaving the area. This applies to sims with complex builds with large number of textures as well, not just hair

But you bring up a good point - client-side vs. server-side lag are two different things.

Thanks for the explanation Ziggy. So, the frequency with which the AO checks the state places a higher demand on the server than the 'average' script? I appreciate there is no such thing as an average script, but I am using the term only to understand if AOs are a heavier_than_average burden on resourses as compared to commonly used scripts.



I suppose that's the cycles used to 'send' information to the clients connected? So am I right in assuming that complicated geometry in a sim will up the 'image time'?

Like you said, it's difficult to come up with an 'average' script in SL.



Not the frequency so much as the fact that it needs to be done at all. Let me put it this way - good system design tries to avoid a situation like this, where one entity has to periodically check the status of another entity. This wastes resources, because most of the time the status won't have changed, but you have no way of knowing so you have to check it anyway. But sometimes this kind of periodic checking is unavoidable, AOs in SL being one example. Av scanners/security systems are another example - if there were an event that the sim sent to a script that said "person X has arrived", the script could sit and wait for these events. But there isn't, so the script must periodically wake up and scan the sim. The more frequently it does this, the more resources it uses. Same for an AO, or anything else that does something on a regular time interval.



Read the link in my first post in this thread. Someone took the time to measure the script time impact of many popular gadgets. As Jessica said, it's not super reliable data, but it was a pretty good test within SL's limits (IMO), and any data is usually better than no data (again IMO).



I think image time keeps track of time spent in sending textures to clients. I *think* 'client time' would track geometry, but I'm not positive. Regardless - the basic point I was trying to make is this: the more geometry and texture information there is in a sim, the more work the sim has to do every time a new av arrives. Textures are easy to understand, a 128x128 texture has less data than a 256x256 texture, so it's less load on the sim and the network to send it. Geometry is a little more complex, and I don't know all the numbers (I'm a scripter, not a builder). But I know that a plain cube requires much less information to represent it than say a hollowed/cut/twisted torus.

I understand the constant polling being a waste of resources, but is it really that uncommon? I mean is there any reason to single out AOs over and above other scripted objects that are wasting cyles unneccessarily? In a busy commercial sim, I would have thought that other scripts that fit into this category would outnumber the number of AOs? <shrug> I don't know, just supposition!





I'll take a look!



Math is more my area, and so I can appreciate how the level of geometrical complexity could affect the size of any data sent.

You know I wonder if it would be worth having the ability to restrict the draw distance in a sim in estate tools; it seems obvious, assuming the 'geometrical complexity density' within a sim is roughly constant (big assumption I know), the size of data sent would increase with the square (or even cubed if there is a lot of height to the geometry!) of the draw distance. Draw distance must have a major effect on size of data sent!

Thanks again for your explanation Ziggy.

As discussed in previous posts in this thread, AOs are inherently laggier than the "average" script because of the sub-second polling interval. But there are AOs, and then there are AOs. The AOs in the Franimation Override family (including ZHAO and Wet Ikon) are about as efficient as possible within the limits of LSL (perhaps barring some cryptic pure-performance hacks) because they rely on a relatively inexpensive call to llGetAgentInfo() each sampling interval. It still sucks that the script has to "wake up" each sampling interval to see if it needs to do anything, but at least those AOs are pretty quick about figuring out when there's nothing to do.

There are some AO scripts, however, that use llGetAnimation() instead; that's a little slower because handling the string return value is inherently slower than can be done with the bit vector returned by llGetAgentInfo--not perceptibly so on each call, but since an AO executes the call several times a second, it starts to matter. The worst offending AOs, though, use llGetAnimationList(). This is bad news because the call itself is expensive and handling the list returned to the script is very expensive. There are some freebie typing keyboard AOs that use this function (in a script with other performance problems), and unfortunately that script has found its way into a lot of widely-used variants. They are alarmingly laggy.