lights: Direction / Occlusion culling

Well I don't really know OpenGL. I've read what I could but it looks rather disappointing. Am I right that there's no real way to limit the direction of light? Apparently light is always emitted equally in all directions. So things like spotlights are out of the question.

Another problem is that light passes thru anything. As long as an object is within range, it is lighted. Is it possible to have occlusion culling solve this? So if I'm behind a solid wall with no windows can the OC routine then decide not not to render the lighting object and hence it's light?

I know that the fact that SL has a non-fixed lay out makes it totally different from games that know in advance where the light will come from if you're in a certain area. Still the limits are quite tough once you compare the possibilities with the creative ideas.

Yes, no spotlights yet but the falloff value can simulate a spotlight.

If the light-emitting prim is within the occlusion box it will be culled and, hence, its light. However, the camera has to be really close to a wall for it to occlude prims close to that wall.

Yes, but, at least with occlusion rendering, SL is getting a bit more optimized. Could still use portal rendering for TRUE indoor space occlusion, however...

Autogenerating portals, especially for imprecisely-welded dynamic content, is hellahard. Not impossible, but I wouldn't blame LL for not bothering to try.

Well if they implemented CSG and changed the default action when linking so it became union (combining the meshes of two or more prims together) portal rendering would become simpler. At least, that's my perception of the process. No seams = easier to define boundaries.

It can but it's very limited to say the least:
The spotlight will send the light in 6 fixed directions. So you can't target and you 've got to deal with the "noise" of having the light go in 5 directions you don't want it to go.



I haven't really been able to get it to cull lights. Maybe it's possible but apparently not likely.

To be honest, the majority of lights you see around you can't be replicated in SL with the new system. Nobody is keen on seeing the light of the room below coming thru the floor in the room upstairs. Car lights that shine not only in front of you but also at the sides and the back aren't exactly useful either.

Speak for yourself, I know plenty of night time drivers who would like that feature. Makes it easier to spot those silly deer off in the brush before they jump in front of you. o.O;

Ray tracing would be necessary to block off lights from passing through prims. We would all love it in theory, but in practice it would probably mean we'd all need upgraded computers.

Spotlights are natively supported by openGL (light cone angle is controlled through GL_SPOT_CUTOFF parameter, the direction through GL_SPOT_DIRECTION) so there's no reason for them to not be in, really...

Thanks for that. With that in hand I found a more useful OpenGL resource and indeed this is obviously what I'm looking for. So can any Linden comment on our chances of getting more features for lights?

Since I can't log-in atm, I'm assuming that you can only make an entire prim a light-source? I'm just wondering, it would perhaps solve the directional lighting issue if you could optionally declare only a single face as lit? This would be an either/or, you can either light the entire prim, or a single face of it, multiple faces might not be pretty.

But anyway, this option would probably only be available for undistorted faces, ie you can only it to the side of a cube, if the cube hasn't been twisted or whatever. The shape of that side can then be used to create the light and restrict it to that area. The range can be used to to limit it's distance.
In this way, if you have a room building using simple cube walls, you can set a ceiling cube to have it's lower face as a light-source. Your room is 6m high, so you set the range to 6m, the result? That section of room is now lit, but only things under the ceiling are affected.

I don't know how it easy it would be do for more complex shapes (ie twisted prims as so on), but for the simple primitive faces it should be possible. While it's slightly more complex than a sphere calculation, it's not very much extra at all (a circle calculation to find things above/below a cylinder, ignore ones above if the face is underneath, then a distance to see if they are lit and how much.

