The Kids With Sticks Team has recently published a thorough tutorial on how to create destructible objects in UE4 and Blender. With their permission, we are sharing it on our website. Follow this link to see the original post.
While Chaos physics engine is on the way, we were testing approaches to make destroyables in Unreal Engine 4. Here you can find how we did it.
As always we start by pointing out what we would like to reach:
We were searching for best references that fit our needs and we found that destructible from Dark Souls 3 and Bloodborne fit perfectly for us.
The basic idea is easy:
We are using Blender for object preparation, we recommend using it too. To create fracture mesh we use Blender Addon called Cell Fracture.
- Enable Addon
First, you would need to enable the addon as it’s not enabled by default.
- Search for Addon (F3)
Then enable addon on selected mesh.
- Configure Settings
- Run addon
Check out our settings here:
- Select by Material to unwrap the cut parts
Then just create UVs for parts.
- Add Edge Split
Edge Split will correct shading.
- Link Modifiers
This will apply Edge Split modifier to all selected parts.
- Final
This is how it looks in Blender. Basically, we don’t need to model all parts.
Our destroyable is an Actor who has a couple of components:
We are configuring some things in the constructor:
In Begin Play we are gathering some data and configure them:
There are three places which will trigger break:
- OnOverlap
For example: when you want to break if someone is dashing or using the specific thing like rolling ball.
- OnTakeDamage
When destroyable is receiving damage.
- OnOverlapWithNearDestroyable
This one is important. When you put one destroyable on another one. In our case, they both break as we don’t want to have too many specific physics issues to handle.
When a part is going to sleep (from sleep physics event or forced sleep by delay) we are disabling physics/collision and set mobility to static. Thanks to that performance will increase.
Sometimes your physics asset won’t go to sleep and will still update even if you don’t see any movement. We are forcing all parts to go to sleep after 15 seconds if they still simulate physics:
After breaking we are trying to check if we can destroy the actor (eg. player is far) if not – check again in some time.
We decided that Blueprints are responsible for the audio-visual part of the game so we are adding Blueprints events where we can.
Our game can be played in editor and custom editors created by us. That’s why we need to clear out everything we can on EndPlay.
The configuration is simple. You just put parts attached to the base mesh and tag them as “dest”. That is it.
Graphics artists don’t need to do anything else in the engine.
Our base blueprint class is only doing audio-visual things from events that we provided in C++.
Begin play – load necessary assets. Basically, in our case, each asset is soft object pointer and you should use it as well even when creating prototypes. Hardcoded assets reference will increase editor/game load times and memory usage.
On Break Event – spawn effects and sounds. Here you can find some Niagara parameters which are described later.
On Part Hit Event – spawn hit effects and sounds.
Basically we are always trying to implement logic in C ++ and use the Blueprint to configure parameters and do audio-visual things.
You can create Utility Blueprint for Asset Type Actions to generate collisions for all the parts. Much faster than creating it by yourself.
Niagara is a life changer now. Here you can find how we created this simple effect.
Erosion, color, and alpha come from Niagara.
As you can see most of the effect is coming from the texture. We could use B channel here to add more details but currently, it’s not needed in our case.
We use two Niagara Systems: one for break effect (which is using base mesh to spawn particles) and the other one when a part is colliding (without static mesh location).
To be able to sample static mesh in Niagara your mesh needs to have AllowCPU checked.
TIP: In the current (4.24) version of the engine if you reimport your mesh this value will reset to default. And in shipping build when you try to run such Niagara System with a mesh that doesn’t have CPU Access enabled you will have a crash.
That’s why we have added simple code to check if mesh has this value checked.
Which is used in Blueprints before spawning Niagara.
What is cool you can create an editor widget to find Destroyables, and set their Base Mesh AllowCPUAccess variable.
Here’s the python code which is searching for all destroyables and set CPU access on the base mesh.
You can run it directly using py command, or create button to run this code in Utility Widget.
On update we are doing a couple of things:
You should definitely watch some presentations about Niagara. We will be doing more Niagara focused tutorials over time.
We could use the current destroyable system from UE4 but we want to have better control over performance and visuals. You should ask yourself if you need a big system for your needs. In our case, we don’t. As for Chaos, we are waiting when it will be production-ready.