S&box Wiki




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 breakable 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:

Currently, it is unclear how some these properties relate to each other. Anybody with added knowledge of these properties should add to this page over time!

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 able to sustain 2-3 high speed impacts, as the prop is repeatedly flung with the Physics Gun, at reasonable 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 additional context, you may also open an existing compiled breakable citizen prop, such as the watermelon, in order to observe the necessary properties of a destructible prop.

Adding breakpieces to the prop.

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



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 then edit each breakpiece from the node tree. This will allow you to set any unique properties for each piece such as the surface property:

While you are able to preview embedded breakpieces after compilation, you cannot edit them as any .vmdl file because embedded breakpieces do not receive a .vmdl of their own. They are seemingly compiled from preset instructions and automatic PhysicsHullFromRenders. It also delimits the use of LODs.

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...

Breakpiece node name Compiled breakpiece filename
piece_0 piece_0.vmdl_c
piece_01 piece_01.vmdl_c
piece_02 piece_02.vmdl_c
... ...

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 if you wish. However...



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

To get more control of each breakpiece, you can set up additional .vmdl files that only represent the breakpieces externally and then refer to these using BreakPieceExternal.

You need to create standalone props of the individual pieces ahead of time, with appropriate nodes within, and then refer to these using external breakpiece nodes:


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


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, this option will probably be enough.

However, it is also dangerously easy to neglect performance impacts from a lack of LODs, the lack of customizability and flexibility, such as including further breakpiece nodes inside of another external breakpiece.

If these extra options sound enticing to you, it is generally recommended to utilize BreakPieceExternal instead, assuming that the breakpieces for your model are ambitious enough, and the extra customizability of each breakpiece model is mandatory for your application.

Special Pages



Render Time: 72ms

DB GetPage 54
Generate Html 0
SaveChanges (1) 13
Render Body 0
Render Sidebar 1