Cut and fill calculation with 2 meshes

I am currently working on a large park project on a steep hillside where there is slated to be a large amount of filling and cutting the landscape - and the goals is to calculate the total volume estimated to be cut and filled with the current design.

The existing models of the landscaped were exported from Revit (which should calculate cut and fill but is failing to do so) and brought into Rhino as meshes. My thought was to project a grid of points on the two meshes, subtract one point from the other A1-B1, A2-B2, etc etc, and separate and add the negative vs. positive sums to come up with a total cut and fill depth, which could then be multiplied by the grid spacing to get a volume.

It seemed like it should work, and I created the grids on the surface by intersecting a series of planes with the mesh to create a curve and then intersecting an additional series of planes with the curves to get points.

The points work great (consistently) with the existing topography mesh, but on the new topography mesh it doesn't pick up on the entire mesh, leaving blank splotches. For example, on mesh point grid generates over a hundred points, whereas the other generates 30. Is this simply a glitch, or is there something I can do to get it creating a consistent grid on both surfaces? Other approaches to reaching the end goal are certainly appreciated!

Attachments:

CutAndFill_PlaneGrid.gh, 17 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on April 6, 2015 at 2:49am

Kelly

If this is a real-life Project (as opposed to some "abstract" Academic study) I would strongly recommend a total different approach since this is a classic optimization problem where:

building profile topology<>terrain<>excavation cost <> habitable spaces <> you name it (for <> : read "interact").

Have some fun with a greatly reduced/oversimplified demo from what I'm using in real-life for similar problems (dealing always with breps (terrains) instead of meshes: notify if you want ways to do that).

PS: Load Rhino file first.

best, Peter

Attachments:

buildings-in-terrain_V1.3dm, 342 KB
buildings-in-terrain_V1.gh, 324 KB

Permalink Reply by Kelly Sanford on April 6, 2015 at 11:00am

Hi Peter,

Thanks for your response. I had a little difficulty understanding your use of <> but it seemed to make a little more sense after opening your file. In your file, it is looking at excavation only underneath the buildings, as if to determine how deep the building could/should go into a landscape that is otherwise not changing - correct?

The project is a real life project, but we are not designing to optimize for excavating at a building footprint, rather we are doing some earthwork to sculpt the entire landscape and create a new 4.5 acre park- including filling in an abandoned reservoir. If you have advice for converting meshes into breps I am all ears!

Permalink Reply by peter fotiadis on April 6, 2015 at 12:20pm

Hi Kelly,

Well ... for <> you can read <= listens + => talks (meaning a bidirectional interaction between one "constrain" and another: for instance the steeper the slope the more semi-sinked habitable spaces may occur that may impose building regulation and/or insulation and/or structural issues and/or excavation stability issues... that may affect cost/profitability/break-even point(s) blah blah).

As regards the affected landscape as a whole (buildings + surround) the actual (not the demo) C# can create excavations + "banking up/filling" for anything (be that a building and/or a landscape object treated as a "building"). It's not that simple mind since the excavation breps can "overlap" each other and "overlap" with the fillings as well ... anyway the demo C# was just an oversimplified version of the real (quite complex, mind) thing that I use often. The sum of all these "solid" operations are much preferable been based on Breps than meshes, thus I always use terrains as Breps.

As regards mesh to brep matters play a bit with this attached (load Rhino file first for the demo test cases).

Attachments: