[tuhopuu-devel] Fwd: Re: Graphite - Blender integration

[Brecht Van Lommel]

-----Forwarded Message----- 
From: Bruno Levy <Bruno.Levy@loria.fr>
To: Brecht Van Lommel <blendix@pandora.be>
Subject: Re: Graphite - Blender integration
Date: 05 Mar 2004 13:38:43 +0100

Brecht Van Lommel wrote:

>Hi,
> 
>We now seriously started working on improving the UV mapping in Blender
>with the help of Graphite. We decided not to integrate any code
>directly, partially because we don't want to have yet another math
>library in Blender (we already have a couple of them), and we think it's
>better not to have too much 'uncontrolled' code in the sources, which
>would make it harder to manage. Also, speed wise all the converting
>isn't really ideal.
>
Yes, on the one hand, I agree with that view, duplicating the code would 
be not a good
idea, and it's safer if you control all Blender code (it would be 
annoying to have to
cope with multiple versions of libraries). And I think that LSCM can be 
implemented
with not so much code (it only needs a representation of sparse 
matrices, a linear solver,
and a mesh representation).

On the other hand, I've received several requests for a "Graphite 
programming
library" that would be less heavy than the whole system (and that people 
could
easily link with their own software).  The idea is to have
a version that contains only the core functionality, without the GUI, object
model, scene_graph and renderer code (see attached file). I've included
a Makefile generator that compiles everything in a single lib.
Using that would facilitate integrating Graphite's future features in 
Blender
(ABF++, Signal specialized mapping etc...). If you choose this solution,
I think that adapting LSCM code to Blender's mesh data structure is 
quite easy
(and is better than duplicating the mesh).

If you do that, then you just need a part of the math library (SuperLU + the
SLS::SparseMatrix and SLS::Solver wrappers). If there is sufficient 
interrest
for this solution, I'll try to make a generator to extract that from the 
Graphite
distribution (this will make the OpenNL (Open Numerical Library)).

Whatever you choose to do, I'll be very happy to see Graphite features 
included
in Blender and give help.

>If you're interested, we are doing all communication on the
>tuhopuu-devel@blender.org mailing list. Tuhopuu is the experimental cvs
>tree of blender, which is the place where we will write our code before
>it gets in the main cvs tree. Archives are here:
>http://www.blender.org/pipermail/tuhopuu-devel/
>
OK, I'll have a look at it. For the moment, I'm creating a new research 
project
at the Inria and I will not have much time in the next few monthes for 
helping
Blender's development directly (I mean, writing code in Blender). However,  
feel free to ask any question. It will be easier for me in a few monthes.

>So we decided to write uor own code (which will heavily be inspired by
>the Graphite code). The first thing we want to do is LSCM unfolding.
>Jens Ole Wund, who is working on this together with me, had some
>thoughts about speeding up the implementation, and we would like to know
>why the Conjugate Gradient method, which should be well suited for a 2nd
>order minimization problem, was not use to Solve the equation, instead
>of superLU. Just changing PERMSUPERLU to any CG method in the Graphite
>code doesn't seem to work, but could you explain why CG wasn't used?
>
My initial implementation of LSCM was based on CG (there is still an 
implementation
of CG in Graphite,  and changing PERMSUPERLU
to CG in Graphite should have worked, maybe there is one or two 
parameters to tune).
The reason why I'm using SuperLU is that SuperLU is between 10x and 100x 
faster
than CG !!!
SuperLU is a direct solver, most people (including me a few years ago) 
think that
a direct solver cannot be faster than an iterative one. SuperLU is an 
exception.
There is also another even faster solver called MUMPS that I'll try (it 
was written by
J.Y. Lexcellent, who works also at the Inria, the same institute as me). 
The only problem
with MUMPS is that it's written in Fortran 90 :-(

>I must say the Graphite code is really clean and structured, which makes
>it really easy to read and focus on the math.
>
Thanks :-) I'll forward that to the rest of the development team !!


>
>Thanks in advance,
>Brecht Van Lommel
>