The Key to Superior Lighting in SL: Unlimited Reflectivity on Textured Objects

SL is notorious for making textured objects look rather "flat" in bright daylight. This is because objects are not currently allowed to shine brighter than their texture values. You could take an object with a dark brown texture and put as many bright light objects around it as you want, and it will still be just as dark brown as the texture it bears. Light simply does not work like this in real life.

I propose adding a new material type that does away with this limitation (keep the old style for backwards compatibility and for signs that could otherwise become washed-out under this new method). If a dark brown textured object were to use this material, additional light would cause it to go from dark brown, to light brown, to tan-yellow, all the way up to white. In fact, this can currently be demonstrated using an untextured object whose color is set to dark brown.

I've included some comparison pics just to show what a drastic improvement this can make. Each image pair shows the same object twice, taken with the same camera angle at the same lighting angle. The first in each pair shows the object lit normally by the SL sun. The second shows a brightened-up version of the object dimly lit by the moon, to simulate the effect I'm talking about. Note that these images have not otherwise been doctored.

Nice job identifying this visual deficiency.

Very well done illustrating it with such a clever hack!


BTW, I'd love to see SL support a software rendering engine for rendering stills. Or a plugin to a radiosity engine. It's such a great building interface. It would be nice to be able to use it to bake lighting instead of having to go to a third party rendering package such as maya.

Yup. It'd be nice. But then so would proper z-ordering of 32bit textures. And hardware based local lighting. And... And...

Personally I don't see them fixing any of the issues with the renderer until we get the "2.0 renderer".

Oooh! Exporting a scene so we could import it into other software would be good, even without the textures.

Yes yes yes!!! I want all of that and then some! After having struggled photographing with local light (yuck!!!) for months, I'd really want something better. Local lights with it's bugs and limitations drove me so mad I had to stop photographing. Only two local lights plus the sun makes it a real challenge getting even a half decent light. But I've got an idea for a specific light rig now that together with Photoshop or PSP will give good results. In theory at least

Not to mention that coloring an object to match a textured object is impossible, because colored objects (as you note) do get brighter and brighter.

Indeed. When I first built my av, I kept wondering why lights caused my untextured colored hair prims to get bright while the rest of me (av skin and textured prims) stayed the same.

I believe what you're referring to is either diffusion or a form of specular highlight. Active Worlds (AW) has a similar problem but its RenderWare script (RWX) objects' surface settings (ambient, diffuse, and specular--before AW3) can be configured, unlike SL's. I believe an increase in SL's prim surface diffusion would create the look you want--perhaps with a hint of specular for highlight.

I didn't like when AW3 changed its lighting model with hardware lighting because of untextured polygons becoming brighter near light sources than textured polygons. But if, at least, the lighting was consistent (textured/untextured polys either not getting brighter or both getting brighter equally) it might not be that big of a deal--if the brightness could be controlled (how much the surface gets brighter relative to full white light, for example).

What I'm referring to is basically an improved version of the diffuse lighting SL already uses. Softening the diffusion would make everything appear more softly-lit, but it wouldn't increase the lighting realism like the method I suggested would.

Specular lighting works in much the same way SL's shiny effect does (it's a mirror-like reflection) -- if the current shiny reflection map were replaced with a single blurred spot of light, we'd essentially have specular highlights. Hmm, user-made reflection maps... that's not a bad idea, either!

What you are describing is Phong lighting. This along with user definable cubic environment maps vs the shiny would make sl a much prettier place.

http://en.wikipedia.org/wiki/Phong_lighting

Phong Shading Search results on GameDev.Net

I think this would be great.

Actually, I'm suggesting a sharper diffusion, not a softer one. A greater diffuse amount would add more contrast, not less. In AW I use(d) ambient .5, diffuse 1 and got a very realistic look:

On further research, it actually looks like you're describing pixel/vertex shading.

