Lag-free "Set Texture" Solution

[Rutherford Beresford]

I've got this really big prim... approximately 40m wide by15m tall.  On one face of this prim I want to display one of 14 textures "on demand", meaning I need the ability to pick and choose which texture displays and when.  I'm familiar with the LSL arsenal of commands and functions at my disposal so I know there are a number of ways to do this but...

The area in which this prim resides will be occupied by 50-100 avatars so the potential for lag is huge.  What's the most efficient, most lag-free way for me to communicate with this prim, telling it which texture to set so that the 50-100 avatars in attendance can see the new texture as quickly as possible.  The two things to consider are both how quickly the prim gets the message to change textures as well as how quickly the texture rezzes for all the world to see.

Any and all suggestions are welcome and encouraged.

Thank you!

Ford.

[Profaitchikenz Haiku]

The most common way to handle this is to have the textures which will be displayed on the face already visible to the clients, although on much smaller prims so that it isn't obvious that you are preloading them, Around your giant prim you place several much smaller prims, on which you have already loaded the 14 textures . Then when you command the giant prim to display a new texture, it is only new to the large display face, since it has already been *seen* on one of the smaller prims.

However, this mathod may create lag in that each avatar arriving has to load up the 14 textures, instead of one single texture. If these 14 textures are large (1024x1024) then the amount of data to be served out to all the avatars can be a source of lag in itself.

If the sequence in which you are going to display the textures is in anyway predictable then you can reduce the lag by showing on a smaller prim the next texture to be displayed. When this texture is itself moved onto the large display, the new next texture to be displayed is then preloaded.

If each texture is going to be displayed for a longish (60-seconds+) period before being replaced then I would suggest you only preload one or two textures.

If however you want to be flipping between any of the fourteen textures every few seconds, I would sugest you find a way to preload all of them on smaller prims.

I'd suggest you use llRegionSayTo if the prim is going to be instructed by another prim not in the linkset, but otherwise, llMessageLinked is about as quick as you're going to get. llShout risks chat-lag delaying the instruction.

I would make sure that there is no touch event in the display prim itself, as the number of avatars you expect to be present all touching the prim experimentally to see what happens could build up quite a queue of events to be processed. People forget that in a touch_start/end event, the parameter records the number of touches detected, and it can be greater than 1

[Rutherford Beresford]

Thank you for the wonderful feedback.  I will be displaying the images in sequence, and they will be displayed for approximately 4-5 minutes at a time.  So, with what you said about pre-loading, I was wondering if, perhaps, I could preload the "next" texture on the "back" side of the same prim that is currently displaying the image I want everyone to see on the "front" side?

I've never used the llRegionSay before but I do see that I can use a "secret" channel for communicating with the prim.  Will the llListen cause any additional lag if I code it thusly...?

llListen(intSecretChnl, "", llGetOwner(), strTextureName);

Thank you, again!

Ford

[Rutherford Beresford]

One more question, if I may...

Would using a HUD as the "Texture Controller" have any impact, positive or negative, on lag or on my desired results, if I were to use the llRegionSay along with an llListen?

Thanks!

Ford

[LepreKhaun]

Better would be llRegionSayTo as far as lag reduction. Otherwise, smaller textures will always win out over larger and keep in mind that a face set to an alpha of 0.0 (completely transparent) will work for preloading textures.

[Nova Convair]

All solved - just the "Lag-Free" in the title got my attention.

You load all 14 textures to everyone in the vicinity, even if they don't need it. That is what i call a resource waste - the opposite of Lag-Free - but in return you get a quick reaction on user input.

Nothing wrong with it. The LL servers are running and are greatly overpaid and you will need many resource wasters to produce a noticeable lag - so use 'em - just don't confuse this construction with something that will reduce lag.