Grasshopper

algorithmic modeling for Rhino

I was looking at a post earlier today, which got me thinking about the logic of how to collect intersected curves into discrete, closed cells. This got me looking at this post which led me to the excellent codequotidian blog by Trevor Patt and this post, which uses half-edge mesh data structures to sort curve networks. I've been lucky to closely observe Daniel Piker and Will Pearson as they work their magic with Plankton, so I thought I'd take a look at sets of intersecting curves alone to see if a similar approach could organize them effectively. What I've done is a pretty rough workthrough of examining planar curves, blasting them apart based on intersections, and creating sets of "half-curves"...much like half-edges, but these allow for curves of any type to be used for edges in composing faces. I've only done planar curves because calculating angles is the means by which they are sequenced, but I think it'd be possible to also do this for curves on a surface or mesh, with local planes for calculating angles determined according the surface or mesh normals at each vertex.

No doubt the code's pretty ugly, and there'll be bugs.  It definitely likes curves that intersect...I haven't resolved how curves that float alone are treated, or if closed curves lie inside of other closed curves...But in any event, here's the code, have a play if you like...and enjoy!

131111_curve_network.gh

Views: 998

Tags: closed, curve, network

Comment

You need to be a member of Grasshopper to add comments!

Join Grasshopper

Comment by Богдан Кузьміч on November 14, 2013 at 2:50am

Simple test:

VB result in 5 seconds

standard one just freezes and not responding

Like it!

Comment by Pieter Segeren on November 13, 2013 at 1:04pm

Very impressive work david! And thanks for sharing it. Really Cool.

Comment by Arie-Willem de Jongh on November 12, 2013 at 8:27am

David, your the man! Thanks for this, I wrote also a really dirty solution, but it takes ages to compute and only works with polylines.

Thanks for sharing!

Cheers!

Comment by alex.lupascu on November 12, 2013 at 4:27am

Yes, there is definitely a difference in processing time  - a fair price to pay though if you can't code :)

thanks

Comment by David Stasiuk on November 12, 2013 at 3:42am

Yes...split surface definitely works, and it's a solution I've used before as well. The primary difference is computational time, really. Splitting a surface gets extremely heavy when you introduce many curves (even with just the few curves in the example definition, splitting curves runs at 868ms versus 18ms for the script...try doing it with a few hundred curves :) ).  Likewise, I started this thinking more along the lines of creating regions for curve networks that were near breps/surfaces/meshes...but just threw it together quick last night and kept it in planar space.

Comment by alex.lupascu on November 12, 2013 at 3:32am

Hello, i was wondering why is it necessary to code a VB component if this can be easily done with the standard ones? I remade your def using the split surface in combination with the bounding box and culling the index 0 of the original bounding surface.. seems to do the same thing and less buggier.. yours seems to generate extra surfaces for the regions that are isolated or inside other regions.

curve network 2.gh

Translate

Search Grasshopper

Photos

  • Add Photos
  • View All

© 2014   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service