Creating Cells (Like Voronoi) Based on the Size of an Area

Hi there,

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

Any suggestions for achieving this solution?

ps: solution of those would be greatly helpful for any urban designers for their conceptual density calculation phase and the solution will be nominated as a gift to mankind :))

Just trying this using Kangaroo and the PolylineArea goal with the onCurve goal.

Need to keep the points in order around the curves but it might work… (14.0 KB)

I bet @DanielPiker could do this in 30seconds :slight_smile:

(Post curve examples to test on please!)

I didn’t open your file yet, but it sounds like something a bit similar to this thread:

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. (17.7 KB)

1 Like

Is that EqualArea goal the same as the PolygonArea goal?
I think this will work in some instances but I still get points sliding past each other …

I agree that setting the curve seams is important.

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.

1 Like

This sort of works but the corner cutting plots will be a problem…
image (20.2 KB)

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.

image (34.9 KB)

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… (27.2 KB)

The sphere radius can stop it finding a solution though because the points can’t move closer together than 2 * SphereRadius.

Perhaps there is a good combination of strengths for the goals that works with most curves.

Could do with some real world examples to test it more.