Why do STL meshes from SolidWorks sometimes contain rendering artifacts?

[adamkewley]

This question was ported from a combination of an in-person discussion and an email, so some details are REDACTED, but I kept a screenshot of the initial problem in this discussion so that SolidWorks users know what to look for.

I have designed mechanical parts using SolidWorks and now would like to use the parts, exported as STL files, in OpenSim Creator and OpenSim, but I'm seeing rendering artifacts like below after updating from OSC 0.5.7 to 0.5.8:

Before (0.5.7):

The kind of rendering artifacts that 0.5.8 shows (also show in Blender, pictured here):

And how it looks in OpenSim GUI:

[adamkewley]

I think I can see some of the problem. Essentially, the earlier OSC (0.5.8) was using flat shading, which you can simulate in Blender by right-clicking the mesh and then clicking "Shade Flat". If you do this then (e.g.) the bottom bracket of your Metacarpal​ looks flat. Here's what I see in Blender 4.1:

However, if I look at the file with smooth shading (the default, and uses a similar algorithm to OSC 0.5.9), these weird shading artifacts start to pop up:

They aren't related to winding (as you've already investigated). They are because the STL file is sharing vertices on sharp corners. E.g. this vertex, highlighted white:

Is participating in triangles inside the barrel and on the base's surface. The surface normal inside the barrel is (e.g.) {0,0,1}, whereas the base's surface normal is {-1,0,0}. The smooth shading algorithm takes the arithmetic mean of all triangle surfaces connected to a single vertex, so this particular vertex will end up with a normal like {-0.5, 0, 0.5}, which is why you're seeing funny shading artifacts.

The original algorithm (flat-shading) does not take this arithmetic mean and, instead, assigns a unique vertex for each triangle in the mesh (i.e. it ignores sharing) and assigns each vertex a normal based on each independent triangle's surface (which is why flat-shading shows those little creases you see).

Solution for OpenSim/OpenSim Creator (and any software that uses smooth-shading but doesn't support normals in datafiles):

• Import your STL mesh into Blender
• Select it and enter edit mode (TAB)
• In the top menu, go to Mesh > Split > Faces & Edges by Vertices​
• Re-export the mesh as an OBJ
  • Ensure that the "Forward" and "Up" axes match the "Forward" and "Up" of the STL import (on my machine, the STL import defaults to F=Y, U=Z but OBJ export was defaulting to F=Y, U=-Z)
  • The format does not need to support normals, but blender's STL exporter seems to ignore the splitting operation.

This should result in a flat-shaded representation in OSC, but it somehow manages to look even worse in OpenSim GUI. I would guess that the reason there are issues in OpenSim GUI is because it has some upper limit on the number of triangles in a mesh (e.g. 65k). I will investigate whether "Smooth by Angle" should be a default part of OSC's mesh importing (or investigate adding normals support to OpenSim itself, but that requires coordinating with other teams, etc.).

Solutions for non-OpenSim platforms:

• When rendering the STL in VFX software use flat shading. Alternatively, use "Shade Smooth by Angle" (e.g. in Blender) and set the angle to something like 15-30 deg. "Shade Smooth by Angle" will test each triangle's normal against the arithmetic mean and selectively flat-shade triangles where the angle between the triangle and the mean is above some threshold (if that makes sense?)
• When rendering in non-VFX software that supports loading normals from data files (e.g. OBJs), use VFX software to "Shade Smooth by Angle" and re-export the mesh in a format that also exports normals (e.g. OBJ, gltf)

[adamkewley]

AK: This was a later reply from the same user in the email chain

I tried out the method you described and it worked! What I tried so far for Opensim GUI is using the decimate function (and setting it around 0.6) in Blender which improves the mesh a little bit in the OpenSim GUI and scaling down the mesh 1000x, because Solidworks works with mm and I know that OpenSim uses meters. However, I don't know if using decimate I am removing some important faces from the mesh because at some angles the mesh seems to be less filled in, if that makes sense. Unfortunately, the combination of using decimate and splitting the faces and vertices does not result in the same results in OpenSim GUI:

[adamkewley]

AK: reply to reply

I cannot say for sure, but if I were guessing, I would guess that OpenSim GUI is using 16-bit indices to index triangles in the mesh, which has an upper limit of ~65k vertices. OSC has already encountered problems with this (e.g. high vertex-count CT scans) and has code to upgrade a mesh to 32-bit indices (i.e. up to 4 bn vertices) if the user provides high-vertex-count data.

I mention this because it might help with finding the 'edge' on decimation (i.e. stick it around 60k verts or so and try it out in OpenSim GUI - I'd bet that it's probably fine but something higher, like 80k would start to show the artifacts)