Animation Overriders

I check in on this thread every now and then to see if anybody has answered my newbie questions yet.

coco

I noticed that of these animations I picked up for free, some are moving and others are static. I put these in folders I labeled, "moving animations" and "poses." I am wondering, what is the use of those static poses?



cocoanut, the static poses are used in furniture.

so sayeth:

marilyn

well, what i am saying palomma is, the standing animations used by any ao, makes the user look bored and disinterested. i realize i am bucking a new trend as so many want these things so they too can look bored and uninterested. without the ao u just alt/click on the person you are talking to and your avatar watches them and speaks to them. with the ao you are just staring anywhere, looking at the ground as often as not, or off into some tree. so, if u get a sexy walk anklet/bracelet whatever. and do without the ao posturing when standing still, its the best combination.

so sayeth:

marilyn

Coco, IM me in world so you use the walk I sell in my place by Vicious... is not an animation override

Actually visit DoveVogue Davvi 70,70.. that is where it is... go there anytime.. is on the lower floor...

That's not the AO, Marilyn -- that's the animation. I don't know the specifics on creating anims, but I have learned this: some standing animations leave your head free to move, and some don't. I know because out of the five standing anims in my AO, only one of them leaves my head "unlocked". As a result I'm looking for some replacements, because I agree with you that fixed standing poses don't look very good for conversational use.

Ooooh okay!!! yes it is my AO (feels stupid) but yes I am using the OLD OLD Animation Override. Im sorry haha *rushes to get the newer one*

Love you bunches!!!

I don't find that animations make you look bored or uninterested, if anything my stands make me look less rigid. Of course everyone is going to differ on what kind of animations they prefer. I find that static modeling poses aren't good for casual stands and I also don't care too much for the animations where you fidget. This is just my opinion but I am glad to see so much variety now rather than everyone standing the same old way.

So sayeth Torrid

On another note someone mentioned heads being locked in their standing poses. You can always ask the animator if they would upload the animation with a priority of 2 or at least delete the head movement in the bvh. I'm not saying they would do it but it's worth a shot!

Ahhh... so it is that simple an alteration? LOL Let's get the word out on this one... I realllllllllly hate these statue head thingies. They seem to want to tilt the head a wee bit so that our eyes are rolled up and look downright sinister and evil. LOL!! It is actually kinda amusing to see our eyes rolling around like we are preparing to blow the sim up or something tho.

Yeah, Yeah, Yeah... I know they want the head steady for modeling and photo shoots. But, ahhhhhhhhh.... turn that off when uploading as AO Stand Replacers. LOL

Francis and I have disagreed on this several times, but quite respectfully, as we're friends.

I find they do cause lag. While I applaud Francis's code and efforts with the AO, they definitely do cause lag and can be made more efficient. Here are some problems (at least in the initial one I revised; I admit I haven't reviewed the later versions):

(1) Multiple listens on an open channel. The caused code to be parsed multiple times whenever the avatar wearing the AO would say anything. I find this unnecessary, especially with dialogs now in place. Listens DO cause significant lag, especially when you're in a sim with many people where every single server cycle is precious. Listens on an open channel are the main culprit.

(2) The timer event was set for 0.001 (1000 times a second), although SL has a hard coded limit for timers to run 10 times a second. This seemed silly to me, because if a change is sensed, the servers still have to send to each client which animation is playing, and the animation data itself. This causes a delay naturally, so why have a script constantly parsing code 10 times per second instead of 2 or 3 or 4 times a second?

We're had this discussion on #secondlife several times with a lot falling on either side of the argument. Its comes down to efficiency versus ease of use.

The fact remains, Francis did a great job take the initiative to code it as a stop gap. This is REALLY a function which should be native to the SL client as part of preferences, or perhaps inventory (right click anim ---> Set as Walk anim?). Having 10,000 of the 20,000 regular SL users walking around with scripts running open listeners and executed code every 10 seconds? That is not the solution, IMHO.

Regards,

-Flip

Flipper,

A few things to address your concerns:

Listens do consume some server resources. 1 listener or even 30 is not going to make a significant difference. To understand why, I will explain how chat works in SL:

All chat, regardless of channel is entered into a sim-wide circular buffer. Each script that's listening for chat will search the entire buffer. This linear search is sub-optimal, and if you have an excessive number of listening scripts (say, 1000) this can have a negative performance impact.

Multiple listen statements in a single script are internally combined into a single listen filter. So having multiple listens is of no significant interest.

As for timers, they are also implemented sub-optimally in SL. There is no "queue" of timers. The lag associated with timers comes from the fact that all scripts with listeners are checked to see if their timer event should fire. I have done experiments that indicate that the amount of CPU consumed by a timer is roughly the same regardless of the timer interval.

Also, as far as the discussion of "10-20000" avatars, I think this is irrelevant. Although there may be many avatars running the same script, there will also be thousands of servers to accomodate that load. So the overall impact is negligible.

