[sldev] Re: [SCULPTIES] New Scripting Functions

Argent Stonecutter secret.argent at gmail.com
Sat Sep 29 10:34:59 PDT 2007


On 29-Sep-2007, at 11:51, Lawson English wrote:
> What I proposed to Qarl and Zero was along the lines of a texture  
> animation where instead of the texture map being used by one  
> sculpty, it was used by n sculpties, n beng greater than or equal  
> to 1.

[...]

OK, first of all, you *don't need to do anything special* to use  
different portions of the same map for multiple sculpties if you just  
make the mechanism a parallel to the texture animation one. You get  
that for free with the texture animation start and length parameters.

Second, texture animations on prims start when the parameters are  
downloaded to the client. Sculpt texture animations would be the same  
way. So if you set them concurrently they would run concurrently, and  
in general tiled prims with lined up texture animations just work...  
and when they don't it's because you've got unlinked prims that  
didn't rez together.

So sculpties in a link set are going to generally start animating at  
the same time and in sync with each other and texture animations.

HOWEVER, it would be nice if there was a mechanism to sync periodic  
client-side operations.

Well, there is. It's the audio sync mechanism. I'm not suggesting  
that this be used to sync to audio, I'm suggesting using the existing  
audio sync mechanism to sync periodic actions in prims. ALL periodic  
actions. Currently it only works for audio.

That is, if there is an audio master present, then prims with the  
"audio sync" parameter set would wait, at the end of the cycle (of  
texture animation, sculpt animation, llTargetOmega, periodic particle  
generator), until the next time the audio sync loop started. So after  
the first loop, they would start in sync.

The audio master does not need to be audible, it could be a silence  
loop. But there's already a mechanism in the client to sync looped  
sounds to a master, there's no reason that couldn't be extended.

It would also be really useful to be able to generate the master sync  
without a sound file, to make it linkset-local or avatar-local, and  
so on.

Finally, syncing might not need LL to do anything. It might be enough  
to have the client check if there are multiple looped events in a  
linkset *with the same periods* and sync them... and WE can implement  
and test this part using texture animation.

1. The first part of what you want comes for free with texture  
animations, and it's something that Linden Labs needs to do.
2. The second part of what you want needs to be a general mechanism  
that handles things other than sculpties.
3. Apart from designating the sync master and slave hierarchy, this  
is all client stuff that YOU could implement, and for a single  
linkset you could test it with sculpt textures now.
4. If that works, all LL needs to do is to create a sculpty version  
of texture animations.


More information about the SLDev mailing list