[Soc-2009-dev] Weekly report and plan

Jingyuan Huang jingyuan.huang at gmail.com
Sat Jun 6 02:13:56 CEST 2009

What I did last week:
I added light paint brush and a non-linear solver. The current build
from my branch allows users to paint a scene with multiple strokes. A
video is available here:
(for some reasons I can't upload it to youtube...)

The solver depends on LAPACK, so the build only works on machines with
LAPACK installed. I tested cmake and scons with linux, but not macs or
windows. I'm currently reinstalling leopard and will soon install
windows for HPC learning purpose, so in the future I can probably make
sure my branch builds on all systems (not for every check-in, only the
ones that I think are in a good state).

What I will do next week:
There are plenty of problems in the current build.
    * there is an ugly change in derived mesh drawing to make sure
that selection in light paint mode is right (but it makes vertex paint
    * Undo/redo paint strokes
    * Re-load init blend file should reset default light environment.
Loading a new file should reset that as well.
    * The computation job needs improvement!
    * testing! testing! testing!

So I will be working on those next week. If I get extra time I will
try to look at some more solvers and constraints, but again let's not
be too ambitious.

One issue is the ugly change that I mentioned in my list of problems.
The back draw part is used for selection for all the painting modes.
However, different from vertex paint or weight paint, light paint need
to select vertices that are in the derived mesh, not mesh. I wonder if
drawMappedFaces can add a parameter to indicate if original indices
should be used or not. For now I can use Global to check if it's in
light paint mode (in my own repo, not checked in yet), but I believe
that G would eventually go away and we need a better solution.

There is a comment for bbs_mesh_solid: /* TODO remove this - since
face select mode now only works with painting */
I don't really know what it means. Does that mean that I shouldn't use

Another issue is the same one that I brought up last week. It's not
quite an issue for me now, since I use rv3d's flag to indicate if a
calculation is necessary for the scene. Personally I don't think
computation code should be done in drawing methods, but unless Brecht
has some magical function ready I wouldn't worry too much about it

Best Wishes
Jingyuan Huang
Computer Graphics Lab
University of Waterloo

More information about the Soc-2009-dev mailing list