Regarding my AO scipt, it only sends a client update when the animation changes. (ie. No more than absolutely necessary.) Client updates with my script cannot be reduced without sacrificing correctness.

On the topic of runtime, even though the timer will fire at a maximum of 10 times per second, it still spends most of its time sleeping. There are internal optimizations in the script to insure that no redundant computations are run.

In Laymen's terms, most of the time when my AO is running, this is what it's doing:
- "Has the avatar's animation changed?"
- "No? Okay, I'm going back to sleep."
- "sleeping"
- "sleeping"
- "sleeping"
- "still sleeping"
- repeat

I've said it before, I'll say it again - optimization of LSL is a black art, and full of counter-intuitive pitfalls. If you're going to say something causes lag, perform an experiment that demonstrates it. I have performed these tests with my AO script that indicate that it does not consume any resources to the expense of anyone else.

I agree with whatever flipper says below me...

Okay, I just ran a test with Baba Yamamoto as a witness. He was around... and, of course, being a wise ass.

Indigo with 2 of us present before AOs rez'd:

sim fps 1250-1350

5 AOs were rez'd by FlipperPA.

sim fps 1000-1150

FlipperPA started typing 5 letters per line, once per second.

sim fps 850-950

FlipperPA stopped typing.

sim fps 1000-1150

FlipperPA rez'd 5 more AOs, totalling 10:

sim fps 800-900

FlipperPA started typing once per second

sim fps 750-850

FlipperPA deleted all 10 AOs:

sim fps 1250-1350.

Baba was here, watching as I did this, step by step.

Regards,

-Flip

Interesting. Optimizing for an excessive amount of chat is not something I had in mind. I imagined people would chat maybe once or twice a minute on average.

Anyways, I looked at the code, and added a short-circuit for an early ignore of "random chat cruft".

I did test here in Mocha, with 1 Agent, (ie. me)
Before = 130-160fps
32 Animation overrides, 3 random chat messages a second = 130-160fps
After = 130-160fps

Look for version 1.6 soon

*smacks his forehead*

*attempts to speak, smacks his forehead again*

Are you SERIOUS?

Maybe you should put a disclaimer on your AO, "Warning: Do not speak more than once every thirty seconds!"

Incorrect.
/invalid_link.html

This thread should give you an idea of how listens prioritize filtering.


It depends on what you're filtering and how you filter it. They definitely are not "pretty much the same" and that myth should not be passed on to new scripters!
/54/f8/34253/1.html


Ah, kinda true.

The basic resources consume just simply to have it may be the same because, at the OpenGL level, you're adding another trigger for C++ to need to process.

However, the resources consumed in the actual use of Listens varies greatly depending on how it is scripted.

Any more and I'd be giving away critical code to my new PosAbility PoseCube system,
but there's no reason people shouldn't have a simple non-laggy anim override.

// Warning - I'm doing this off the top of my head, so it may have a type-o.


// Commands: 
// all commands done on the channel indicated
// a number will indicate the number of the anim you want. 
// "next" will move to the next animation


integer store;   // storage variable for listen
integer channel = 5; // put the channel to speak on here.
integer which = 0;

update()
{
       llListenRemove(store);
       theanims = [];
       integer c;  integer d = llGetInventoryNumber( INVENTORY_ANIMATION);
      if(d>0)
      {
           for(c=0;c<d;++c)
          {
               theanims += llGetInventoryName( INVENTORY_ANIMATION,c);
          }
      }
     which = 0;
}

animate()
{
           if(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION)
           {
               llStopAnimation( llGetAnimation( llGetOwner() ) );
               llStartAnimation( llGetInventoryName( INVENTORY_ANIMATION, which) );
           }
           else
          {
               llOwnerSay("Permissions not set for Animation Overrider. Please allow animation permissions.");
               llRequestPermissions( llGetOwner(), PERMISSION_TRIGGER_ANIMATION);
           }
}

default()
{

    state_entry()
   {
       update();
   }

   on_rez()
   {
        llListenRemove(store);
       llListen(channel,"",llGetOwner(),"");
       if(!(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION))
       {
           llRequestPermissions( llGetOwner(), PERMISSION_TRIGGER_ANIMATION);
       }
   }

   listen(integer chan, string whom, key owner, string msg)
   {
       if(msg=="update")
       {
            update();
        }
       else if(msg == "next")
      {
            ++which;
            if(which >= llGetListLength(theanims))
           {
                which = 0;
           }
           animate();
      }
      else
     {
        if((integer)msg >=0)
        {
            which = (integer)msg;
            animate();
         }
     }

   }

}

Hiro,

There's no need for drama or disrespect here.

I made the assumption that people on average, don't chat very fast. Certainly not at a rate of once per second. Most of the optimization was spent making the animation logic as clean as possible

The next version of the Franimation Override will have a more efficient command processor.

