Fixing STORM-1909, llSetTextureAnim() ignores repeats per face

[Tonya Souther]

I got bit by the bug described in STORM-1909, that doing llSetTextureAnim() on a face with repeats and an offset specified ignores both. This bug also has been known as VWR-28409 and VWR-4018 and possibly others. (Since it's a STORM JIRA, you will be able to see it by clicking the link.)

I've got a fix mostly figured out, and will be hammering it out today. In the process, I've come across a question, and I'm not sure wht the right answer is: it depends on what content creators expect the function to actually do.

Specifically: It is possible for faces on the same prim to have different repeat and offset values from each other and from the default. Do you expect it to animate the texture on every face correctly if you specify ALL_SIDES in the llSetTextureAnim() call, or if you're doing this, do you animate only one face?

The tradeoff is that it's pretty simple to have the repeat and offset values work on one face; doing it for all faces on a prim can be much more computationally intensive, since every face would have to be animated separately. This could build up fast in the presence of several prims with ALL_SIDES specified.

My guess, putting on my content creator hat, is that getting it right only in the case of one side would suffice. But I don't want to make that decision for the entire SL community. What do you tolks think?

[Rolig Loon]

Well, much of what you're asking about is moot, since you can't have miore than one texture animation on a single prim.  From the wiki ...

You can only have one texture animation on a prim

• Calling llSetTextureAnim more than once on a prim will reset the existing animation.

I'm not sure that STORM-1909 is accurately called a bug at this point.  It has been around for at least 5 years.  Somewhat cynically, we might now call it "expected behavior".  It would be nice to have it changed, though, because there are plenty of times when you want to display and animate only part of a larger texture.  It's a nuisance to have to resize and crop the texture in Photoshop and then upload it agaian, just to do a job that would be easy with a repeats setting.

[Tonya Souther]

You can have one texture animation on all sides of the prim at the same time, though, and that's what I'm asking about. How often do people do that and have faces with non-default repeat and offset parameters?

And yes, the situation you describe is exactly what I'm trying to do: animate the face of a path-cut cylinder. It looks terrible with the resized and cropped texture I had to use.

Yes, it's been a bug for years. Doesn't mean it's too late to fix it, though.

[Innula Zenovka]

I may have misunderstood Tonya's question, but I took her to be saying that she's found a solution that works when llSetTextureAnim is called for a single face but not for ALL_SIDES.

 

[Haravikk Mistral]

Basically the only time the base texture repeats should be interfered with is when playing a frame animation with a sizex and/or sizey value greater than 1, in which case the repeats should be treated as <1.0, 1.0>.

For all other types of animation the function should be applied onto the texture exactly as it would appear on the prim normally (without animation).

[Dizzi Sternberg]

In the cases where i've used this it has been for 1 side of the prim only i.e. a scrolling water texture though i may have defaulted to ALL_SIDES i will have made the other textures unused to be transparent, majority of times it is a sculpt I'm animating which just has the one texture face

since it seemes to be things like waterfalls and scrolling starfields I would think that correct scrolling on one face would be enough

[Tonya Souther]

Actually, the solution would work for ALL_SIDES, but would require that the animation process be repeated separately for each face. For a cube, that means 6 separate animations would need to be done for each step. That can get expensive.

[Tonya Souther]

Ah, but if the prim has ALL_SIDES specified, which face would be animated? I suppose I could see if there's just one face that's not set to totally transparent and convert the call to just that one face, but that might get interesting.

[Tonya Souther]

Actually, the frame animation is exactly the case where repeats and offset should be honored. Animating the scale or rotation, pretty much by definition, changes the repeats and offset values.

[Rolig Loon]

---

Tonya Souther wrote:

Actually, the solution would work for ALL_SIDES, but would require that the animation process be repeated separately for each face. For a cube, that means 6 separate animations would need to be done for each step. That can get expensive.

---

Ah... That's the part that got me confused earlier.  I thought you were trying to call llSetTextureAnim 6 times, once for each cube face.  That won't work.  It seems that's not what you're talking about, though.  You're talking about what would happen if you ran llSetTextureAnim once, with ALL_SIDES set but with a different scale factor on each face. That would start to get computationally intensive, I'm sure.

[Toysoldier Thor]

Hi Tonya!

Its great news that this bug will finally be permanently fixed.

A couple years ago some creator (I dont even recall the name of the creator) gave me a script that actually fixed this bug as long as the script was applied.  It was no mod so I dont know how he fixed it.   But its nice that this bug will be fixed without the need for a script.

I am a bit confused about the question as well after I read it.   Each surface of a prim / sculpt / mesh  should be able to have its own unique repeat pattern.  For example can surface one have a 4:8 and two a 2:2 and three a 1:1?  If so, the llSetTextureAnim should not break the repeat values no matter if it was set before or after the scripted command executed the animation.

What I am further confused on is what is ACTUALLY the bug?  I sell sculpted waterfall shapes with seamless water textures that flow down the surface of the sculpt.  To reduce load on the sim, after I load the texture animation script that sets the speed and direction at which the texture moves, I remove the script.  The movement of the texture becomes a permanent attribute of the prim/sculpt.  And all works well with the set repeats.  Then for whatever reason the prim reverts back to the 1:1 ratio.

So is it really a bug of the script or a bug within the code of the prim?

[Tonya Souther]

The bug is in how the viewer displays animated textures on a prim, not in the script code or the server.

Currently, a prim can only have one animation applied, to either one face or ALL_SIDES. I'm not proposing to change that.

To understand the issue, let's first think of a cylinder. It has one face around the outside. That face can be animated with a repeat pattern, say 4 wide by 2 high for 8 animation frames. So far so good.

But let's say you don't want the whole cylinder. You just want a pie-shaped slice of it, say a quarter of the way around. So you use the path cut to select the part from 0.0 to 0.25. That gives you the piece of the cylinder you want , but now you only see the leftmost 1/4 of the texture. To see the whole texture, you change the number of horizontal repeats from 1 to 4. This works fine; the other three copies of the texture are on the parts of the cylinder that have been path cut away, so you're left with what you expect.

Now say you want to animate the texture by displaying those 8 frames I discussed earlier. In a script you drop in the prim, you do:

llSetTextureAnim(ANIM_ON|LOOP, 1, 4, 2, 1.0, 8.0, 1.0);

to turn on the animation in loop mode, on face 1 (the outside of the cylinder), for a 4x2 matrix of frames, starting at frame 1 for 8 frames, changing at one frame every second.

This works fine if you're animating the face of a cube, or the whole cylinder, or anything else where you have let the texture repeats per face default to 1 in each direction and the offset default to 0. Otherwise, it ignores the values you set, and so the quarter-cylinder in my example only shows the leftmost quarter of each frame.

The fix I'm working on fixes this case so that the repeat and offset values you specify on the prim are honored wihtout any other fiddling.

The problem I'm asking about comes along when you specify ALL_SIDES instead of face 1 (or whatever). That prim can have different numbers of repeats per face. If you specify ALL_SIDES in the llSetTextureAnim() call, what's the right answer? Do you ignore the repeats and offsets as is done now? Do you apply the values from one face, and if so which one? Or do you do it separately for each face on the prim? That's feasible, but it might eat up a lot of horsepower if there are many prims with ALL_SIDES being animated in a scene.

Note that you can only have one llSetTextureAnim() in effect for a prim, so you can't have one side animated with a 4x2 sequence of frames and another with a 3x3, or even a 2x4. Changing that would not only be even more expensive, but require server-side changes that are well out fo the scope of this fix.

[Qie Niangao]

If I guess correctly about the motivation of the request, the case most likely to arise here is that of SMOOTH animation (simple sliding, not with SCALE nor ROTATE), as much as the default cel animation. Take the case of a hollow waterfall prim, say, with the hollow face and the outer face both animated (using ALL_SIDES). Imagine that some builder wants to use two halves of the same texture for these two faces, by scaling to .5 and offsetting by .25 and -.25, then animate them both. (IIRC, these would have to be vertical halves because SMOOTH animation slides across the X axis.)

If I'm guessing wrong about this, I hope somebody will correct me.

[Toysoldier Thor]

Yes Tonya - what Qie said.

Your description of the issue was very insightful.  I didnt know there were limits to the animation of a prim.  But you had my head spinning on the description of the animating of a Cylender.

For many of us that have complained about this bug over the years, the bug is more simple.  So can you explain to me the root cause behind what I was seeing - as well as many others....

-  I rez a SCULPTY prim.  It had 1 texture surface.  (a waterfall shape)  and its a tall sculpty

-  I apply a seamless water texture (512x512)

-  I set the single texture surface of the sculpty to 4:4

-  I insert the script with the llSetTextureAnim to simply smooth loop the texture so it slides across the surface

-  I remove the script from the sculpty

-  I stand there and watch the waterfall flowing well at the 4:4 repeat pattern and my viewer has no problem seeing it at the set 4:4

FASTFORWARD:

-  I  leave the area where the waterfall can be seen by my viewer (leave sim or even just far enough away that its outside of my viewer's ability to see the waterfall).

-  I come back and the waterfall returned back to the 1:1 repeat - still animated but looks terrible as it returned to the original repeat default.

 

How is the bug you are talking about causing this to happen?

[Tonya Souther]

I'm not sure I understand what you mean by setting the texture surface of the sculpty to 4:4. Do you mean to set it to 4 repeats vertical and horizontal on that face? Or do you mean you have an animation that's a matrix of 4x4 cels?

What's the call to llSetTextureAnim() you use in that temporary script?

In any case, I think it's happening because the animation definition inside the viewer for that prim is reset when you get back in view of it, and the object update from the sim to the viewer sends the parms again - and overwrites the correct ones wiht repeats of 1 in both directions.

[Tonya Souther]

Crud. If so, that's going to make life more complex...but if it's a common use case, then I'll need to handle it correctly. Thanks.

[Toysoldier Thor]

---

Tonya Souther wrote:

I'm not sure I understand what you mean by setting the texture surface of the sculpty to 4:4. Do you mean to set it to 4 repeats vertical and horizontal on that face? Or do you mean you have an animation that's a matrix of 4x4 cels?

What's the call to llSetTextureAnim() you use in that temporary script?

In any case, I think it's happening because the animation definition inside the viewer for that prim is reset when you get back in view of it, and the object update from the sim to the viewer sends the parms again - and overwrites the correct ones wiht repeats of 1 in both directions.

---

I mean horizontal:vertical repeat.  That is the critical aspect that is bugged.  My use of llSetTextureAnim never involves cells.  Its all about the more simple model that Qie mentioned.

Here is the exact little script I use and provide to my waterfall/river sculpty customers....

 

float waterspeed = 0.02;

default

{    

    state_entry()    

    {      

          llSetTextureAnim(ANIM_ON|LOOP|SMOOTH, ALL_SIDES, 0, 0, 0, 0, waterspeed);    

    }

}

 

[Tonya Souther]

Thanks. As it happens, I think my fix will fix this case too, but I'll be sure to test.