I received a 3d mesh model from a customer in OBJ file format that has some very strange material with extreme highlights that I can’t override with a Rhino material. No matter what I try, that object’s material is unremovable. It’s also not shown in the material list, meaning that it’s either some hidden material or the object has hidden properties that the ! _MatchProperties command is incapable to replace. Maybe it contains information from some rendering material or plug-in used in the program where the model was originally created. The mesh does not have vertex colors either. I can’t show images or share the file, because it’s confidential. Any suggestions?
These are colors or materials assigned to the Face per the import, use the RemovePerFaceColors command to remove.
Unfortunately, that does not help. Also, this command does not let me pick any of the mesh models.
For some reason, when I drag any mesh face, the unremovable material disappears.
I extracted several mesh faces, so that you can observe if this is a bug.
Unremovable material.3dm (133.6 KB)
The original material was paint, changed it to Paint 1 by dragging and dropping. Modifying the original material’s color is also an option. Modify the Shading Display to Rendered Material or Object color if need be.
That does not help in my Rhino 7. It changes the basic paint colour, but retains the unremovable material’s properties. I made a video of the process to show it. Seems like a bug to me.
In my opinion, the ! _MatchProperties command must be capable of matching 100% of the properties, including the removal of any “hidden” unremovable material that come from imported objects.
You’ll want to use flat shading mode and turn off casts shadows. I don’t work with meshes often but i believe this has to do with the welding angle
I just tried it, but it didn’t resolved the bug. In fact, the _FlatShade command “fixes” the mesh model just temporarily, but then everything else get flat shaded. Once I repeat the _FlatShade command, every other model is smooth again, but the mesh model shows its weird material like before.
Seems like moving one face somewhere and them moving it back to its original position is the only way to completely fix this bug forever.
Try the RebuildMesh command
1 Like
@Rhino_Bulgaria the mesh has weird vertex normals, and no face normals. Using _List the output contains:
20 mesh vertex normals:
m_N array hash ON_SHA1_Hash::1B49762A09F4721F9425C174F3FD82D549E9F415
m_N[0] = (0,-1,0)
m_N[1] = (0,-1,0)
m_N[2] = (0,-1,0)
m_N[3] = (0,-1,0)
m_N[4] = (0,-1,0)
m_N[5] = (0,-1,0)
m_N[6] = (0,-1,0)
m_N[7] = (0,-1,0)
...
m_N[13] = (0,-1,0)
m_N[14] = (0,-1,0)
m_N[15] = (0,-1,0)
m_N[16] = (0,-1,0)
m_N[17] = (0,-1,0)
m_N[18] = (0,-1,0)
m_N[19] = (0,-1,0)
You need to run just _RebuildMeshNormals
2 Likes
Thanks for the tip. I will try it later when I can.
I just did that and both, RebuildMesh and RebuildMeshNormals fixed the issue. I wonder why the ! _MatchProperties does not fix that automatically, since its current implementation leaves the unremovable material and its weird shading. 
Maybe “McNeel” should consider adding this option in the “Match properties” panel, because those bad mesh normals prevent the proper matching of properties and material taken from another object.
vertex/face normals aren’t object properties, whereas all the entries you see in the match object properties dialog are. Normals are part of the geometry itself.
addendum: you can say in this case the mesh data is bad.
The more important question is: Will “McNeel” prefer to leave this particular inconvenience in its current state (imported mesh models often look weird even after applying a Rhino material and can’t be fixed via _MatchProperties), or it will make the life of Rhino users easier via one of the following 3 ways?
a) including the fix inside the _MatchProperties command (either as a under-the-hood fix or an additional tickbox);
b) or offer an automatic detection of bad normals upon the import process;
c) or add an option to fix the normals inside the “OBJ Import options” panel.
While looking for a fix for the weird shading and inability of Rhino to render my custom material properly, I figured out that numerous people in the past years also had the same problems and they struggled to find an answer. This is why, I believe that it’s important to offer a more transparent and easy to find way to fix the aforementioned bad shading. Especially since “McNeel” puts a lot more effort on 3d mesh and Sub-D modeling in recent years, than working on NURBS surfacing tools.
Tip: Check how “Smoothing groups” in 3DS Max work. They are very convenient and allow for a full control over the shading of the mesh models. Just wondering if Rhino has an equivalent of “Auto smooth” in 3DS Max, which smooths out adjacent mesh faces based on a set threshold angle?
As mentioned earlier the normal data is not part of properties. Also, I originally said there were no face normals - I saw that incorrectly, there are. Just the vertex normals are weird.
I don’t know what the original format has for the vertex normals. It could be that they were set there on purpose like that. But for showing in Rhino it causes issues as you have noticed.
Anyway, the Rebuild commands help fixing the issue.
The closest you can get is with _Weld. But it isn’t the same as smoothing in autocad.
I’m aware with the fix of that graphics bug in Rhino, however, an optional automatic detection of bad mesh normals (or even under-the-hood automatic reset of mesh normals) upon importing meshes in Rhino could help a lot of other Rhino users. The mesh normals don’t change the actual 3d mesh geometry anyway, but fixing them automatically definitely can make the experience of many Rhino users smoother.
The file which I posted in this topic was in OBJ (object) format and as far as I know was originally created in 3DS Max. In my opinion, the dialog window that shows up upon importing any file format that supports mesh data must have a tickbox option to reset the mesh normals. This saves a lot of time and inconvenience.
For this I logged: RH-83295 Offer option to rebuild normals on import
1 Like
The bug is still present in another model, but this time both, ! _RebuildMeshNormals and ! _RebuildMesh, fail to fix the mesh normals. ! _UnifyMeshNormals also fails. Rhino urgently needs some better tool to make the end point normals normal to the polygon surface.
Rebuild mesh normals fails.3dm (38.1 KB)
This mesh has an overlapping triangle and quad that also are facing in opposite directions. Deleting the triangle and rebuilding the mesh normals fixes the mesh:
_MeshRepair also tellls you it is a bad mesh. The dialog is a bit unwieldy to use - I prefer just manually selecting the triangle and deleting it, then running either RebuildMeshNormals or UnifyMeshNormals.
I’ll log a bug for this (done: RH-83312 Artifact in mesh import ), although I’m not sure how this should be solved. I assume that this is already like that in the original data format from which this part is imported. If so then it’d probably useful to get that file so I can attach it to the upcoming bug report.
That said, if it is the case that the original file already has the error in the mesh then the fix really should be made to the original data in the program that it got authored.
2 Likes
This particular model is a small portion of a large mesh model created in Rhino 7 via “QuadRemesh” tool with to the following settings:
QuadRemesh this with anything between 200-400 target polygons.3dm (5.8 MB)
For some reason, I can’t replicate the same mesh topology as before. Maybe this command creates different output mesh every time? In the above picture, the white mesh was the first one created and used to report the bug. The light blue mesh is the preview of “QuadRemesh” using exactly the same setting as before. But there is a noticeable difference between the two meshes.
Here are two QuadRemesh meshes that consist wrong normals.
Bad meshes created by QuadRemesh.3dm (95.4 KB)
Bad meshes created by QuadRemesh 2.3dm (82.0 KB)
Note that these last few meshes are NOT a result of imported files, these are meshes created by Rhino 7 SR37 (7.37.24107.15001, 2024-04-16) with the ! _QuadRemesh command. However, similar bugs sometimes appear on other, imported models.
Interesting. I’ll update the bug report and attach the files so that our mesh wizards can look into it.
Is there any chance for the fix to be applied to Rhino 7, too?