In one of the threads you've linked, I talked about the importance of running experiments:
"Optimization in LSL is a black art. It is full of many counter-intuitive ideas. Personally, I've decided not to listen to anyone claiming that something is laggy/not laggy without seeing experimental results. Anything else is just opinion, and we all make mistakes."

Try posting numbers and experimental results. By sharing our data, we can all work towards gaining a stronger understanding of LSL optimization problems.

This is a study I posted a long time ago:
/54/c8/25865/1.html
The numbers are a bit out of date, but you get the idea of what kind of results I like to see. Maybe you can be the one to update those numbers?

As for your conjecture, regarding multiple listeners, try the experiment,
/54/c8/25865/1.html

I was surprised by the results too

Yes, I've seen the results, but my comments still stand. The test you referenced does not really examine variations in working conditions while people talk - which is exactly where the lag from listens take place.

Assumptions are the killer of programming.

And before I hear the obligatory "well, why don't you script your own thing"... I am. I've been testing and tweaking and retesting PoseCubes for months, so that when I release it, we won't have a laggy mess on our hands.

We scripters have a responsibility to the community. There aren't many of us, and when we release items that are likely to be universally used, we have an obligation to not lag the whole dang grid.

I'm sorry if this is harsh. You get people praising you all the time, so I'm sure one person pointing out some constructive criticism won't hurt your reputation.

Wait here, I run fashions show constantly in DoveVogue and yes.... when 30 of 40 people that attend the show has overrides, it DOES CAUSE lag because the AO is constantly updating. We see it in Debug/System update.

We tell the models to remove all AO, plus we beg the audience to do so. same as blings, anything with listeners, that constantly updates. But AO is the #1 cause of our lag. Models can't move. We are very close checking on the amount of people with AO's.

We had lindens checking on this and definitely that was #2 reason, #1 is the amount of avatars.

So, I need or looking for no lag AO if possible... ohh and my reason on this thread, I want to hug and not turning off the ao to hug when I put on.

Flipper, Hiro, Francis... you guys are awsome and thanks for all you bring to SL world, really... I love when guys like you start thinking on how to get things better...

Francis, in my shows we constantly chatting describing outfits... maybe you can come and test too when we are doing the shows... Flipper I have seen you there and Hiro, you too come to the shows...

There is one today Friday at 2:00 pm SL for Shiryu Musashi... we are looking for a full crowd as usual...

Testing is the best.... Even thou I will ask to remove all AO *smile*

Hmmm..... I have used two different AOs and neither one shows anything at all via Debug/System Update. No red.. no blue.. nothing at all.

You don't see your own... but well when I am there alone or with less than 5 people I never lag... when I have 40 in audience with many using the AO's oh yes!!

This really worried me, as I am very conscious of what I do here... I know how lag affects my experience and the last thing I want to do is hurt someone else's experience unknowingly. So... I took Torley's advice on how to get two avies inworld at the same time. (Thanks Torley!!) I have two different AOs, so I put a different one on each avie. Twenty minutes later and I am still not seeing any poofs of any kind or color via the Debug/Show Updates. *shrug* Maybe I am missing something here.. but I see poofs from other things.. have had shoes and jewelry that poofs.. etc etc.. but still not seeing anything on the AOs.

Uh, if you have 40 in the audience WITHOUT AO's its going to lag more than when you're alone or with 5 people. I think you need more scientific proof than '40 people with AO's lags my sim more than 4 people without'...

no need of scientific proof... I feel it.... many do... I am not saying it is just the AOs the reason of the lag... but contributes to the rest...

Lindens told me when they were there in show.. and I believe them... *smile*

I am not a scripter to give anyone scientific proofs, I just feel it, feel how slow it is and difficult to move like everyone else...

I am just a someone that while hosting the fashion shows, or watching them, I feel the effect on my functions. the way my avatar moves when there are scripts that updates constantly, when there are 40, full sim than where is me or less than 5, the feel of the avatar moving is different... I feel it like many of us there and still continue our function with or with more difficulty because of lag.

Anyway, I am not complaining because I love my shows and what we bring to SL. But I just give my opinion of what I feel, no need of scientific proof.. hehe.. I leave that to the amazing scripters.. the creators, inventors of getting things work better for us....

And you can actually 'sense' the difference between 'AO lag' and that caused by 40 people's bling, sexy walk animating boots, particle poofs, furry avs, armor, hoochie hair, prim chain jewelry (realistically modelled from 200 tiny torii!), personal scanners, dance attachments..?

Well then I concede! No scientific proof needed! Francis Chung is evol and must be hanged! How dare she release a free script that is so successful that almost everyone at every event is using it! One that might potentially cause a miniscule amount more lag than you would have had anyway when they all use them together!

Now I remember why I stopped doing freebies. It was in case they became popular. That and because so many Second Lifers DO like to whine endlessly about lag and speculate and point fingers at it's causes when they know so very little about it. Actually, let's not hang Francis. Let's have her committed. After all, who in their right mind would want to provide services to a community like this one? lol