Beautiful, and the spatial hash grid is the right call here — I went
looking at glsl-sim.js expecting an octree and found cell hashing with
texture ping-pong instead, which is a much better fit for something that
has to stay inside a frame budget.
On an M-series Mac it stayed smooth even at 262k, which honestly
surprised me for a WebGL 2 path.
One question: how do you handle the first frame? I hit a much dumber
version of this problem — an exhaustive search that blocked the main
thread for 1.7s before anything rendered, and no amount of optimising
the inner loop fixed the fact that the user was staring at nothing. I
ended up shrinking the problem instead of speeding it up. With 262k
bodies you must have a similar cliff somewhere. Do you build the initial
grid progressively, or is it just fast enough not to matter?
12 comments
[ 0.31 ms ] story [ 27.4 ms ] threadOn an M-series Mac it stayed smooth even at 262k, which honestly surprised me for a WebGL 2 path.
One question: how do you handle the first frame? I hit a much dumber version of this problem — an exhaustive search that blocked the main thread for 1.7s before anything rendered, and no amount of optimising the inner loop fixed the fact that the user was staring at nothing. I ended up shrinking the problem instead of speeding it up. With 262k bodies you must have a similar cliff somewhere. Do you build the initial grid progressively, or is it just fast enough not to matter?