Divide surface based on corners

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…
:confused:

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

http://www.albahari.com/threading/

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

1Na9YE7HXiR0YlhldRJJ-MA


http://stanislaschaillou.com/thesis/GAN/unit_program/

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…

http://imgs.xkcd.com/comics/simple_answers.png

7 Likes

I was looking for this kind of discussion on this discussion for a while now ( thanks to @laurent_delrieu !). I just posted a post with a similar problem to yours. @Riccardo Majewski’s script with Anemone works wonderfully, but I was wondering too if it was possible to feed to Anemone multiple grafted polylines at once.

(aand by the way sorry to re-bring this up ! )

Amazing topic!

The solution provided by @maje90 woks great!

I’m trying to understand how to avoid this type situation:

Thats why the solution works great on large ortho polygons, but if you have smal areas, with corners lower than 10cm, the code generate small subdividions, which is fine based on solution, but i’m trying to understand how to avoid this and produce a balaced areas between the subdivivion itself.

My goal could be like this:

You keep the minimum amount of subdivisions, but when there are corners with such small lenght it extends its lines and forms larger (balaned) subdivisions areas, I don’t know if I was clear, i’m sorry.

I’m also trying to understand how to perform with a range of polylines and not only one.
Any help how to do this or how to include this type criteria I’d be thankful!

This is the original @maje90 solution:
rectangles_V3_R5.gh (35.1 KB)

Thats my type of poly to work with:
Test subdivision.3dm (25.6 KB)

If i remember correctly my script worked with shortest, external, edges first.

… maybe a method by giving a “score” for each edge and then picking the best.
So giving very low score to an edge near another very short edge… it will make it use that edge late or never…
Still, i think the top left part of your case will be filled with a vertical rectangle…
It seems like you only want horizontal divisions… maybe one of the @Joseph_Oster solutions would fit better?

Would you accept something like this?

If not, it need more details on the rules you want.

1 Like

Yes I accept for sure! it fits perfectly for me too

Ok… I did that with MS paint… :rofl::sweat_smile: