[tuhopuu-devel] UV-LSCM

[Brecht Van Lommel]

Hi,

On Thu, 2004-03-04 at 22:14, bjornmose wrote:
> Shedule
> 1. Ask Bruno Levy if he did try a CG approach, which i think is the 
> best for a 2nd order minimization problem. ( the code is prepared to do 
> so, by changing a line ) And if he did (i am almost sure he did), why 
> he does not use it in LSCM. (can you ask him brecht?)

I mailed Bruno Levy about it, got a response immediately and I have
forwarded it to this mailing list.

> 2. I did not dive into blender's math libraries too deep to know if 
> there was a good "linear equations solver for sparse matrices". if not 
> consider superLU ( copyright ! ), which seems to be a bit clumpsy 
> interacting with GRAPHITE because of different data structures ( needs 
> data copied from yin to yonder)
> Would not want to have complete superLU (graphite) code in blender 
> since it is far oversized ( think of building time, compiling all! 
> linking to some few functions ), but for a first shot i'd argee.
> All the algos are available in "Numerical Recipes in C / William H. 
> Press [et al.] (ISBN 0 521 43108 5)" (  my bible for advanced math 
> algos ) So this may be the guide to slim the stuff down to our needs.

Considering the reply I got from Bruno Levy, I think SuperLU will need
to be used. By looking at the code you can see it is insanely optimized,
and I don't think we could do that when writing our own solver, even if
it would work on the data directly.

But the data structure copying is still a problem. Even if we would work
on our own data directly, we'll still need to convert it. If you look at
the new relax uv code (with linked lists), you see what I mean (small
note: the building of the data structure equals the efficiency of bubble
sort, but I could use qsort, just didn't feel like fixing it yesterday
:). You need to split up you uv map in islands, based on explicit or in
this case implicit seams. But building such a data structure for every
function is obviously a problem.

My suggestion would be to make a more intelligent / O(1) data structure
like the data structure used in Editmode, that would be available in
Face Select mode. This could then be used both for some simpler tools
like heal UV, select sticky, .., but also by the more advanced
algorithms.

Another strange possibility is to keep the Graphite data structure alive
when in Face Select mode, and extend the Graphite code. But that would
probably be too messy.

> 3. what is left in math sense is the "pinning" data in any case.
> This could be the borders of an island as well as "stretching the data 
> to a given region in UV space" or any other user friendly defined 
> subset in the UV mapping. 
> 
> cheers
> ole (bjorn the moose)
> _______________________________________________
> tuhopuu-devel mailing list
> tuhopuu-devel@blender.org
> http://www.blender.org/mailman/listinfo/tuhopuu-devel
> 
>