Compfox,

If you care to post the .c4d file (either here or in a PM), I'll take a look at it.

Cheers.

Quote - LOL thank you Robyn <3

I'm trying to make morphs for her eyes.... ...and if I use Cinema4d with the TrueSymmetry plugin Poser tells me the result has a wrong number of polygons...

(warning - self-serving ad ahead...)

If you Import/Export .obj files using Cinema 4D's "built-in" .obj code, you will have this problem (well, the vertices get re-ordered).  To avoid that issue - and generally be in Poser-Compatibility-Heaven - you'll want my Riptide Pro plugin.

Riptide Pro preserves vertex-ordering (required when making Morph Targets) and also preserves materials, grouping and even UVMapper "Regions".  It also gives you tons of other options and comes with "Import/Export From Poser" presets.

(There is also an older 'free' version of the plugin, but it does not work beyond R11.5 and doesn't have Presets and many other features - but it still preserves vertex-ordering, etc.)

Cheers,

Keith

Quote - Oh. Spanki! HI!

Yes, I use your free Riptide ;) Was one of the first things I got for C4d, because I use C4d for Poser stuff since the first time I got it! Thank you for this, my C4d would be quite useless without it.

I've been eyeing the Pro version for a while. Maybe if these morphs sell well.

 

Ahh - gotcha.. and thanks for the comments.

Quote - In any case, what was breaking things was the TrueSymmetry plugin - I don't know how it does the symmetry, but it was breaking the vertex order...

I see... I downloaded TrueSymmetry a long time ago, but never got around to playing with it... that's a shame - it may be 'rebuilding' the mesh on the fly, internally (sorta like a transparent Symmetry Object/generator).

Quote - Gladly, as I have ZBrush, I only needed C4d for my pupil morphs, so I was "faking" a manual symmetry: selected a single point, the same in both sizes, turned soft selection on, moved up and down only; for side movements, I used Scaling instead, so that the points would come closer together or farther apart.

Ahh.. yeah, I do the same thing, quite often.  I also use the "Selection Symmetry" command of my Undertow plugin to help with that :)... (I feel another self-serving ad coming...)

Undertow also has some other commands useful for Poser 'newly generated Symmetrical mesh' creation (like "Group Mirror") and lots of UV-related commands. (it's commercial as well, but reasonably priced and has a 30-day free trial period).

While I'm at it, my Morph Mill plugin might also be interesting to try out when you get the time.

Anyway, I'm looking forward to your morphs - they will be very handy!

Quote - ...(by the way, does it help at making symmetrical UVs?)...

Yes, in fact I was just using it...

...I spent a fair amount of time generating and tweaking the uv-mapping for the left hand of my model (hilighted, on right) and then used the UV Symmetry command to have that mapping mirrored to the right hand.

I don't want to continue jacking your thread, so I sent you a pm :).

Quote - ...then use the V3 mapped Toni...)

Does anyone have a handy link for that?

...nevermind - I found it on the home/development page.

Hmmm... the V3-remap is 'nice', but has some problems (note: doing a remap like this is a ton of work and very tedious - so I mean no disrespect for all the work dph did with this!)...

• some 'coloring outside the lines' :) (uv-vert positions outside/larger than V3's - and thus outside the texture in some cases)
• the UVs on the hi-res figure did not have Catmull-Clark smoothing applied when sub-divided (each 'new' sub-divided uv-vert is in a straight-line between the parent verts, instead of falling on a curve between them).
• some general distortion in some areas

...I think I'm going to take a stab at remapping it (I'll let you know when I'm done if anyone's interested).

I'm currently / specifically looking for V3 at the moment (so I can use Morris' excellent texture), but I'll consider doing a V4 remap afterwards.

Quote - I'm currently / specifically looking for V3 at the moment (so I can use Morris' excellent texture), but I'll consider doing a V4 remap afterwards.

...ok, I ran into a bit of a snag...

My plan was to remap the lo-res version (fewer uv-polys to deal with) and then sub-divide the mesh to (re)create the hi-res version of the mesh (which would also carry over the new uv-mapping, but sub-divided nicely).

I did the remap of the lo-res mesh and it looks great.  The problem I'm running into is when sub-dividing the mesh to generate the hi-res mesh...

• vertices get re-ordered.
• polygons get re-ordered (and thus, the uv-polygons)
• 'slight' differences in the final positions of some vertices - likely due to the 3D software I'm using to do the sub-divide, but possibly also due to some 'options' (vertex weighting) of that process.

