Hi,
Firstly, thanks for a really great managed physics library, I have tried everything else and was utterly dissapointed!
I won't have to many dynamic physical objects in my game, so I would like to know, performance wise, would it be a bad idea to create all game entities Non-dynamic objects so that I can hook in to the collision system? Or, would it be better to only create those few dynamic objects, and then create my own external collision detection system, and if a dynamic BEPU object interacts with one of the non-BEPU objects, I handle it accordingly ?
So basically, can I use BEPU as my collision detection system as well ? Or would it hamper performance ?
Regards,
Jaco
Mixing BEPU objects with non-BEPU objects
Re: Mixing BEPU objects with non-BEPU objects
I'd guess that it would be best to use BEPUphysics for all the physics and collision detection, though I don't know exactly what your use case entails.
For example, if your have characters and some physical crates in a static environment in an FPS match, and you want little health packs here and there:
-The character would be best handled by the CharacterController or one of its alternatives, which at their core are dynamic entities.
-The crates and such would be dynamic entities.
-The environment would probably be a StaticMesh, maybe with a few kinematic entities here and there if something needs to move, like an elevator or fan.
-Health packs and ammo pickups, assuming they spawn and don't bounce around dynamically, should probably be kinematic entities with collision rules set up so they only generate pairs/contacts with the character entities. Then, when you detect a collision (via pair or contact) between a character and a pickup, remove the pickup entity and give the health/ammo/weapon/powerup to the player.
Having more objects in the simulation will slow things down, of course, but for that to be a significant issue on the PC you'd need a lot of objects or collisions. In the above FPS example, the total physics cost would be very low. There may be some other very specific game uses where it would be beneficial to create an external system, but usually it's better to have the objects living within BEPUphysics's BroadPhase for quicker pruning and testing.
For example, if your have characters and some physical crates in a static environment in an FPS match, and you want little health packs here and there:
-The character would be best handled by the CharacterController or one of its alternatives, which at their core are dynamic entities.
-The crates and such would be dynamic entities.
-The environment would probably be a StaticMesh, maybe with a few kinematic entities here and there if something needs to move, like an elevator or fan.
-Health packs and ammo pickups, assuming they spawn and don't bounce around dynamically, should probably be kinematic entities with collision rules set up so they only generate pairs/contacts with the character entities. Then, when you detect a collision (via pair or contact) between a character and a pickup, remove the pickup entity and give the health/ammo/weapon/powerup to the player.
Having more objects in the simulation will slow things down, of course, but for that to be a significant issue on the PC you'd need a lot of objects or collisions. In the above FPS example, the total physics cost would be very low. There may be some other very specific game uses where it would be beneficial to create an external system, but usually it's better to have the objects living within BEPUphysics's BroadPhase for quicker pruning and testing.
Re: Mixing BEPU objects with non-BEPU objects
Thanks for the quick reply and for the info.
So I am building a hybrid RTS/3d Person game, which is basically mutliplayer only, if that would give you better context. Would that still be acceptable then to do everything via the physics engine ?
So I am building a hybrid RTS/3d Person game, which is basically mutliplayer only, if that would give you better context. Would that still be acceptable then to do everything via the physics engine ?
Re: Mixing BEPU objects with non-BEPU objects
That depends on exactly what you plan on doing with the collision detection. My default guess would still be to just use BEPUphysics for everything reasonable.
A general guideline is, if your object will need to query the broad phase to locate other collidable objects, then it might as well be a BEPUphysics object to begin with. An object that lives in the broad phase will collect pairs faster than individual queries.
If there's some collision detection that simply isn't related to the rest of the physics engine at all, then that would be a place where you might want to use a separate system. For example, in an RTS, it's common for units to be nonphysical blobs that follow the terrain precisely but don't actually 'collide' with anything except (sometimes) other units. In that case, it might be worth setting up some other simple system for the purposes of pathing and such. That separate system could be a stripped part of the BEPUphysics collision detection pipeline if you wanted, too; for example, you can create another BroadPhase instance in isolation and use it without a Space.
A general guideline is, if your object will need to query the broad phase to locate other collidable objects, then it might as well be a BEPUphysics object to begin with. An object that lives in the broad phase will collect pairs faster than individual queries.
If there's some collision detection that simply isn't related to the rest of the physics engine at all, then that would be a place where you might want to use a separate system. For example, in an RTS, it's common for units to be nonphysical blobs that follow the terrain precisely but don't actually 'collide' with anything except (sometimes) other units. In that case, it might be worth setting up some other simple system for the purposes of pathing and such. That separate system could be a stripped part of the BEPUphysics collision detection pipeline if you wanted, too; for example, you can create another BroadPhase instance in isolation and use it without a Space.
Re: Mixing BEPU objects with non-BEPU objects
Thank you very much, that helps a lot. My goal is to hook in as much as possible with BEPU, so I will try what you have suggested.