<cat>Dev.Model</cat>⤶ <cat>Model.Intro</cat>⤶ <title>Breakpieces</title> #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: <upload src="4e91c/8d976cc8b83166b.png" size="4654" name="adding_prop_data_node.png" /> Once the node has been added to the tree, it can be edited in the following fields to receive properties of destructibility: <upload src="4e91c/8d976d04d9d15b8.png" size="18873" name="editing_prop_data_node.png" /> <note>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! For example, damage by fire, bullets, explosives, etc.</note> 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. <upload src="4e91c/8d976cfe400a894.png" size="11131" name="compiled_prop_data.png" /> 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 <upload src="4e91c/8d976da70ce4763.png" size="963" name="image.png" /> 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: <upload src="4e91c/8d976d26017c9a0.png" size="48890" name="image.png" /> 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: <upload src="4e91c/8d976d354b7e4f9.png" size="22362" name="image.png" /> <note>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!** Instead they are directly compiled from seemingly preset instructions, with automatic PhysicsHullFromRenders. For this reason, they also delimit the use of LODs and other external node features!</note> 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 at your own content. ## BreakPieceExternal <upload src="4e91c/8d976de44da45aa.png" size="927" name="image.png" /> 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: <upload src="4e91c/8d976dc1c3f9dde.png" size="105179" name="image.png" /> 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.