4 ms·
This is very coincidental timing. The physics simulation in the Source game engine, and Garry's mod, absolutely cemented in me an interest in computational phys
by hnuser123456 4y ago
This is very coincidental timing. The physics simulation in the Source game engine, and Garry's mod, absolutely cemented in me an interest in computational physics. I really wanted to see fully simulated fluid water in games, particularly GMod, but it never really happened, 15 years ago.
This never stopped bothering me, so I recently loaded up the game and programmed an entity that was simply a particle that repelled itself with inverse distance-squared falloff. I was only able to get up to around 100 particles before the game slowed from 200+ fps to ~10. There seemed to be a huge amount of overhead in the lua scripting system's connection to the game/physics engine. Something about getting the position of 100 particles, or asking for all the particles within a given range of each particle, even for only 100, was enough to send frametimes over 100ms-1000ms. I wanted at least 500-1000 particles at at least 10fps, and I'm sure in terms of raw math, that is nothing for modern CPUs, even with the most naive implementation. I had to figure out exactly which lua functions had the most overhead for such a small amount of simple math.
So, I re-wrote the script, seeking to chase every rabbit hole that would let me increase the number of particles while maintaining over 10fps.
1. Switch from per-particle loop, to a global loop that cached each particle's position per frame, so it was more pure math and less engine bindings/"context switching". Approx 50 particles to approx 150.
2. Limit the particle simulation to 10hz instead of 66hz+, and adjust the force scale to compensate. Raised the limit to approx 300-400 particles.
3. A dynamic scaling system, so that the system would never try to simulate more than 100 particles at once, per 10hz tick. Raised the limit to approx 700 particles.
At this point, there are now other non-CPU bottlenecks. Any method of drawing 700 entities, even basic wireframe?, even with a very high end GPU on a nearly 20 year old game, is significant, and there's no easy way for me to break past this.
I am sure if I learned how the source engine's plugin system worked, and I hooked into the physics engine using C++ instead of however the lua bindings work, I should be able to simulate a thousand particles at 100+fps, but that's about where the scope of the project starts to contend with "real life", and I continue to wait for a 3D sandbox game with satisfying fluid physics.
Your optimization method of "only one iteration per frame" is in a sense, the same, and in a sense, the opposite of my method of simply not even simulating every particle every frame... I just didn't have the spare performance for that. Then again, I'm only simulating a single force field with no proper collision detection or anything fancy
- pistachiopro 4y agoRealtime fluid sim is making lots of progress, though full 3D sims still appear to be computationally out of reach, at least for games that aren't focused exclusively on them. Here are some fun fluid sim examples from members of the Ten Minute Physics discord: https://twitter.com/Michael_Moroz_/status/1595076099670933504 https://twitter.com/Michael_Moroz_/status/159507609967093350... https://twitter.com/MytinoGames/status/1600278137564184579 https://twitter.com/MytinoGames/status/1600278137564184579
- hnuser123456 4y agoI might have to join the discord, that first link is extremely satisfying, and the shading on the materials in the 2nd one does a great of giving the feeling of the 3rd dimension without the computational complexity. Thank you for sharing
- ladberg 4y agoThe 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.
- cyber_kinetist 4y agoFor 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.
- hnuser123456 4y agoI 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?