"Mesh split plane" component fails

[djordje]

I have an issue with “Mesh split plane” component. It fails to find an intersection between a plane and a single faced mesh:

If I use “Mesh mesh split” component instead, everything works fine.
Also “Mesh plane section” component shows that there is an intersection line.

So the bug must be with ‘Mesh.Split(Plane)’ method.

I am using:
Rhino 6 Version 6 SR25 (6.25.20114.5271, 04/23/2020)
Grasshopper 1.0.0007 (04/23/2020)

Attached is an example of the upper screenshot.
splitMeshWithPln.gh (13.4 KB)

[diff-arch]

Hi @djordje,

One issue is that your geometry sits 85395.52 document units away from the origin, which is a bad idea, since all sorts of tolerance issues can pop up. For each calculation that Grasshopper has to do, and it probably does lots, it now has to deal with huge numbers, even for simple stuff!

Furthermore, MeshSplit doesn’t seem to work because your mesh is not watertight! It is a simple mesh face, not even a mesh plane, not that mesh planes would be watertight either.
If you extrude your mesh to give it some thickness, splitting works!

splitMeshWithPlnEdited.gh (19.4 KB)

[laurent_delrieu]

@diff-arch there is no reason it doesn’t work.
It tested it with Rhinocommon and the documentation is clear
https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_Mesh_Split_1.htm
It must be a BUG in Rhinocommon
Here I used my component Mesh iso Splitting so the iso values are distance from the plane.
The only problem is that I use triangles.

splitMeshWithPln.gh (21.9 KB)

[diff-arch]

@laurent_delrieu

@p1r4t3b0y there is no reason it doesn’t work.
It tested it with Rhinocommon and the documentation is clear
https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_Mesh_Split_1.htm
It must be a BUG in Rhinocommon

@laurent_delrieu, I simply pointed out that the distance between the geometry and the scene origin is relevant and something to keep in mind!
Concerning the mesh splitting, I wrote “[…] doesn’t seem to work because […]”, which should indicate that it is a theory of mine. I never said that no bug was involved, but it is a fact that it works with watertight meshes, as proven above!!
I’ve also tried it with rhinocommon and @djordje’s mesh face in Python, and I came to the same conclusion. It doesn’t work. So either there is a bug, or it’s meant to only work with watertight meshes?

[laurent_delrieu]

Yes you are right I didn’t mean to offend or criticize, your conclusion are goods.
For points far from the origin there is now a place in the mesh to store vertices in double precision. It is not super easy to use because there 2 arrays of vertices (one float, one double) but it works and it must be useful to deal with all the far from origin problems.

For the concern @djordje has it is a bug in Rhinocommon or in the documentation.
@piac it seems that MeshSplit doesn’t work as intended. I don’t understand why it works on solid mesh and not the others. That doesn’t seem logical as it outputs son solid mesh.

[diff-arch]

@laurent_delrieu

I didn’t mean to offend or criticize, your conclusion are goods.

Don’t worry about it! I may have overreacted with my reply.

@laurent_delrieu

For the concern @djordje has it is a bug in Rhinocommon or in the documentation.

Absolutely, do you think it might have to do with how peculiar Rhino analyses meshes? Mesh planes and single faces usually don’t fully pass the test, since they are not closed volumes.
I guess only volumetric meshes are true meshes?

@laurent_delrieu

That doesn’t seem logical as it outputs son solid mesh.

Hm, for me it outputs an empty array, when I did my testing in rhinocommon!

[laurent_delrieu]

@diff-arch

it outputs an empty array, when I did my testing in rhinocommon!

the same thing for me.
I wanted to say if the function was intended to work on solid mesh it must output solid mesh or/and give an option.

[diff-arch]

@laurent_delrieu

I wanted to say if the function was intended to work on solid mesh it must output solid mesh or/and give an option.

Yes, at least the component description should state that it only works with solid meshes, if that was the intention. I’m curious what the devs have to say about this?

[djordje]

Thank you for all the testing and replies both @laurent_delrieu and @diff-arch!

