Fastest way to update texture offset?

[Eric Stuart]

Working on something that basically fakes a scope into a map with a second linked object at a lower texture scale, one that when you sit on an object you can move it around, got everything going fairly smooth using input controls.  However, I've tried a few options to get the texture offset to be more precise, or update faster, and it's still choppy.  I've tried setting the timer to different variable rates, tried it without a timer, and I'm not sure if I've found the fastest option and it's just going to be choppy because of how fast SL updates.  The movement and input itself is not choppy so I don't think that has anything to do with it.  I've tried setting the timer to 0.01 as I think that's the fastest it can be, but it's still only registering about 8 to 10fps and when you have smooth movement but the texture can't keep up, it's very obvious.  Here's the current portion involving the offset update.  Any input would be great.  Thanks!

    timer()
    {
        if (moving)
        {
            scopePos += velocity;

            if (scopePos.x > 1.0) scopePos.x = 1.0;
            if (scopePos.x < -1.0) scopePos.x = -1.0;
            if (scopePos.y > 1.0) scopePos.y = 1.0;
            if (scopePos.y < -1.0) scopePos.y = -1.0;

            list textureParams = llGetLinkPrimitiveParams(2, [PRIM_POS_LOCAL]);
            vector texturePos = llList2Vector(textureParams, 0);
            vector scopeLocalPos = <0.0, scopePos.x, scopePos.y>;
            llSetLinkPrimitiveParamsFast(3, [PRIM_POS_LOCAL, texturePos + scopeLocalPos]);

            vector offset = <-scopePos.x / 2.0, scopePos.y / 2.0, 0.0>;
            llSetLinkPrimitiveParamsFast(3, [PRIM_TEXTURE, ALL_SIDES, textureUUID, textureScale, offset, 0.0]);
        }
    }

 

Edited August 16 by Eric Stuart

[elleevelyn]

when wanting textures to animate smoothly instead of using a timer then you might look into https://wiki.secondlife.com/wiki/LlSetTextureAnim

 

[PheebyKatz]

I'm not sure if the OP is asking about actual animation settings, like looping or rotating or pingponging, but if so, the above is seconded, because yeah, texture animating.

This feels more though like a case of someone wanting the texture to animate in response to external input, which would require far more control. It makes sense to do it using a method like what they're already using in that case.

I know that llSetLinkPrimitiveParamsFast isn't as fast as might be desired, especially when it's being called a lot. I'm not sure if it's one of those functions that sleeps for tenth-of-a-second intervals, I just know that it's not as fast as I would like for some things, at least when it's being used more than once or twice at a time.

I don't know if it'd help with speed, but I tend to declare variables universally, up above the rest of the script, even if they have to be set to "" at first. I figure it might not make that much of a difference, but the script only having to scan, say, the word "vector" twice on initializing/resetting, and not 20 times per second while running, might conceivably speed things up, if only a tiny (microscopic, probably) amount.

I'm sure someone has way better answers than anything I can offer, but hey, it's something to read while waiting for the heavy hitters to reply.

 

Edited August 16 by PheebyKatz

[Qie Niangao]

There could be a single call to llSetLinkPrimitiveParamsFast() that updates both PRIM_POS_LOCAL and PRIM_TEXTURE parameters. That's to minimize the number of separate object update messages the sim needs to send to all the viewers watching the scene. It'll still be "choppy" because it's a network trip from server to viewer (and the viewer may have other things to do besides update this object).

To really make the texture move smoothly, @elleevelyn's suggestion of using texture anim wins because it operates strictly viewer-side, avoiding that object update messaging from the server until the animation needs to change. So if the texture offset were the only dynamic, you might set the texture animation corresponding to the velocity and it would be very smooth, but here you're moving the link around too, so I doubt it would be a win for the texture to move more smoothly than the surface on which it's painted.

Some code tweaks might make it imperceptibly faster, like embedding inline calculations instead of assigning intermediate results to variables that then need to be referenced in the dependent calculation, but that makes it harder to read and debug. An even less impactful change, but one I'm too OCD not to suggest is a couple of else clauses: scopePos.x can't be < -1.0 if it's already known to be > 1.0, and same for .y. Also, personally, I might use a global variable to store the value of link #2's PRIM_POS_LOCAL wherever it gets updated, rather than get it from the prim each time I need it, although that's not really all that different (and would be a mistake if link 2 moves around more often than this timer fires).

(Oh, in passing: you mentioned setting the timer to 0.01 because you think it's the fastest it can be. It doesn't really matter, but a timer won't fire more than once per simulation frame, and the simulator runs at 45 FPS, so that's 0.0222… seconds minimum. But yeah, even if your script were scheduled every frame, it may not get around to running every expired timer event.)

[Eric Stuart]

So, this isn't an animation per say, it's a reaction to movement and resetting the offset based on where it's positioned.  So it's meant to emulate a sort of magnifying glass over a texture by having a zoomed-in appearance and doing the math to change the offset as you move the magnifying glass around.  The magnifying glass updates it's texture it shows based on it's X/Y (technically X/Z?) position.  You sit on an object, it moves the camera to the map, and your WASD input moves the magnifying glass around to the edges of the map.  The movement of the glass is smooth and the texture offset changes seem fairly precise, but the offset updating is very jittery, only about 10-15fps at most.  I wasn't sure if animation would work with that as it'd need to be reactive to the movement to match it's location with the texture and it's offset.

I was under the impression llSetTextureAnim was more for things like flip-book style animations.  Is there a secondary usage that would affect the texture offset faster?

Edited August 16 by Eric Stuart

[Frionil Fang]

You couldn't animate a texture to scroll in 2 dimensions anyway, scrolling is limited to one axis.

I'm guessing the disconnect is that object position changes are interpolated by the viewer, but texture offset changes aren't. I made a small dummy object to test a similar effect and sure enough, texture offsets change in a noticeably more jarring manner, here's a clip: left window is an alt controlling the object by clicking around on it, right window is the main view with the object selected to prevent interpolation (I can't find any interpolation option that would prevent child prim movement interpolation, other than having the object selected).

https://i.gyazo.com/512612411e506db67ddcd3ab16454b8f.mp4

The left side has the movement slide smoothly and the texture updates feeling disconnected, the right side is non-smooth movement but the texture updates are in perfect sync.

[Eric Stuart]

If I'm understanding then, there's no real way to get it smooth based on input movement?  I'm stuck between having one or the other?

[Qie Niangao]

I think it's worse than that. As @Frionil Fang rightly points out, there's no way to use smooth texture animation except along one dimension of the texture, so for your purposes it's simply impossible to have smooth viewer-side texture motion. But what's even worse, you can't not have smooth object motion (at least I, too, don't know a way to prevent that interpolation), and if that's correct then the texture can't avoid jittering on the more smoothly moving object surface.

[Quistess Alpha]

8 hours ago, Qie Niangao said:

you can't not have smooth object motion

True, but object parameters don't interpolate. For the specific case of a square texture, clever skew and taper parameters of a box prim can move a face within a limited range of motion without interpolation.