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

[Martin Poirier]

It could be like the Envmap texture type, where you can use a computed envmap (in this case, the SH coefficients), save a computed map to disk (generate and save the light probe) or use one from disk (same concept).

Martin

--- On Fri, 5/22/09, Matt Ebb <mattebb at gmail.com> wrote:

> From: Matt Ebb <mattebb at gmail.com>
> Subject: Re: [Soc-2009-dev] Weekly (late) report and IBL integration
> To: soc-2009-dev at blender.org
> Received: Friday, May 22, 2009, 8:29 PM
> 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
> 


      __________________________________________________________________
Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/