Rhino mesh vertex coordinates are defined by single precision floating point numbers:
https://developer.rhino3d.com/api/RhinoCommon/html/T_Rhino_Geometry_Point3f.htm

A rule of thumb is that for single floating point numbers, there are approximatelly 7 digits precision.

Plenty of webpages online can be found, showing how to precisely calculate it for a specific number (range):

Demystifying Floating Point Precision

For a given 85395.52 document units, precision is 0.0078125.
This is smaller than my tolerance: 0.01, so there is no problem with the model being far from Rhino’s origin.

By the way, we should be checking the X,Y,Z coordinates of the vertices not its distance from the Rhino origin (which is what 85395.52 is in this case) - mesh area centroid coordinates are: 24344, 81678.9, 5321.25).

Mesh should be a mesh, regardless if it is closed or not.

[laurent_delrieu]

Yes Rhincommon has something broken
@piac it works as expected in Rhino 5. It outputs 2 meshes

[piac (Giulio Piacentino)]

Ok guys, I’ve debugged and I think I know why this case doesn’t work. I’ll try fixing asap.
This does not have to do with the new intersector in WIP, so this should be able to go in a Service Release for V6 as well.

RH-58640 is the YouTrack issue.

[piac (Giulio Piacentino)]

@djordje

For a given 85395.52 document units , precision is 0.0078125.

This might unfortunately not suffice. Just because the coordinate has enough precision, it does not mean that the calculation of the intersection with a ray will have enough precision. Calculating the intersection of a ray and a triangle requires some relationship with the determinant. Calculating the determinant can go well, or not so much. Things become very difficult, very fast.

The problem was however different.

The bug was related to simply not allowing perfectly aligned meshes that have no projection in a dimension of the plane, to split. It was just a logical bug in the code.

[djordje]

Thank you for the clarification Giulio. What is the triangle in this case? The plane? And the rays are mesh edges?

[piac (Giulio Piacentino)]

Meshes are all triangles in the end. Plane is also made into two triangles.

@djordje

And the rays are mesh edges?

Yes, or something else.

[djordje]

@piac

This might unfortunately not suffice. Just because the coordinate has enough precision, it does not mean that the calculation of the intersection with a ray will have enough precision. Calculating the intersection of a ray and a triangle requires some relationship with the determinant. Calculating the determinant can go well, or not so much. Things become very difficult, very fast.

So there is no way to know what would be the precision of mesh vertex coordinates?
As the ‘method’ by which some of the mesh vertices were created is not as precise as the method used to create a brep vertex/edge…?

(‘Method’ in this case is splitting mesh with a plane (thus creating two new meshes and new mesh vertices). But it can be anything else: splitting mesh with a mesh, or with mesh with a curve.)

[piac (Giulio Piacentino)]

@djordje

So there is no way to know what would be the precision of mesh vertex coordinates?

There’s the same precision you originally have. Rhino 6 and WIP do not modify double precision vertices and do not require single precision vertices.

I am referring to computing a particular operation that creates/tries to determine new values. In this case, intersections happen within existing triangle space. There are fewer and fewer available “steps” in a triangle, the farther you go far from the origin. And picking the “best” available value becomes more difficult, far from the origin. This is true for pretty much any operation and any object in any program, from points to lines to NURBS to meshes, etc.

If you have only 10 gaps available (let’s say, you have less in 0.0078125 vs 0.01, probably just 1 or 2), then being sure that the ray hits the triangle at an available gap becomes a gamble.

[djordje]

Thank you Giulio.
So splitting a brep with a plane would not result in more precise ‘split’ than its mesh counterpart (for this specific example of a single faced mesh - 4 cornered planar brep)?

[piac (Giulio Piacentino)]

@djordje

So splitting a brep with a plane would not result in more precise ‘split’ than its mesh counterpart

In theory not. There might be bugs as usual, both ways. If a developer, however, converts to floats or only uses the single precision vertices from Rhino 5, then there will be less precision.

[brian (Brian Gillespie)]

RH-58640 is fixed in the latest Service Release Candidate