thoennes posted at 4:28AM Sat, 14 March 2020 - #4383501

OK. This seems to work:

Mirror a morph (create a "flip" or "reverse") morph on a symmetric mesh actor or set of actors that, combined, yields a symmetric mesh.
IE: a symmetric Hip mesh or a Hip+rThigh+lThigh mesh. This is symmetric about X=0 (the presumed centerline of a body)

Just for the records:

Lets take the hands as an example- Left and right, both don't start at X-coordinate 0. But - if you add the lowerst X-coordinate from both geometries, you get zero. Or, with other words: Assuming 2 symetric points from left and right hands geometry, the distance to 0 is equal for both of them. The bodys centerpoint can be ignored :)

The approach: unimeshinfo seems to produce a mesh that's incorrect. That is, not every vertex_index in the unimesh GEOM is mapped by the sum(actor_vertices).

If you simply add up all actor vertices. you add a bunch of duplicates. Each point on the seam of a bodypart is counted twice: In the current actor and in the actors parent.

That is why unimesh exist: Unimesh geometry is not splitted in parts. To preserve vertex count, the Poser-programmers used to set the duplicate coordinates to 0, 0, 0. This works (each vertex stays in his original position), but leads to another problem: No polygon refers to this entries. So external modeling apps want to remove this bad vertices. Some while loading this object, others don't want so save unused points. But that's another story. Fact is: Adding up the vertices and comparing with unimesh can't work.

Then I make a 3 key recursive dict on vert[x][y][z] = list_of_actor.verts_with_that_coordinate (with XYZ being ints to specific precision).

Maybe it's not a good idea to use numerics as keys for a dictionary. They are not made for this (look into the Python docs for deeper info how dictionary keys are handled internally). Beside of that, a dictionary needs a lot of memory. And you are using three of them per vertex...

---