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

Martin Poirier theeth at yahoo.com
Tue May 19 22:18:57 CEST 2009


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


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

More information about the Soc-2009-dev mailing list