rework lights to have energy and color

[Aeva]

Now that we have a good selection of light types (issue #225), I can focus on refining the actual illumination model. If the math isn't too verbose, I'd like to base it on photography. Lights would be expressed in some energy value, and then some factors could be used to tweak the dynamic range. It might also be a good idea to try to mirror blender internal's light model.

Also, I'd like to add some notion of specularity to this system.

Issue #51 is relevant to this ticket.

[Aeva]

After some research and discussion, Physically Based Rendering is probably what I want for what I described above, but also may be a bit heavy for some uses. Having support for PBR would be nice in the long term though.

Instead of committing to a specific lighting model that may very well be unfashionable in a couple of years, it would be better if the deferred renderer was made to be easily extensible. So with that in mind, I think it would be neat to try to code in the direction of having three or so stock lighting systems:

• simplified blender internal inspired
• physicality based rendering
• some kind of non-photorealistic shader

A nice part about this then is if someone wanted to create a custom lighting model, they could do so in the same way as the stock ones would be implemented.

So for simplicity, I think it makes the most sense to start with a BI-inspired simplified renderer and add the PBR and NPR ones later. The BI one is going to favor being fast over being pretty.

[Aeva]

I added support for glsl structs in #229 so that a common struct can be used as the sole parameter to BRFD functions.

So I think the next step is to modify lighting_passes.frag so that it calls standard "light volume" functions, and the hooks in the BRFD function calls in places like this one where the light volume function would return a non-zero value.

There should just be one BRDF function stub, which is passed the parameter struct and should be expected to return a vec3. The light volume functions should also return a vec3. The light volume functions should not modify BRDF's return value in any way, and should either just return the BRDF return value or zero.

Last, the sort of proto-BRDF functions currently in the lighting pass shader should be moved out of the deferred renderer entirely, and a helper method should probably be used to instance the renderer, but such a method is the scope for another issue (#230).

[Aeva]

Things to do next:

• [x] let lights control their color and intensity
• [x] fix the driver property for light energy, also rename to intensity
• [ ] figure out a nicer way of controlling the dynamic range

[Aeva]

the basic parts are working more or less correctly, so I guess the next step is to create a less horrific brdf function, and add some notion of ambient light

[Aeva]

I think instead of having an "ambient" shader setting, it would be better to have some kind of "scattering" setting on the sun lamp, which would interpolate between being 100% directional vs providing only ambient light.