I have a mesh and a brep - I would like to trip the brep using the mesh. Can anyone advise on the most efficient approach to doing this? i.e. directly as a mesh or using converting the mesh to polysurface/brep etc?
Here is the problem in a little more detail in case this provokes a better solution: I have existing terrain data (XYZ data reduced to the area of interest and meshed - delauney) and a proposed embankment . i need to produce some cut and fill analysis i.e. to compute the volume between the proposed and the existing. This is a fairly common task I will repeat in future so I am happy to use plugins as much as native components - if required.Simple Example.gh (10.5 KB)
couldn’t open your file, there’s some curves and 3dm files missing. Can you take a printscreen of what you wish to achieve? I’ll try to do something similar here.
I have attached a sketch and simplified example to my original post. A plugin called Bison has a custom component that does exactly what I need but I would prefer to verify this with an alternative method.
I have an arbitrary mesh (terrain model with many points) and a proposed embankment (a brep at present). I need to process the volume of the area between these objects. Bison allows this by first meshing the brep then comparing them. Before finding this I had considered using the terrain mesh to trim the brep then pulling out the volume of a capped brep that remain.
Wim - thanks for confirming. I am going to explore the possibility of turning the mesh to a polysurface (subject to processing demands) and see what options that opens up. Bison returns cut/fill figures but they don’t correlate well with a handcheck so I need to dig a little deeper.
In other posts I came across mention of a native command that computes the volume difference between two meshes - I will take a look at this.
Thanks for this - it is currently making my laptop work very hard - hopefully it gets to the end without crashing. Unfortunately I have a fairly dense mesh - I am going to pre-process the DTM file in CloudCompare.
I can achieve my goals using an approach with SolidDifference but the challenge with this is converting the mesh into a polysurface (Pufferfish Mesh to Polysurface) at this scale the computing time is ridiculous.
Without the Bison component I don’t see how this would feasible with larger meshes in GH. The problem is fairly simple and common - but I appreciate a solution isn’t always as simple as the question is to ask.
The brep is meshed - and Bison is using both meshes to solve the fill. But without Bison what other native components could be used to achieve the same result? I need to be able to verify Bison’s numbers somehow (for complex terrain a hand calc is not feasible)
Just looking at your “Simple Example.gh” file, it’s not clear to me what needs to be cut and what needs to be filled. I see that Bison spits out some numbers but I don’t know what they mean.
If you are creating the embankment with soil, I suppose you are only after the volume that needs to be put on top - a “fill”. Alternatively, if the embankment is in concrete, you’ll need to dig a hole to put that block inside - a “cut”. In that simple example, I don’t see how you would have both a fill and a cut.
At any rate, calculating intersecting volumes requires just that - volumes. In your case, both objects are open. That’s not ideal but workable. The issue is that both objects do not completely intersect. There are no sidewalls on your embankment object. To be able to calculate intersections, Rhino always needs either completely closed intersection curves or open intersection curves that run to the edges of the objects. Neither criteria is met in your example.
If you create a closed polysrf (brep), you’ll get a closed intersection curve and the volume intersection can be computed. In Grasshopper, you can either use the Mesh Split component to split both meshes with each other and join these into closed (mesh) volumes or you can use Mesh Intersection to get the part that is common. The volume of that common part would be the cut if you need to dig. If you need to add volume to the existing terrain, you’d subtract that volume from the volume of the complete brep. I’ve attached the Grasshopper file… Simple Example.gh (22.6 KB)
You could possible use the Quad Remesh component in Grasshopper or the Cockroach plug-in in Rhino if you wanted to stay in a single environment.
-wim
Well … if the Brep is a blob type of thing (as used in the demo posted) meshing it is not the solution … meaning that you should get a Brep (from the Mesh) as a cutter. But remember that Rhino is a Surface modeller thus certain operations that are very fast in Solid modellers (Micostation/CATIA/NX etc etc) are not that fast in Rhino.
On the other hand and since the cutter is in fact a collection of planar faces (case: tri mesh) there’s the recursive way around as well (trim the blob on a per face/plane basis etc etc - but don’t be very optimistic on that).
That said when working on Terrains I always use Breps (but I never work with Rhino anyway). Plus: if you want to extract excavation data in general … using a mesh with a zillion vertices as a cutter is kinda attempting to tune any Harley Davidson (avoid at any cost).
AECOSim for instance. In any case I’m in the AEC market sector (notably Architecture) and thus I always convert any LIDAR (and the likes) sourced mesh in a solid Brep.
Ok it’s a little bit confusing. When you say solid in terms of rhino you also mean closed meshes except of closed polysurfaces correct. Everything that is close and have mass properties. Because it’s not so easy to convert lidar data in closed polysurfaces eliminating the sharp edges. Is that correct or by solids you mean only closed polysurfaces? I know that Bentley civil products (open roads) uses now closed meshes.
