S&box Wiki
Home
/
Edit Breakpieces
View
Edit
History
No Category
Developer Overview
The Project System
Publishing To Asset Party
Getting Started With Hammer
Mapping Basics
Mapping Entities
Advanced Mapping Techniques
Getting Started with Modeldoc
Animgraph & Animation
Physics
Modeldoc Nodes
Advanced Modelling
UI Basics
Styles & Stylesheets
Razor Templates
Game Menus
Materials
Built In Shaders
Shaders
Shader Reference
Sounds & Audio
Particles
Getting Started
Making Games
Input
Networking
Physics
Rendering
Editor & Tools
VR
Misc
Playing Guides
Console Commands & Variables
Dedicated Server
Log in to edit
Breakpieces
<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.
S&box Wiki
Development
Developer Overview
6
Editor Overview
General FAQ
System Requirements
The s&box wiki
Troubleshooting
Useful Links
The Project System
4
Adding Assets
Creating a Game Project
Project Settings Window - Games
Project Types
Publishing To Asset Party
2
Uploading assets
Uploading projects
Hammer
Getting Started With Hammer
3
Getting Started With Hammer
Making Your First Map
Mapping Resources
Mapping Basics
7
Cordons
Hotspot Materials
Selection Sets
Standard Mapping Dimensions
Tool Materials
Tools Visualisation Modes
Using Entities That Require a Mesh
Mapping Entities
2
Creating a Door
Light Entities
Advanced Mapping Techniques
8
Collaborating With Prefabs and Git
Instances
Prefabs
Quixel Bridge Plugin
Tilesets
Tilesets-Advanced
Tilesets-Proxies
VIS Optimizations
Models & Animation
Getting Started with Modeldoc
7
Automatic Model Setup
Breakpieces
Creating a Model
Guide to Models
Importing Rust Weapons
LODs
ModelDoc FAQ & best practices
Animgraph & Animation
4
Animations without Animgraph
AnimEvents, AnimGraph Tags, Attachments
Animgraph
Delta Animations
Physics
3
Cloth Physics
Collisions, Physics & Surface Types
Jiggle Bones
Modeldoc Nodes
1
Custom ModelDoc nodes
Advanced Modelling
6
Bodygroups
Citizen
First Person
IKChains and Stride Retargeting
Morphs
Vertex Normals
User Interface
UI Basics
7
Custom Fonts
Embedding Websites
Enabling Pointer Events
Events and Input
Localization
UI Basics
UI with Components
Styles & Stylesheets
1
Video Backgrounds
Razor Templates
4
A Razor Overview
Aliases and SetProperty Attributes
Generic Components
Templates
Game Menus
1
Making a Custom Pause Screen
Materials & Shaders
Materials
5
Guide to Materials
Material Attributes
Material Resources
Texture Settings
Using Dynamic Expressions
Built In Shaders
2
Foliage Shader
Glass Shader
Shaders
4
Compute Shaders
Constant Buffers
Material API
Shading Model
Shader Reference
5
Anatomy of Shader Files
Getting rid of Tex2D macros
Shader Reference
Shader States
Texture Format Cheat-Sheet
Other Assets
Sounds & Audio
4
Guide to Sounds
Sound Events
Sound Occlusion
Soundscapes
Particles
5
Creating animated sprites
Creating your first particle effect
Understanding Particle Editor
Using custom sprites
Using particle systems from C#
Coding
Getting Started
5
Cheat Sheet
Learning Resources
Setting up Rider
Setting up Visual Studio
Setting up Visual Studio Code
Making Games
2
Components
GameObjects
Input
4
Commands
ConVars
Input System
Speech Recognition
Networking
7
Auth Tokens
Http Requests
Lobby System
Networked Types
Networking Basics
RPCs
WebSockets
Physics
5
Collisions
Hitboxes
Joints
Traces
Triggers
Rendering
3
Render Tags
RenderHooks
Scenes
Editor & Tools
7
Creating a Tool
Custom Asset Types
Guide to Widgets
Hammer API
Hammer Gizmos
Hotload Performance
Widget Docking
VR
3
Getting Started
VR Input
VR Overlays
Misc
13
Asset Types
Attributes and Component Properties
Backend API
Cloud Assets in code
Code Accesslist
CPU Performance Profiling
DisplayInfo
FileSystem
Mounting assets at runtime
package/find
Setting Up A Navigation Mesh
Threaded Tasks
TypeLibrary
Playing
Playing Guides
3
Default Keybinds
Proton
s&box on macOS (Experimental)
Console Commands & Variables
1
Launch Arguments
Dedicated Server
1
Dedicated Servers