Do "Light Objects" Cause Server Lag?

I make signs. They are pretty good signs...

I use a simple LLSetTextureAnim command to run them. I already know from the Wiki that this particular command initiates a client side response and so inherently are NOT a cause of server lag.

However many mall owners now are telling me to turn off the "light" on my objects, as opposed to "wood". My signs don't look near as good when they are "wood".

So my question is this : " Does turning an object from "wood" to "light" cause server lag? Does it cause client-side lag?

I need a definitive answer that I can use to point to for mall owers.

Thanks.

I always thought light objects just caused lag with the client?

* edit * but only when local lighting is turned on. From what I've heard anyway.

I would agree that it is client side. Turn local lighting on.. and watch your game slow down when they are more then 10 avatars around. So i really dont see how making an object "light" from the drop down menu in edit.. can make the game lag...

I really think people mistake lag and their own cpu/ram/graphics card for the same thing...

Can a master scripter shed some light on this subject regarding a lit object causing lag

A Light prim will only cause lag on the client, not on the server.

That said, you should definitely check out what the sign looks like at night with local lighting on. It may look "nice" with the lack of shadows, but sometimes you'll find that when you turn on local lighting, you've got a ghastly looking greenish orange glow shining on everything or something equally horrendous.

Also realize that for each prim in your sign that is set to light, you're going to lag someone just that much more. So try not to use Light much if you can help it.

And remember to beg LL for a Self-Lit option that doesn't involve emitting light.

Objects set to PRIM_MATERIAL_LIGHT do not inherently cause appreciably different server side load. They don't cause server lag. However, on clients with the "Local Lighting" display option enabled, objects set LIGHT cast light upon prim faces within a radius determined by their size. For large objects, e.g.: signs, this can wind up being much of the sim and cause literally hundreds or even thousands of additional calculations. Per prim. A few of these in a sim crowded with objects (say, a mall) can grind even a powerful new PC down to 2-5 FPS, because in Second Life, local lighting is calculated entirely in software and NOT by that flashy new video card.

I have heard that one trick around this is to set prim face 0 to be shaded <0,0,0>, which causes it not to cast light even when set to the LIGHT material and large, but you still get that "glow" effect on the other prim faces, but without the lightcasting.

You can see the lightcasting lines by turning on local lighting and enabling 'light rays' (I tihnk, or something similar) in the debug menu of the SL client.

Just for the record : my signs are one complex texture on a single prim. So any one sign is just a box with a texture and the llSetTextureAnim command with proper syntax structure.

I don't use PRIM_MATERIAL_LIGHT. I just make the box LIGHT from the drop down box in the Object section of the single prim in the edit menu.

Single texture. Single Prim. Drop down box Light. Single line of code.

Also I dont ever use local lighting so will try that out sometime...LOL.

So will this cause server lag? Client Lag? No lag?

Thanks.

That does indeed work, Chromal! Basically, objects of MATERIAL_LIGHT cast light the colour of their side 0. I have no idea if making side 0 black reduces client-side lighting lag from the 'lit' object, though. It does let you create some really stupid effects, however, like a glowing red box that casts blue lighting.

If you still want your sign to be "lit-up" but don't want it to cast a glow with Local Lighting on, you can use what people call "self-lit prims".

The idea is that a prim will cast light the color of its top face (side 0). If side 0 is black, no light will be cast but the prim will still be lit up.

You can do this quickly by dropping a simple script into the prims you want lit:

default
{
state_entry()
{llSetColor(<0,0,0>, 0);}
}

In some cases (spheres, toruses (torui?)), the default side 0 is the outside; you can get around this by making discrete cuts (.01 or so) in the prim, creating a new side 0. You can also use other prims to hide large black faces.

Edit: Doh! I didn't read the above posts carefully enough, someone already explained this. But I hope this is still helpfull.

I just wanted to state for the record that these two "different" settings are one in the same.

"PRIM_MATERIAL_LIGHT" is a setting in the Scripting Language; and has the same effect as manually changing the 'Material:' drop-down box in the Prim Editor to "Light".

Take care,

--Noel "HB" Wade
(Tread Whiplash)

I wonder if a private sim owner would be willing to setup a bunch of light prims, and script them to change between side 0 being set to white, and side 0 being set to black, every several seconds, and see if it impacts client performance.

I tested, it does seem to effect performance. Independent tests would be good though .

intresitng, with local light on it can cause allot of client side lag. But for peope who don't use local lighting. not using allot of light primitives leaves rooms kind of ugly at night.

Id assume making side 0 black would make it not emit light, but still cause loss of FPS client side.. The lindens need to make a new material that is like light but doesn't emit light. (the emitting light part is what lowers client fps so much.)

don't assume, test, in my experience using the side zero black hack does improve your client fps. They do need to make a specific material though.

The non-emmisive side 0 trick does work. I have tested it extensively. Better still having a prim made of light with the non-emissive trick boots the contrast of the prim significantly for local-lighting enabled and disabled clients. I find that trick very useful for photographs and signage.

One way to get a qualitative view of the costs of emissive lighting is to enable Debug->Render->Trace lights. Your screen will be filled with red markers (ambient sources - the "sky" and green lines (rays from the ambient sources) and white lines which show the rays calculated from an emmisive source. Find a big patch of water, drop your draw distance down and you should see only red and green. Find someone with a diamond ring and look at the myriad rays cast by their one finger. Go into a typical club and notice that you cannot see anything but light traces for they fill the screen.

On a related note, I have found that light cast is proportional to prim size although I've not tested whether it is the size of side 0 or the volume of the prim that matters. Judging from the light traces, one large light source has considerably lower computational burden than many small ones. For interior illumination, you can often use the ceiling to good effect as a light source provided it is white (unless you want a color cast). Failing that, one biggish prim with a pure alpha texture on it (i.e. invisible) and phantomed can be placed just about anywhere as a convenient source. If you wanna get crazy, you can even color an invisible prim and it casts light of that color.

I hope these tips don't encourage people to use more light sources but instead use them a little more judiciously. A frame per second is a terrible thing to waste...

This was actually the basis for the lighting console I created not too long ago. I was using it to create many different colors of light from just a 3 button console. The console would rez a small sphere (about 1x1x1) in a specific color (either R,G or B), at a specific spot. The prims were invisible and phantom so people could walk through them, and if your rezzed two prims, say one blue and one green, it would give you cyan, using the basic principles of light color mixing. You could get any color in the visible spectrum that way, and it didn't cause too much lag on the clients computers from what i've been told by others. If you put too many prims out in more than one spot, then it could cause lag, but if there is many prims, stacked right over top of each other (I had 20 at one point with no really visible effects on my computer), then you can create any color in the visible spectrum. You can also get a cool effect by having a few spots out there, with a couple of different colors. And yes, the larger the prim, the more light it casts out. I believe this is all set up through the 0 side of the prim too.