Hello everyone,
I believe I’ve stumbled upon a potential bug in Rhino 8. Currently, I’m using Version 8 SR8 (8.8.24135.14001, 2024-05-14). As depicted in the attached image, there are several meshes with materials applied and one particular mesh with vertex colors. The vertex colors appear to be correctly applied in the original file. However, when I export the meshes in .OBJ format and then reimport it, the vertex colors seem to be applied to a different mesh.
You can find these files in the attached .zip archive: vertex-colors.zip (6.8 MB)
What downstream app are you using to read you obj file?
I think if you give the mesh with vertex colors and the red mesh object names and then export with Rhino object names set to OBJ "g"s you get an obj file that looks correct to me in an editor.
I think there may be something wonky in our importer that is getting stuff mixed up. I can clearly see in the editor that the mesh with ~20k vertices is the one that has vertex colors but the one with vertex colors in Rhino is the one with ~6k vertexes. All of the vertexes are in the right places though so it’s only getting the vertex colors mixed up.
I thought the problem with the top piece is that it has both a Render Material specified in the .obj and .mtl files in addition to it having vertex colors. My simpler .obj imported ignored the Render Material spec so it just shows the vertex colors. But even after removing the material from the .mtl file, the vertex colors are not shown when importing with Rhino.
This is what I get when I import the 4 meshes using Rhino.
In Rendered View:
I was confused about the objects needing names. They get assigned a name object_1, object_2, etc. if use Rhino object names as obj "g"s is checked and the object is nameless.
After further experimentation I found that the index reported in the Properties panel increments up every time the meshes are imported and do not impact the appearance.
So far I have been unable to get Rhino to import the top mesh and show the vertex colors like my .obj importer does. I tried removing the diffuse_250_250_250_255 material in the .mtl file but this did not do the trick.
But when I try to mix and match - one mesh with vertex colors and the other with materials - things go haywire.
I did find a workaround though. I can auto unwrap the upper mesh and transfer the vertex colors to a bitmap. Or, like @BrianJ suggested, using VRML 2.0 (.wrl) seems to do the trick. So, I’m gonna go with that and mark his answer as solution.
This is the result when I import the .wrl in Rhino 8
I think the troubles you may be running into with downstream apps could the same problem the Rhino importer had, which is now fixed btw. There are no vertex colors in the OBJ spec so adding them has to be a hack. What I’ve seen and what we do is add three floats from 0.0 to 1.0 or ints from 0 to 255 to each vertex that has a color. The mesh that had vertex colors in Rhino has vertex colors in the obj file. The problem, at least for the Rhino importer, was I was only adding vertex colors to an array when they existed. This happened at the same time vertexes were added to the array. The counts of the arrays were mismatched and that’s why you saw the weird meshes on import. Now I add a placeholder for color for every vertex and get rid of what isn’t used just prior to adding the mesh to the doc.
Brian James suggested to me that maybe we add vertex colors based on the display color (or diffuse material color) to meshes that don’t have vertex colors in Rhino on export. This may make it so your downstream apps can use them. I’ll talk to him more about this today. It’s an easy thing to do but I’m not sure which version of Rhino is appropriate since it will be sort of experimental code. I’d hate to break something that’s working for others.
Adding vertex colors the way you described is quite common. The .obj files generated by DroneDeploy and other photogrammetry programs use the same format with both the 0-255 or 0.0 to 1.0 range options employed.
That being said, I do not think always outputting vertex colors is a good idea as it may break some usages. It could be a user select option for sure but not the default.
Brian’s suggestion was not to always add vertex colors. The check box would remain and it would need to be checked in order for vertex colors to be exported.
His suggestion was, when the checkbox is checked, to add vertex colors for meshes that don’t have them already based on the display color in Rhino. Then the obj file will have a 1 to 1 correspondence between vertexes and colors. That’s the reason the Rhino importer choked on reading its own output.
Can you try the attached obj/mtl and see if it works in your downstream apps? It has vertex colors based on the diffuse color of the render material for the meshes that did not have vertex colors to begin with. The Rhino V7 importer will import it without messing it up so I think it may work better for you too.
Hi Tim,
I’ve successfully imported the obj/mtl files into various applications that I typically use, and it works excellently!
I noticed that the fix is scheduled for release in version 8.10.24169.06001, so I’ll be awaiting the release candidate. Do you have plans to implement this fix in Rhino 7.xx as well?
Thanks to everyone for their assistance! The support has been outstanding!
