Texture animation sync ?

is possible to synchronize the animation textures in multi prims ?

I don't think so if we are talking llSetTextureAnim(), But I have made an observation with two prims both with an llSetTextureAnim() and with the same rate (frames/second) they will get synchronized. I guess it is because, when both textures are loaded at the same time to the client they will start the animation simultaneously on the client. I can rezz them at different time and they are not synchronized, but when I come back, from another sim or I log in, then they are synchronized.

You can try selecting both items, and doing a drag copy of both items, then delete the one's you have currently selected after the copy, the two remaining ones (those are the new copies) should be sync'd


http://www.secondscripter.com

I'd think it depends on when each individual client receives the commands to animate the textures, not the actual textures themselves (since texture animation is just manipulating the face offset values, regardless of what texture data is present). Hence, the sync will vary from client to client.

/me wonders if this would make a good JIRA.

Should there be another bitflag in llSetTextureAnim called SYNCHED or something? Maybe it'd tell the viewer that all prims in the object that animate with that flag should loop at the same time?


For the times that I've been frustrated trying to get prims within an object to animate in sync, I was far more concerned with getting each animated face to be at the same point and far less concerned that different clients would see exact same thing. The goal is to get different prims to animate smoothly in relation to each other, not in relation to different clients.

The general case of a SYNCHED flag would be pretty complex, I think. For example, I once had an unlinkably huge prim pool where the "water" needed to be sync'd, and with selectable texture animation speeds. I managed to get this to sync (almost always) just having scripts in each prim listen for a synchronization message (probably llShout, back then) that specified an effectivity timestamp maybe a half-second in the future. The scripts would stop the texture anim, set themselves a timer for that timestamp, then when the timer expired restart the texture anim at whatever speed. Once in a while they'd not quite sync perfectly, but usually it worked without noticeable offsets between the prims. (Just syncing on a listen without waiting on that script-local timer had much less satisfactory results.)

Texture animation is handled client side. Therefore what looks good to you must not neccessarily look good for someone else and the other way round.

You can try to "sync" animations using the methods described by the previous posters but in the end you have no way to "force" a sync.

I truly have no idea how texture animation is implemented in the client but I assume that each animating face has a counter of where it is in its own loop. For the SYNC flag, which was just a thought and not really a 'zomg! gotta have this!', I was thinking that it'd reset the loop counter back to 0 on all prims that are animating and used the flag. Or maybe have a new global counter that all SYNC'ed prims work off of. Dunno.

It was just a thought. For how hard it'd be to implement in the viewer, I have no clue where it sits between "oh, that's easy" and "er.. that's a naively stupid idea."

All that said, I like Qie's idea and will probably use it.