Animated texture across multiple meshes - sync issues?

[Ozwell Wayfarer]

I'm currently working an an animated river set and running into a roadblock.

Basically, I am creating the river in sections, so I need a script that animates the water sections without creating seams. In theory, this should be simply done with the following script:

Code: Select all

default
{   state_entry()
    {
        llSetLinkTextureAnim(LINK_SET,ANIM_ON|LOOP|SMOOTH,0,
            1, 1, 
            0.0, 1.0, 0.05
        );     
    }
}

And it works......at least initially. I apply the script to the root prim of the linkset, and all the faces animate as expected. No seams visible.

However, if I log out and back in, suddenly there are visible seams. This is also true if I go to another region and come back again immediately. So its not a "region restarting" thing.

Its been driving me a bit crazy, I thought for a while I must be making some error.

I dropped into SL to test and the script works 100% as expected there. So I suspect the issue is something to do with Opensim or Kitely specifically.

Is this a known issue? Does anyone have any ideas how I might get around this? I would be sad to have to shelve the project. Thanks!

[Ozwell Wayfarer]

Hi Ozwell,

Texture animations using this LSL function set a property for the texture on the server side (where the script engine runs) and are then handled purely by the viewer (where the rendering is done). There shouldn't be any difference in how the viewer renders the same texture asset in SL and OpenSim.

Does this texture look seamless when rendered in a non-moving grid inside the viewer?

[Ozwell Wayfarer]

Hi Ilan,

Yes the texture is seamless (or at least, in the direction that matters, the direction it will be scrolling). To emphasise: upon initial application in Kitely, the script works fine and no seams are visible. If the texture was not seamless to begin with, it would not work correctly the first time.

Like I say, I thought I was going mad for a while. Thinking that I simply had not noticed the seam previously and it must be my error.

But today I imported the exact same linkset of meshes I had been working on in Kitely over into SL and it worked perfectly fine and consistently. The actions in question (ie: leaving the region and returning or logging in and out) did NOT produce any anomalies.

Its hard to capture screenshots to illustrate the issue, but it should be replicatable with the above script, a seamless texture and two mesh planes.

[Ilan Tochner]

Does the seem look like a missing line from the intersection point but otherwise as you'd expect?

Does it look different depending on how far your camera is located from the texture?

Do you see the same problem if you create texture repeats on the same object face?

Does it happen when you do this on a simple cube?

Does it also happen with a different texture?

[Ozwell Wayfarer]

Does the seem look like a missing line from the intersection point but otherwise as you'd expect?

Yes - it occurs exactly at the point two meshes meet one another.

Does it look different depending on how far your camera is located from the texture?

No.

Do you see the same problem if you create texture repeats on the same object face?

No.

Does it happen when you do this on a simple cube?

Yes.

Does it also happen with a different texture?

Yes.

Strangely enough - today I logged in and all the meshes that were showing a seam last night displayed correctly. But I quickly logged out and back in again, the seams have comeback on SOME meshes but not others, even though the meshes in question are exactly the same meshes, running exactly the same script. The only difference between them is their physical location in my region.

I am beginning to suspect it has something to do with when the mesh physically loads into the "scene" or region. If there is a milliseconds delay between two planes loading, that seems to be represented in the animation of the texture. If I separate the mesh planes slightly, you can see the "gap" is just a millisecond or so.

The meshes are just a flat plane with a few subdivisions, so there is no way the geometry is somehow messing things around. They are essentially basic rectangles. I am 100% sure something funky is happening here.

1st login: https://ibb.co/drGp9CL - lovely, as expected.

log out and come back: https://ibb.co/YyXzSVp - clearly visible seam. Nasty and no good.

log out and come back - displaying correctly again! See picture 1.

I would be interested to bring this to the meeting tonight and see if other users can replicate it.

[Ilan Tochner]

Discussing this in the meeting is a good idea but it sounds like some rendering issue, which is something that should be brought to the Firestorm devs attention. Please open a Jira ticket for this issue in their system.

[Tess Juel]

Discussing this in the meeting is a good idea but it sounds like some rendering issue...

Texture animation is all done client side so yes, it is a rendering issue. But it's a known limitation to texture animation so it's not something that will be fixed and it's certainly not something the Firestorm developers can do anything about, it would have to be adressed by Linden Lab.

SL and OS simply do not have any mechanism to synchronise two animated textures and there probably never will be since adding such a feature would be a major undertaking for the developers. If two animations are started at exactly the same time, they may stay in sync for a while but sooner or later one of them will have a hickup and they're off. It's the same in SL so it was just a coincidence if Ozwell got it to work there.

But when it comes to a stream, do you really want it anyway? With some careful overlapping you can use it to create a little bit of variety in the water animation.

I suppose Ozwell is planning to make a modular stream kit so this is probably not relevant to him but for a custom fitted one you make it as a single mesh. The default max size for a mesh on opensim is 256 m and that should usually be more than enough. With some creative use of diagonals you can stretch a narrow strip like a river to about 440 m. Alternatively, if you have your own grid, local or online, you can change the max allowed size, upload there and export to where you need it.
You want to use a repeated texture for a stream that long of course but that's easy, just change your script to:

Code: Select all

default
{   state_entry()
    {
        llSetLinkTextureAnim(LINK_SET,ANIM_ON|LOOP|SMOOTH,0,
            0, 0, 
            0.0, 1.0, 0.05
        );     
    }
}

Or better, since we're not talking about a linkset anymore:

Code: Select all

default
{   state_entry()
    {
        llSetTextureAnim(ANIM_ON|LOOP|SMOOTH,0,
            0, 0, 
            0.0, 1.0, 0.05
        );     
    }
}

The point is that the x and y values have to be set to 0 to have smooth texture animations with repeats. Any other value and the repeat rate will defualt to 1.

(Edit: correcting a depressingly large number of stupid typos and clarifying a few points)

[Tess Juel]

At the Kitely Community meeting today Mike Lorrey came up with a possible workaround for the synchronisation problem. His idea was to reset the animation every now and then to keep deviations from accumulating. I'm not sure if it'll work but it's definitely worth a try.

Here's a modified version of the script he proposed, fixing a minor bug and hopefully adressing two objections Ilan had:

Code: Select all

default
{
    state_entry()
    {
	llSetTimerEvent(20);
    }

    timer()
    {
        llSetLinkTextureAnim(LINK_SET,ANIM_ON|LOOP|SMOOTH, 0, 0, 0, 0.0, 1.0, 0.05);     
    }
}

The timer will have to be synced to the animation speed or the animation will jump every time it's reset. In the example here, animation speed is 0.05 which means each loop takes 20 seconds, so the timer has to be set to a multiple of 20 (20, 40, 60 etc). In principle the higher you can set the timer the better but there are two problems if you set it too high. One is that the animations will be unsynchronized at first when somebody logs on and see them, they will only get in line the next time the timer event is triggered. The other is the obvious one: If the timer is set too high, deviations may accumulate before the animation is reset.

[Ozwell Wayfarer]

I can report that while it has improved things a little, seams do still appear sometimes. So I have decided that this set will be a new freebie with a "careful, might be glitchy" warning attached to it. I don't want it to hold me up any further (big list of other stuff I need to do), but it would be a shame to let the work go to waste. And it has been a community effort after all. Thank you to everyone who tried to help me solve this. It will be available for everyone to mess around and get frustrated with with once my inworld store is open again.