SubD bad normals?

I have a low-poly model that I need to apply a SubDivide to for a higher quality render. I am able to do so, but when I import the .obj into my rendering software (Luxion KeyShot), it appears the normals didn’t calculate properly. The problem is, I recalculated the normals, and while it’s improved, it’s definitely still unresolved. In the example images below, I applied a chrome material to better show the issue I’m having. I’m guessing the real issue is something else that I’m unaware of. Can someone with more experience tell me what I’m running into?

This first image is before recalculating normals

This next image is after recalculating normals.

Hi Will,

That looks like double verts in the mesh to me. In Rhino use WeldVertices and select the entire mesh for each part. Then send a new obj over to your renderer. Any luck?

I don’t see how this relates to the category you posted to though. Were you using the SubDfromMesh command as a way to increase the density of your mesh?

Thank you for the reply. I tried WeldVertices, but had no luck - same results. However, I kept experimenting after that, and I got lucky and found the culprit. When exporting the mesh to OBJ, I unchecked the “Create NGons” option under the “Mesh” tab. It looks flawless in my rendering software now. I guess KeyShot doesn’t like NGons.

I apologize for this being in the wrong category. Yes, I wanted to increase the density of the mesh. I initially tried the SubDFromMesh command, but Rhino was giving me an error when exporting the resulting SubD’s to OBJ files - “The file writing plug-in failed”. I noticed that using the SubDivide command instead still gave me the result I was looking for, but instead of replacing the meshes with SubD objects, they remained meshes. As meshes, I was able to export to OBJ.

Thanks for explaining more and I’m glad you got it fixed. Yes Ngons can cause issues in some renderers when being smooth shaded. SubDivide is a mesh command and would smooth the result as you found. SubDfromMesh makes a sub-division surface and works best if you give it all quads. To get that subd object out to an OBJ, use ToNurbs on it first, Join all the patches into a PolySrf and then Export that as an OBJ.

Thank you! Is one technique (SubDivide vs. SubDFromMesh > ToNURBS > Join) going to be more accurate than the other? Or is there another reason to use one over the other (other than having NURBs objects that are easier to manipulate)?

I don’t know which will be more accurate. I suspect the base mesh you start with is a factor there. I bet the results will be similar. The advantage of going to a SubD surface is that you could edit the control points to make changes easily just as you would with a normal NURBS surface. I’ll drop a secret test command on you too though in v6… TestSoftMeshTransform can be used to enable proportional editing on the verts on a mesh. I’m hoping this idea gets expanded to work on any ctrl pts in a future Rhino version but it may help you here with mesh edits.

1 Like

Thanks for all your help!