Controls: Use the space bar to send the sphere at a high speed into the building.
NOTE: The FPS may be somewhat slow at times, but is now much faster than before thanks to a new optimization technique seen in the version just uploaded.
The reason for doing this over the last evening and today was in part to test a possible new mechanic for an existing game of mine and in part as a response to all of the new sandbox physics games being developed that currently do not use a concept for jointing objects to make destruction of them a tad more realistic by allowing the formation of arbitrary pieces and allowing more realistic stress simulation.
This is different from another one of my tests in destruction (modular destruction), because this time I start from actual rigid-body objects and do not approximate it with multiple pieces and debris objects.
One final thing, you are free to use this concept in your own games, I’m not asking too much in return, but a little credit would be nice.
Okay, uploaded a new version with the new optimization technique.
The file now has two buildings, but each of them are in their own invisible action box where all of the objects within start with their physics disabled. When the sphere hits one of the box it activates the physics of the objects inside and allows it to destroy it as it would in the screen in the first post, the second building then contributes little effect to the FPS as it remains disabled until the sphere goes into its box.
As a bonus the starting FPS gets a bit faster, but will still slow down when every object in the entire building is moving.
Was playing with this again and something struck out at me in terms in what one of the bottlenecks were.
I noticed that large parts of the buildings were activated physically, but they were barely moving at all meaning they were stable, so I immediately began to think of a way to use logic to deactivate those stable areas physically while not compromising the quality of the destruction.
The solution is in the new image, the coloring is actually a visualization of a system that uses a raycast as well as checks for object motion to determine if the object is anchored, and if it is not moving or sitting on top of another object, if there’s little to note force being applied to the joints, and it’s not in the immediate proximity to the destructive ball objects, deactivate the physics. Other checks are then used to determine if the conditions have changed in a way to reactivate the physics.
In the new demo, anchored objects are visualized as red, you’ll also be seeing objects turning green as well and then red, this is to start a cooldown that means a slow moving object must remain below the threshold for a period of time before being considered as anchored, in which in the cooldown restarts if it leaves those conditions.
While there is an offset with the increased amount of time needed for the logic, the fact that there’s a near absolute-minimum number of objects executing physics as opposed to all at once means an FPS that is up to several times higher or more, the bounce back time for the FPS after the balls leave the area is also much shorter as well. An actual game could then improve the FPS further by disabling the logic of the objects if the player leaves the area.
So in other words it’s not extremely slow anymore despite the fact that it could still use some improvement (either through some different logic technique or the BGE itself getting more optimized in this area through ways such as the ability to run on more than one core.).
Pushed a quick new update with some significant optimizations in the logic.
-Split the main logic into three separate parts that execute one at a time instead of all at once, this gives back quite a few frames per-second.
-Simplify and clean up the loop that determines whether an object is anchored or not, less code to execute and fewer checks.
-Start the objects off in a completely inactive state this time, this means a full 60 FPS at the start which is what you would want if you have this in a game and the player is not in the area.
EDIT: Found some simple things, also some more changes.
-Changed the way you view the demo by replacing the spacebar ball release with a single ball that is controlled by the arrow keys (along with the space key for moving up), this I thought would be a better way to see it since it is more interactive.
-Restored the crumbling seen in early demos by reminding myself that one of the points of the anchoring logic is to actually use the command to restore the physics with anchored is 0.
Did a bit more work on it and uploaded a new version.
-Introduced the concept of whether or not an object is ‘Grounded’, that is if it’s attached to the ground or is attached to a line of objects attached to the ground, this helps reduce the amount of objects that have their physics enabled at once while maintaining more realistic destruction.
-Created a system where each object chooses a random inactive state to create a staggered execution pattern that helps optimize the logic while maintaining destruction quality.
-A basic object spidering system is now in place, in that objects with disabled physics get activated when active objects are nearby without enabling the physics for every part of the building, this helps to greatly reduce instances of floating parts, but doesn’t eliminate them (otherwise, any optimization might have to be toned down a bit which may not be worth the reduction in speed). The fact that the script creates permanent connection data by assigning the names of neighboring objects to properties eliminates the need for constant (and costly), six-way raycasts.
-Another logic optimization, disable the logic for objects with no connections left, now they’re just like basic physics objects
-Updated the visualization system to signify anchored grounded objects as purple
-Experimental PhysicsLevel system that allows you to define the level of optimization, doesn’t seem to have a major effect as of now though.
There’s some significant improvement in cases, but it would seem that getting a solid 60 FPS especially with moving pieces on both buildings would be nearly impossible without the BGE code being reworked to take advantage of multiple cores, not without compromising the ability to keep the incident of small floating pieces to a minimum (which compromising could still be acceptable in cases where it’s just walls in a building frame made of static geometry)
Now there might be some ideas I haven’t tried that could give similar results to what I have now and yet be a bit faster, but I’m not sure what they would be if they exist.
