Hi there,
I found something quite weird with MeshBooleanIntersection.
So first of all: We wrote a small command to do a clash detection with MeshCollider etc. in C#.
It works quite good altough there are many clashes detected that are not really clashes. We built in some double checks for that to try to filter that.
But… more problematic is that there are clashes that are NOT detected.
This clash e.g. is neither detected by Mesh collider nor anything else and MeshBooleanIntersection does not recognize it as well. BooleanIntersection works but is of course super slow when running it on hundreds of elements…
Any idea why this very obious clahs is not detected with mehes?
@martinsiegrist
Well I am aware of course that my model contains two breps as this is our modelling source. But the problem is not the clash command or clash in GH.
Problem is as written in my explanation.
When turning these breps into meshes (whatever settings you use - result is same) : Mesh BooleanIntersection does not deliver any result.
Same with C# code MeshCollider… We used for meshing in C# MeshingParameters.FastRenderMesh
Any idea anybody?
Script can’t be shared, but if you use the mentioned methos you will see the outcome that result is Null.
inC#:
generating mehes of the breps with MeshingParameters.FastRenderMesh
And then using MeshCollider. The general code is not that much of interest, problem is that MeshCollider does not recognize the collision of the meshes of these breps
Hello @DominikIC and thank you for bringing this up.
We are working on MeshBooleanX commands in Rhino V7 and Rhino WIP, and the final outcome will probably be ready only in V8 times. In Rhino V7, however, there are several new powerful functions. Among them, there’s the new MeshIntersect. I haven’t followed the development of the incarnation of the commands that you mention in this thread, because they predate my insertion in this part of the team – but I think we will look into them at some point again. For now, I want to suggest this:
You should attempt any mesh operation by first creating very neat meshes. Getting the render meshes might not be the best idea
In V7 SR8, you can use the MeshIntersect command. If intersections are found, then you have a clash
I am seeing a problem in MeshIntersect in 7 SR9 that needs to get fixed. Please make sure you test this operation in SR8. The problem is located in preprocessing, because we work very hard to make sure that the meshes fit perfectly the strict requirements for good intersections.
Thanks,
Giulio
–
Giulio Piacentino
for Robert McNeel & Associates giulio@mcneel.com
thanks @piac for the answer!
In C# code we first detect clashes with boundingBoxClashes, then we use the MeshIntersect to find clashes in a fast way. Only then we further investigate the clash with MeshCollider and MeshBooleanIntersection as we need to analyse the clash result in terms of volume, orientation etc.
Then we found that there were mayn clashes in step 1 & 2 but some were not detected in step3…
So it seems to be the issue with aligned faces, thanks to @Joshua_Kennedy !
So we need to wait vor V8 then unfortunately
Sorry, that was written little bit confusing from my side. MeshCollider does not deliver any further informations than MeshIntersect. Out internal class that holds all the routines is called MeshCollider as well… The last and third step is actually only using MeshBooleanIntersection
