[tuhopuu-devel] UV-LSCM

Brecht Van Lommel tuhopuu-devel@blender.org
03 Mar 2004 00:04:30 +0000


Hi,

On Tue, 2004-03-02 at 21:29, bjornmose wrote:
> Hi Brecht and all
> 
> Did a refresh to the math i learned some years ago.
> The least square conform mapping algo has it's root in complex functions 
> therory. Knowing this the whole math boils down to poor some ten lines in 
> Bronstein ( the math bible with me )
> A mapping from a subset in the complex plane to some other subset in the 
> complex plane is conform (preserving angles ; ABF :-) math is beautifull !! ) 
> when it satisfies the Cauchy Riemann equations.
> The other way around : If we can not match the C-R equations, we'd like to 
> come as close as possible. And we can't, since our mapping wants to have the 
> edges of triangles in the image to be straight lines. If we would drop this 
> Riemann gives a proof for the existace of such a mapping. So we can hope to 
> get close to it and as Bruno Levy shows the solution will be unique with a 
> proper definition of distance.
> 
> So what i want to say
> 1. i do understand LSCM down to the details now.

Cool. I can follow pretty well now, just some of the steps are not that
evident, and I keep forgetting how it worked again, just a lack of math
knowledge I suppose. 'least squares problem' is on the agenda in math
class tomorrow, so I'm catching up :).

> 2. i am not quite sure if building up the matrix and solving the minimization 
> with the "old workin horse" LU decomposition ( ya i am into numerics quite 
> while )  fits the needs we have in blender/tuhopuu. it looks a bit oversized 
> to me. 

> I am working an a "local relaxing" solution, like you (brecht) built in  
> tuhopuu, minimizing the error in respect of the C-R equation. this should 
> meet the blender needs more closely and would be far less waste of CPU than 
> the "one hammer fits all screws" aproach in 'Graphite'. ( hoping not to 
> offend anyone, but definitly setting variables to zero and still happly 
> multipling with (knowing it is zero) is waste of CPU)

Hmm, I can't really say I agree with you. The LSCM unfolding is
lightning fast (takes less than a second to unwrap the girl-face model
here). It is the seam cutting and texture packing that is slow. Try
turning of 'Auto Cut' and make sure you have only one 'island'. I think
that if it is this fast, there is no need to search for a lower quality
method.

I tried to convert my relax uv function to the "stretch L2" function in
Graphite today. Got it partially working already after only a couple of
hours of work. Still need to write code to detect the borders (that are
supposed to be locked) and to virtually triangulate the mesh, but it
works. It's a slow algorithm and I'm even using random movement, but I
just couldn't stand the fact that there was a "Relax UV" function in the
menu that didn't work properly ;). It's a simple algo, but I think it
can stay in tuhopuu as long as we don't have a proper replacement.

Cheers,
Brecht