I'm in the early stages of a game and still experimenting with different physics options. My main requirement is that I need to be able to handle as many colliding bricks as possible.
I know PhysX.NET is a good candidate for this but I read something about you have to notify Nvidia whenever you use PhysX, which has put me off completely. I'd just like to know
how well BEPU handles this sort of requirement- for example on a standard "minimum requirements" for modern gaming type pc (dual core 2GHz).
General question about BEPU
Re: General question about BEPU
BEPUphysics is pretty speedy, but I can't tell you for sure how fast it will be for a given simulation without trying it out. I'd recommend grabbing the demos source and playing around.
There's also a variety of ways to make the simulation faster at the cost of accuracy. Check out the ConfigurationHelper in the BEPUphysicsDemos for a variety of options. There's also a few other things, like adjusting the time step duration to take longer steps. This can sometimes help, but it has a big impact on stability.
If you're planning on simulating a few thousand blocks or less, chances are it will work out just fine. The cost of a simulation is determined in large part by the number of collision pairs, though; if all 3000 blocks are in a big pile, a more modern computer will be required.
If you need to simulate 100,000 or a million blocks in a vast world or something, then tricks will be required (e.g. deactivating portions of the simulation to ensure the total simulation object count is kept at a reasonable level).
If you have any questions about how to speed up a particular simulation, I might be able to provide more specific advice
There's also a variety of ways to make the simulation faster at the cost of accuracy. Check out the ConfigurationHelper in the BEPUphysicsDemos for a variety of options. There's also a few other things, like adjusting the time step duration to take longer steps. This can sometimes help, but it has a big impact on stability.
If you're planning on simulating a few thousand blocks or less, chances are it will work out just fine. The cost of a simulation is determined in large part by the number of collision pairs, though; if all 3000 blocks are in a big pile, a more modern computer will be required.
If you need to simulate 100,000 or a million blocks in a vast world or something, then tricks will be required (e.g. deactivating portions of the simulation to ensure the total simulation object count is kept at a reasonable level).
If you have any questions about how to speed up a particular simulation, I might be able to provide more specific advice
Re: General question about BEPU
Well you've certainly won me over in terms of user support- and I've noticed others say the same thing.
Yes, I've just been inspecting your demos- and I'm certainly impressed by the variety of features available. Regarding the number of bricks- I very much doubt it would even go beyond 1000 so it sounds like there'll be no problem. I have a couple of slightly more specific questions if you're free:
1) How resource-hungy is BEPU while a simulation remains still- (if a tower of bricks remains untouched)?
2) Regarding terrain, what's the optimal setup with BEPU in terms of the size of bricks (for example) in comparison with the size of the terrain squares. In some engines the bricks need to be much smaller than the terrain squares or performance takes a hit. The problem with this is that I don't want anything more elaborate that vertex based texture splatting for the terrain visuals- if your terrain squares need to be huge for optimal physics, it limits you to very vague texturing.
Hope you can help me out with these, thanks.
Yes, I've just been inspecting your demos- and I'm certainly impressed by the variety of features available. Regarding the number of bricks- I very much doubt it would even go beyond 1000 so it sounds like there'll be no problem. I have a couple of slightly more specific questions if you're free:
1) How resource-hungy is BEPU while a simulation remains still- (if a tower of bricks remains untouched)?
2) Regarding terrain, what's the optimal setup with BEPU in terms of the size of bricks (for example) in comparison with the size of the terrain squares. In some engines the bricks need to be much smaller than the terrain squares or performance takes a hit. The problem with this is that I don't want anything more elaborate that vertex based texture splatting for the terrain visuals- if your terrain squares need to be huge for optimal physics, it limits you to very vague texturing.
Hope you can help me out with these, thanks.
Re: General question about BEPU
If it manages to go to deactivate, it's very cheap. It still incurs a cost in the broad phase and a few miscellaneous other bookkeeping sections, but those are much, much cheaper than running the full pipeline including narrow phase collision detection and collision solving.1) How resource-hungy is BEPU while a simulation remains still- (if a tower of bricks remains untouched)?
It's not absolutely free, though. If there's 50,000 sleeping objects, you'll still feel it. It won't be anywhere near as expensive as having 50,000 active objects, but it could still eat into the simulation budget. (For reference, a 3770K at 4.5ghz can run the broad phase for 10,000 sparse boxes in 0.2 milliseconds. The total cost for sleeping objects will be a bit higher than this in a regular simulation depending on the number of sleeping collision pairs.)
The cost of collision detection with terrain increases roughly linearly with the number of triangles that must be tested against colliders as determined by overlapping bounding boxes. The denser the terrain, the more expensive it will be.2) Regarding terrain, what's the optimal setup with BEPU in terms of the size of bricks (for example) in comparison with the size of the terrain squares. In some engines the bricks need to be much smaller than the terrain squares or performance takes a hit. The problem with this is that I don't want anything more elaborate that vertex based texture splatting for the terrain visuals- if your terrain squares need to be huge for optimal physics, it limits you to very vague texturing.
I'd expect having triangles around twice the size of a box or wider would produce decent results. The worst case there is 8 triangles tested with one such box. For comparison, the worst case for triangles roughly the width of the box would be 18 tests. The number of triangles that need to be tested for smaller widths increases from there quite quickly.