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

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.