[Soc-2009-dev] Weekly (late) report and IBL integration

Matt Ebb mattebb at gmail.com
Sat May 23 02:29:09 CEST 2009

I don't think this is such a great idea - if you mean this lightenv
struct to be some kind of internal structure, that should be fine, but
I think for anything to do with environment lighting, you should stick
to the 'lowest common denominator' of light probe images. There are a
few potential ways that you can do environment lighting, either as a
global thing - i.e. sampling a 'sky light' as part of illuminance
loops etc, or as part of a specific shader (i.e. a node adding colour
in a shading node tree). It's very likely that there will be a few
different techniques for in too - not just bent normals+SH
coefficients, but perhaps also something similar to raytraced AO, or
importance sampled, photon mapping, shadow mapped light domes, etc.
I.e what happens if during a photon mapping process, it encounters a
LightEnv with only SH coefficients stored - sounds a bit ugly to me.

Anyway sure there can be ways to cache and store the SH coefficients
alongside for optimisation, but I think if you're designing something
that's meant to be a general purpose usage, you should keep it
general, and allow the SH lighting to be 'plugged into' it seamlessly
and equally with other systems too.

The other thing is that working with HDR images themselves is quite
nice. They're just files you can copy around, you can see previews of
them in any old file/image browser (not just in Blender), you can use
them in other applications, they're nice and concrete unlike abstract
SH coefficients. You don't have to worry about appending 'LightEnv'
datablocks etc around. Keep it simple and general!



On Wed, May 20, 2009 at 7:02 AM, Jingyuan Huang
<jingyuan.huang at gmail.com> wrote:
> A quick note on LightEnv:
>>Unless the lightenv data blocks are meant to be reusable (appended, linked to more than one world in different scenes, link to other files, ...), I don't think it's need to make them an ID type of their own. It could just be a separate struct in >DNA_world_types. It depends on what the struct contains too, so if you can flesh that out, it would be easier to decide where to stick it.
> I would hope that lightenv can be reused. It means that we don't have
> to write/load everything as an HDR image if it's just some simple
> coefficients that we calculated for another scene. In my mind, world
> would have only one final lightenv (after being composited by light
> nodes, for example) and that one would be used for rendering. However,
> just like we can have multiple materials and textures, we can have
> multiple light envs (each of which would be associated with a light
> node). Users can pick the ones that they like for another scene.

More information about the Soc-2009-dev mailing list