Mesh artefacts is still a problem (R6.12)

Is this old mesh problem being addressed?


Perhaps there’s something wrong with the surfaces (the model was drawn two years ago, I think) causing the “rays” in the picture above when I opened it in R6.12 (version downloaded today) but, I have any idea how to track down the cause of these artefacts.

I made a copy of the vertical surface-slice from the item on the left and extruded it (the item to the right) and the problem multiplied…

Since this is a a fairly isolated problem in the model I post the failing part here, if it can help tracking down the problem:
Mesh Problem - L70.3dm (240.7 KB)

I see these kind of crazy artefacts in Grasshopper too all the time. It’s not very entertaining.

// Rolf

System info:

Rhino 6 SR12 2019-1-29 (Rhino 6, 6.12.19029.6381, Git hash:master @ ae9d7fba5fda0b43002dc44a34e059a9a382db04)
License type: Commercial, build 2019-01-29
License details: Stand-Alone

Windows 10.0 SR0.0 or greater (Physical RAM: 32Gb)
Machine name: RIL-POWER

Non-hybrid graphics.
Primary display and OpenGL: NVIDIA GeForce GTX 980 Ti (NVidia) Memory: 6GB, Driver date: 11-2-2018 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 416.81

OpenGL Settings
  Safe mode: Off
  Use accelerated hardware modes: On
  Redraw scene when viewports are exposed: On
  Anti-alias mode: 4x
  Mip Map Filtering: Linear
  Anisotropic Filtering Mode: Height
  Vendor Name: NVIDIA Corporation
  Render version: 4.6
  Shading Language: 4.60 NVIDIA
  Driver Date: 11-2-2018
  Driver Version:
  Maximum Texture size: 16384 x 16384
  Z-Buffer depth: 24 bits
  Maximum Viewport size: 16384 x 16384
  Total Video Memory: 6 GB

Rhino plugins
  C:\Program Files\Rhino 6\Plug-ins\Commands.rhp	"Commands"	6.12.19029.6381
  C:\Program Files\Rhino 6\Plug-ins\rdk.rhp	"Renderer Development Kit"	
  C:\Program Files\Rhino 6\Plug-ins\RhinoRender.rhp	"Rhino Render"	
  C:\Program Files\Rhino 6\Plug-ins\rdk_etoui.rhp	"RDK_EtoUI"	6.12.19029.6381
  C:\Program Files\Rhino 6\Plug-ins\rdk_ui.rhp	"Renderer Development Kit UI"	
  C:\Program Files\Rhino 6\Plug-ins\NamedSnapshots.rhp	"Snapshots"	
  E:\__Install\_install_local\XNurbsRhino\XNurbsRhino.rhp	"XNurbs"	
  C:\Program Files\Rhino 6\Plug-ins\RhinoCycles.rhp	"RhinoCycles"	6.12.19029.6381
  C:\Program Files\Rhino 6\Plug-ins\Toolbars\Toolbars.rhp	"Toolbars"	6.12.19029.6381
  C:\Program Files\Rhino 6\Plug-ins\Displacement.rhp	"Displacement"	

Hi Rolf - EdgeSoftening does not like these objects much I guess…


Mmm, I noticed that. :slight_smile:

But why? It seems to me to be be a “generic” problem with the mesher (a bug) since often I see this meshing problem in GH as well.

Even simple spheres (included in each other) can suddenly go bananas, with mesh “spikes” pointing towards the World center point (while working within 500 mm from the World center).

// Rolf

If you turn off Edge Softening, put a point on the intersection of the two surface edges where the artifact shoots out, and then zoom in on the point you’ll see that there is already a meshing problem.


The extracted render mesh also shows trouble here:


I don’t know if you could rebuild the object somehow so that you end up with cleaner geometry.

I tried exploding the object, then UntrimAll on all surfaces, but the result looked to confusing to try a quick one.

It looks like some of the modeling was done at a more coarse tolerance, then the tolerance tightened up later.

I found this by Exploding, RebuildEdges, and Join again.
It didn’t totally fix the issues with meshing but I suspect that was the cause of these issues.

The simpler polysurface is fixed by deleting the two flat side surfaces with the rounded corners, and using Cap to replace them.

At the lower tolerance of 0.01mm (default settings for V4), I deleted one of the similar shaped faces and replaced it with Cap, and now the two polysurfaces seem fine.


@John_Brock &

It all looked good in R5 which was used to draw this. I don’t recall about any tolerance tweaking though (too long ago).

To me zooming in doesn’t show anything meaningful (about the cause). I also tried to test for continuity and get expected results G1 and G0. Shouldn’t surfaces be OK with what you see and after checking continuity?

I also tried to recreate the big flat surface on top (which has the problem in that corner), but the problem remained, which makes me think that the root cause here is (/was) likely not tolerance tweaking.

But, if I recreate the vertical surface (with two rounded corners) the problem seems to go away. That in turn raises the question why I couldn’t spot the problem by visual inspection (can’ zoom close enough) nor checking continuity.

I clearly must have missed something in your (and @nathanletwory’s ) attempt to explain.

To sum up - a model which was OK in R5 was not so in R6, and I could not spot the problem visually or by checking the connectivity of the edges. :frowning:

// Rolf

The only way I know to spot a tolerance change or a user that has used JoinEdge inappropriately, is how I described:

  1. Explode
  2. RebuildEdges
  3. Join
  4. ShowEdges

OK, thank you for that hin. I have acually tried quite a few ways to fix this, for example MergeAllEdges. But I never tried “RebuildEdges”. Good to know that that is what to try next time. But what does RebuildEdges do which MergeEdge doesn’t do?

I just want to learn how to figure out how to solve problems like this in the future. Because the mesher seems to have become very (very) picky in R6… :wink:

// Rolf

(my keyboard suddenly only reluctantly passes on letter t and u, hence numerous spelling errors)

RebuildEdges undoes the visual changes that Joining does.
Many time after rebuildedges, you can zoom in at the corners and see the problems.
If you really needed the higher tolerance, then moving control points or replacing ill fitting surfaces is the technique.

Here’s the corner of a box with the corner points moved 0.001mm away from each other:

After Join with a tolerance of 0.001mm:

After Explode:

After Rebuilding the edges:

Change the tolerance to 0.0001mm and Join:

OK, thankis. Got it. :+1:

// Rolf