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!
@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?
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.
Don’t worry about it! I may have overreacted with my reply.
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?
Hm, for me it outputs an empty array, when I did my testing in rhinocommon!
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?
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):
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.
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.
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.
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.)
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.
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)?
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.
