This algorithm has a problem if there is a hole or opening inside the closed polyline
there’s always a hole inside a closed polyline.
if not always then 99.99% since if you join two overlapping lines you get a closed polyline with hole very close to 0
1 Like
Sure, it can’t work with a set of curves.
For example the extended point inclusion test is done with a single curve, to have a “holed shape” we have to use a different logic, such as “Boundary surface” first and closest distance to surface then.
Added a step where a set of parallel rays (lines) are made and try to intersect with other curves, if an intersection is found, the distance of current rectangle extrusion is lowered.
Fixed the other steps…
…
Code is more and more messy and nothing to be proud of, only work with flat/XY-planar and orthogonal shapes (external perimeters and holes).
I didn’t test it deeply…
rectangles_V3.gh (35.2 KB)
4 Likes
Thank you for the definition but a screenshot would be nice because it shows relay, subtraction and multiplication component missing. Please post a screenshot of your definition too.
Edit: I figured it out. Thanks for the definition and your outstanding work!!
For some reason in Rhino 5 it is not working even after plugging right. Kindly check and help.
rectangles_V3-query.gh (37.0 KB)
1 Like
You’re right.
rectangles_V3_R5.gh (35.1 KB)
Strange/intresting/SAD thing… on Rhino 5 this definition is almost twice as fast than on Rhino 6 (the same exact file).
It seems the CCX intersection component is running a lot slower on Rhino 6…
1 Like
I have scripts that started running a lot slower after upgrading from 6.13. I use intersection a lot in them.
Have you tried that with parallel computing/multithreading turned off in Rhino 6?
-wim
to make it faster? How does that make sense?
It takes quite a bit of overhead to chop up a process, put it in different threads and then stitch all back again. For longer and more complex computations, that will still be faster than single-threaded but for simpler things, that will be slower.
-wim
Also see:
Tried: yes, it work faster with multithread turned off.
It would be useful if the component auto-detect by itself if MT should be used or not… in “some” way…
In this case MT=on is 100% slower (2x) than MT=off.
Anyway, thanks for pointing this out.
That’s - more or less - a chimera: study what the Master has to say (and enjoy):
I was merely thinking about a “rating” based on the count of the curves, their degree, and the amount of virtually possible intersections.
If they are all lines (single degree=1 durve) and the amount is under 100-ish, just avoid MT.
I’m sure it’s a very complex logic and probably it would waste more power than the actual solution, but then maybe it is to reconsider to set it default off, or give an option to change the default…
How to make it work for multiple polylines. Kindly help.
1 Like
Post your attempt at making it work. You should try on your own a bit.
2 Likes
now combine it with archigan:
3 Likes
@jesper also developing same kind of thing called adaptive plan using just native grasshopper components/batteries. Amazing work by him.
And he is planning to launch a plugin by 2020 called Finch3d. More at his website www.finch3d.com
Instagram: https://instagram.com/jesper.wallgren?igshid=17nusgaiowurv
4 Likes
At first glance this does look kinda cool, but I doubt that it would work for more complex base shapes, like for instance an L-shaped ground plan, at least with vanilla GH components. At some stage this needs some serious coding, probably machine learning too, to achieve full “autonomy”.
I wonder though what this would mean for architecture…
