Using An ES With Physics

Articles, Presentations, etc

• How we use Box2D with Artemis - Really worth reading.
• Tom's presentation - He talks about Physics during this presentation. I think around the 2/3ds mark.
• Appropriate level of granularity for component-based architecture

Discussion

(Lots of questions about this… needs filling in ideas here … someone type something and delete this text)

• This is just some off-the-top-of-my-head-way-too-late-to-actually-be-thinking-about-this stuff. I use the box2d physics package. A physics "body" has quite a bit of data wrapped into it - transformation matrixes, position, velocity, rotation, size, shape(s), etc. Could you create "shadow" (i don't know if that is the right term - just making shit up) components, which would pull the specific data they needed from the physics body? Ie. we have a position component, which needs an X and Y value. Normally, these would be public attributes on the component (struct/class/DB field/whatever). However, when creating the position component, it is given the physics body, and pulls/pushes to that bodies X, Y value. This then ties the position component directly to the physics system, but allows you to work with only the position data in the Position System… Which i guess you wouldn't even really need, since the Physics system does most of what the Position System would do. Rendering (ha) most of my brilliant idea moot. Rats.
• After spending the night/day thinking about this, i'm still no clearer. Was thinking of having a PhysicsComponent, which would then have all those values a physics engine body would have. But then when it comes to the rendering system, you'd want both physics bodies and non-physics bodies. So it wouldn't be a simple collection of Renderable Components and Position Components, but you want Renderable AND (Position OR Physics) components. Not sure what the thinking is of more complex queries then the simple ANDs i've see so far. Although if we really are thinking of that data as being "in a DB", then complex ways of querying that data should be ok. Maybe.
  • I'd suggest the PhysicsComponent have the physics properties you need, like the body and then have a DummyPositionComponent that extends the default PositionComponent. This dummy will simply have a reference to the PhysicsComponent in order to return the X and Y variables of the physics body. So now, for a Physics entity you'll have a PhysicsComponent, DummyPositionComponent and RenderComponent. The Render System only cares about the DummyPositionComponent and the RenderComponent. So you let the physics engine do it's thing and just get the results whenever needed (i.e. when rendering). If you want control over the physics engine, I think you should apply forces and don't directly change the position values. But I don't have enough experience on this.

Physics done as a system I've been playing around with using Verlet integration as a simple Physics base (in AS3/Flash). I'm thinking about how to use Systems and Components to implement the physics. Having a "physics" components, which would hold the OldX and OldY values, which are required for Verlet Integration, then we'd have a Verlet System, which would take a Position component (x, y) and Verlet component (oldx, oldy) and do the simple integration. Where i start (ahahahah) to get confused/unsure is how to define the relationships between individual verlet points - to make sticks (2 points), cubes (4 points, 6 sticks), triangles (3 points, 3 sticks). Do you break systems down into very small parts? ie. have a stick-constraint system, which only deals with solving the constraints between 2 points/1 stick. You would then have some kind of Stick component, which would contain a reference (?) to another point? Or perhaps a stick component has p1x, p1y, p2x, p2y values in it… This is where a fly-weight or references would help, maybe. I'm unclear as to whether you can have "pointers"/"references" to other data in a component…

• So, can you have a component which has a reference to 2 other entities (the 2 verlet points)?
• Or, in re-reading the blog-posts, would it be possible to reference the other components themselves, rather then the entities.
• This would also allow for System based collision detection/reaction using whatever form of detection makes sense for your game. You could then, as an example, have a component which could hold the "shape" which the system would then use to check collisions against.
• Ah! I just watched Tom's presentation. He talks about Physics systems, like what i've been blathering on about, and rather then using an existing tool, writing something that works with an ER system from the get-go. Now, i'm no physics expert, but i can do Verlet pretty easily (because its pretty easy). I'm going to work on a verlet system/component, but i'd love some help/suggestions on how to partition the data. The issues i talk about above - having a position for a verlet "point", but also having to deal with constraints (creating a Verlet stick - constraint w/ 2 points), and how to pull out the data for that into components.
• In thinking about this, i'm having a really hard time figuring out the granularity of an Entity. Is a single Verlet point an entity, or is a Verlet Stick (2 points, 1 constraint) an entity? How do complex object, with lots of related data, get converted into components? Can you have more then 1 instance of a component associated with an entity?
  • You are complicating this too much. You should simply have a PhysicsComponent that has a list of points and sticks. The physics engine should handle all the simulation steps. The only thing you care is rendering that object (or adding more functionality). But try to avoid duplicating what the physics system is already doing for you. Check this out: Appropriate level of granularity for component-based architecture -pek
  • Ha - thanks for this link, I said "just do it", and went with the simplest thing that would work, which is what you have suggested. I've got a VerletPhysicsComponent, which holds a bunch of points and constraints. The VerletPhysicsSystem then uses this to do all the interesting integrations. Sometimes i do have a tendency to go towards "Architecture astronauts"-style. More experimentation will help too. Thanks again.