Based on that image, I guess you mean casting a smaller "spread" of light on an object so that large areas of it aren't lit at maximum brightness (which makes it look flat). That can help in some cases, and is in fact already possible in SL by setting a textured object's color to some shade of gray (or, for an untextured object, a darker shade of whatever color it's set to). When you look at an object in real life, though, there really is no limit to how brightly it can reflect. It's that limiting of the maximum brightness to the texture's values that keeps everything looking cartoony in SL (and I'm afraid even the AW snapshot you provided still looks cartoony to my eyes).

Vertex shading affects the positions of vertices, not how they're shaded (it's a bit of a misnomer in that respect). Pixel shading really refers to the general process of determining a pixel's color value, whether done through the video card's hardware or a "pixel shader" program running on the CPU or GPU. All I'm describing is a different formula for calculating the final color values for objects using that material type.

Um, no, I'm not saying a SMALLER ambient-diffuse difference but a LARGER one. "Sharper diffuse" = higher contrast = LARGER ambient-diffuse difference (the max being, in AW terms: 0 ambient, 1 diffuse, which makes the object completely black).

Well, SL has several material types but they have to do with mass and collision sound, not light. Whatever shading it is, one of those should do it more realistically than SL's current light calculation. It depends on the hardware, probably: and seeing as how most 3D chips support Gouard lighting, and not Phong or Blinn, yet most support shaders, I would think shaders would be the way to go.

I wish the technical Lindens would get in on these discussions; just seems pointless discussing these feature improvements with no input from them...it's like these forums are here to let us run around in but the Lindens already have their design roadmap in place and never look here...
Well I think my stuff looks more realistic than SL's stuff anyway (except for environment/bumpmapping which AW does't have, of course).

SL objects/avatars need MORE diffusion, specularity (also not in AW since AW3), and the day-night light cycle needs work (too many irregular color changes near dawn/dusk, etc). This, combined with the alt-LMB object highlighting since SL 1.6 and the lagging terrain/prim light updates since SL 1.7, shows SL lighting needs SERIOUS work.

they need to get their tech issues worked out first

when a top of the line pc with badass hardware cannot out perform my mediocre from 2 years ago pc there might be something wrong.
(i love my performance, my amd 2200+ nails SL like a cheap hooker)

when i cant run SL on my mac with a decent ati radeon but i can with a CRAP GF2MX(that i got out of a dumpster) there might be something wrong.

when basic projection lighting in a Open GL enviroment is software based, there might be something wrong. (my voodoo 2 can project a light source faster than SL on a 6600GT)

it could go on...

they could also promote offical education so every other texture isnt 1-2 megapixels, non transparent but yet saved as 32 bit, even their offical areas are littered with ginormus textures that are what? a gradient and shiny... god help us all.

they could add all the "modern" (caugh 5 year old) tech but when most ppl brag about them getting 11fps in a club (when their machine can do 3dmark2006 @70+fps) do we really need more stress?

Maby in 2.0, course i speculate in 2.0 they will finally have a useless version of havoc 2 (but havoc 6 will be out) and maby the gfx quality of UNREAL (circa 1998 with a voodoo2, which is gorgeous with its lighting, eventho the texture tech is quite low)

Actually, isn't the SL 'shiny' a kind of 'environment'? It's confusing because shiny moves with the camera relative to the horizon, which is wrong for environment maps. The effect is so overused as to be comical in SL, especially on things like leather chairs.

To be systematic, 3d materials have at least:

Diffuse (color in cinema 4d)
Self Illumination (luminance in cinema 4d)
Specular
Reflection
Transparency (refraction included)
Environment (a faked reflection)
Bump/Displacement
Alpha
Radiosity/Global Illumination

'Specular' is a cheat to reflect digital light sources. In SL this is baked into textures entirely I believe.

But I'm a noob on zero sleep. lol

Hooray! Someone else who doesn't think "shiny" is the coolest thing ever! I turn it off and I wish I had a "mod" version of some of the things I've bought without knowing they were shiny so I wouldn't be so "man, that looks horrible to everyone else".

