Introduction

Breakpieces are dynamic pieces that spawn once a prop is destroyed by any of several types of damage. In an organic context these may also be referred to as "gibs".

Making a prop destructible

Common to the setup of any type of breakpiece, a prop needs to first be made destructible before breakpieces can spawn. This is done by the means of Prop Data in ModelDoc:

Once the node has been added to the tree, it can be edited in the following fields to receive properties of destructibility:

Note the properties that are highlighted in blue, as these are changed from their default value to reflect a limited health pool and the prop's tolerance towards damage caused relative to its speed at an impact.

The current values represent the tolerance of a prop that is capable of sustaining 2-3 high-speed impacts, as the prop is repeatedly flung with the Physics Gun, at considerable effort, into the ground. Subsequently, you may want to edit these values to represent a prop that is either more durable or less durable for your own application. Experiment with these values to your liking.

For additional context, you may also open an existing compiled breakable citizen prop, such as the watermelon, in order to further observe the necessary properties of a destructible prop.

Adding breakpieces to the prop.

In the current stage of setting up, breaking the prop will simply cause it to disappear. This is where breakpieces are needed.

BreakPieceEmbedded

Breakpieces can be embedded into your model, which will correspond to the individual model files that you choose (.fbx, .dmx, etc.). This process is easiest automated using the Add Break Pieces From Mesh wizard:

After doing so, you can edit each individual breakpiece from the node tree. This will allow you to set any unique properties for each piece such as the surface property:

The default naming scheme for each breakpiece after completing the wizard is piece_0, piece_01, piece_02 and so forth...

These will ultimately result in the compiled files piece_0.vmdl_c, piece_01.vmdl_c, piece_02.vmdl_c, etc...

When the model is compiled, the embedded breakpieces will generate into a folder with the same name of the .vmdl you are working on, if they have not already. Their names reflect the same as above, unless you rename the nodes before compiling.

At this point, your prop should have capable breakpieces that spawn once the prop is destroyed, and you can finish your work off here at your own content.

BreakPieceExternal

The customization of embedded breakpieces is limited to the properties of each node. For applications where props break into a considerable amount of breakpieces at once, it can be very taxing on performance when the prop is destroyed because the embedded breakpieces do not allow for LOD functionality, even if broken from far away.

To gain more control over each breakpiece, you can set up additional .vmdl files that only represent the breakpieces externally and then refer to these using BreakPieceExternal. What this means is that you need to create standalone props of the individual breakpieces ahead of time using ModelDoc, with appropriate nodes within, and then refer to these models using external breakpiece nodes:

Notice how some properties have disappeared from the list when compared to the embedded node, as these are now handled by the nodes within the Model that is being referred to at the bottom of the property list. Henceforth, we get external dependencies.

Conclusion

BreakPieceEmbedded is generally considered the common and faster option towards introducing breakpieces into your model, in part due to the associated quick wizard in ModelDoc. For moderated applications with very simple physics, this option will probably be enough.

On the other hand, it is easy to neglect deteriorating performance as a result of a lack of LODs. Furthermore, the lack of customizability and flexibility, such as including breakpiece nodes inside of another breakpiece, is only realised when using the simpler embedded breakpiece nodes.

If these extra options sound enticing to you, it is generally recommended to utilize BreakPieceExternal instead. This assumes that your application requires the use of nodes that associate with breakpieces directly and therefore cannot be handled by the destructible prop itself, such as a unique material group only for breakpieces.