With Magnum and EnTT.
An adaptation of ecs_nbody which is example material for Flecs. Made as a learning exercise of Magnum and EnTT, and data-oriented design in general.
Related
Compared to Pong, systems are methods of the application this time, meaning no more global variables. Other than that, it's pretty much the same. Too early to tell whether it's any better (or worse), but it does mean there's the possibility of state in the systems, and that the systems share state. That isn't intentional and could lead to trouble down the line. Ideally, they would carry no state, which is already the case here; they merely share a few constants like overall speed and initial sizes of things that I didn't feel comfortable exposing as global variables like in the Pong example.
This example depends on Magnum and EnTT.
Build
git clone https://gist.github.com/86d33be269f6e721e847f26e4cb299c4.git nbody
cd nbody
mkdir externals
wget -O externals/entt.hpp https://raw.githubusercontent.com/skypjack/entt/03c4267b84fafca32be264892c81fb0d17d7c2f7/single_include/entt/entt.hpp
mkdir build
cd build
cmake ..
msbuild nbody.sln
start debug\nbody.exe
This example illustrates a few interesting bits in Flecs that isn't implemented here, primarily threading and having one system called in response to another system. In this case, that call is made using just the function call. My suspicion is that the reason this is made more complex in the Flecs example is to facilitate threading.
- Bulk Create Entities Entities are currently being created in a loop, and startup with 20,000 entities takes a few good seconds; that's no good. There's a way of bulk creating instances, but the real hurdle is bulk initialising entities, as they are each given a unique position and velocity on startup which is (I think) where the real bottleneck is at.
- Call
forceSystem
in response togravitySystem
This is what I mentioned about one system directly calling another. I think EnTT has some mechanism of hooking systems up via events; it might not be relevant here, but look into that and figure it out. - Threading With 2,000 entities, this example just about maxes out 1 core on my machine, with about 10% GPU utilisation. At 20,000 fps drops to about 0.5 frames/sec.
- More Efficient Neighbor Lookup At the moment, every entity is looking up every other entity to calculate distance that is later added to as attraction force; the closer it is, the stronger the attraction. That lookup is
O(n^2)
. Surely there must be a better method of finding only the closest ones within a given distance? Find it, implement it. - Trails Particle-looking circles is cool, but what would be really cool is if they could draw something like a trail after it.
Argh! Got confused by the forks and replied on the wrong one. Sorry @alanjfs ... that comment should have gone to your gist.