Part of the problem with the shiny is the lack of control over it. It would be nice if we could at least define the value of shiny as a float or integer vs the three options we have now, would be even cooler if we could define the image ourselves, then it would be useful. As it is now I agree that shiny kinda sucks, better than nothing no doubt but still not that usefull.

Well there's POV-Ray which is a free and slightly open source (see link for details) raytracer. I think it does a good job on rendering, and it accepts pipes to and from other programs, so it's possible that SL could use it as a background renderer as a post processing deal. We get all the textures and stuff for the environment as normal, no lighting information or anything (essentially everything's full bright) and then POV-Ray goes to work rendering all the lighting locally in the background, applying the new textures as they arrive.

This would work great for static objects, like buildings or the trees of the Forest, where the object's lighting would change very infrequently based on the sun/moon's positions and the surrounding local lighting (which could be baked onto the textures this way). However a better renderer would be required for rendering physics objects and avatars.

Er, the day/night light cycle intensity changes at least every 10 seconds. I doubt POV-Ray could recalculate lighting for everything in the scene within 10 seconds...

10 seconds? Seems a lot longer to me. It could probably do it if it took a minute between light changes. Perhaps just a light/shadow map which would be applied over the textures, that should be fast enough. Of course it would help if we could choose to store particular sims locally. If we want to dedicate a gig or two to caching the textures of a sim we frequent, that's our choice.

Watch the sun; it changes position every 10 seconds which also affects the sim's directional light source angle.

http://secondlife.com/badgeo/wakka.php?wakka=llGetSunDirection

Even with 10s the jumps are noticable 1min would be even worse sadly.

Raytracing, while it yeilds a wonderful result is far from being applicable to games without hardware acceleration or serious reductions in image quality. Any interactive raytracer you see (Fprime for Lightwave is a good example) does it in passes, refining the image with each pass. But it still takes and inappropriate amount of time for games.

There are a few pixel and vertex shaders that would greatly assist in improving the look.

First off, half of light is shadow. We lack that portion of lighting so our lighting will not be "superior" until we get semi-accurate shadowing. For this I would recommend the stencil volume shadow approach, this gives a decent result at an acceptable hit in performance (using current hardware).

Chapter 9 of the GPU gems book (IBSN 0-321-22832-4) covers this including supporting vertex and pixel shaders and basic implimentation. I'd include it but this isnt really as important to our discussion.

You can opt for the more expensive shadowmapped shadows and those are far superior in quality but you make up for that in cost.

Both shadowing methods are limited in certain ways, omni directional lights are specifically performance intensive, so expect spot lights and directional lights to be about the best you can hope for and retain speed.

Though that is all more of a sideline to the issue at hand, but still part of it. To address the reflectivity issue....

The current shader gives us -
Cubic/Spherical Reflection of a predefined image.
Basic fresnel effect (darkening of the edges)

Neither of these give us a highlight, only faked reflection and a more natural metal look.

A possible solution is something more along the lines of image based lighting. Image based lighting will serve to give us several things we desire, namely...

</p>

1. Specular Highlighting (via image, so we can control placement)
   
2. Improved lighting complexity - since its image based the look is totally dependent on the texture.
   
3. Gives us more options in difining the look we want which will result in a wider variety of possible uses in-world.
   

I had started copying a chapter from GPU gems but it got to be far too much to write. Read GPU Gems (see above) chapter 19. Image-Based Lighting. It has all the necessary vertex and pixel shaders. Fascinating technique and a very nice result.

I found this page about image-based lighting. It includes some images that makes it more clear what this technique is about.

Yes, that is the high end version of IBL. Here is another one that shows it on a simple sphere in DX window. This one is using HDR images though that is not strictly necessary (though what an improvement it is!)

http://www.gamedev.net/reference/articles/article2208.asp