CreateMeshes bug?

Hi,

I have a Python script which worked rather well for two years. It exports the scene mesh & transformations to a XML format for use in an external tool.

Recently I came across an error in the exported mesh normals, happening on one polysurface object in a complex scene. Some vertex normals seem random, the error is reproducible and can be isolated to a single object.

I create the mesh with :

object.CreateMeshes (Rhino.Geometry.MeshType.Render,
                     object.GetRenderMeshParameters(),
                     False) 
meshes = object.GetMeshes(Rhino.Geometry.MeshType.Render)

Then I access the mesh properties with:

for v in mesh.Vertices:
for n in mesh.Normals:
for f in mesh.Faces:

As mesh faces contain only vertex indices, I assumed that normal indices are the same, and that there is exactly one normal per vertex (which is not true in any 3D software)

By debugging the erroneous polysurface, I noticed that the render mesh has not the same number of vertices and normals : 128963 and 128949

However, If I manually convert the polysurface to mesh in Rhino before exporting, this problem disappears.

Is this a bug or can there be different vertex and normal count in Rhino meshes? In this case, what are the normal indices?

Thanks!

Hi Etienne,

can you post the mesh to inspect it. Usually a clean mesh should have the same amount of mesh vertices and vertex normals. But there are cases where unreferenced vertices do not have any normals.

c.

test.3dm (1.2 MB)

This is actually not a mesh, but a polysurface. I’m speaking about the render mesh generated by CreateMeshes, which is missing some normals. With this example I am getting 5658 vertices and 5656 normals.

Hi Etienne,

Inspect the brep closely, the geometry clearly has some problems. Some of the surface trims near the floor area seem to be out of tolerance so proper meshing can not be as expected. It generates initial vertices but no surfaces (and normals) in this case. I´m a bit surprised that these surfaces are not found when using _SelBadObjects.

Usually, if surface isopharms are ending somewhere but not on the edge or trim edge, or if surfaces are folded like in your example, i would not rely on the mesher to give you something usable. Unfortunately, this geometry has to be fixed first.

c.

I know the geometry has some problem, but the mesher creating indices pointing to missing normals in this case is a bug.
And strangely, manually doing “Surface to Mesh” instead of using the render mesh does not exhibit this issue.

I agree that invalid surface might generate meshes that are not looking good or no mesh at all, but not that Rhino is right by generating dangling triangle indices…

Yes, i agree with that. Meanwhile, until this can get fixed, you might work around the problem by doing some pre-check before export like this in your script:

    # check for different count of mesh vertices and normals
    if mesh.Vertices.Count != mesh.Normals.Count:

        # get the id of the problematic brep 
        brep_id = .........
        rs.UnselectAllObjects()
        rs.SelectObject(brep_id)

        result = rs.Command("_ExtractRenderMesh", False)
        if result == True:
            mesh_ids = rs.LastCreatedObjects(True)
            mesh_id = rs.JoinMeshes(mesh_ids)
            rs.UnselectObject(brep_id)
            mesh = rs.coercemesh(mesh_id)
        else:
            print "Error extracting rendermesh"
            return False

        # use this mesh instead for export
        return mesh
        # delete the rendermesh after export

    else:
        # export as usual

c.