[Soc-2009-dev] Weekly Report

[Ton Roosendaal]

Hi Jingyuan,

I would follow Matt's suggestion:

> 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.

Get the light paint to work first in its minimal useful basics, as 
simple as possible. Having it as a global and/or with optional 
per-material override would be sufficient to get a good use case for 
validation of this system.

It will be much easier and much more fun to ensure the light-env 
related workflow is first fully worked out; then hand it over to the 
artists out there to play with it. Typically the use cases will give a 
lot of information about efficient next steps to make.

The disadvantage of a adding light-envs in our current node-shader 
system now is just that the entire shader system is in a twilight zone 
anyway... originally just meant to control multiple Materials (layer 
multiple materials).
What we still seek for first is a good generic shader editor for 
Blender, treating light (envs and lamps) correctly to create advanced 
and well re-usable shaders.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 11 Jul, 2009, at 3:04, Matt Ebb wrote:

>> === 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
>
> _______________________________________________
> Soc-2009-dev mailing list
> Soc-2009-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2009-dev
>