Possible BUG with Analysis mesh?

The attached pipe model is an offset surface (5 mm bigger, “Loose” option enabled to preserve the structure) of a pipe that was made from a simple arc. However, when trying to apply any analysis tool, such like Zebra or Curvature, Rhino fails to do so. It takes forever to calculate an analysis mesh. If I trim the pipe somewhere, the Analysis tools work just fine. The issue is present when the pipe is not trimmed…


Analysis mesh fails.3dm (205.5 KB)

Hi Bobi - one thing I notice is the analysis mesh setting - max distance edge to surface is .002 mm - clearing that setting, (overrides the max edge length if in conflict as far as I can see) or making it larger allows the mesh to be created. .005 works, here, .002 is indeed vary slow.
A good way to set anlaysis meshes is to leave all the numbers ‘reasonable’ or even zero (=Off) and set a large number in ‘Maximum initial grid quads’, like 5000 or 10,000.

The initial quads are fast to generate, even in large numbers and sort of force the mesh to be evenly divided and close to the surface just through sheer numbers. It is not efficient of course in terms of mesh size so don’t use this idea for shading/rendering meshes.

1 Like

Thank you for the explanation, Pascal!
I used that setting for a very refined result and it worked on any model (even complex polysurfaces made of hundreds of joined surfaces) except this simple pipe.

Can you tell me which of the parameters in the Polygon mesh detailed options will override the others? It seems like Rhino regularly ignores some of them. For example, recently I had one occasion where I was unable to force Rhino create an analysis mesh of a 3 mm diameter circle (not flat; part of a trimmed double-curvature Sweep 2 rail surface) with more than 8 sides, even though I set “Maximum edge length” at 0,1 mm and “Minimum initial grid quads” to 10 000.

Also, I find it strange that Rhino will always render spheres with way too many polygons, despite using the “Jagged and faster” render mesh quality setting. For example, a sphere with 2 mm diameter uses a whooping 18752 triangle polygons. It’s a bit unnecessary to use that much geometry for such a tiny object. Considering the size, number of polygons should be no more than 600-800. It would be nice to set more strict maximum amount of polygons when using the default rough mesh setting. Here are some interesting results when using the “Polygon count” tool:

0,1 mm sphere = 528 triangle polygons
1 mm sphere = 3968 triangle polygons
2 mm sphere = 18752 triangle polygons
3 mm sphere = 18752 triangle polygons
5 mm sphere = 18752 triangle polygons
10 mm sphere = 18752 triangle polygons
20 mm sphere = 18752 triangle polygons
50 mm sphere = 18080 triangle polygons (fewer polygons than the 2 mm sphere, despite the bigger size)
100 mm sphere = 14136 triangle polygons (more than 4500 fewer polygons compared to the 2 mm sphere!)
1000 mm sphere = 18752 triangle polygons

Hi Bobi - can you send a screen shot of the full mesh settings for these examples?


It’s the default “Jagged and faster” setting found in the “Options > Document properties > Mesh” menu, with “Large objects, millimeters” pre-set. No detailed mesh settings are shown.

Hi Bobi - I get different results, here, from yours - I get the same number of vertices, give-or-take a few, for a mesh from ExtractRenderMesh of a sphere, regardless of the radius. Oddly, Smooth and slower returns more, by ~1200 or so. The numbers are not the same as yours -
8385 vertices, 8192 faces
Still more than is needed, in this case, for sure.


Hi Pascal. I also noticed that a 10 mm diameter sphere will actually have a lesser polygon counter when the “Smooth and slower” option is selected. It returns 16128 polygons, compared to 18752 polygons for “Jagged and faster”. One would expect that the latter would unload a huge amount of geometry from both the CPU and GPU in order for the scene to run at a higher frame rate and to reduce the file size. This is for a close-up view of the sphere with “Zoom selected” used, on a FullHD resolution.
However, even more odd is that when I zoom out the camera so that the 10 mm sphere get about 1 pixel big, its polygon count (sort of LOD like what’s used in the video games on distant objects) changes to 17312, which is in fact an increased number of polygons compared to when the sphere is shown at close-up. This is also against any logic. At that size the sphere’s LOD should turn in into a cube with 6 square polygons (or 12 triangles), because there is no reason to waste graphics power to render whopping 17312 polygons for something that looks like a tiny dot. Maybe you get different polygon count number, because the sphere on your side is located at different distance from the camera.

Also, it seems like it’s unnecessary to over-burden the GPU with so many polygons for a simple sphere with 1 mm or a few millimeters of diameter, since most of the time it will take no more than 1 pixel from the screen, unless the camera is too close to it. That’s a lot of valuable graphics power used onto objects that are unnecessarily heavy in the polygon count department.

I think that if the default meshing settings for the rendering engine are more optimized that would make Rhino 6 considerably faster, especially with scenes that involve spheres or similar objects.