[tuhopuu-devel] UV-LSCM

Brecht Van Lommel tuhopuu-devel@blender.org
06 Mar 2004 17:14:32 +0000


Hi

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

I agree.

> >
> > 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 
> better ( i am inclined to believe that, since he is doing that as a 
> research work ) coping data is "peanuts" against using a slower/faster 
> 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 
> which would be nice in future) ) providing proper data strutcures ( 
> Bruno or who ever did interface with graphite's data structres so we 
> could go directly to what  superLU expects)
> 2. think about "pinning"! ( you did already, i suppose when doing the 
> relaxing stuff )

Not really. It just locks the borders of the UV island automatically.
But there you do it based on the 'implicit seams'. I think we should
give users the ability to define 'explicit seams' on a mesh, by clicking
on an edge in Face Select Mode, like in Graphite. We can first implement
LSCM without it, but it would limit the possibilities.

We can't store edge data in Blender directly (I remember that was the
reason why we didn't have creased SDS). But it think it's really
essential for the LSCM algo. I guess we should store it in the TFace
struct, as one char with 4 bitflags. That may not be the most convenient
way, but it's easy and the seams are associated with the UV data, so it
would be a logical place to put it..

> 3. implement a local version of LSCM in editsima.c ( i'll do when the 
> superLU solver is runnnig, not a big thing any more then, doing some 
> linear algebra )

Shouldn't be too hard. I don't have too much time myself at the moment
(exams), but it's not like I will not have any time either. I'll see
what I can do and where I can help.

Cheers,
Brecht