Thanks gankeyu! This very helpful.

It seems like I need to learn LINQ more. I didnâ€™t know even Take().

Btw, I guess this syntax is very new. Donâ€™t know if it works in C# node inside GHâ€¦

Thanks gankeyu! This very helpful.

It seems like I need to learn LINQ more. I didnâ€™t know even Take().

Btw, I guess this syntax is very new. Donâ€™t know if it works in C# node inside GHâ€¦

And, heeey! Whatâ€™s this syntax!? This is Python tupleâ€¦ Didnâ€™t know recent C# has it!

Itâ€™s `ValueTuple`

. Compared to `Tuple`

, itâ€™s about 50% faster when used as a `Dictionary`

key. I donâ€™t think GHâ€™s C# supports it.

Nope. You would need:

```
...
List<Point3d> list = null;
if (dict1.TryGetValue(key, out list))
...
```

1 Like

Thank you! Thank you! Iâ€™ve been away from C# for a couple of years.

Iâ€™ve been using Python because writing is faster than C#. But obviously performance is notâ€¦

Is there somebody out there in McNeil who want to buy this code?

500pts 0.37s

5000pts 1.9s

50000pts 25.5s

500000pts 5.3m

How about $10?

1 Like

David Rutten is doing Poisson Sampling for GH2 so I am not sure McNeel need another one

1 Like

Joke, it was a joke. Looking forward way powerful GH2!

Donâ€™t underestimate your job, I am sure GH2 will brings efficient algorithms, but sometimes there are some lacks that are taken by plugin (offset â€¦). So if you have made good improvements to your script publish it on this forum and food4rhino.

I think also populate 3D geometry (you have done 2D populate) could use Heat Method from Keenan Crane â€¦

2 Likes

What algorithm(s) did you use to get such results?

I attached a **human-readable** code and the strategy already But thanks for having interest.

I would remind again that the goal is to achieve O(N). Not to make the code only faster.

The key point in the algorithm is if you divide the region to the cells, there are only one, or two, or maybe three points in a cell. The number of points in a cell cannot go high even if you increase the number of points.

So if you compute the forces between points that are only in the adjacent cells, the total amount of computation is nearly proportional to N.

.

1 Like

Sorry, I must have skipped that somehow.

Sounds similar to the Poisson disc sampling algorithm.

1 Like

You could try switching from Dictionary to HashSet. Lookup goes from O(log n) to O(1) in that case. And I think in the newer HashSets itâ€™s now possible to retrieve an entire value stored in the set if you find a colliding key. This wasnâ€™t possible before making HashSet a lot less useful.

On the other hand, it seems youâ€™re creating points *everywhere* within some boundary, so why not just store your points directly in an array? Or am I mistaken in believing this array would not be particularly sparse?

1 Like

Hi David! Thanks for popping out!

I simply didnâ€™t know HashSet. Iâ€™ll check it out. Thank you.

I assume your â€śarrayâ€ť is an array of the cells. The reason Iâ€™m using dictionary instead of a static array is, simply I was not able to come up a good strategy to cover an arbitrary region by cells.

Theoretically the initial points may be covering the entire region almost perfectly. So the cells computed from the points may cover the region perfectly. But there is a chance there are some missing cells, and when points move to those missing cells, we need to add a cell. If you want to avoid this, you need to compute the cells without the help of the distributed points but only by looking at the boundary curve. I simply didnâ€™t come up any ideaâ€¦

.

Are you sure about this? I for instance know that in Python dictionary lookups are also O(1), though sets are also considered a little faster still for different reasons, maybe because there is no referenced data?

Absolutely, I for instance stored the points in a one-dimensional array, which is faster and cheaper than multi-dimensional ones, when I implemented Poisson disc sampling for a project of mine. You can still easily loop through it with a two-dimensional row-column-logic, like so:

```
#include <tuple>
int columns = 10;
int rows = 10;
// Array of pairs representing two-dimensional points
std::pair<double, double>[columns * rows] points;
for (int x = 0; x < columns; x++) {
for (int y = 0; y < rows; y++) {
points[x + y * columns] = std::make_pair(x, y);
}
}
```

I guess you donâ€™t even need â€śrealâ€ť cells, when each position in a one-dimensional array is simply considered to stand for a cell. If you for instance only allow one point per cell, a vacant cell could empty - itâ€™s position in the array would be `NULL`

, `None`

, `-1`

, or whatever -, whereas occupied cells would be defined by simply a point at that index in the array.

If you have a non-rectangular region, you could for instance test not only if the new point is in a free cell, and at a tolerated distance from neighbouring points, but whether it is contained within the region in question. The grid could be simply a rectangular grid filling the bounding rectangle of the region, if that makes sense.

Hereâ€™s a real-time demo of my Poisson implementation creating 7,300 points in a 400 by 400 unit region:

Itâ€™s somewhat slower than yours, but I havenâ€™t optimised it.

1 Like

Though I agree dynamic generation of cells is not the best idea, this animation explains well the algorithm.

2 Likes

Iâ€™m by no means an expert on all of this, but what is always a â€śproblemâ€ť with dynamic object creation, is the reallocation of memory (copying of memory), if your dynamic data structure changes in size, since this is probably the slowest memory operation that can be done.

Potentially, using a quadree spacial division could even be faster, especially since points are only inserted and not moving iteratively (which would mean that the quadtree would need to be rebuilt at each iteration).

Other than that your stuff looks amazing and your times are mind-blowing!!

Maybe, Iâ€™ve missed this, but you use multi-threading right?

ummm, maybe Iâ€™m too thinking in Python way, you have lists and dictionary. Itâ€™s a world people casually create and dispose objects dynamically.

Only a big bottleneck I see in this algorithm is, when points move out from a cell and enter to another cell, it is removed from the original list and added to a new list (letâ€™s stop talking about dictionary inquiry cost! For me itâ€™s fast enough). This happens everywhere actually. For instance, by ensuring a point array of 20 items for every cell, you can avoid dynamic allocation of memory. (or maybe this is what David initially suggestedâ€¦)

Yes, its using parallel-foreach

No, forget about this post. I donâ€™t know how to remove a point from an array.