Mesh vertices added importing .obj file; what is Rhino doing?

Rhino
, , , ,
1

(Forgive me if this is a noob question; point me towards the right docs if so.)

I’m considering using Rhino/Grasshopper to manipulate and analyze meshes created by a body scanner. When I take a .obj file from the scanner containing a single, watertight mesh and import it, Rhino consistently adds duplicate vertices to the mesh.

This is a problem, as I’m comparing homologous meshes; preserving the order and number of vertices is the ante.

However, if I import the .obj file choosing “Import as morph target only,” I get the correct mesh data. This makes superficial sense to me, as any vertex data used for a morph has to match vertex count and order. Note that the number of faces/triangles isn’t affected in the import. Saving the morph import as a Rhino file preserves the correct vertex count in subsequent file opens.

So I seem to have a workaround, but I don’t understand why importing an otherwise well-formed, watertight mesh should step on the data when it’s imported. Any thoughts?

(The workaround does get me the data I need, but it also has the side effect of losing any parameter space coords in the .obj file, as morph targets don’t need texture or normal info.)

And apologies, I can’t provide a sample file, as the body scan data I’m using is from real people, with attendant privacy issues.

Here’s a comparison of the detail display from the two mesh imports:

Default file open/import

    Closed double precision polygon mesh: 50991 vertices, 99056 faces with normals
      Bounding box: (-0.5229,0.000138377,-0.152599) to (0.648143,1.64724,0.180045)

Import .obj file as morph target:

    Closed double precision polygon mesh: 49530 vertices, 99056 faces with normals
      Bounding box: (-0.5229,0.000138377,-0.152599) to (0.648143,1.64724,0.180045)

Thanks!

Rick

2

Hi Rick - see if the Weld command sorts that out in Rhino.

-Pascal

3

Thanks, Pascal!

Doing a weld with a parameter of 180 degrees will remove all the dupes, ie a brute force merge of all duplicates, no matter how far apart their normals are.

(One note, the original data has texture params, but not normals.)

A quick, cursory spin through the resulting vertex coords seems to show that the coordinate data is intact, and in the correct order.

Texture data looks to be scrambled, definitely pointing to different tuples in the list, a spot check shows some are just reordered, but some values are different.

So main problem solved, but not the ancillary one.

Any idea what the cause is?

Rick