[Soc-2009-dev] Weekly (late) report and IBL integration
mattebb at gmail.com
Sun May 24 02:57:47 CEST 2009
On Sun, May 24, 2009 at 4:07 AM, Jingyuan Huang
<jingyuan.huang at gmail.com> wrote:
> 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.
Yeah, I realise what you're saying, but I think it's better to keep
things simple. I don't want to have to worry about the distinction
between light probes, SH coefficients, etc - it's much easier if it's
all one and the same. Like I said, HDR files are nice and tangible,
adding abstract 'light envs' into the mix just makes things more
complicated, imo needlessly complicated. I know you're not proposing
to use the terminology spherical harmonics coefficients anywhere, but
artists may be confused by the distinction between 'light environment'
and 'hdr light probe'. And there's really not a huge reason to the
have the distinction anyway.
That's what I liked about your original proposal, it's was nice and
simple, easy to understand and visualise - it's 'a method of
generating HDR light probe images'. You do some painting and get an
image out of it. It's analogous to painting in Blender's image
editor/3d view. You can generate new images, paint on them, test
render them, but if you want to keep them and use them again, you just
save it to disk. Light paint can be completely consistent with this.
PS. one other small argument about the distinction between 'lighting
environments' and just hdr images, is that with just plain images, you
have the ability to use the image for both lighting, and as a
reflection environment/reflection map. Using the image itself, you can
easily assign it around to multiple textures, used in image based
lighting, reflection maps, etc and then if you want to replace that
image, the changes automatically ripple though. This is quite nice
when testing different lighting setups, and it's also very simple :).
More information about the Soc-2009-dev