Second Life Viewer and animations drifting into synchronization

[Ardy Lay]

Does anybody know why avatars playing a common animation drift into synchronization after a while when viewed with Linden Lab's Second Life Viewer?  I have been asked several times but can only call it a "happy accident" that resembles that described by the Kuramoto Model.  This leaves me wondering what would be the mutual forces at work causing this drift into synchronization.

[animats]

Running the animations uses some CPU time, probably. It takes very little coupling to make oscillators synchronize.

Watch them synchronize. Pay attention to the one in the right column, second row.

[Ardy Lay]

11 minutes ago, animats said:

Running the animations uses some CPU time, probably. It takes very little coupling to make oscillators synchronize.

Watch them synchronize. Pay attention to the one in the right column, second row.

So, you don't know.  Got it.

[Jenna Huntsman]

I'm not sure about animations 'drifting' into sync, but animations can be synced (either deliberately or by accident) by controlling when an animation starts or stops. Note that calling an animation may require the viewer to download the relevant asset from the server, so a script calling the same animation on 2 different avatars in a 3 second interval would likely result in the animations starting at the same time (as the asset hasn't been downloaded to the viewer yet, so the animation will start to play when it is available, irrespective of the time passed between the animation calls)

[Lucia Nightfire]

It "might" have something to do with the recent Jelly Dolls code where animation frame is updated based on number of frames that elapsed since the last update.

It still has areas where it fails such as with animesh, ranking and also screws up outside of the interest list.

The goal was to attempt to have agents/animesh leaving impostored state on the correct elapsed time frame and not just update animations one sequential frame every second while impostored.

Other than impostored state, distance from camera is another factor.

[animats]

12 hours ago, Ardy Lay said:

So, you don't know.  Got it.

I'd expect that to happen. An animation uses some resources and has a fixed time delay. That alone will result in sync. I see this all the time, because I have some animesh side by side on pose stands, in different outfits, all running the same animation list. The animation switching is sim-side, so there's a common resource conflict that makes them fall into sync.

It's a known annoying problem in computing. It usually comes up with things that poll. If the polling works by having a delay between the end of one poll and the beginning of the next, and replies to a poll have some variance based on delay, all the pollers will synch up. One of the early workers in networking, who was at LLNL and a physicist by training, first saw this.

The way you stop this is by timing from before you start the event, not after. That way, how long the event takes doesn't force a drift into sync.

I once built up some oscillators on a solderless breadboard to experiment with this. If close to the same frequency, they'd sync up just because they drew power from the same power supply.

[Ardy Lay]

Not saying the offers are inaccurate, but that my question was not specific enough.

Back when I joined Second Life I noticed that two or more avatars playing a common animation from their inventory, not using any scripted objects, eventually drift into synchronization.  "some resource in common" seems like the most likely influence, since, these are indeed all running the same animation asset on the viewer.  Perhaps the looping mechanism on the continuously looping animations functions like the polling instance animats described.

[Profaitchikenz Haiku]

I suspect for animations the data being sent back to the server saying "avatar A has just commenced frame 2 of animation xyz" gets sent not at the precise moment that xyz starts again, but at a defined slot when a batch of information is sent, and so there will be an inherent locking into one of several distinct timeslots when the information is re-broadcast.

 

I wonder if it's unique to animations or if it occurs in all client side activities. If you set a wheel of fortune spinning using targetomega and several people observe it, do they ultimately see it turning in the same orientation?

 

 

[Ardy Lay]

30 minutes ago, Profaitchikenz Haiku said:

"avatar A has just commenced frame 2 of animation xyz"

Nothing like this gets sent to the service from the client.  Client can send something saying user has requested to play a specified animation on their own avatar, then server sends animation UUID and target agent to all in-range agents, which appears to be the same message sent to agents when a script tells service to start a specified animation on an agent.

30 minutes ago, Profaitchikenz Haiku said:

If you set a wheel of fortune spinning using targetomega and several people observe it, do they ultimately see it turning in the same orientation?

No.  What the observers have in common is prim parameters, but no timing data is included in the UDP packets other than their circuit ID and sequence, IF those are included, they usually are not.  Looking away and then looking back can even effect the apparent angular rotation if the object is removed from the render pool.

 

Another thing that people may not notice is that particle effect life begins in each viewer when the viewer first renders the prim with the psys parameter set, not when the value is set on the prim.  So, if you wear a particle source that poofs then decays but does not get turned off by scripted removal of the particle system parameters then another agent enters the area they see the beginning of your poofer's particle system effect as if you just arrived or turned it on.  I have used this to briefly display a large sign to people when they arrive.

Edited December 3, 2021 by Ardy Lay

[Profaitchikenz Haiku]

12 minutes ago, Ardy Lay said:

So, if you wear a particle source that poofs then decays but does not get turned off by scripted removal of the particle system parameters then another agent enters the area they see the beginning of your poofer's particle system effect as if you just arrived or turned it on.

I've puzzled over that for quite a while  TY

[Ardy Lay]

Sorry if I seem to be banging on this pointlessly.  I am thinking about how to make the shared experience more synchronous but everywhere I look I find that SL isn't designed for synchronicity.  The effect of asynchronously started instances of a single animation asset drifting into synchronization is teasing me mercilessly.  Some time ago I asked a group of people, mostly Linden Lab employees, how this synchronization occurs and if it could be reinforced service-side.  Andrew Linden said there is no such synchronization mechanism there and that it may just be illusory.  A couple of us demonstrated the effect.  Took a few minutes.  Andrew said "Interesting."  Simon Linden followed up Andrew's statement by saying the visual effect is real and that it is just a happy accident somewhere in the code, nothing intentional.

I was hoping someone had examined this accident and could maybe help it get in synch more reliably.  Currently we depend on scripted objects to attempt to start animations on avatars simultaneously, which sometimes works, or we use a TPV hot-key-sequence that restarts all playing animations in the viewer.  Some help with sync would go a long way toward improving the dance routines we have carefully assembled using animations that have a tempo that is the same as the music playing along.  Currently we manually time-shift the music in the video recordings to match the lead dancer, and, usually, but not always, the other dancers are in sync with the lead dancer.

Now, imagine if the viewer could use Presentation Time Stamp data in the music to synchronize the animations.