3 ms·

I feel like in this day and age, GPGPUs are underused for this purpose. I've been working on a somewhat simpler problem recently, and eventually realized that y

• maccard 6y ago
  For games, gpus are often busy rendering. Parts of a physics engine (integrators mainly) parallelize well, but in my experience, all the rest of the code is very branchy, which doesn't work as well.
  • adamnemecek 6y ago
    You are right they are rendering, however say collision detection is comparably less compute heavy than rendering. I think with ECS, you can avoid a lot of this branching.
    • maccard 6y ago
      The basic implementation of GJK is inherently branchy - see [0] as an example. Extracting the contact points is similarly branchy, I'm not sure offhand how that would translate into gpgpu friendly code. I'm also not sure it's worth it. If you have a small number of bodies, it doesn't make sense to attempt the collision detection on the GPU, the benefit of the GPU is really that it scales. If you _do_ have a large number of bodies, youre likely going to be using lots of your GPU for rendering anyway.... There's also the gameplay side of it - moving the bulk of the physics engine to the GPU will make things like contact filtering, scene querying difficult to do. Gameplay code is usually very straightforward, and adding in complex or async callbacks likely would be met with resistance.. [0] http://vec3.ca/gjk/implementation/ http://vec3.ca/gjk/implementation/