Live data from Hacker News

Functional Flocking Quadtree in ClojureScript

lbjgruppen.com

11–14 of 14 posts

Re: Functional Flocking Quadtree in ClojureScript

#11
post #2

I think the flocking behavior of birds is one of the most entrancing natural phenomena, it's great to see it play out in such an intuitive way here. Is a quadtree generalizable to three dimensions? This looks like so much fun, thank you for sharing, I'm looking forward to playing with this over the holiday.

Quadtrees and octrees are themselves quite deep research areas. If the acceleration data structures interest you, I highly recommend Hanan Samet's book "Foundations of Multidimensional and Metric Data Structures". It's from 2006, but is basically the bible for the field.

Re: Functional Flocking Quadtree in ClojureScript

#12
post #3
post #2

I think the flocking behavior of birds is one of the most entrancing natural phenomena, it's great to see it play out in such an intuitive way here. Is a quadtree generalizable to three dimensions? This looks like so much fun, thank you for sharing, I'm looking forward to playing with this over the holiday.

https://en.wikipedia.org/wiki/Octree

And the same approach of just splitting in half in every dimension at each tree level can extend to arbitrary dimension, but usually something else like a kdtree is used instead.

Re: Functional Flocking Quadtree in ClojureScript

#13

Note that even without an acceleration structure ("direct summation" in N-body research terminology), a CUDA program or GLSL shader program can exceed 60 fps with 10,000 to 20,000 particles. And a parallel, C/C++/fortran vectorized CPU code can do the same with over 5 thousand.

FPS is a poor metric anyway, things like this should be measured in frame time instead - but either are meaningless numbers without knowing the hardware it runs on.

Re: Functional Flocking Quadtree in ClojureScript

#14
post #13

Note that even without an acceleration structure ("direct summation" in N-body research terminology), a CUDA program or GLSL shader program can exceed 60 fps with 10,000 to 20,000 particles. And a parallel, C/C++/fortran vectorized CPU code can do the same with over 5 thousand.

FPS is a poor metric anyway, things like this should be measured in frame time instead - but either are meaningless numbers without knowing the hardware it runs on.

Sure, I usually measure performance of methods like these in terms of FLOP/s; getting 50-65% of theoretical peak FLOP/s for any given CPU or GPU hardware is close to ideal.
Post reply on HN