Inaccurate mesh extraction

Rhino Developer
1

Hello,

In the attached .3dm example (MeshExtractionAnalysis.3dm (1.9 MB)) I have to extract the mesh from the surface in the “Surface” layer.
In order to reach my purpose I use following code:

const double tolerance = 0.005 / 3.6; // 0.0013888888888888889

ON_MeshParameters meshParameters = ON_MeshParameters::DefaultMesh;
meshParameters.SetTolerance(tolerance);
meshParameters.SetGridAspectRatio(0);

ON_Mesh* mesh = brepFace->CreateMesh(meshParameters);

Unfortunately, the extracted mesh seems to be farer away from the surface than the tolerance I set.

I want the maximum distance between my surface and the extracted mesh to be less or equal to the set tolerance.
What did I go wrong?

From your documentation (Polygon mesh detailed options | Rhino 3-D modeling):
Maximum distance, edge to surface
Polygons divide until the distance from a polygon edge midpoint to the NURBS surface is smaller than this value ….

At this point, in order to measure the distance between the mesh and the surface, I created points on the polygon edge midpoints and used ClosestPt command in order to have the distance between points and surface. The result is 0.828 mm. (See layer “SurfaceResult”)

Is it the smartest way to measure the distance edge to surface with Rhino?

Moreover from your documentation (Polygon mesh detailed options | Rhino 3-D modeling):
Maximum aspect ratio
The default value for this option is zero …
while, If I don’t set the grid aspect ratio, it turns out to be 6. That is the reason why, in the code, I explicitly set this parameter to 0. It seems different about what I read. Can you explain this behaviour?

Attached you can also find a Rhino command containing the full code I used in order to reproduce the problem (cmdTestAlberto.cpp (2.8 KB)).

Thank you in advance,
Alberto

2

Hi @margari,

With Surface being curved and SurfaceResult mesh only has 2 faces, your observation seems correct.

You might just run Rhino’s Mesh command, noodle the settings until you get what you want. Then plug those values into ON_MeshParameters.

– Dale

3

Dear @Dale,

Thank you for the prompt reply.

Still, I need to have further clarifications.

My application has used the reported ON_MeshParameters settings for a long time and it has to work (potentially) with all the geometries. Now I discovered that with this particular geometry, it doesn’t work as expected by me. What I need is to understand if I’m setting any parameter in a wrong manner, keeping into account that this new parameters setting will be used for all my customer geometries, since now on.

In particular, I need to understand:

1: Why the tolerance parameter is not respected: is it an expected behavior (maybe there is an other parameter that disables its application) or is it a bug? Does exist a way to force the routine to respect this parameter?
2: Why the grid aspect ratio default value is not 0 as the documentation reports? Could it cause any other unexpected behavior or explicitly setting it to 0 is enough to fix this mismatch?

Please keep also in mind that I have to keep the extracted meshes less dense as possible since denser meshes result in slower computations. Therefore I want to add a new constraint to my parameters setting only if it is strictly required, and legitimated by documentation.

By the way, I tried to use Rhino’s Mesh command, as you suggested, but when I set the parameters with the same values that I used in ON_MeshParameters structure, the extracted mesh results close to the surface and respects all the given parameters. Anyway this would not be a solution for me since I need to fix the problem for all the possible geometries and not only for this peculiar example.

Thank you,
Alberto

4

Hi @margari,

I like these comments better:

https://docs.mcneel.com/rhino/7/help/en-us/popup_moreinformation/polygon_mesh_detailed_options.htm

I’m not able to repeat this. Have a look at my sample code.

cmdTestAlberto.cpp (2.6 KB)

I see this in opennurbs_mesh.h:

double m_grid_aspect_ratio = 6.0;

Perhaps the Rhino command doesn’t follow the SDK.

– Dale

5

Hi @Dale,

Thank you for the new documentation link and also for your sample code: the way you test the edge-to-surface distance results very useful to me.

I found that the output difference between your example and the mine is given by the ON_Mesh::ConvertQuadsToTriangles() call.

The problem is that I need to have only triangle meshes as output. In order to reach my goal I tried to use both ON_Mesh::ConvertQuadsToTriangles() and ON_MeshParameters::SetFaceType(1) strategies but both produce meshes that don’t respect the edge-to-surface constraint.

You should be able to easily reproduce the problem using the new attached example (cmdTestAlberto.cpp (2.6 KB)).

Can you help me to obtain triangle meshes, of course respecting the edge-to-surface distance constraint?

Thank you very much,
Alberto

6

Hello,

is there any news about quad-to-triangles conversion?
I’m sorry to put pressure on this topic but this is a very urgent and critical problem for my customers and me.

Best regards,
Alberto

7

Hello,

please anyone can help me on this topic?
I simply want to create a mesh, from a given surface, respecting 2 constrains:

  • the edge to surface distance less or equal to 0.0013888;
  • the face type set as triangle only.

Theoretically I think it is possible to create the mesh with these parameters;
Did I use any parameter in an improper way?
Is it an OpenNURBS bug?

Best regards,
Alberto

12

Hi @margari,

No.

The test command I wrote shows the mesh is within the bounds of your meshing parameters.

It isn’t until you split the quads into triangles that your tolerance isn’t respected - the edge to surface distance is measured from the middle of the mesh edges.

So other than generating a denser mesh, I’m not sure how to help.

– Dale