lighting screwed up

What's up with SL's lighting? Besides prims getting bright when the camera is focused on them, or if selected, moved, or, hell, breathed on wrong, now prims aren't responding to flickering lights. I use a flicker light (turns off and on at random intervals) for my fires and it used to cause prims (and avs) to flicker. Well, avs still do (and attachments) but not prims by themselves. Prims take longer for sim light changes (day-night light cycle) too and I'm having to select prims or move the camera closer to them before they wake up and adjust their reflection accordingly. It seriously kills the immersion! Please fix SL's screwed up lighting--it gets worse with each build!

Okeydoke Eep... is this with Local Lighting and Shadows on, or does that not matter?

Any good pictures? Or video footage, even?

I'm curious about what's going on here.

Well, local lighting on, obviously, and the darker (lower nighttime brightness slider all the way left) the more noticable this bug is. With shadows off, it doesn't appear to happen so it has to be a shadow calculation lag issue. Shadows also get screwed up along terrain cell grid lines. I took a screenshot when I submitted the bug report but here's another:



Moving the camera closer to dark parts (day, or light parts at night) usually causes the prims to fade to the correct light reflection intensity, but sometimes I have to select/click the object for it to trigger the fade.

Ah yes--alright, reason why I asked about Local Lighting is that some have remarked about the "terrain cell grid lines" without it on, which I've seen when changing day to night very fast via Mouse Moves Sun. But that's usually transient and doesn't stay, and the effect does compound when Local Lighting is on, and there's light objects with extra ambient glow.

I have had similar appearance problems with Shadows off.

There appears to be a whole bunch of compound problems related to having Local Lighting on right now, including this very reproduceable one.

That does sound related to the known issue:



albeit a variation on the theme. But yeah, I've seen this too...

Local Lighting (as much as I love the glow!) is in a quagmire because of things like this.

I have associated pictures from awhile back.

Well, in the above scene are only 5 light sources. In previous SL builds, if there were more than at least 8 (but I think like 10 but not sure) light sources, the terrain cell grid lines would become apparent and any more lights would look lit but not cast any light. This is a hardware lighting limitation, as I understand it from my experience with Active Worlds (AW) hardware lighting. There are issues in AW with OpenGL lights that may be present in SL and, thus, contributing to the lag:


Do you know if this is true for SL's OpenGL hardware lighting? I've heard SL's lighting is software/CPU-based but I don't see how that can be the case since video cards have supported hardware lighting for years now... However, perhaps it is the case for SL, as in AW, that:


SL could learn some things from Active Worlds' lighting, which is all client-side. Just look at all those options that, mostly, aren't possible in SL. I made a flicker light in SL but because the server has to get in the way, lagging the light flicker and making it look like it's fading in and out on the terrain while the prims are, correctly, getting flickered (before this recent bug anyway).

SL may want to look into supporting Direct3D which seems to be able to handle lighting better, among other things...

SL could also benefit by having more client-side effects instead of relying on the server for most things like llOffsetTexture which could have a server-side only option since it's not usually necesary for texture offsets to be in-sync for everyone, but I'll leave that for another thread...

From what i've gathered, local lighting is software based, basically due to the 8 light source limit of opengl, when used without local lighting turned on sl can use upto 8 light sources, not sure how many they actually use, but i thinkg the sun/moon as well as ambient light count for 3.

Local light so i've been told is procuded using raytracing thus why its quite cpu hungry, although compared with the time a raytraced image would take minutes to render things have come along abit as multiple frames per second can now be achieved.

But if OpenGL can support up to 8 hardware lights, why would SL's local lighting, running under OpenGL, be software-based? That's just silly. With local lighting turned off, why would there be additional light sources beyond the sim's single sun/moon (only 1) light source? That doesn't make sense either. Light sources shouldn't include ambient light (which is dispersed evenly throughout the sim) but only directional lights (point in parallel throughout the entire sim, as from a sun) and point lights (as the "light" material type emits).

Who told you these things about lighting? I'd like to talk to them directly...

As i said in my above post, its software based because it uses raytracing to provide more than the 8 light sources.

There is not one individual i have got this information from but over the months of all the previews i have done you get to learn bits and pieces here and there, if you go into preview and find a bug and report it, if they have the time they may respond to a report

Well, perhaps it would be better to render the first 8 lights in hardware and use software for more with raytracing.

I would be happy if there was an option to turn on the closest 7 (or 5, or whatever is left over after the sun and ambient light is taken care of) light sources with HARDWARE lighting and render the rest as full bright.

That would allow me to use lights inside my house. I don't care if that means I can't cast a bat-signal on the clouds or whatever people are using distant lighting for, I just want a lamp I can turn on.

Actually, I have been noticing problems with ambient light levels and prim/terrain coloration even with all the lighting options turned off!

I have a low end system, a Mac Mini that just barely meets the minimum performance specs for SL. So I don't have local lighting, shadows and all that good stuff turned on. At dusk and dawn especually, I've noticed that both prims and terrain segments are illuminating very unevenly, until you focus a camera on the offending place. Like two prims with exactly the same texture and orientation, side by side, and one is very much darker than the other. It's very annoying! And this is in a sim that only has me in it, not someplace so laggy that I can't move.

OpenGL doesn't support a maximum of 8 light sources, it supports a minimum of 8 light sources - often many more with good efficiency. And we're just talking about the old fixed-function OpenGL pipeline; with vertex shaders of various flavours including the modern GLSL, lighting gets considerably more flexible (with another step up to properly utilizing fragment shaders things get yummier yet again).

The generally tardy updates of lighting (with your fake flickering effect etc) you're seeing are, I'd guess, due to spotty updating of a mesh lighting cache introduced to mitigate the cost of SL's IMHO quite slow, unnecessary, and unnecessarily slow software lighting model.

But SL's lighting didn't used to be THIS bad. My flicker light used to affect everything around it--even the terrain but the terrain stopped responding to it (unless the prim/object the flicker script was on was moving) and now ALL prims do after they are deselected or don't have the camera focused on them (after they highlight--entire object if root prim focused on--then return to normal).

Who knows when it was made worse but LL isn't adding everything they change to the release notes--that's for sure!

SL's lighting needs SERIOUS work!