What are the main tips on light interference?

Hi, I cannot find a good reference that covers various situations on the interference / combination of lighting from different models.

For example, I recently found the glow from one object built by someone appeared to be causing a lot of white-out inside a nearby building built by someone else. It was told " you need is a TGA rather than PNG texture bewteen them".

So, in this case, what are the recommendations on how to deal with one modeller's lights affecting another's creations?

Also, there does not seem to be a good reference covering how all the different lighting combines/interferes. I have pieced a fair bit together, and as I understand computer graphics I can follow what they say (e.g. about glow being done as a vertex shading pass).
however, there does not seem to be a straight forward reference covering all the lighting methods and issues in SL.

Glow is really the only nasty one in the bunch, and it is truly evil. It is not only garish, it penetrates any 32-bit texture. If the setting is very high at all, it creates a painful white-out, as you have noticed. You can screen it by putting a 24-bit texture in your line of sight. The best solution, though, is to just avoid glow like the plague and hope that your neighbors do as well.

Incidentally, it makes NO difference whether you create a texture as PNG or TGA (or JPG for that matter). When SL uploads it, the texture is converted to JPG2000 format anyway and has no memory of what it used to be. One potential problem, relevant to your question, is that it is VERY possible to create a PNG texture that is saved in 32-bit mode by accident, while you can never do that with a TGA texture. A mistaken 32-bit texture might create alpha sorting problems for you when you least expect it, or might fail to block that nasty glow.

There are certainly other lighting quirks to be aware of, but they aren't problematic usually. Just odd.

[EDIT]Rolig beat me to the punch, and said it much more succinctly than I did. Oh well, can't win 'em all. [/EDIT]


So you understand, glow and light are two very different things. But you seem to be referring to them synonymously, which is a little confusing.

When an object emits a glow, the renderer just draws a bright halo around it. It's a post-process effect. It's got nothing to do with lighting at all.

When an object emits light, it will affect the apparent luminance of all other objects around it, within its radius of effect.

Set an object to cast a red glow, and all you get is that one object glimmering red. Set it to cast red light, on the other hand, and the entire area will turn red.

If the object you spoke of had the power to wash out the coloring inside a nearby building, then it must have been emitting light, not just glow. That is, unless your description of what actually happened is in need of some clarification, which very well could be the case. Did the object actually overpower the ambient lighting, or was it just that you were able to see through the wall, to observe the glowing object from the other side?

If it's the latter, then what you observed was a draw order problem in the renderer, not an actual lighting effect. Glow and transparency, unfortunately, don't mix too well in SL. They're not rendered by the viewer in a good timely fashion to coincide properly with each other. The end result is glow appears to shine right through any 32-bit textured surface.


Regarding the PNG vs. TGA thing, either whoever told you that didn't really understand what they were talking about, or you just didn't understand what they meant. I'll explain.

It's not the source file format that will make the difference; it's the bit depth. Put simply, 32-bit textures have transparency in them, and 24-bit textures don't. And as we discussed, glow and transparency don't play well together in SL.

Here's where PNG vs. TGA comes into play, in this regard. PNG is a format that happens to support multiple forms of transparency. As such, accidental 32-bit textures are generated from that format fairly often. If so much as a single pixel is less than 100% opaque, the entire texture comes out 32-bit. An image with just 1% transparency in just one single pixel might well look totally opaque to the human observer, but as far as the computer is concerned, it's all or nothing. There's no "close enough". If it's got any transparency in it all, it's a transparent texture, a 32-bit texture.

TGA, on the other hand, only supports one form of transparency, alpha transparency. To get a 32-bit texture from a TGA file, the image has to contain an alpha channel. And in most graphics programs, it's nearly impossible to add an alpha channel by accident. If you didn't deliberately put that extra channel in there, then the resulting texture is gonna be 24-bit. There's almost no margin for error. Accidental 32-bit just doesn't happen with TGA (extreme absent mindedness notwithstanding).

So, what that person most likely meant to say was not just, "you need a TGA rather than PNG texture," but "you need a 24-bit rather than 32-bit texture, and a surefire way to make sure you have that is to source it from TGA rather than PNG."

But that doesn't mean sourcing a texture from TGA will automatically solve the problem, or that sourcing from PNG will automatically create the problem. If the texture comes from a 32-bit TGA, then it's a 32-bit texture, end of story, just like it if had come from a not fully opaque PNG. And if you're exceedingly careful with PNG not to introduce any transparency, then the texture will be 24-bit, just as if it had come from a 24-bit TGA.

If I've been talking over your head, and you need to know more about bit depth, alpha channels, etc., in order to follow me, read the stickied guide to alpha transparency, at the top of the Texturing Tips forum.

Thanks Rolig, that helps, I'll watch for the 32bit thing. Tho I generally stick to jpegs and TGAs.

I think there is a bit of basic etiquette here as well, like if you build some thing large and with high glow it can cause 'light pollution' grief for other modellers.

re alpha sorting, Rolig, do you know anything about the algorithm?
I have noticed if I have two transparent faces parallel, one with tranparency and the other with a TGA containing transparency, then if i stand facing the nearest and rotate my view the two will swap front/back even when inches apart.

yeah I understand glow is done in a late vertex shading rendering pass (at least that is some doco I found) but I have found no info on whether glow lighting is combined in an additive way with other light shading. I am assuming it is.


I think it is doing both. I had windows with low level of transparency and from certain angles blooms right thru. But this is from over 20m away (and light settings I see have a 20m limit) so I assumed it was from glow rendering not light rendering. this is apart from the sun/moon of course - which are more overpowering and have no range limit that I know of.



the latter- there was slight transparency on my windows ( with jpeg textures) and turing that off stopped the glow-through effect.


I quoted the person exactly but I think it was just not expressed that well.



no that's ok , I have a good background in graphics just needed to find some definitive documentation on what goes on with the rendering. had trouble finding the right details specific to my query.

thanks v much!

Standard lighting in SL is done via vertex shading. Glow is a pixel shader effect that was added into the SL engine render pipline mix later in it's development. The vertex shader based lighting is not affected by the presence of glow done via pixel shader.

You don't have to just take my word for it. You can test this yourself, scientific like, in engine by putting an object on a prim plane or right next to a wall and then cranking glow to max. Compare and contrast that to checking the light box.

Most of the lighting blow out I see is a combination of a couple of issues. First is someone just checking a light on and not adjusting a thing (contrary to the defaults, light isn't 100% white with max intensity in the real world). Second is objects reviving illumination with textures that have RGB values set too high. A good rule of thumb if you are developing textures or solid color values for lighting is to not go over 85% maximum (217 in the 8 bit colorspace of SL).

As to interference from traditional, non-glow, lights, there's a very helpful run-down of the priority in which they're rendered at /8/03/259102/1.html, and it's more complicated than you might expect.

Personally, I find light sources -- PRIM_POINT_LIGHT -- much more of a problem than glow because people tend to crank up the lighting in a misguided attempt to make the light source itself look bright -- which, of course, it won't, but it will illuminate everything in range. The light thus emitted goes through everything, 24 or 32 bit, and it's insidious because the source of the problem isn't obvious in the way PRIM_GLOW is. In consequence, you can easily mess up your neighbour's lighting effects because you don't realise that the small flickering candle in your house is throwing out a bright light for 20 metres in each direction.