Hi Tom >" it will be really slow and will work only for fairly low poly models
and few words before you stated - that retopo will work on simple submeshes - correct? then - algo, which was donated might be used as well it is fast as can be seen. so here is a question to select appropriate algo. > Didn't miss it - I just have more direct knowledge of what is going on. maybe you have some knowledge - but it does not mean you know everything. or can from out hand say that algos which are specially developed for retopo are 'unapproriate' > The use case is entirely different. This is faster manual creation of > a retopology, things are very well constrained so heavy math lifting > doesn't need to be done to find what the contours of the mesh are in > order to best align the edge loops. so again - does your script provides all useable use cases? will general algos be better in they are just 'interfaces' - Nick integrated donated code in few days - and it is already can be used with Blender. in case you can guaranty this - no problem, but the general case might be - select quite a wide area and then push - iteratively retopo it. and those algos do provide this - they are appropriate - the question - to select one which is most appropriate based on few things - including your knowledge, that rohith retopo will work on relatively simple areas ( but again - this is a case for retopo ) Regards Sergey On Mon, Apr 4, 2011 at 2:26 AM, Tom M <letter...@gmail.com> wrote: > On Sun, Apr 3, 2011 at 2:03 PM, Sergey Kurdakov <sergey.fo...@gmail.com> > wrote: > >> so you kind of big boss? > > No, Ton is the Big Boss - I'm more of a medium boss :) > >>> Rohiths code can only work on extremely simple meshes because the math >>> library he needed for accelerating the process was not integrated yet >> >> this is incorrect > > No it really is correct, me and rohith exchanged emails and chat > discussions, here is a direct quote from about a month ago, > > QUOTE > > " it will be really slow and will work only for fairly low poly models > > the reason being that I did not find a usable sparse matrix implementation" > > END QUOTE > > Anywho he is currently looking for a usable sparse matrix > implementation and has some bugs to fix. However it is irrelevant, > since it still wouldn't be appropriate for the two tasks that the > student is interested in working on (which are much simpler cases). > > >>somehow you missed it big boss, > > Didn't miss it - I just have more direct knowledge of what is going on. > >> so to use ready code - is difficult. Or Tom - maybe you can allow a >> bit of creativity? that will easily pay off. >> maybe rohith did not finish intended feature because he tired of you? > > It is great that you wanted to help a student by providing papers, it > isn't so good that you are insisting that you are correct in an > insulting manner. > >> all mentioned approaches was like these: take arbitrary mesh and make it >> better. >> it is developed with simple interface with mesh in - mesh out. > > The use case is entirely different. This is faster manual creation of > a retopology, things are very well constrained so heavy math lifting > doesn't need to be done to find what the contours of the mesh are in > order to best align the edge loops. > > LetterRip > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers