[Soc-2009-dev] Weekly Report

[Matt Ebb]

> === Issues: Where should light node go? ===
> ZanQdo and I had a quick talk over IRC about whether we need a
> separate node for light node.
>
> What was in my original proposal was quite simple - light node would
> make creating new probes easier. It allows us to mix existing HDR
> probes with the ones that we create. The workflow is very simple, so
> maybe it shouldn't be a separate node mode after all.
>
> ZanQdo proposed that it should probably be a part of shading nodes as
> IBL should be a shader and not treated globally. I'm however not sure
> how light nodes would fit into shading nodes since it's not related to
> materials or surface properties. So I hope we can hold some
> discussions here or during Sunday's meeting about this.

I agree, in fact I thought the original proposal was to have a 'light  
node' as part of the shading nodes, that would basically add the  
illumination from the light probe, given an input vector. I haven't  
been willing to comment on this much yet since I haven't actually  
tried it but a few points:

* We already have too many shading-related node types, imo. It's a  
clunky workflow, and easy to lose track. Adding another set of nodes  
to worry about makes this problem worse.

* It's too much complexity  and overhead for a very specific feature.  
Nodes in Blender are usually used as very  general purpose things.  
That's the point of nodes, it's a general purpose system that allows  
users to construct their own functionality. IBL is a very narrow and  
specific usage in itself, let alone even this very specific  
implementation of IBL (diffuse spherical harmonics). I can't see how  
this system would work well for other types of IBL implementations  
such as photon mapping, raytrace/importance sampled, etc. or even if  
it did work at all, if it would be any better than similar methods in  
shading nodes.

* The functionality that (from what I can tell) you want to make  
possible, such as mixing existing light probes with painted ones, are  
imo quite uncommon corner cases. There are much simpler solutions to  
the functionality that you want, which is simpler to both use and  
implement. The compositing node editor already handles any mixing/ 
distortion/filtering of light probes, and the shading node editor can  
handle mixing/blending of lighting results at render time.

I think you're better off thinking about what functionality is needed,  
and then finding simple, easy ways to make this possible, rather than  
spending a lot of effort making this big system :) I'm pretty sure it  
can be easily solved within the current workflow, which would be a lot  
nicer to use.

cheers,

Matt