Keeping the boundary is simply a matter of adding another goal for this:
plot_area2.gh (18.0 KB)
Solving a problem like this with Galapagos is a bit like throwing darts at a board, it might solve it to within 5% or so if you wait a few minutes (and as you scale the number of plots this will get much worse), instead of just following the gradient and getting a solution to within 0.0001% in a few milliseconds.
Evolutionary solvers are fantastic for some types of problem, where there are a smallish number of input variables and there isn’t any way of knowing the gradient, but this isn’t one of them.
Oops, sorry - forgot to internalise everything:
plot_area3.gh (22.9 KB)
EPIC! This is awesome!
is there some information about when to use/not use galapagos?
is it something like this:
low number of input parameters and a “direct” correlation from input to goal
and my followup question would be:
why can kangaoo handle a problem like this so easily?
Actually maybe I came across as too negative about evolutionary solvers there - the great thing about something like Galapagos is that you can plug it into any problem where the target can be evaluated as a single number and the inputs are some numerical sliders. Sometimes even though theoretically a way of evaluating the gradient might exist, it might be hard to find and evolving it could be the best and sometimes only practical alternative to just brute force checking all combinations.
If we take the classic optimisation example of climbing a hill, a gradient based solver like Kangaroo can directly follow the steepest slope (provided we know enough about the thing we are optimising to evaluate this), in fact with the projective solver in Kangaroo2, it can even know how far to step along this gradient direction.
…whereas an evolutionary solver would randomly evaluate many coordinates in the terrain, and take combinations of which ones gave the highest result. As you get into problems with hundreds or thousands of dimensions (harder to picture as hills here, but these dimensions could be the x,y,z coordinates of a few hundred points), this performs really badly.
thanks! very informative
Def the computing time went orders of magnitude down. Evolutionary solvers are blind after all.
Here’s a nice example of the power of evolutionary solvers.
I can’t see any way these sorts of results could be achieved by simple gradient descent.
Well … in fact a slightly different approach is required here: given a boundary List AND an indicative “start” partitioning per boundary (via either “spines” or lines or both) … get the polylines (split BrepFace with Curves then get the outer Loops) and then … blah, blah.
Plus there’s the building regulations (per country) that MAY dictate some additional goal(s) with regard the acceptable parcel shape/topology and the derivant building clearances per parcel etc etc. This makes the whole puzzle more challenging,
Good points. For making the polylines, one further issue is that some plot boundaries will need to be split not just at their corners, but also at points on their straight sides when there is a t-junction with multiple plots adjacent, otherwise triangular voids of no man’s land could appear in between. I think maybe the script Giulio posted here could be part of how to do this.
Also agree that further constraints might be necessary to constrain the plots to reasonable shapes, such as no very sharp angles. If the initial division is not fairly close to the final one, it could also become necessary to allow for some sorts of topological changes, which would make this all much more complicated.
Well … cases like these are like annual checkups > better avoid doing them because you’ll never know what may pop-up out of the blue, he he.
May save your life as well.
Hi Daniel! I was testing your script because I need a solution for lots like this one. However, when I do a different block shape (not with the cul de sac in the middle) , the lots distort all over the place. I don’t understand why? I followed the script step by step I just don’t know why it is not working.
Difficult to say without seeing the file.
I’d guess it’s something to do with the outer boundary constraint.
Ah, it looks like the curves are oriented clockwise. Flipping them fixes this:
I’ll add a check for this in the next version so curves are always given the right orientation.
Ahh!! it was driving me crazy hahaha thank you very much!