wRect provides a means to effortlessly generate fully functional, physics based, fractured meshes from axis aligned rectangular slabs.
Specialized, multithreaded slab fracturing for when simple is ample and fast is a must.

It can provide adequate performance without resorting to using native code or compute shaders reducing the need for compatibility testing and continuous support significantly.
Walls, glass panes, sections of destructible tarmac, anything you can put together from wooden planks and panels and generally anything made of cuboids can now be made destructible without leaving the familiar confines of Unity editor.
Written in C# works anywhere Unity does. The only requirement is true multi-threading must be available.
Performant and more importantly, multi-threaded generators can create fractures as fast as possible without hogging the main thread.
Good old Unity Physics based. Those who understand this physics engine will be right at home. Fractures will naturally work nicely with any other rigid bodies and colliders in the scene without having to augment them with any additional components. If they update to new version of PhysX you don’t need to worry about compatibility. In fact you don’t need to do anything.
Whenever only a deterministic, replayable animation is needed without full physics interactability, helper component will allow you to use GameObjectRecorder to record destruction simulations without a nuisance.
Finally for additional designer-friendliness this package also offers generating fractures from several combined point clouds with local chunk density easily controlled manually using curves.
Road Map:
- Select parts of code may also be reimplemented as Burst Jobs or Compute Shaders
- More UV mapping options
- Inner surface detailing (tessellation)
- Bevel with UV remapping
- Tutorial Framework based tutorials
A bonus nugget of knowledge:
Gritty details:
Gritty details:
Assemblies are fully IL2CPP ready. In fact, this kind of build is strongly recommended if performance is of any meaning.
Fractures can be generated on-the-fly. Even on less capable hardware in-background generation doesn’t cause stutter, just takes longer.
Pre-creating fractured objects in editor, both as part of the scene and in the form of prefabs is just as effortless.
Fracture chunks can be connected (grouped) into larger fragments to emulate more natural looking cracks and breakage.
Extensive caching mechanisms at different stages of fracture generation can reuse intermediate results depending on how similar the fractures are. Thanks to that nothing takes longer than it really has to. For that reason you shouldn’t really bother putting every single fracture into a separate prefab unless you have other reasons to do so. Similarities between fractures will be recognized automatically and if any close enough match is found among previously generated objects they will only be modified to much current request. In other words don’t try and over-organize things - leave it to the software.
The above is the main reason why it made a lot of sense to create a specialized cuboid fracturing package.
General mesh slicing can never hope to get anywhere near this level of algorithm optimization or reusability of generated objects.