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!
Comment
YOU RULE DAVE
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.
Very impressive work david! And thanks for sharing it. Really Cool.
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!
Yes, there is definitely a difference in processing time - a fair price to pay though if you can't code :)
thanks
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.
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.
© 2016 Created by Scott Davidson. Powered by
You need to be a member of Grasshopper to add comments!
Join Grasshopper