I am working on developing a Grasshopper script for road design. I am using some logic that I believe was developed by @Joseph_Oster (I am not entirely sure, as I haven’t been able to find the original thread where I found it).
It works by creating two sweep meshes (one for fill and another one for cut) and intersecting them with the terrain mesh.
I’ve made some changes on the input parameters and received catastrophic results (mesh difference not performed for fill operation, a completely null mesh as the result of the cut operation)…
I would try shrinkwrapping those self-intersecting meshes to generate good solid bodies before doing any boolean operation, because bools with self intersecting stuff is usually prone to fail sooner or later
I don’t remember much about this eight year old code, and would certainly write it better now, I didn’t try to understand your code but looked at adapting my old code to your terrain. Some issues are immediately apparent.
You have eight roads (“3D allignment”) in a grafted list while my code is written for only one.
My code specifically says “Make sure it starts and ends outside the bounds of the mesh surface.”, yet none of your roads do that.
My terrain mesh has 818 faces while yours has nearly 19,824 faces - 24 times more So everything is much slower. SDiff and SInt take minutes.
Even so, this hasty adaptation runs to completion and results look reasonable.
Later… I can’t resist making a few changes to this old code. For one thing, the road banks too much due to curve torsion - and there are other issues. Will post an update eventually.
The primary change I made was to keep the road from twisting in the curves (“banking” according to torsion). The angle of the cut/fill trapezoid is now a settable parameter. There are some mesh anomalies but they are minor. I scaled the road I had to fit your terrain (assuming meters) without regard for having it follow ridges and valleys, which would be better.
I experimented briefly with your grafted list of road segments, making some minor adjustments, and it works better than I expected. But as @inno said, it fails with stuff like this:
However, I think your solution does not suit me because of some facts:
I have to preserve mesh operations, solid operations are not an option. I know that my mesh is very big (19,824 faces) but that mesh has been simplified! My original meshes have much more faces. That’s why performing solid operations is not an option because it slows down the script significantly…
I don’t really know why it is necessary to start and end the alignment outside the terrain
It was already adjustable before too!
Here the slope can be adjusted. The angle will be, in this case, arctan(2/3).
I know, but,is there a way to “clean” that sweep object?
I think none of these is a problem. Each road is divided into segments of 20 meters in length; all of them have the same width and the same angles. However, having different widths or angles shouldn’t be a problem with a little bit of data tree management.
I’m not convinced. The performance of “solid operations” is not that bad in this case (1.5 minutes using your list of seven road fragments) and I don’t know how to get cut/fill volumes otherwise.
As I recall, it avoided errors in the cut/fill volume calcs, but I have now removed that assumption and related features.
I didn’t read or use your code. I trust my own more and prefer it.
33.7 degrees. I changed that value in my code.
Reducing the height of the trapezoid helps. I cleaned up your roads a bit, using a disabled gray group above the canvas,
They are valid issues. I have improved my code in several respects to handle them better.
By the way, I understand the desire to have a very high resolution terrain mesh near the roads but is there some way to combine hi-res with lo-res when the terrain is more than ~100 meters from a road? Might save time on the solid operations? In fact, for cut/fill volume calcs, most of the mesh is not needed at all
Mesh faces are culled when their centers are more than five times the road width away. Improvements could be reducing the jagged shapes and re-integrating mesh fragments.
P.S. Re-integrating culled mesh fragments is easy and relatively quick (orange group). The slowest part of all this, not reflected in Profiler times, is just rendering a large mesh with so many faces.
I’m not sure how to really be helpful here, given that you all made huge leaps forward. One little suggestion I may add is that there’s also the Lands design plug-in that creates “paths, cuts, fills, or divisions” in Grasshopper. It might be fun to have a look.
Similarly, for walls, ramps, or irrigation systems, users can apply algorithms to link and place objects. In terrains, users can define input data such as 3D curves or points for generation, followed by executing operations like adding paths, cuts, fills, or divisions. This robust integration empowers users to efficiently create dynamic designs with precision.
Looks worthwhile for professionals ($$). I noticed that raising roads causes more fill than cut volume so added a negative minimum value to that slider, Also saved 11 seconds by wiring to eliminate a cluster. Now takes only 30 seconds when opening this file.
For multiple roads (or sections of a road), it makes sense to have multiple ‘raise path’ sliders.
P.S. Oops, the code I posted fails when switching to a single road. Working on it…
The most expedient fix is to restore the MeshB cluster (yellow group) and use Fit Curve for Pull Point ‘G’ input, as before. Too hasty in avoiding a “Cyclical data stream”, sorry.
So everything is much slower. SDiff and SInt take minutes.
