[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