This would make it MUCH easier to light most rooms without worrying about lights make it through walls, also provides you with more shapes than a sphere (which isn't good for uniformally lighting a square space).

Somebody asked about the lighting on the Q&A forum and this was the feedback:



Well I'm not really keen on learning OpenGL just to understand lighting but it does seem a bit odd that slight modifications to the current implementation would be very costly. For example you can use the falloff to limit the light and it will then send out spotlights in 6 directions. How hard would it be to allow us to reduce the directions? I guess that a light that only has to shine down or up is less work for the graphics card? That alone would be enough to get proper interior lighting.

I really hope some investigations are still being done for possible improvements. The lighting is fun but while lighting is now off for most people in 1.9 because it taxes hardware it will be off because off too limited use in 1.9.1. If my neighbour puts a light at the edge of his lot to light it I'll get it too even if that wasn't his intention, he can't help it.

I believe Steve's rationale is that because most users' computers aren't, seemingly, powerful enough to handle hardware lighting, adding additional light options would be futile since most people wouldn't use them. However, I don't agree with this assessment because SL's lighting has been messed up for so long it has forced most users to disable it. I say add the cone/spot lights now while you're in the code and it's fresh in developers' minds...

How easy is it to calculate cone areas in the same fashion as an llSensor() request? I know they use a sort of cone shape which (with a high enough angle) becomes a sphere. If that could be done it would be neat.
Even having semi-spheres (ie ignore everything above or below the object) would be plenty to give us lights that don't go crazy on surrounding buildings.

My fear is that while the lighting is sweet, it won't be well suited enough to the uses most people want to apply them to, or people will use them without taking into account the fact that it also lights objects through walls.
Similar with flex prims, they're awesome too but I can't apply them to anything I initially hoped they'd be good for, while still great they might not be used much except for a small range of applications.

The new lighting doesn't tax hardware -- at least not in the "nearby lights" setting. I have tried it on the two computers I use for SL, neither of which has cutting-edge video hardware (an NVidia FX5600 and a Radeon Xpress 200M, if you must know); the effect on frame rate is negligible. ("All lights", when it was available, was a killer; it seems to be grayed out in the current preview client.)

Hardware-accelerated lighting calculations have been around since appearance of first GeForce and Radeon cards, i.e. for ~6-7 years by now. Older cards may have problems processing more than 2-3 lights, but it's quite reasonable to presume nowadays if one's computer can run SL client to begin with, it'll also support hardware lighting.

On the subject of editing light parameters, i think it could be done nicely if there was option to mark a primitive as 'light definition'. Such primitive wouldn't be drawn itself, but simply define the actual position of light along with its colour and range, with optional light cone angle and direction if the primitive was a cone. Obviously, this would be option only for spheres and cones, but it'd make tuning the lights quite a bit easier and more intuitive (since you could literally see the area covered by light before the switch to treat it as light definition is checked, and animate it by animating the defining primitive)

Shirley, you're right but it seems a bit irrelevant in the current discussion.

As I said:
In 1.9 (current live version) the lighting is off for 99% of the people because it taxes HW
In 1.9.1 the lighting will be off because there's not enough oppurtunity to get rid of annoying side effects and the lights have too limited use.

As long as we can't control the direction or at least the spread of the light there's not much you'll be able to use it for.

Er, the GeForce FX 5600 and Xpress 200 are hardly "cutting-edge" video hardware these years. Regardless, "nearby lights" is only up to 8 total hardware lights, which hardly taxes decent GPUs (which yours is but, again, hardly "cutting-edge". Try setting lighting to "all local lights + shadows" and then see how well your "cutting-edge" GPU holds up. Dunno why it appears to be greyed out for you though; it isn't for me on my GeForce 6600GT...

Yea, I'm not sure why Steve Linden thinks hardware lighting is that taxing on current hardware, but it should be fairly trivial to add cone/spot lighting--especially if it's already built into OpenGL...

This isn't necessary since an existing prim can already be marked as a "light definition" (or, simply, "light". The lit prim can be made invisible but, unfortunately, is still rendered, but just use a tapered prism to use the least amount of polys in a prim.

Limiting lights to only spheres/cones would be annoying. However, a separate "light prim" could be added that would take on the shape of the light (sphere if point, cone if cone/spot, etc).

The light area can be seen in 1.9.1 and can be animated (scripted), though it would be nice to have a separate llSetLight function instead of ONLY being able to use llSetPrimitiveParams.

I'd like a "dimple" setting for the area lighting to make a half sphere or cone. Or more likely make the spot light such that it emits over a 180 degree angle. You could use that for wall lighting without disturbing nearby neighbours with unwanted lighting permiating their walls.

Aye, i was thinking of the former rather than the latter. That is, not to limit existing possibility to set any prim as light source, but rather to add this option to have 'light prims' that'd maybe make setting things up easier. But if the light area can be seen already, then it's probably not needed (as long as the option to actually have spotlights is put in somehow)