yep, I definitely need to read more thoroughly before posting… I threw myself at the problem and noticed the guidelines were not quite right (dashed: original guidelines, continuous: new guidelines):
Nice one, I implemented it in this new version:
Divider_AE2.gh (301.6 KB)
Both are defined imported geometries. I have 2 different images. I received very bad vector files, so I spent a lot of time correcting the lines and thought I could spare some time automating this part. I thought it was going to be faster with grasshopper. If I solved the thing for the first one it would have taken no time for the second one.
Furthermore, of all the lazy wishes I could have is that your spacing lines were consistent with your artwork as opposed to having different start/end conditions, for instance:
That’s something interesting that I have no idea why happened. For instance, the artwork and lines in Rhino’s viewport arealigned, but when I inport them into rhino, they Are not aligned. Here’s how they are in Rhino’s viewport:
I have another file where I extended the lines so they are actually wider than the artwork. That’s a bit of a mistery to me, because even before any work on lines/artwork in grasshopper, as soon as I inport them into grasshopper they are not aligned.
I think this one is close enough to what I need. I can check and clean the curves better before feeding them into the procedure. The solution has many components that I don’t know, so I’ll have to study it a bit
Got it—makes sense. Easy fix, though, via the ‘brep contour’ method. Not sure if you took a look, but in my latest example I made sure spacing lines and artwork were consistent and kept in the right position. I relied on a
shatter-all-at-once method (‘multiple curve intersection’) from the start to get all segments at first and sort them from there. Also, All non-colliding artwork curves exist under the lines and won’t get split for that reason, so they’re set aside and brought back at the end, assuming they’re still needed as part of the artwork. I meant to ask how you wanted to treat the data tree but I didn’t, so I left you separate unmerged streams: above and below.
Fun stuff! Cheers!
Hello all! So… I got new curves to work on, this time I cleaned them very well before trying again to work on my file, and after adding some extra checks I think I found what the problem was. Mostly lists missmatch.
As I was trying to check why some of the segments worked perfectly and some not, when I worked with more guidelines than curves, everything would brake. So I made sure that after the first curve|curve check for intersections, I cleaned the guidelines list keeping only the ones that intersected with a curve.
Other than that, I also made sure that both lists, curves and guidelines, were ordered by Y height. After that, things actually worked out perfectly.
Thank you all for the time spent on it. I learned a lot through the interactions. Here is my final file (there are some checks that I could add on the picture side also, but for now it does what I need with, so I can go on with work):
Divider.gh (506.7 KB)
This task frustrated me to no end:
I’ll leave this here for now, but have comments for later.
I am sick looking at that snobby mug.
So, there are three points that make this task more difficult than simply contouring the curves, splitting them and grouping them by Y-domain.
Firstly, curves that do not intersect with the Y-domain bounds need to culled from the data set (black curves in the image below):
Then, there are curves that appear to intersect Y-domain bounds by the contouring of the Curve Contour component, but actually live inside Y-domains. Here:
you see problematic curves with contour points that live above the Y-domain division line. This happens because as mentioned above:
And lastly, even though this sketch seems reasonable at first glance:
there are curves that intersect the Y-domain bounds more than twice:
leaving closed island curves in addition to the desired outer profile.
Dealing with these edge cases accounts for a little under a third of the scripting:
and could be avoided with the expectation of clean geometry.
Not that the geometry is as bad as curves that back-track on themselves and aren’t planar, but finding the an optimal Y-step is tedious and possibly impossible.
You’d have to have 5 to 7+ of these images to have the time and effort you put into building a generalization be recompensatory.
My initial instinct was to avoid curve contouring. This was because it involves having to deal with the split curves in terms of their grouping, endpoint alignment, and direction for linear connection.
A simpler method would have been to leverage regions and boolean operations. Here is some demonstration geometry:
You create a linear array of rectangles in the width of the geometry’s bounding rectangle and in the height of the desired Y step across the height of the curves:
Then Region Difference the curves from the rectangles:
By exploding the the region curves and checking which segments have midpoints that lie on the bounding rectangle of the rectangles via Point In Curve, you know curve segments you need to cull.
Rejoining the curve sets gives the final result:
The script is no more than this once the curves are cleaned and the rectangles found:
no curve sorting, no endpoint adjustment, no nothing.
However, I could not get this to work on a large scale! I don’t know what it was, but as soon as I connected the curves to the Region Difference component, the entire script stalled. I could get subsets of the regions and curves to work, and working through all the curves and rectangles in subsets, none of the image sections failed. But the srcipt refused to work on all curves and rectangles at once.
Would this component help?:
Oh my god, I am such an idiot:
I fully underestimated how long it takes for Region Difference to calculate and how much faster it goes if I cull for just those curves that intersect with a rectangle.
Will clean up later.
Why are we so stubborn??
Also (@CarlosFilho):
Not sure this ever happened. I opened your latest file and I realized they were NOT ordered consistently—but maybe it’s my Rhino, who knows!
Other than that, with your new artwork curves + when they’re ordered, indeed you made it easy and got rid of the problem, so no longer fun:
*Just for illustration purposes, without post-cleanup, obviously you’ve moved on.
Here, the final product:
Yes, it is slower than the curve-line intersection solution, but it’s not so bad. With the current set of curves it takes approx. 7 secs to process. I guess it is as @Fabio_Franchetti says:
that it is a question of what you value or need more; brevity and clarity of purpose or speed. I suppose if you were coding a component, you would avoid the boolean difference for the speed and because you don’t read anything of how the coding component works from the outside? But I wouldn’t know.
In the above post, the Anemone loop is an artifact of me trouble shooting. It’s not needed, but it is useful in the sense that it prevents the screen from stalling, and gives a visual indication in the model space of how far along the script is.
Because cleanliness is next to godliness.
I bumped on Anemone for the first time thanks to this post.
Unfortunately I have time to work on this only during work, and I also have to keep going with work stuff, so as soon as it worked the way I posted here I moved forward. But as I said before, I’m pretty sure I can still refine my version also. As soon as I have time again I’ll check al the other versions here. I’m fairily new to grasshopper, so different approaches actually help a lot to improve…
Thank you all… This has been by far the most fun interaction I had in this forum 
Everyone is likely sick of me posting to this thread by now.
A version incorporating @ale2x72 's Pull Point method to speed up the curve grouping but also delivers only a single top and bottom profile curve for each line:
Speedy Gonzales.
