Hacker News new | ask | show | jobs
by ladberg 1287 days ago
The problem sounds like you're doing O(N^2) calculations at every tick because each particle has to interact with every other particle. To make it faster you should keep some spatial datastructure so that you can query the other particles within a certain range of your current particle and just interact with those, ignoring the rest.

The usual implementation is an octree or something similar.

That said, N=100 should still be fast with the naive algorithm so I'd definitely move off the scripting language to something faster.

2 comments

For particles of uniform size, a simple uniform grid will work best. If you set the grid cell size to the particle diameter, then you only need to search the adjacent voxels for each particle. The uniform grid method is also easy to port to the GPU, unlike other acceleration structures like BVHs or Octrees.
I do have a parameter so that each particle only takes into consideration other particles within 750 units, when the free space is 3000x3000x3000 units, but this parameter did not seem too critical, and it's still calculating the distance between each pair twice technically, so I guess I could speed that up. Vector/"table?" operations seemed slower than plain loops, not sure if there's plain interpreter speedup possible there?
These references helped me a lot when building a spatial hashed fluid sim that runs on the GPU:

https://developer.download.nvidia.com/presentations/2008/GDC... https://wickedengine.net/2018/05/21/scalabe-gpu-fluid-simula...

(See from page 16 on the NVIDIA presentation)