I’m an Urban Designer and using Rhino extensively for our projects.
Today we had a golden thought of grasshopper support that would greatly help and improve my productivity tremendously!! Here is the question:
As urban designers, we are creating residential areas and creating parcels as division areas.
I was wondering is there any way the create a grasshopper function, that makes the automatic area divisions based on areas we define.
For example, if we play with a parameter of 1000m2 it would create cells of 1000m2 areas inside a curve.
And if we define it to 800m2, it would create areas with 800m2 with more cells…
Here is an example of what we could be able to achieve
Above we were able to divide the area with the same length Crv sections… but not based on areas.
What we are trying to achieve is not based on the length of the crv but based on the areas we are creating.
Because in this example we did, areas are very different as you can see from the image below
It’s similar but in that example the plots seem to have been roughly drawn and then equalised whereas in this example we start with an outer and inner curve that need to be split into equal target areas. The plot corner points need to stay on the original curves AND not slide past each other. I can’t figure out how to stop the points sliding past each other or whether there is another way of doing this.
Like what you did here for repulsing points on a messy curve…
In this discussion @DanielPiker posted a definition with a C# Kangaroo custom goal to repel points on a curve or a mesh I think. It’s in the attached definition
I’d do it like this -
Aligning the seams of the curves first gives a reasonable initial division, then clamping edge lengths so they don’t get too short, and a weak angle goal keeping them approximately rectangular to not get too skewed.
EqualArea is different because the target areas are not set as input, only that they all need to be the same.
Dividing the area between the curves by the number of plots probably works well enough too, but the sum of the areas of the straight sided quadrilateral plots will be slightly different and EqualArea allows this to adjust.
To avoid them sliding past each other you probably just need to adjust some of the strengths or the ClampLength lower limit if your input curves are at a very different scale to the example I posted. If you share the file I can show this.
For stronger protection against overlaps you could potentially use another goal keeping points in the same order in the curve parameter space (I think I did post a goal for this once in relation to developable lofts), but I don’t think it should really be necessary here.
You’re missing the angle goals I included in my example file above. Using this to reduce the skew also reduces the corner cutting.
If you did want to model the plots as more than just straight sided quads to more closely follow the curve, the area goals do work with general polylines so you could have several points along the inside and outside curve for each plot. You’d probably want some length equalization of the segments to keep them well spaced.
I think the corner cutting is just where there are areas of high curvature in the input curves.
I’ve split the input curves at the division parameters and then divided these sub curves to create higher resolution polylines. It works OK to begin with but always drifts away from ideal as points seem to slip past each other.
Its as if we need the points to behave as if they were on a queued conveyor (I remember a Kangaroo conveyor example but I don’t think its relevant)
The RigidPointSet goal looks similar to what I’m after but I don’t understand it properly.
I tried using SphereCollide with OnCurve to stop the points sliding past each other (a point would need to deviate from the curve by the sphere radius to get past another point on the curve) and it works sometimes but needs tweaking depending on how many points the curve gets split into and the radius of the spheres used to prevent the points passing each other whilst remaining on the curve…