• Register
Post news RSS Building destruction physics

A bit of information on the destruction physics, how they work, and how it'll behave, as well as some technical information.

Posted by on

Hola, people! This post is about the destruction physics I'm adding to Lexicon. I'll be explaining some advantages gameplay-wise, as well as the tactical and dynamic advantages it gives you while playing. After that, I'll give a short run-down of how it works.

First off, some basic information. I aim to have fully destructible physics, with as minimal of a performance hit as possible. In a previous write of Lexicon (I restarted in early January), I had this sort of system working, but with many drawbacks due the how limited I was thanks to the mostly inefficient code of that write. Here's a few links to YouTube videos of the destruction physics:

Youtube.com - A test to see how well my code coped with extreme stress on a low end system.

Youtube.com - Just a show of some of the destruction
Youtube.com - Original, first video of progress I'd posted

Now for gameplay advantages. This system opens the game up to many possibilities, including new gametypes, weapons, and tactics. There could be hidden areas that one would have to blast their way into to reach, maybe holding ammo or vehicles. There could be gametypes dedicated to seeing which team can destroy the most in a certain amount of time, or a gametype in which a team must attach an objective and do as little damage to it as possible. The list goes on, and in the end any major disadvantages end up heavily outweighed by the advantages.

Some tactical advantages include things like being able to drive a tank clean through a wall, taking down sniper towers, etc. The thing about it is, you must be strategic and thoughtful about the destruction you do. For example, if your flag is inside a base building, and the enemy is inside, it's obviously not the best idea to blow down the entire building. That just puts your flag right in the open. At a time like that, an on-foot assault is a much better idea. Now, on the other hand, if there's an enemy atop a sniper tower, and you've got a handy-dandy rocket launcher, you get the opportunity to test sniper vs. gravity. Or, if you really want to be mean, you could just test sniper vs. rocket to the chest. Either way, the destruction allows you to experience this to the fullest.

From here down I'll be explaining how the system works, and how my asset pipeline builds right into it. Non-technical people might get confused, and the technical might enjoy it.

First, when I model a building, I use a fracture script to break the modeled building into a specified number of parts. For most buildings, it's around 200-300 parts. I group-name objects with prefixes like "_B", "_M50", or "_L10". More on what those do later.

Next, I load the model into the game and iterate over it's parts. For each part, I read it's name and check for certain key phrases that give it different behaviors.
If a name contains "_B", it marks that it can be fractured (or broken off) by a bullet instead of only explosions. I mark windows, railings, and small edges with this.
If a name contains "_M", I read the following 3 numbers to check for a specified mass. Obviously I don't want a shard from a window weighing as much as a chunk of concrete. The default, if this isn't specified, is 100, but for windows and lights I usually make it around 5-10.
If a name contains "_G", I read the next 2 numbers to check what group it belongs to. If a part belongs to a group, and is broken, the rest of the parts in it's group fracture too. I use this for windows, sometimes railings, and other things like that.

After this, I check the volume of the part. If it has a low volume, I give it a simple box collision shape. This saves the CPU from having to simulate mesh-close collision shapes that are too small to even be noticed. If it has a higher volume, I give it a dynamic mesh shape, which is a convex hull collision shape that's accurate enough to be realistic, but low-detail enough to be used at runtime.

Last, I add each part to the physics space. If a bullet hits a part that is marked as fracture-able by bullets, I fracture it. If a part is hit by a grenade, and the force is high enough, it gets destroyed as well. When a part gets fractured, I take away it's mesh-accurate shape, replace it with the post-fracture collision shape I generated before, and give it it's specified mass. After that, I give it an impulse from the direction it was hit from, or from where the explosion was. Also, I set the parts to have a raised linear and angular sleeping threshold so they ignore changes in position and rotation more often than other rigid bodies.

And that's it! The changelog for today is as follows:
+Added grenades (still working on them, they're a bit lag inducing)
+Added painfully un-optimized, very basic, subject-to-change building code. And subsequently played with it for 2 hours. :D
-I added a camera sway effect, but I'm not very happy with it. I'll throw a bit more time into it when I'm done with buildings.


So cool! Two questions:
1) Are there any added complications with models not made from scratch, e.g. if you buy a model pack and want to apply this method (fracture script) to those models?
2) What modeling tool are you using? And, are you completely tied to that particular tool?

Reply Good karma Bad karma+1 vote
VinexGames Author

1. There are no complications there at all. All texture mapping is saved, all normals are recomputed, and everything else is accounted for as well. You'd just have to (optionally) specify custom traits for certain parts, like making corners take more stress to break.

Reply Good karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.