Forum: Poser - OFFICIAL


Subject: Morph Cleanup Script

Cage opened this issue on Feb 24, 2010 · 592 posts


Spanki posted Wed, 10 March 2010 at 5:16 PM

~waves~

[Cage pointed me at this thread...]

Hi guys... I am in fact busy on other things these days, but I just wanted to de-lurk long enough to say hi, thanks for the comments/mentions and congrats on the new/continued work.

I've read through the thread and will try to follow along, but don't really have the time to participate too much at the moment, so/but here are a few general comments...

**re: Vert->Surface vs. Vert->NearVerts correlation methods...
**
Vert->Surface:
Our original Vert->Surface correlation method has the primary advantage of being fairly deterministic and correct (as far as getting the desired results), since it does not depend on knowing ahead of time how many vertices make up the underlying (correlating) polygon of the disimilar mesh.  It identifies the 'surface' of the other mesh that corresponds to the vertex position of the mesh being adjusted and uses a weighting scheme that typically (or at least ideally) comes up with the right answer.

Where that method fails is that it depends on the two meshes having "generally similarly angled surfaces".  In other words, it does not work well (fails miserably, in some cases) when trying to correlate vertices who's normals don't point at the surface of the other mesh (for example, vertices on the bottom or backside of a cuff/hem/belt on clothing... those rays shoot up in the air or out from the body, instead of towards the other mesh surface).

There are similar circumstances in some tightly meshed areas, like the nostrils, eyes and ears, where mesh folding may not line up well between the meshes being compared.

Vert->NearVerts:
The advantage of this method is that it addresses the disadvantage of the Vert->Surface method... since it doesn't really rely on casting rays along normals to find surfaces, it can much more easily find the corresponding "close-by" vertices of the other mesh.

The disadvantage of this method is in determining the 'right' number of vertices of one mesh that should influence (correlate to) each vertex of the other mesh (given the diversity in polygon sizes).  In many cases, that number will/should be different for each correlation and you might well end up with some that shouldn't be included - or miss some that should (although due to the nature of most morphs, this is likely not a big problem).

From my brief scan of this thread, it sounds like you've already taken steps to correct for some of this and it appears to mostly be working well for you - nice job.

**re: Using a UV-Matched mesh to determine Vertex Correlation...
**
I don't recall off-hand who suggested this, but it is something that I considered in the past and at least "seems" like a natural/good idea.  I haven't sat down and re-evaluated this idea in it's entirety, but IIRC, it's actually a much more complicated process than it sounds like.  Aside from the UV-seams / Islands issue that Cage already mentioned, the more general problem has to do with how the weighting is done between disimilar mesh topologies...

I wouldn't want to rule it out as an option or speak much more on the subject without looking back into it, but either way, it would be a much less general solution (ie. it relies on someone coming up with the UV-matched meshes in the first-place).

**re: Generating a UV-Matched mesh...
**
The flip-side of the discussion is the viability  of generating a UV-matched mesh, after having done the correlation and weighting process.  As Cage has discussed (and supplied some sample scripts for), we did get this mostly working... but hadn't yet come up with a good means of accounting for and cleaning up the uv-seams (island edges/borders).  Basically, anywhere there's a seam in the uv-mesh, the process needs to determine "which" of potentially many different uv-values is correct for the given vertex.

As Cage has mentioned, I have ported (or orginated / test-beded, in many cases) a lot of this code (including the UV code) over into plugins for Cinema 4D... at some point, I may try to tackle this issue again, but don't have any solution at the moment.

**re: Anyway...
**
Good luck and have fun! :)

Cheers,

Keith

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.