Basically what it does is create a 'Prop' out of your morphed figure - with the morphs applied - to the original .obj file vertices without any rigging-induced error.

You can then Export this prop as a .obj file to be used as a 'mannequin' in your 3D app for creating morphs in clothing for that (morphed) figure.

Cheers.

Quote - @Spanki:

No, I'm not on a PC. I have a Windows VM on my Linux machine at home, but no C++ on it (yet). If your program needs Microsoft compilers or libs, I won't touch it, though. :-) Bummer, I didn't think of that. It's alright though, it's actually not too big an effort to redo the whole thing in something that's not Scala. It won't be C++, though, because I'm not a masochist. :-)

D'oh! :).  Out of the languages you listed, my vote would be Python.

Quote - > Quote - > Quote - > Quote - Does your method account for all of the above?  Without resorting to comparing vertex-positions (assume they are morphed out of position)?

Yep!

Very nice! I don't suppose you'll be converting that code to C++ any time soon? :)  I'd love to study it more, but without knowing Scala, it's tough for me to separate language-construct from the method implementation.

Fair enough! I don't feel inclined to implement all the necessary data structures and input/output routines in C++, though. If you had something I could plug it into relatively easily, I might give it a go. :-)

Hmm... are you on a PC?  I'm about to hit the sack, but after I get some sleep, I'll poke around and see if my S.T.O.M.P / Crunch (stand-alone windows gui, OpenGL 3d display, .obj file reader/writer, thingie) still compiles - I haven't messed with it for a few years, but it might be good enough to use as a test-bed.

Quote - > Quote - Does your method account for all of the above?  Without resorting to comparing vertex-positions (assume they are morphed out of position)?

Yep!

Very nice! I don't suppose you'll be converting that code to C++ any time soon? :)  I'd love to study it more, but without knowing Scala, it's tough for me to separate language-construct from the method implementation.

Quote - A program to design and edit Poser dynamic hair files.  It would need to be able to handle line geometries, perhaps work with splines.  If the formatting is handled properly and the base vertices for the hairs aren't moved, an external tool should be able to handle Poser hair.  Making dynamic hair accessible would be a big boost for Poser.  :laugh:  

My Riptide Pro plugin (for Cinema 4D) will convert line records ('l' records in .obj files, which Poser uses when writing out dynamic hair-guide-splines) into Splines within C4D.  You can then convert those splines to C4D Hair-Guide splines to use with it's Hair system.  Robert's interPoser Pro (a Poser file reader plugin for Cinema 4D) can also do this.

Unfortunately, neither plugin currently 'exports' these splines (back into a .obj file), so it's a one-way trip.

Quote - When I say topology, I mean what you get when you look at a basic OBJ file without texture coordinates or normals and ignore everything but the 'f' lines. Basically, that tells you that have a certain number of vertices, numbered from 1 to, say, 14512, and that certain cyclic sequences of these form polygons. If you change all the numbers consistently - say, you add 1000 to each - you still get the same topology...

Hmm... I've been working with .obj files for 10+ years now and my most popular plugin is actually .obj file IO filter (Riptide Pro, for Cinema 4D), so I'm pretty familiar with the subject :). So just to clarify some terminology...

v <-- vertex line/record

vt <-- texture-vertex (uv-coordinate) records

n <-- normal records

f <-- 'facet' (polygon) records

...so looking at the facet lines in more detail, each one describes one polygon (indices into the v/vt/n tables).  If we ignore texture-vertex indices and normal indices for the sake of discussion, a sample might be...

f 1 2 3 4
f 4 3 5 6
f 6 5 7 8

...in my example above, I'm describing 3 rectangular (quad) polyons, lets say stacked on top of each other, using a clockwise vertex-ordering (the 1, 2, 3, etc. numbers are "indices of the vertices" that make up each polygon).

If the 'order' of the vertex-table changes, then those indices would also change. Note that the order does not necessarily (doesn't have to) change in a polygon-homogenous way.  In other words, it's possible that vertex '1' is now vertex '6', vertex '6' is now vertex '3' and vertex '3' is now vertex '1', so the new facet records would look like so...

f 6 2 1 4
f 4 1 5 3
f 3 5 7 8

...it's also possible that the 'starting point' of the polygon ordering has changed.  for example (using just the first polygon from the first group, above)...

f 1 2 3 4
f 2 3 4 1
f 3 4 1 2
f 4 1 2 3

...each describe the exact same polygon, but the starting index shifts around.

Finally, the order that the polygons themselves are listed may also change (using the first group as an example)...

f 1 2 3 4
f 6 5 7 8
f 4 3 5 6

...or using the second example, where the vertex indices have changed as well...

f 3 5 7 8
f 4 1 5 3
f 6 2 1 4

...I briefly looked at your Scala code, but a) I'm not familiar with the language and b) not terribly familiar with hash-tables...

Does your method account for all of the above?  Without resorting to comparing vertex-positions (assume they are morphed out of position)?

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.

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?

...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.

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.

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.

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.

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.

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.

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).