I have an Entity Component system and I want to have a Physics Component that would add the given object to the physics simulation.

My problem arises because the Bullet API requires me to add each object before doing the simulation.

How should I proceed to create a System(System in entity component terms) that wraps the Bullet Physics API to do simulation while the Physics components are getting added and removed?


This is how my Entity component system looks like.

class Entity
    std::unordered_map< size_t, void* > components;
    // setters getters for components based on key
class EntitySystem
    std::unordered_map< size_t, Entity* > entities; // maps entity GUID to entity*
    // calls function on all entities
    void Process( void* userdata, void (function*)(void*, Entity*) );

    // Entity creation, setting, getting, component index management, etc...
  • \$\begingroup\$ to clarify: you mean you can't add/remove bodies during the physics simulation step like in most other physics engines, right? If so, this is simply a matter of checking whether the physics simulation step is currently running, and if so, queue the bodies to be removed/added and then perform the remove/add post-step in a callback. \$\endgroup\$
    – CodeSmile
    Dec 15, 2013 at 21:36
  • \$\begingroup\$ One of the reasons I don't advise anyone to use an ECS is partially because one of the main benefits from them are usually made redundant by middleware packages like an external physics engine. There's almost no good reason to use a cumbersome and overly-complicated component model like an ECS once you start letting a physics engine manage your simulations and a separate (from the object system) scene graph manage your rendering. \$\endgroup\$ Dec 15, 2013 at 23:30
  • \$\begingroup\$ @LearnCocos2D I can add things on the go, but its heavily inefficient, and I wanted to know if there is a de-facto solution as to how to keep that from happening.(like caching what was a rigid body last frame, or having creation of a component fire an event to add it to the simulation, etc. ) \$\endgroup\$
    – akaltar
    Dec 16, 2013 at 13:25
  • \$\begingroup\$ @SeanMiddleditch The reason for using ECS is that I am making a game that is completely moddable(it is much like a framework), using ECS made everything a LOT simpler so its worth the trouble in this case. \$\endgroup\$
    – akaltar
    Dec 16, 2013 at 13:30
  • 1
    \$\begingroup\$ @SeanMiddleditch You better hurry up with that article! I'll be racing to finish up an open source project and a slew of articles about engine architecture :) I might beat you to it. \$\endgroup\$
    – RandyGaul
    Dec 16, 2013 at 22:33

1 Answer 1


There's no need to shove a pre-made physics engine into a particular model. All good physics engines are going to be using some form of data oriented design; you can't have a fast physics engine without cache optimization. This means that any benefits from attempting an Entity Component System, or any other data oriented approach will be redundant.

What you can do is write small wrappers that are stored as components in your engine. I'm not familiar with exactly how Bullet works, but I do know most engines have colliders and rigid bodies separated. What is usually done is a collider is represented with a component type, and a rigid body is represented with a different component type. This allows the separate wrappers to support dynamic transferring of the colliders to attach or remove themselves from rigid bodies.

You can apply any programming paradigm to your own wrappers. I honestly think that any wrapper will be perfectly fine. If Bullet does not support run-time modification of the physics objects, then you're out of luck.

  • \$\begingroup\$ I was specifically interested in how should I create such a wrapper for it to be efficient. \$\endgroup\$
    – akaltar
    Dec 16, 2013 at 13:33
  • \$\begingroup\$ I honestly think that any wrapper will be perfectly fine. Like I said, the internals of Bullet are efficient and isolated from anything you'll be doing. If you're extra paranoid about efficiency place all your components together in contiguous memory. This will be more efficient than you really need. \$\endgroup\$
    – RandyGaul
    Dec 16, 2013 at 22:31
  • \$\begingroup\$ @akaltar Added! \$\endgroup\$
    – RandyGaul
    Dec 17, 2013 at 17:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .