[Bf-committers] GSoC 2011: Improving Retopology Tools

[Sergey Kurdakov]

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 <letterrip at gmail.com> wrote:
> On Sun, Apr 3, 2011 at 2:03 PM, Sergey Kurdakov <sergey.forum at 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 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>