Jump to content

Avoiding script lag with animated mesh.


You are about to reply to a thread that has been inactive for 1536 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

If I were to use a script to animate a mesh on an endless loop would it constantly communicate with servers. For example: I want to upload several meshes and animate them but not with transparency. But I wonder, does the script communicate with the servers and sync with every call. I kinda find that a little unnecessary, I would like the script to call and sync with the server with every so much frames. Does this make sense? :smileyvery-happy:

I just worry about someone taking one of my animated meshes and making a ton of copies and each one unfortunately communicates with the servers creating lag.

Can I run a script, have it sync with the server at the start of the animation and not call on the server until the animation starts the loop again? Hopefuly I'm making sense.

Link to post
Share on other sites


RipleyVonD wrote:

I want to upload several meshes and animate them but not with transparency

What does this "animate" mean, specifically? What are these meshes supposed to appear to be doing, "not with transparency"?

There are purely viewer-side forms of animation, notably texture animation, that do not lag the servers (nor the network) at all once started. That can be a very efficient way to get frame-by-frame (cel) animation, but of course that very much is "with transparency" built-in to the texture(s) to be animated.

If, in contrast, "animate" means translating linked meshes around with respect to others in the linkset, yeah, that's gonna use some sim processing and send a big fat stream of object updates through the network for as long as the animation plays.

If "animate" happens to mean moving whole linksets around, Key-Framed Motion is somewhat less sim processing than other kinds of scripted motion, but still sends a bunch of updates over the wire.

Link to post
Share on other sites

Right Cerise, it would be for a mesh object not an avatar.

Qie by animating I mean, I would upload for example 5 low-poly meshes.

1- I would align them together

2- Shrink all of them by 4 times their original size

3- Drag the link set underground so you can't see them

4- Unshrink a mesh for half a second or so

5- Reshrink and start on the next mesh.

This would create a flipbook effect just like switching transparency on or off, but you wouldn't have the burden of transparency compositing. The only thing to watch out for is poly count and script lag, at-least from what I think I know about scripts.

I haven't actually tested this and couldn't find info on the web on doing this, but theoretically it should work.

 

Link to post
Share on other sites

That strikes me as a lot more work for the servers to do than simple alpha switching would be.  Changing the size and position of an object takes more work than making selected faces transparent.  As long as you are using low poly meshes and take care with how you make your LOD models, you should be able to stack a half dozen versions of your object in a low L.I. linkset and then "animate" them by making one after another visible.  I've done that several times without seeing any appreciable load on the region.  Obviously, results will vary depending on the size and complexity of your mesh and on how long you plan to animate them.

Link to post
Share on other sites

Okay, that's indeed frame-by-frame animation, just with a bunch of extra work to change the scale and position of the component meshes. I don't expect that would have any advantage over flipping transparency -- although to save rendering complexity you might try not using llSetAlpha() to change transparency, thus forcing alpha blending, but rather switching to an all-alpha texture when hiding an element. That's a little longer update message (a key instead of a float) but it should speed rendering. You could also try adjusting bit masking threshold to toggle the visibility of a 32-bit texture, but that adds some initial download cost for caching that texture compared to 24-bit, and (at least) Lumiya doesn't seem to notice the masking threshold updates; not sure if other viewers miss them too.

Again, though, if there's only a few steps of animation, you can make the whole process run viewer-side by using llSetLinkTextureAnim to cel animate a mostly-transparent surface texture. This is simpler to keep synchronized using separate faces of a single mesh, but I've done it with multiple links (and even unlinked). It however does require larger textures for the same visible resolution, because they'll necessarily be sparsely populated.

Link to post
Share on other sites

I forgot to mention the the only thing looped by script is shrinking or unshrinking.

 

I would align them together (without script - when preparing object)

Drag the link set underground just a bit so you can't see them shrunken (without script - when preparing object)

The following steps are after an object is rezzed on the ground

0- Shrink all of them by 4 times their original size (with script once - not looped)

The following steps 1 - 10 are the only steps looped by script

 1- Unshrink mesh 1 (0.5 sec)

 2- Reshrink mesh 1.

 3- Unshrink mesh 2 (0.5 sec)

 4- Reshrink mesh 2

 5- Unshrink mesh 3 (0.5 sec)

 6- Reshrink mesh 3

 7- Unshrink mesh 4 (0.5 sec)

 8- Reshrink mesh 4

 9- Unshrink mesh 5 (0.5 sec)

10- Reshrink mesh 5

 

Hopefully that's a clearer explanation. The timing can vary depending on what the animation is for 0.5 sec is only an example

 

My concern using transparency is a creator can be careful about about poly count, but the owner of the object might want to create a dozen copies of the same object for example animating flowers or grass and the transparency compositing increases dramatically. That's where I think shrinking an object can help avoid that.

 

(spelling edit)

Link to post
Share on other sites

... a dozen copies of the same object for example animating flowers or grass and the transparency compositing increases dramatically. 

If "transparency compositing" means the rendering impact of combining overlapping transparent surfaces, that only really happens when those surfaces are set to "blend" their alpha components.

It may be that your application for some reason needs alpha-blending, but that's really to be avoided whenever possible.

I could ramble on about this for hours, but let me just drop a little script here (under the spoiler tag) to demonstrate the effect. To play with this, rez a fresh cube and either wear it or use a sandbox with lots of spare prims. Then select it and choose "More info" in the Build Tool's land impact text, then watch what happens to the "Display" weight when you touch the object to cycle through the alpha settings. (Probably best to keep it selected throughout because otherwise there are some modes where it gets pretty hard to find and touch -- which may be a win for such object animation.)

integer alphaState;list BLANK = [ PRIM_TEXTURE, ALL_SIDES, TEXTURE_BLANK, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0 ];list TRANSPARENT = [ PRIM_TEXTURE, ALL_SIDES, TEXTURE_TRANSPARENT, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0 ];list AMODE_NONE = [ PRIM_ALPHA_MODE, ALL_SIDES, PRIM_ALPHA_MODE_NONE, 127 ];list AMODE_BLEND = [ PRIM_ALPHA_MODE, ALL_SIDES, PRIM_ALPHA_MODE_BLEND, 127 ];list AMODE_MASK = [ PRIM_ALPHA_MODE, ALL_SIDES, PRIM_ALPHA_MODE_MASK, 127 ];list TRANS_0 = [ PRIM_COLOR, ALL_SIDES, <1.0, 1.0, 1.0>, 1.0 ];list TRANS_100 = [ PRIM_COLOR, ALL_SIDES, <1.0, 1.0, 1.0>, 0.0 ];default{    state_entry()    {        // Make complex enough geometry for stark effect from alpha        llSetLinkPrimitiveParamsFast(LINK_THIS,            [ PRIM_TYPE, PRIM_TYPE_TORUS,                PRIM_HOLE_DEFAULT, <0.025, 1.0, 0.0>, 0.95, <1.0, -1.0, 0.0>, <1.0, 0.5, 0.0>,                ZERO_VECTOR, <0.02, 1.0, 0.0>, ZERO_VECTOR, 1.0, 0.0, 0.0 ]);    }    touch_start(integer total_number)    {        if (0 == alphaState)        {            llSetLinkPrimitiveParamsFast(LINK_THIS, BLANK + AMODE_NONE + TRANS_0);            llOwnerSay("Alpha mode = none, Transparency % = 0... Display weight should be 894            That's just basic opaque, no-transparency rendering cost of the object");        }        else        if (1 == alphaState)        {            llSetLinkPrimitiveParamsFast(LINK_THIS, BLANK + AMODE_BLEND + TRANS_100);            llOwnerSay("Alpha mode = blending, Transparency % = 100 ... Display weight should be 2784            That's the most common \"transparency-flipping\" technique, same as llSetAlpha");        }        else        if (2 == alphaState)        {            llSetLinkPrimitiveParamsFast(LINK_THIS, TRANSPARENT + AMODE_NONE + TRANS_0);            llOwnerSay("Transparent texture, Alpha mode = none, Transparency % = 0... Display weight should be 894            That's another flipping technique, using a transparent texture");        }        else        if (3 == alphaState)        {            llSetLinkPrimitiveParamsFast(LINK_THIS, BLANK + AMODE_MASK + TRANS_0);            llOwnerSay("Alpha mode = masking, Transparency % = 0 ... Display weight should be 894");        }        alphaState++;        alphaState %= 4;    }}

(Obviously it would be cleaner if the script could actually measure that Display weight, but AFAIK a script can only get that weight as it affects the whole avatar's rendering complexity, and that would entail more bookkeeping than I'm motivated to do just to demo a concept)

The point is that it's not necessary to worry about the rendering cost of transparency-flipping if you do it the right way.

(I'll just give one last pitch for texture animation as an ultra low-cost way of effecting this transparency-flipping, if the animation steps are few and the textures are small and alpha-maskable.)

Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 1536 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...