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

[Jingyuan Huang]

Hi Matt,
I'm not saying that we should get rid of HDR images all together. In
fact, if we create a light env by specifying an HDR image, the SH
coefficients should never replace the file itself since they are just
approximations.

However, if we create light envs by ourself, we only have
coefficients. An HDR image can be calculated (and store as a file)
from those coefficients, but for internal uses I think it's easier to
keep them as coefficients. IBL methods other than SH can use an HDR
image, not the coefficients. For example, a user wants to use light
paint method to light the scene, however he/she already knows that
there's a light env in another blender file that can be used. Instead
of opening that blend file and export the light env into an HDR image
and load it into the desired scene, he/she can link the light env from
that blend file.



Best Wishes
Jingyuan Huang
------------------------------------
Computer Graphics Lab
University of Waterloo




On Fri, May 22, 2009 at 8:29 PM, Matt Ebb <mattebb at gmail.com> wrote:
> 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!
>
> cheers
>
> matt
>
>
> 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.
> _______________________________________________
> Soc-2009-dev mailing list
> Soc-2009-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2009-dev
>