Road from Centerline Script - closed curves and Region Union problem

Hello,
I made this Road from Centerline script last year but had some problems…

  1. This script is not working for closed curves. Trying to solve it, the script easily gets big and reduces efficiency. Since this is dealing with complex road networks. Every computation power counts. Any idea how to realize this effectively?

  2. The Region Union component takes a lot of computation time…Any thoughts on working around it to significantly reduce the calculation time would be very much appreciated.

  3. Maybe there is a completely different and better logic/structure to script this. I am all ears.

Please notes:
This script is made in Rhino 7 and needs at least Human and Elefront to run.

Thank you,
Rui
Road_auto_intersect_by_layer 1.00.gh (28.6 KB)

2 Likes

Can you internalize stuff after your ‘trim tree’ component so you can get help without us having to install Human and Elefront? :grinning:

*You’re also using Pufferfish, LunchBox, etc.

JK, 'seems you’d have to internalize data prior to the pufferfish offset lol

Or, of course, wait for help from other plug-in enthusiasts :slight_smile:

Thank you, René! I forgot to do that… I simplified the script and internalized the data. All the components are grasshopper-native components now.
Road_auto_intersect_by_layer 1.00 troubleshooting.gh (30.3 KB)

1 Like

missing

Except for Pufferfish. I worked around that (purple group) but the circles engulf everything, the roads inside disappear.


Road_auto_intersect_2024Feb8a.gh (38.7 KB)

@Joseph:

Yeah? I can see the problem, don’t know the solution?

Look further in the code to see how RUnion fails.

1 Like

Same

One approximate solution:
Road_auto_intersect_2024Feb8a (2).gh (31.8 KB)


Faster than RUnion but sacrifices resolution a bit - mesh quality can be bumped up, though - the fillets might be a bit shorter…

*Another one would be to extrude all roads as solids, boolean-union them (slow), get their intersection with the ground plane…BUT, when you do that, the solid union produces unwanted edges where solids unify - we can clean them up but the booleans will still be slow, so no bueno.

If speed isn’t the top priority, Solid Union may be slow, but if you Merge Faces, you can avoid discretizing the curves.


1 Like

:grinning: awesome! Forgot about *FMerge

LoL - 1.2 s … I love how anything above milliseconds is slow in gh world :rofl:

1 Like

I resorted to SUnion too. Looks OK?


Road_auto_intersect_2024Feb8b.gh (27.4 KB)

@Brian_Washburn A {failed} attempt to beat you lol:


No code?

1 Like

Apologies, code below:

Road_auto_intersect_by_layer 1.00 troubleshooting_BW.gh (32.9 KB)

1 Like

@Brian_Washburn, I know it’s short/simple but your file doesn’t have your solution!

p.s.: still trying to beat your 1.2 s without solid unions nor meshing (discretizing the curves) like I did above:
image

lol so close but I quit for now - still discretized :frowning: but just as shortcut to skip SUnion and RUnion…the actual ‘smooth’ curves were kept and shattered.


Road_auto_intersect_2024Feb8a (4).gh (43.8 KB)

@inno I think I invoked you :stuck_out_tongue:

1 Like

if you are happy to end up with all Polylines, and are also happy to use Clipper2 plugin… here is another possibility (Clipper2 is so fast that the bottleneck becomes the Fillet component lol)

all closed curves, a single whole region :+1:

Road_auto_intersect_by_layer_inno.gh (25.3 KB)

@René_Corella you saw me typing :rofl:

2 Likes

@René_Corella It should be in there at the end, but it grabs the curve offsets from the Pufferfish add-in. This one does it all with native components.
Road_auto_intersect_by_layer_BW-Native.gh (19.8 KB)

This one does the faster mesh thing with all native components, but then cleans up the polylines so fillet works properly.
Road_auto_intersect_by_layer_BW-Native Mesh.gh (25.1 KB)

-Brian

1 Like

Oh Wow! Thank you ALL for the input! This is a lot! I will try your approaches and let you know the results.

Funny enough your amazing scripts work on NURB curves but for some reason give errors on simple ellipse :smiley: but that is never used anyway IRL…

I was wondering whether it would be possible to keep some information about which curve degree would be filleted with which other so there could be a similar hierarchy to hose fillets.

Say I want the major-major, major-medium, and major-small would have x units of fillet for high-speed turns, the middle-middle, and middle-small would have y units of fillet, while small-small would have z units fillet.

I just sat down to the computer so I don’t have any progress myself yet. Will post if I get something.

EDIT. For now I resolved to classic attractors script but on larger geometries it might not be the best option and also in some cases the fillet point is closer to the small roads (extreme angles) so its not 100%.