...I have tools (plugins I've written) to help me with the first two issues, but they kinda rely on...

• same number of vertices/polys - no problem here.
• the uv-mapping being identical - which is obviously not the case here, since the point is to generate new mapping, or...
• the polygon-ordering being identical - which is not the case here... and/or...
• at least having the vertex positions all identical (within some small tolerance) - which is also not the case here...

...so... the biggest areas of the mesh where the vertices are different is:

• finger-tips (including fingernails)
• toes (including toenails)
• a few vertices around the nipples
• every vertex where teeth-meet-gums

...so... I have now gone back and clipped out portions of the original mesh (for example, finger-tips w/nails, toes w/nails) and merged them back onto my new hi-res mesh.  I had to re-uv-map those bits (extremely tedious), but at least the vertex positions are now correct.  Here's a sample image using one of Morris' V3 textures...

...and just for yuks, here's a head-shot...

...so... the last remaining issue/area are the teeth/gums mapping.  In order to copy/paste this portion of the mesh over (and getting it remapped) will be very tedious - so I'm considering just pasting it in with the Antonia mapping.  In other words, the following Materials would use Anotnia textures instead of V3 textures...

• Teeth
• InnerMouth / Gums
• Tongue

...speaking of which, Antonia's eye-mapping is close enough to V3's that I also left that alone (you can use either Antonia's or V3's textures).  I also followed dph's V4 mapping of the eyebrows (the closest in mesh-shape to Antonia's).

Anyone have any comments for/against leaving Antonia mapping on the inner mouth parts?

Thanks.

BTW, I've also managed to remove a lot / most of this texture-stretching/distortion...

...here's my remapping...

...note that you might not even notice much of that distortion when using some textures, but there are (were) some detail areas where it's fairly evident.

Ahh - that might explain it - thanks... I'm using Cinema 4D and when I sub-divide the mesh (using Catmull-Clark), I have an 'option' to add weighting to any vertices/edges to help keep them 'sharp' (for example)... it looks like he may be doing something similar in some areas, but there may also be some slight differences in how the Catmull-Clark routine is implemented.

The majority of the mesh is 100% identical, but the afore-mentioned areas (finger-tips, toes, etc) are coming out 'off' a bit.

My plugins attempt to (basically) do what you suggest, but the problem is...

The areas that are 'off' are in places where lots of tiny polygons (ie. very close vertices) are bunched together, so trying to find matches between the two meshes is problematic - the 'closest' vertex in the original mesh may not be the 'matching' vertex.

My plugin loops through comparing all the vertices of one mesh with the other mesh (within some 'tolerance' distance), marking off vertices as it finds matches, then loops again with greater and greater tolerances, looking for the closest match for each vertex (out of the remaining un-matched vertices).  The problem is those false-hits (we've seen these before, eh? :) ).

Once I manage to get identical vertex-location-equivalence, I can re-order them to match the original mesh and use a look-up table to remap the polys using those vertices (and the matching uv-polys), based on the newly re-ordered vertices.

Anyway, I'm mostly done now (I think)... it's mostly now down to the question of whether I want to spend the time re-mapping the inner mouth parts to match V3 (again) or just leave them with Antonia 1.2 mapping.

...the more general problem is - that 'nothing' matches, so I don't have any frame of reference.  In other words, if the poly orders were the same, I could use that as a frame of reference to find (or at least test) the vertices.  If the uvs matched, I could use those as a reference to find the polys/verts.  If the verts all matched, I could use those to find the polys/uvs, etc. :).

At this point, I think I finally have all the vertices matching, so I can get everything re-ordered.

Quote - Hey Spanki,

Like Cage said, I wrote some tools for this kind of thing, back in the day. They match mesh topology, not positions or orderings, so they should be pretty robust. Basically, you can take two meshes with the same topology and transfer any kind of information - vertex positions, UV positions, grouping - back and forth between them. I used this a lot while working on Antonia, particularly for propagating UV maps from the low-res to the high-res version and such.

I've never really bothered to give these tools a decent API or at least prettify the command line interface. But if you want them, and I can still get them to compile, you can have them. If you prefer source code, you can find that here: https://github.com/odf/scala-meshes

The code is pretty ugly, because it was my first exercise of programming in Scala (which I since have abandoned as a language). Otherwise, I'd have suggested that you could just study what I did and replicate it. :-)

Cheers,

O.

Ahh - thanks for the info.  I am a little confused about your explaination though -  maybe it's a matter of semantics / terminology, but...

Quote - ...They match mesh topology, not positions or orderings...

From my understanding, 'mesh topology' is basically defined by the layout of the polygons, which in turn are defined by the 'positions' of the vertices that make up those polygons.  I don't know how you could be comparing mesh topologies without (ultimately) comparing vertex positions (?).

I don't know Scala, but I'll take a look at that code - thanks.

BTW, I know that it's mentioned ('somewhere') in this long thread, but who did the newer (non-A version) uv-mapping of Antonia 1.2 ?  Or perhaps more importantly, do you know what tools they used for it?

Quote - Does your process leave the hi version morph compatible with the standard Antonia hi res?

Thanks for the comments and... yes, that's what I'm (was) trying to do with all the vertex re-ordering.

I now have it all re-ordered and remapped.  I'm just going through it making sure that I have all the grouping and material zones fixed up.