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

[Jingyuan Huang]

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.

Alternatively we can put multiple light envs into world, but that
means if we link world from another scene we link all the light envs.
This might be less flexible?


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




On Tue, May 19, 2009 at 4:18 PM, Martin Poirier <theeth at yahoo.com> wrote:
>
> Hi,
>
> --- On Tue, 5/19/09, Jingyuan Huang <jingyuan.huang at gmail.com> wrote:
>
>> Here is my weekly progress:
>> 1. There is no update on user specs. It seems that people
>> want a build
>> to play with rather than looking at docs. :-)
>
> That's unfortunate, but it was somewhat expected. The thread is started now though, so I would suggest you post updates as progress are made. This keeps the interest level up and means that more people will be commenting once something is testable (or a demo video only even).
>
>> 3. I added (and committed) some code for light paint mode.
>> It now has
>> a light paint mode and if the coefficients are never
>> computed for the
>> scene it would create a job to do the initial computation.
>> I'm only
>> computing diffuse coefficients now. The code is messy and
>> needs improvement.
>
> Code quality is somewhat important, I would suggest this gets taken care of sooner rather than later. (note that I wrote that before seeing that it was on your todo for next week)
>
>> I apologize for my last commit. It was not done as it
>> should have
>> been. I accidentally merged changes from 2.5 and commit
>> everything
>> together. It should have been 2 commits.
>
> Merge can be tricky, if you need some help, don't be afraid to ask.
>
>> There's been some discussions going on in Blender Artists.
>> Several
>> people mentioned IBL and I think maybe it's a good idea to
>> lay out a
>> plan for it. Here are some of my thoughts:
>> 1. I'd like to have a light environment type (maybe
>> DNA_lightenv_types.h). A light environment can take a
>> texture, or can
>> just be something computed by the system. scene->world
>> should have a
>> reference to the lighting environment.
>
> 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.
>
>> 2. Light node would have similar structure as the other
>> node types.
>> Very simple docs here:
>> http://wiki.blender.org/index.php/User:Yukishiro/Design_Specs_for_Light_paint#Light_Node
>
> Light nodes would be at the scene level, like compo nodes, right?
>
> (or per world, but that's sensibly the same thing)
>
>> 4. I'm not sure how this would affect RenderLayer.
>
> Should the IBL effect be included in the diffuse and spec passes or be a pass or their own you mean?
>
> I would vote that they should be added in the current existing passes since they contribute to the same perceptual effect. It should be possible to disable it in a layer though (like Sky and like lights can be restricted to a group).
>
>> I also have some thoughts about how objects should be drawn
>> in light paint mode.
>> 1. light paint mode should not have its own drawtype. In
>> fact I think
>> it should be drawn as it is in solid mode.
>> 2. in shaded mode, there are already a bunch of if-else
>> statements for
>> vertex/texture/weight. Light paint drawing code would go
>> there.
>> 3. I intend to use dm->drawFacesColored (single side)
>> for light paint.
>> Colours are computed as an accumulation of light sh
>> coefficients and
>> object sh coefficients.
>
> Agree on all points except perhaps 2. Having all the if-else there is a bit yucky, but we can't possibly ask you to clean all of that, so using the same structured code for lightpaint should be ok until a cleanup is done.
>
>
>> I will be in Kelowna for CRV/GI 2009. Martin will be there
>> too. :-)
>
> Looking forward to meeting you there. We can take some time to discuss issues in person then (after Wintercamp, it's quite clear that pencil and paper add a whole new dimension to design discussion).
>
> Martin
>
>
>      __________________________________________________________________
> Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php
> _______________________________________________
> Soc-2009-dev mailing list
> Soc-2009-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2009-dev
>