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!

Views: 2820


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

Join Grasshopper

Comment by Brian Ringley on February 12, 2016 at 12:46pm


Comment by David Stasiuk on August 17, 2015 at 9:23am

Hi Max-

I can imagine how to do it pretty directly, but I think it might take a little time to implement, and I am not sure that for all networks it's even possible to have a strictly correct distribution of non-intersecting lists. I haven't looked at this code for some time now...but I think the key would be to start with one resulting face, set it to, say, side A, and then set all faces that share a half-curve with the first one to side B, and mark all of the faces as having been "solved and all of those half-curve pairs as having been solved. Then you iterate over all of the "unsolved" half-curves from the ones you've just set to B, setting all unsolved adjacent faces to A. You keep up with this until all faces are set either to A or B.

Comment by Max Malein on August 17, 2015 at 8:24am

Hi David, your code is fantastic!

Do you see any quick way to sort resulting surfaces into two non-intersecting lists? Considering that all intial curves are closed in this case.

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!


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 :)


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





  • Add Photos
  • View All

© 2017   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service