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

 

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.