I first merged all faces in your brep and then split it with the plane only to join it again. This results in a close to perfect seam on your intersection plane. I had to pull the vertices which should be on the plane perfectly onto the plane, as split mesh created a lot of small triangles otherwise.
I took the edge of one of the two meshes and remeshed it, using the control polygon of the naked edge curve as features. Then joined the two open meshes with the cap. Both separate of course.
Inno is right that the feature curves need to exist in the input.
If the input is a Brep, there should be some vertices along a feature curve, and if it is a Brep, there should be a split or seam that matches the feature.
(you don’t need to explode polylines to use them as features though)
The issue here I can see is that where you’ve booleaned away those rail like bits from the base, those patches don’t have a seam where you’re putting the feature curve.
The problem I have now is to cap both elements in order to obtain two different closed meshes. The thing is that cover must be shared in both meshes, sharing vertex in order to mantain continuity in following analysis. However, I tried to do it and almost all the vertex coincides perfectly but there are some of these that are not located in the same position. Maybe I can use align vertex but it means the cover will not share vertex on the other mesh.
It splits and rejoins the whole thing at the plane, to generate a closed mesh with a seam there.
Then it separates that into 2 (now open) sides, and caps one,
Then separates just that cap (which is the common surface where the 2 sides touch), and remeshes that, keeping its boundary vertices fixed.
Then it joins that cap onto each of the open sides, to get a pair of closed meshes sharing all their vertices at the interface where they touch.
I’ll think about whether there’s a way I could package this process up to simplify it a bit.
Triremesh component does not seem to work properly. The warning message is “Invalid cast: Point » GeometryBase”. Do you know what can be happening? Maybe the version? I openend the file you sent and the same message appears.
This is the version I have. I think it is the last one.
Note that when using Rhino 7, you should not download or install the Kangaroo2 from Food4Rhino. The most current version is the one which comes with Rhino, and this will automatically update along with each Rhino service release.
I was trying to recreate another more complex example following the advices you give me. I think I almost achieved the solution, however the mesh I obtained is still opened. Can you have a look at my GH file? Am I doing something wrong @DanielPiker ?
Maybe using the align vertex I can solve it, however I am not sure about the vertex continuity between both meshes.
Certainly I can see that it would be more convenient for this sort of thing to have a version of the remesher that automatically takes multiple surfaces or Breps and meshes them separately but so that they match where they touch.
You approach the problem in a different way, however there is still one issue I would like to understand. Analyzing your solution I saw both vertex meshs do not coincide mathematically at the intersection, and that maybe be an issue in FEM analysis when exporting geometries despite the despicable differences since continuity is not maintained.
I am sure there is a more elegant way to solve that but this works. I am concerned about possible covers located in different planes where I cannot apply Delaunay mesh command correctly, but We’ll see! Create a version of Triremesh component capable of taking this into account directly would be amazing, but I understand it is quite complicated!
Here’s is a way of resolving that without needing the Delaunay step: meshinterface2.gh (118.5 KB)
but yes, solving it in the remeshing component itself will be better - I do think I can make a version that remeshes each surface patch separately, with matching vertices at the junctions, and rejoins them as in the original breps.