Hi, im currently prototype a game for deployment to the xbox360. We have a requirement for neatly stacked walls of cuboids that are occasional hit by faster moving objects. Currently with walls made up of about 24 1x1x1 cubes we get reasonable performance when the system is in rest but near zero performance at the moment of collision. With a requirement of considerably more objects
We set the system to have a collision boundary of 0 units to allow the walls to stack neatly and lowered the bounciness of each wall part of 0 to prevent the walls shaking themselves apart as soon as physics are enabled. Are there any strategies that can be used to allow this kind of large scale stacking or is beyond what bepu physics is designed to accommodate.
Many thanks
Stacking
Re: Stacking
24 cubes in a wall should be no problem. If there more than a few active walls, each with 24 cubes, the Xbox will begin to have problems though. It's an order of magnitude slower than an average PC at this sort of processing.
That said, depending on the simulation, there are some options. By default, the number of solver iterations (space.simulationSettings.collisionResponse.iterations) is set to 10. This is higher than most simulations need for acceptable accuracy. I created a 12 wide, 5 high (for 60 1x1x1 cubes) wall with only 2 iterations and it is still relatively stable. Combined with the default of space.simulationSettings.collisionDetection.collisionDetectionType = CollisionDetectionType.discreteMPRGJK, this simulation should run in less than 16 ms per update on the Xbox360.
In order to handle much more than that, you'll have to start faking some things. For example, the largest cost is dealing with the numerous collision pairs. If you can explode a wall into bits as soon as it becomes active, the number of collision pairs will be vastly reduced. When in a usual wall configuration, the number of neighbors for each box is much higher than when the box is tumbling through the air or just laying on the ground somewhere.
To encourage things to go to sleep faster after the explosion, you can adjust the space.simulationSettings.deactivation settings.
Performance on the Xbox360 is always a priority, and almost every version increases performance. v0.13.0 should provide some significant gains (you can see a roadmap at http://www.bepu-games.com/forums/viewto ... ?f=5&t=849).
That said, depending on the simulation, there are some options. By default, the number of solver iterations (space.simulationSettings.collisionResponse.iterations) is set to 10. This is higher than most simulations need for acceptable accuracy. I created a 12 wide, 5 high (for 60 1x1x1 cubes) wall with only 2 iterations and it is still relatively stable. Combined with the default of space.simulationSettings.collisionDetection.collisionDetectionType = CollisionDetectionType.discreteMPRGJK, this simulation should run in less than 16 ms per update on the Xbox360.
In order to handle much more than that, you'll have to start faking some things. For example, the largest cost is dealing with the numerous collision pairs. If you can explode a wall into bits as soon as it becomes active, the number of collision pairs will be vastly reduced. When in a usual wall configuration, the number of neighbors for each box is much higher than when the box is tumbling through the air or just laying on the ground somewhere.
To encourage things to go to sleep faster after the explosion, you can adjust the space.simulationSettings.deactivation settings.
Performance on the Xbox360 is always a priority, and almost every version increases performance. v0.13.0 should provide some significant gains (you can see a roadmap at http://www.bepu-games.com/forums/viewto ... ?f=5&t=849).
Re: Stacking
Thanks Norbo, sadly the 1x1x1 situation was just for initial tests. The intention was to allow the user to construct castles out of basic primitive blocks, cubes, pyramids, slopes etc. Then take turns to throw bits at the other persons castle. Sadly this means that I cant blow walls up on contact or it will be a pretty poor game. And users will deliberately try to make complex arrangements that will hold together sadly keeping the collisions pairs high.
I have already tried lowering the iterations down to 2 with little gain in fps, I will play with the deactivation settings and see what fat I can trim off
Thanks for the help
I have already tried lowering the iterations down to 2 with little gain in fps, I will play with the deactivation settings and see what fat I can trim off
Thanks for the help
Re: Stacking
If you're looking for a total entity count in the hundreds organized in such a way that they're pretty much all in the same simulation island if they were all active (like a big pile), you'll probably need to get creative on the Xbox.
One possibility is to build the castles out of prebuilt sections. When initially placed, the entities would be kinematic. Once they get hit enough (or by a large enough impact), the section would become dynamic/destructible. This way, only sections directly involved in the activity or affected by it will fail while the rest of the castle sits idle, keeping the total number of active entities at any time relatively low.
This would certainly change the gameplay a bit, but it would allow for the illusion of hundreds of physical objects.
One possibility is to build the castles out of prebuilt sections. When initially placed, the entities would be kinematic. Once they get hit enough (or by a large enough impact), the section would become dynamic/destructible. This way, only sections directly involved in the activity or affected by it will fail while the rest of the castle sits idle, keeping the total number of active entities at any time relatively low.
This would certainly change the gameplay a bit, but it would allow for the illusion of hundreds of physical objects.
Re: Stacking
Sadly I don't think I will be able to take that route since my brief was pretty specific in letting users create castles from primitive objects. Having played around with your suggested changes I still haven't been able to get a reasonable performance for real time use. Although the simulation does seem to resolve over a few seconds.
When towers etc fall down they are create pretty nasty piles of boxes and its really hurting, especial when they are in content with a part of the castle that is still upright. I'm going to try adding some kind of rules that if object get bashed around too much and are a set distance away from the objects original position (when creating the castle) they are destroyed from the simulation to try and clear away some of the rubble that's building up.
Otherwise I have been toying with the idea (since its a turned based moves) that I can run the physics off-line for a few seconds after players make their moves and bake the object positions and rotations into some kind of animation sequence, still depends what kind of performance I can get to stop player getting bored waiting between turns, but certainly takes the pressure of the physics a bit.
When towers etc fall down they are create pretty nasty piles of boxes and its really hurting, especial when they are in content with a part of the castle that is still upright. I'm going to try adding some kind of rules that if object get bashed around too much and are a set distance away from the objects original position (when creating the castle) they are destroyed from the simulation to try and clear away some of the rubble that's building up.
Otherwise I have been toying with the idea (since its a turned based moves) that I can run the physics off-line for a few seconds after players make their moves and bake the object positions and rotations into some kind of animation sequence, still depends what kind of performance I can get to stop player getting bored waiting between turns, but certainly takes the pressure of the physics a bit.
Re: Stacking
Recording the positions could very well be the best way to do it if you can't fake the actual simulation. 400 blocks in a 20x20 wall take about 130-150 ms per frame on the Xbox360, so it is relatively safe to say that it will take about 10 times longer to simulate a large simulation than real time. With some good tweaking, you could probably resolve most impacts in 1-10 seconds of 'simulation time' (10-100 seconds of waiting without any extra tricks).
If you aggressively pre-simulate, such as starting from when the player is even aiming, you might be able to get through a good portion of the simulation. If you also played back the hit in slow motion the first time, that would give you additional leeway for starting up the playback earlier. If you adaptively slowed and sped up the playback, you might be able to start the playback while the simulation is chewing away in the background. If your playback is going too fast compared to the simulation, it can slow down the playback smoothly to ensure that it doesn't hit the edge of simulation. Fortunately, this slowdown would most likely coincide with interesting things happening (since interesting things are usually slower). Since the playback would be smoothly interpolating the recorded data for rendering at any framerate, it wouldn't look jerky at all.
After it plays back the first time, you could let them go back and forward through the recording at any speed they want with little extra development work too. That would be fun to watch
If you aggressively pre-simulate, such as starting from when the player is even aiming, you might be able to get through a good portion of the simulation. If you also played back the hit in slow motion the first time, that would give you additional leeway for starting up the playback earlier. If you adaptively slowed and sped up the playback, you might be able to start the playback while the simulation is chewing away in the background. If your playback is going too fast compared to the simulation, it can slow down the playback smoothly to ensure that it doesn't hit the edge of simulation. Fortunately, this slowdown would most likely coincide with interesting things happening (since interesting things are usually slower). Since the playback would be smoothly interpolating the recorded data for rendering at any framerate, it wouldn't look jerky at all.
After it plays back the first time, you could let them go back and forward through the recording at any speed they want with little extra development work too. That would be fun to watch