[Soc-2009-dev] Weekly Report

[Jingyuan Huang]

Thanks for all the comments!

I think Brecht's idea probably can work the best. So, here is a mock
up showing lightenv node in texture node mode:
http://img199.imageshack.us/img199/3370/screenshotblender.png
The lightenv node is a type of input node in texture node mode, just
like images. This change actually reduces the amount of work for light
node since I don't have to re-write some of the functionality from
scratch.

I'd also like to add several points:
1. For now all the internal generated light probes are angular maps.
This can be extended to other maps in the future but I'd like to keep
things simple at the moment.
2. Type property will be removed from light environment panel. Again,
to keep things simple, all the internal light probes are synthetic.
External probe images can be loaded as images and mix in the node
mode.
3. I also need to make changes so that render pipeline would take the
correct light probe.


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




On Tue, Jul 14, 2009 at 8:52 AM, Ton Roosendaal<ton at blender.org> wrote:
> 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
>>
>
> _______________________________________________
> Soc-2009-dev mailing list
> Soc-2009-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2009-dev
>