[tuhopuu-devel] UV-LSCM

[bjornmose]

On Wednesday,  3. March 2004 01:04, you wrote:
> 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 functi=
ons
> > therory. Knowing this the whole math boils down to poor some ten line=
s 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 beautif=
ull
> > !! ) when it satisfies the Cauchy Riemann equations.
> > The other way around : If we can not match the C-R equations, we'd li=
ke
> > to come as close as possible. And we can't, since our mapping wants t=
o
> > 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 mapp=
ing.
> > So we can hope to get close to it and as Bruno Levy shows the solutio=
n
> > 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 i=
nto
> > 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 sh=
ould
> > meet the blender needs more closely and would be far less waste of CP=
U
> > 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 am NOT talking about lower quality, but a more local, more efficient al=
go!
you may have a powerfull box doing things in a second, taking hours a few=
=20
years ago, but this little thing is worth looking at if it could take=20
milliseconds then. (again not to offend anyone, but i do not like the=20
attitude we 've got CPU so why not waste it (math rules!).
>
> 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 th=
e
> 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.
>
i am not willing to look at graphite's code any longer since i poked evre=
y=20
now and then to find there is ugly redundant code all over (nice formatti=
ng=20
does not make clean code ) and not beeing able to solve a simple linear /=
=20
square optimization problem ( needing a superLU, which is definitely=20
unefficient on a sparse matrix  like this, to do ) shoots the bird.

sorry for beeing that harsh!
> Cheers,
> Brecht
>
> _______________________________________________
> tuhopuu-devel mailing list
> tuhopuu-devel@blender.org
> http://www.blender.org/mailman/listinfo/tuhopuu-devel