[Open Source] [Unreal Engine Plugin] Niagara Destruction Driver - Turn CHAOS destructibles (Geometry Collections) into performant GPU niagara particle simulated destructible mesh

Resources & Knowledge
1

Hi everyone,

I wanted to share an open-source plugin I put together for Unreal Engine: :boom: Niagara Destruction Driver

:brick: The Problem: Chaos Fracture tools are great for creating destructible geometry in the editor, but the chaos physics runtime can be too expensive on the CPU to drive a lot of cosmetic destruction of props in your scene.

:bulb: The Solution: Niagara Destruction Driver turns CHAOS destructibles (Geometry Collection assets) into very performant GPU simulated destructible static meshes driven by Niagara particles.

niagara destruction driver demo - gpu simulated destruction from chaos destructibles

:hammer_and_wrench: SETUP + USAGE

getting started info in the github README.

:mag: Under the Hood

(can’t add architecture diagram since I’m a new user… but it’s up on github)

Under the hood the plugin uses a niagara system to simulate the physics of the fragments (bones) on the GPU, write their transforms to render targets, and finally a vertex shader to constrain the vertices of a specific fragment to its respective bone using the render targets.

:world_map: Next Steps

  • There’s a rough roadmap up on the github README.
  • Hit me up on here or on twitter (@eanticev) if you’d like to contribute.
6 Likes
2

Architecture Diagram:

2 Likes
3

@eanticev
Did you turn off tsr for the example or do you have a method to deal with the smearing?

4

There’s some half-finished code in the material for smearing that’s not active ATM. Essentially you have to do double the render targets (keep previous and current positions and use those in the material to clean up motion vectors) … this should prevent smearing. Haven’t finished that work, but in our original version at the studio we did fix AA and motion blur smearing with this technique.

If you open an issue on github I can try to finish this.

1 Like
5

Ah, was mostly curious cause I usually “fix” it by passing in motion vectors as a separate target, but noticed you got away with not doing that. So I thought you had a fancy way of fixing it :smiley:

Do you keep a copy of the rotation target to deal with rotational velocity?

6

LOL I wish man, still have to do it like so:

image
image1588Ă—884 153 KB

Notice that it’s half implemented in the material function here but not 100% wired to the particle system.

You have to feed different textures to the different MF inputs from the render targets.

It’s on the roadmap :slight_smile:

1 Like