• 9
• 10
• 11
• 13
• 9

Integrating Bullet into an entity-component system

This topic is 786 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I'm currently trying to integrate Bullet into my game, and I'm a bit stuck on the best way to proceed. So far I've had a lot of success in keeping rendering logic out of my game classes (they only hold minimal rendering data where necessary), but I'm wondering if that's an appropriate route to take for physics since while rendering is not integral to simulating the game world, physics most definitely is.

Additionally, while I'd like to use Bullet in the most performant manner possible, I'd also like game logic to have a high degree of freedom into how physical objects get manipulated.

With that in mind, I've come up with the following component types:

- XColliderComponent (where 'X' is Box/Capsule/Sphere/Mesh, etc)
- RigidBodyComponent
- SoftBodyComponent (really not sure the best way to go about this, seems like it would have rendering implications...)
- ConstraintComponent
- ForceComponent (is there a different way of doing forces that may work better?)

However, this raises a lot of questions. How do you handle the case where two entities with RigidBodyComponents get parented together; should that automatically create a constraint, or should it be ignored? What if you want to have a single RigidBody that's composed of multiple colliders? Bullet stores its state in several btXYZ classes, should those be part of the components, or rather be part of some external PhysicsSystem object?

I'm a bit stuck here, so if anyone can give me advice on how best to proceed specifically with Bullet, or how any physics system like this should work in general I'd greatly appreciate it.

Edited by Salty Boyscouts

Share on other sites

What does parenting entities mean in your system?

Currently it means ownership, as well as nested coordinate systems. It's always irked me a bit with other engines that that wasn't separated, but that's how I've seen it done in everything I've used (Blender, Unity, Unreal...). I'm interested, what would be an ideal mechanism for specifying nested objects, other than parent-child relationships (even if you don't want the objects to participate in the physics simulation, so no constraints)?

Does your system restrict you to only having one component of each type per entity?

No, but I was more concerned with how that would work with child entities providing colliders for their parent RigidBodies (similar to how it's done in Unity). Looking at the API for btCompoundShape, I have a better idea of how that would be handled, thanks for mentioning that!

Can your components have child components

That's an interesting idea, at the moment my API is heavily designed towards blurring the distinction between individual Components and the Entities they're attached to (making Components feel like fully-fledged GameObjects themselves), but they're still ultimately rooted to an Entity. In such a system, would the game entirely consist of trees of components? Is that a good idea?

Edited by Salty Boyscouts

Share on other sites

Are you actually making a game or a demo that requires these non-trivial entity hierarchies and multiple components of the same type? I integrated bullet into my entity-component system the most simple way which was one rigid body component per entity and one collision shape per component and i've yet to require anything else. Point being, just do what you need to do. There shouldn't really be any of these what-if scenarios until you actually need them and then the become scenarios and not what-ifs.

Share on other sites

Where will these components be authored? E.g. if you build your models in Blender the bodies and shapes could even be simply a part of a model component. I would only add that kind of granularity if you want to author everything within some kind of custom editor.

Share on other sites

Are you actually making a game or a demo that requires these non-trivial entity hierarchies and multiple components of the same type?

Yeah, I'm working on this for an independent study for my degree, and the goal for this part is to produce a demo that shows off a tight integration of animation and physics. Being able to compose multiple collider objects onto a single rigid body (and later separating them) is part of what I'm trying to do for the demo.

Where will these components be authored?

I build all of the models in Blender. While I'd like to have an separate editor for constructing levels and prefabs, I don't really have enough time to do something like that so I'm writing a bunch of addons for Blender to build a pseudo-editor for that kind of stuff. It's all pretty much duct tape and shoe strings at the moment though.

Share on other sites

This is actually why I really started to hate entity component systems usually mentioned in blog posts on the internet. Here's how my current system is actually set up.

It's actually heavily inspired by Unreal's Actor system which does use entity-component, but in the loosest fashion that it's still technically an actor.

The Physics component is just a single component. It's literally an interface to Bullet Physics. Because most of the logic is actually handled by bullet, the most that this system handles is information about the objects properties for when it gets submited. If it's static, if it's dynamic. If it's a soft body. And if the bullet implementation needs to watch for any interactions with this entity specifically for callbacks.

If I do get any callbacks, they can not happen immediately. Instead, the callbacks are simply cached and acted upon when we return to Lua. Before that, we also take a moment to update the positions of everything in Lua via one "big ass" array.

Share on other sites

Honestly I'd just do a RigidBody component that acts as an interface to Bullet and nothing else. Constraint component isn't really going to work nicely since a constraint is a piece of memory for caching solver solutions, and a piece of code that operates on two rigid bodies. Components are typically a piece of memory that operates on a single entity. The disparity between operating on one or two things will get pretty weird if you try to shove the concept of a constraint into the concept of a component.

What you really want to avoid is duplicating data stored inside Bullet to create a "mirror" with your components. Bullet is already doing this work! Try to focus on getting specifically what is needed from Bullet, and getting Bullet what it needs.

Whenever components and middleware are used components generally just interface the middleware. Bullet just wants you to give it floats, so it can crunch the floats and give them back to you. Ideally this looks like:

Bullet->DoWork( myFloats, count );
Bullet->WhatHappened( outFloats, &count );

Obviously this is a simplification but this is sort of what I would want out of an interface, if I were the one making the components. I'd try to get my interface as close to this as possible.

Edited by Randy Gaul