[tuhopuu-devel] UV-LSCM

[bjornmose]

Hi blendix and all,

First of all i apologize for not looking at GRAPHITE close enough.

On Friday,  5. March 2004 17:34, blendix wrote:
> 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
=2E...
>
> I mailed Bruno Levy about it, got a response immediately and I have
> forwarded it to this mailing list.
>
reading his answer, i enjoyed reading every line! =20
>
> 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.

I do agree!
But we have to keep in mind, that blender is supporting some other OS's=20
not explicit discussed here. So what ever library we are going to link=20
to should be able to build on ALL OS's. This keeps true for his=20
suggestion providing a OpenNL library and  i read between the lines=20
this would be very low priority in his shedule ( not to blame him, but=20
facing the facts )
I think we can ingnore other OS's than Linux and M$ in a first step,=20
just to see if it is working, but after all it should work for the=20
other ones too. ( i am  sure we have some friends here, to get it going=20
)=20

>
> But the data structure copying is still a problem. Even if we would

When it is like Bruno said, that superLU speeds up solving 10x or even=20
better ( i am inclined to believe that, since he is doing that as a=20
research work ) coping data is "peanuts" against using a slower/faster=20
solver.
May be there is a break even point for "small" meshes, who cares?

> 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

sorry, did not find time to go in there yet, but weekend is comming.

>
> :). 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.
>

my suggestion for further movements:
1. see if we can invoce superLU ( without linking to graphite/ (OpenNL=20
which would be nice in future) ) providing proper data strutcures (=20
Bruno or who ever did interface with graphite's data structres so we=20
could go directly to what  superLU expects)
2. think about "pinning"! ( you did already, i suppose when doing the=20
relaxing stuff )
3. implement a local version of LSCM in editsima.c ( i'll do when the=20
superLU solver is runnnig, not a big thing any more then, doing some=20
linear algebra )

ole (bjormose)