[tuhopuu-devel] Graphite Integration

Brecht Van Lommel tuhopuu-devel@blender.org
17 Feb 2004 21:58:16 +0000


Hi,

I've been looking for ways to improve the UV editor, and there's still a
lot of things to improve in the current workflow. But I've also been
investigating more advanced tools, like relax UV, unfolding algorithms,
seam cutting and texture atlas packing. There seem to be quite some
algorithms out there.

I found that one of the most prominent researchers in this area (as far
as I have an overview of it), Bruno Lévy, has released his application
'Graphite' under the GPL license: http://www.loria.fr/~levy/Graphite/.
It contains many interesting and advanced algorithms for UV mapping. By
integrating some of it's sources I think Blender could get some really
professional UV mapping functionality. If you don't believe me, play
around with Graphite's features, and see what it's possibilities are.

Also, there is a new algorithm coming, ABF++, that IMO is pretty awesome
(already experimentally available in the Windows binary). It's really
fast and still has the quality of the ABF algorithm. Combine this with
them automatic packing of several islands into one texture atlas map,
various UV map optimization algorithms (to minimize angular and length
distortion) and an automatic seam cutting algorithm, and you'll see how
useful this could be. The automatic seam cutting might not always give
good results, but we would allow the users to define the seams edge by
edge, as in the end only they know which parts of the mesh are important
and which parts aren't.

It's hard to compare the Graphite algorithms to those found in
professional UV mapping applications, as I don't know their algorithms.
But I know the algorithms available in Graphite are pretty recent and
IMHO really good. I think I'll ask the main author about this. Anyway,
he offered to help, and thinks Blender is cool software, so that's quite
alright too :).

The only problem I see is the size of the current code. Graphite uses
it's own math library, and two external math libraries. I've already
stripped down the code quite a bit, to about 4 MB, including the math
libraries. I'll probably be able to lower it more, but it would
certainly add up to the compile time and Blender binary size. Blender
binary size went from 4.5 to 5.3 MB here, but I'm not sure everything is
actually in there, I think the compiler might have left out unused
parts. This could also be a good sign, indicating there are still many
things that could be left out.

I find it important to minimize the amount of Graphite code in Blender,
to be able to control it. It would be nice to integrate it without too
many modifications, to be easily able to keep it in sync with Graphite,
but it also shouldn't be a big amount of code that's not controlled by a
Blender coder.

The positive side is that the code is very clean and modular, which
would certainly make things easier to integrate and maintain. It's also
cross platfom, because Graphite compiles on Windows and Linux.

Now, my question is, would I be allowed to try to integrate this code in
the Tuhopuu tree? It might not work out, but I can at least try it in
the experimental tree, right? I'm not sure how useful these features
would be considered, since UV mapping is my current field of interest,
and I might consider them to be more important than they actually are.
Anyway, what do you think?

Cheers,

Brecht