[tuhopuu-devel] Graphite Integration

Brecht Van Lommel tuhopuu-devel@blender.org
18 Feb 2004 01:20:30 +0000


Hi,

On Tue, 2004-02-17 at 23:18, BjornMose wrote:
> hi brecht
> i am going to look at the papers ASAP to see the maths behind it.

It's got many different algorithms involved, and the ABF++ paper is only
expected to be published around mid-May. I will mail the author about
which algorithms will be implemented exactly there, cause there seem to
be some algorithms floating around it, that are not strictly ABF, but
very related. Also, I might attempt implementing one of them, especially
the Seamster aka "Cow Flattener" algorithm is really impressive. Some
interesting websites:

http://www.loria.fr/~levy/
http://www.cs.ubc.ca/~sheffa/
http://citeseer.nj.nec.com/cs (maybe you already know this one)

I lost my bookmarks somewhere changes browsers, but if there's some
paper you can't find, I might have it here. So just ask.

> my first feeling on what you wrote: is this could be doubeling math code
> over and over again (as happend to linear algebra in blender).

Yes. That's a big problem. Problem is also that the Graphite math
library has some features Blender's doesn't have (all kinds if solvers
for example). This immediately raises the question on how to integrate
it. Will we try to modify the Graphite sources as little as possible and
try to fit them in, or heavily modify them to fit better in Blender? The
fact is that there's quite a lot of code in Graphite, which got me
doubting. If we heavily modify the sources we will 'own' the code which
will lead to better integration, if we keep it as is all Graphite
features (and future ones) will be immediately available.

Personally I think we should write the code ourself based on the
Graphite sources, using Moto and other Blender modules. This will take
some time, and features will not immediately available, but it might be
good in the long run. If you would help writing code this option would
become more feasible.

I also think this option would be a great learning experience for me,
and it wouldn't feel like you were just stealing someones code. But
that's all subjective.

> so my suggested strategy would be:
> 1. fully understand what it does.
> 2. think of how it can be integrated to blender.
> 3. start building minimal features to grow.
>
> I think that advaced UV unwrapping could be a killer feature for blender
> but
> 1. maths are not so easy with that (topologly  is not a friend in this case)
> 2. dumping some code found in the WEB to blender / tuhopuu smells a little.

Yes, we should build it up, not immediately drop the code in cvs. There
are still a lot of things to sort out before committing. But I don't
mind, we are not in a rush. Let's do this good, and make it an actual
killer feature. It's not just about getting the big algorithms in there,
you also need to have the small tools / functionality that support them.

> so what i am trying to say :
> play with that stuff, see if it works, integrate to tuhopuu  if you
> feel/know it is good.

Yes, I'm still poking around with it. It's really clean code so that's
not in the way, all you need to focus on is the math.

> i read that copyright is no problem, make sure!

Copyright is okay, it's just GPL. Will check on external math libraries,
but they should be okay, as they are distributed with Graphite. Will
check this carefully.

> i am just a recent joined member to tuhopuu developement, so it is not on me
> to decide.
> But UV is some of the topics i am really interested in and i'd like to work
> on it, so we should keep i touch. (would'n want to do things you're working
> on already)
> 
> mail bjornmose@gmx.net

Great! I would really like to cooperate with you on this. I will not be
committing any code for this immediately, as this needs to be carefully
planned. We should indeed keep in touch. I might be best to communicate
through this mailing list, instead of private e-mail.

This could really be a killer feature, if we take our time and do it
right.

Cheers,

Brecht