Texture animation "stuttering" in sculpted prims

Argh. I'm not sure where to put this, but maybe you can help anyway. Looking at a lot of sculpted water prims, the texture flows smooth, just like it should. Of course when *I* try to make sculpted water, something goes wrong

Basically, I'm using the standard anim SMOOTH script to animate the water texture on my sculpted water. However, the texture seems to "stutter" and reset itself every second or so, rather than flowing smoothly. I've tried messing with a lot of the script settings, I've made sure I was using a seamless texture, and I just can't seem to be able to get the texture to flow correctly.

Has anyone else come across this problem and know how to fix it?

(to see what I'm talking about, go here: http://slurl.com/secondlife/Tean/222/147/24 )

And here's the script I'm using:

I've seen that stuttering before, and I basically understand it...
I would think your ".5" variable needs to be changed to 1.
http://wiki.secondlife.com/wiki/LlSetTextureAnim has some good info, especially in the Examples.

By the way, I find it funny reading a script like this that's mostly comments, and only, essentially, 3 lines of code. Not that that's important though. Although, it's kinda funny to see it say all that and then skim quickly over the meaning of the sorta complex llSetTextureAnim function.

yeah, sorry about that. I got really tired and was being interrupted couldn't be bothered to edit

I tried setting it to 1 and it didn't solve anything. I thought maybe it was the sculpt itself, but one of the sculpts is really just a deformed ball without hard edges and it's stuttering as well.

I'm not in-world right now to take a look, but I can offer two guesses at a possible explanation:

1. It could be your system. Sculpties are more taxing on the viewer than most other prims. Animated textures are more taxing than static textures. Marry the two, and you get the worst of both worlds. It could be that your computer is just having trouble keeping up.

-OR-

2. It could be the sculpty topology. On all regular prims, the vertices are more or less evenly spaced. So when a texture "slides" over them, all parts of it "move" at the same apparent speed. With sculpties, the distances between vertices can be highly variable. If your sculpty has a high density area right next to a low density one, then it's conceivable that any given area of the texture would appear to change speed as it crosses the threshold between the two. If the difference is extreme enough, it could be described as a "stutter". Try viewing it in wireframe to see if that's what's happening.

Or it could just be a bug.

I think half a frame is a weird length, try 0 and 0 for start and length?

I tried that and it didn't solve the problem. There does seem to be something buggy, though, since I realized that *nothing* I did seemed to affect the animation - not even removing the script.

I changed the texture to see if it would reset the animation - nope. I deleted the object and rerezzed it - nope. I removed the other script (particle generator) - nope. I logged out and in again, cleared the cashe, and... both the animation and the particle generators were in full effect. I went to a public sandbox and the "unscripted" sculpt was still animated and spewing out particles.

I did add the same script to another sculpted prim and it wasn't stuttering. Removing the script from the other sculpt also showed that the script was persistent. Even unchecking "running" didn't stop the scripts.

On the recommendation of someone in a sandbox, I reapplied the script, turned off Running, and set the rate to 0. That finally stopped the script. The non-existent particle generator was still active, though.

I'll scour Jira to see if someone else has reported this bug, because this could be a really huge issue

Ok, finally solved the stuttering problem, but not the persistency problem.

Set the script to


then turned the Running button off and on again. Strangely, when I open the script up after closing it, the Running box is unchecked again.

That's not a bug, Isara; that's normal behavior. Texture animation parameters are properties of the prim, just like size, rotation, position, etc. They just don't happen to be parameters you can access via the editor, so you use a script instead. I've never seen the wisdom in why LL chose to make some parameters show in the editor and not others, but that's what they did.

All the script does is change the values of the already existent parameters. Once they've have been set, they stay that way until you change them again. Turning the script off, or removing it, doesn't change anything because you're not actually entering any new information when you do that. The script altered the prim's parameters the first time it ran, and that was that. It would be the same thing if you'd used a script to change the size of a prim. Turning the script off wouldn't cause the object to revert back to its default size. It would just stay at the size it had last been told to be, until it was told otherwise. To change the size, the animation rate, or any other parameter, you have to give the prim new information. Trying just to remove old information cannot work. Prims don't forget.

The reason the animation stopped when you changed the rate to zero was because the zero was the new information that was needed. Until you made that change and hit OK, the animation rate would have stayed at whatever you had previously set it to, forever.

This is the same reason, by the way, that your particles persisted after you'd removed the particle script. Particle generation is also a property of prims. The script is just the tool by which you change the values of the prim's relevant parameters. To turn particles off, you have to zero them out via script, the same way you zeroed out the animation via script.

Wow, thank you! What a brillantly clear explanation!

Isobel