Destructible 2D ☄️ Dynamic Sprite Destruction

​

Destroy all your sprites using Destructible 2D. This feature packed destruction toolkit takes you game to the next level, adding new gameplay possibilities!

Destructible 2D has received regular updates for over 6 years. Thank you to everyone who was purchased, rated, reviewed, and provided feedback!

Get started in seconds with the intuitive design.
​

Quickly learn how to use every setting with the step-by-step tutorial scenes.
​

Automatically split sprites into smaller pieces when you damage them enough.
​

Heal sprite damage for new gameplay possibilities.
​

Fully customizable for any kind of project.
​

Includes many game examples to get you started.
​

And much more...
​

>> Get Destructible 2D <<​

Thank you for reading.

 

this could work with mesh renderer?

 

This uses Sprite Renderers: example

But Sprite Renderers work fine with Mesh Renderers, Particles, etc.

 

Sounds interesting, but I think there's a problem with your webplayer demos as they're not working at the moment (the sprites are black rectangles that don't do anything). I'm on a Mac if that makes any difference.

 

Strange, it worked fine when I last tested. Unfortunately I'm out of town for the next 3 days so I won't be able to thoroughly test it just yet.

 

hi looking forward to watch some setup videos

 

I've now fixed the issue, updated the web player demos, and submitted the fix. It should be online in a few days.

Sure, I'll begin recording them tomorrow.

 

I've uploaded a tutorial video showing the basic usage here:

 

I have a couple small questions I hope you can answer.

What determines which object will be parent or child if the object becomes split. Is it easy to make the parent always be the larger half?

Do objects keep and continue to run their script if split?

Is it easy to output a % of mass left on an object?

I want to use the remaining mass of an object as its health and want to make sure this is possible.

I like the fact that your destruction script can handle multiple kinds of cuts. I have not found another script that can do this. Most will ignore damage unless it passes through the entire object. It also seems to run faster than other code serving a similar function.

 

Right now the splitting is based on the position of the pixel 'islands' in scanline order, where the first encountered island will remain the original.

If you want to force the original to always remain the largest island, then open up Destructible2D/Required/Library/D2D_SplitCalculatior.cs and scroll down to line 109 and add the following:

Code (csharp):

1. fills.Sort((a, b) => b.Count.CompareTo(a.Count));

In the next version I'll include an option in the inspector so you can choose between various sorting modes.

Yes, when a sprite is split, the original gets duplicated, so all scripts and settings will get copied over.

No, but this is a good idea. I'll add it to the next version.



Thanks for the ideas! I'll hopefully get the next version ready today or tomorrow.

 

Thank you for your quick reply. I am looking into creating a game that heavily relies on slicing of 2d objects. Part of the issue I have is that most if not all engines cannot do partial cuts like yours can, they either completely cut through the object, or don't cut at all, they also seem to chug after a couple cuts where as yours seems like it will work great for mobile.

Keep up the good work.

 

Looks cool, I'll be getting this.

 

Code (csharp):

1.  
2.  
3. Ray ray = Camera.main.ScreenPointToRay(transform.position);
4.         float distance = D2D_Helper.Divide(ray.origin.z, ray.direction.z);
5.         Vector3 point  = ray.origin - ray.direction * distance;
6.    
7.         D2D_Destructible.StampAll(point, Size, Angle, StampTex, Hardness, Layers);
8.  
9.  

Okay so I was trying to pass a vector 3 position instead of a vector 3 screen position. Now I can laser through things all day. Going to have to figure out some tricks to make it work smooth on phone though.

 

So something that I am noticing is split is a very expensive action when I think many uses of it might just be visual rather than functional.

In my case I want a static mesh that when sliced, the smaller part becomes a full physics object that cannot be sliced and falls away. I think I may mess around with the code a bit and see if I can come up with a version that does something of the sort, In my case I want to be able to slice things on the iPhone, but the part that is smaller will be inconsequential other than the graphic of it flying off and will just drain processing power if it has a sophisticated collider and can still be cut when I no longer need it to do either.

Just some functionality to think about.

 

If you want to slice stuff in world space then you can use:

Code (csharp):

1. D2D_Destructible.SliceAll(Vector2 startPos, Vector2 endPos, float thickness, Texture2D stampTex, float hardness, int layerMask = -1)

But yea, if your camera is set to Perspective rendering then you would need to project the start and end points into 2D space. The only reason why I didn't include a demo for this is that if your sprites are on a different Z position then the stamps can become unintuitive (e.g. it may appear to stamp the wrong areas on each sprite), so sticking to 2D only demos simplifies things.

Yes, slicing is pretty expensive because I first have to find all pixel islands. Right now I'm just iterating over each pixel and flood filling each region, perhaps there's a much faster method. And once sliced the Sprite needs to be cloned and each AlphaTex needs to be generated, which can also be expensive.

As for slicing static sprites up and have the smaller pieces break off, this is actually a feature I added to the latest version, but I'm just waiting for the Asset Store team to accept the changes. I'll send you an early copy of it to try out.

 

Awesome! I think this is everything I needed. Thanks for the support.
The ability to create dynamic objects from a static one is going to be great, can't wait to start experimenting with it.


Added Solid Pixel Count and Original Solid Pixel Count variables to sprites.

Is this the % of mass left functionality I asked for : )

 

Yes

You can get a percentage (0..1) from: yourDestructibleSprite.SolidPixelRatio

If you're using this on a sprite you've already set up before updating, then make sure you first select your sprite and choose 'Recalculate Original Solid Pixel Count' from the context menu.

 

Hey guys, I uploaded two new demo scenes:

Stalactites - This demo features the new 'Breakable' component, which allows you break static sprites into dynamic ones. If you click the mouse on the stalactites then you should be able to break chunks off the static sprite and have them fall onto the eggs.

Mothership - This demo features the upcoming 'Fixture' component, which allows you to associate a GameObject with a specific pixel on your destructible sprite. This means that if you split a sprite in half (e.g. a space ship), the game objects that are attached to pixels on the other side of the split will still be attached to the correct side. It also allows you to destroy objects that are attached to the destructible sprite (e.g. the engines and guns).

These demo scenes will all be included in the next version of Destructible 2D. Stay tuned for more!

 

The Fixture component is awesome. Super easy to place, I just made an object with a script, added the fixture component and then made the component a child of the breakable object. In my case I made a building with some lights. Cut the building and the lights roll with it.

 

Hi Darkcoder,

Do you know if this will work with the Ferr2DTerrain engine?

http://www.simbryocorp.com/Ferr2DTerrain/

 

By the looks of it, Ferr2DTerrain uses custom a Mesh to render the terrain. Whereas Destructible2D uses a Sprite/SpriteRenderer/Texture2D. I imagine getting Destructible 2D's functionality working with Ferr2DTerrain would be a massive undertaking, so no.

 

This is EXACTLY what i need to finish my project. I was using an alternative to make destructible terrain, but this is much much better, will be buying ASAP

 

Dear DarkCoder,

I'm think of buying your Asset to create a destructible world for my game. However I am curious whether you think the following is possible: say I have a large building and you keep shooting chunks out. At one point, the building may only stay upright due to a small piece of geometry. I know it can be a daring geometric/algorithmic challenge to break up a mesh realistically. But say I want to make some sort of easy version where the edge of the mesh checks where the closest edge is (based on its normal direction or I dunno) would you think that is possible? Would that involve slicing or are there faster / more efficient methods? Attaching an image to clarify a bit, I might not make the most sense when writing

So, the mesh would be sliced or something on the green edges where the distance < threshold, whereas the red lines would be cuts that will not be made due to the distance > threshold.

Also, I think I saw a possibility for this: if a piece of building hits a collider, can I take that point and use it to break up the piece of building, as it were crumbling or something? I guess that would involve slicing, and as you mentioned earlier slicing might not be the most efficient method in terms of performance. Any ideas?

Thanks for you time!

 

This kind of fracturing isn't built into Destructible 2D, but it's something I would like to add in the future. As you say, finding which parts should be fractured without using up too much CPU is very challenging.

For example, in your example picture there are many more places where the sprite could be split up while still being under the maximum fracture distance:



You could say that these additional slices result in chunks that are too small, but preventing this would require you to calculate the size of each section before it's split, which takes up even more CPU.

You could also say that the fracture lines can only appear from corners of the stamp texture, but how would you calculate the corners? especially for things like circles.

These issues all make implementing a system like this difficult.

This can be done using a stamp texture that's an outline of some shape. This would cause a chunk to be broken off, but I suppose in a future version I could do a proper implementation that works with normal stamp textures.

 

Thanks for the answer. As I expected, yes, it's not trivial building something like that in. Naturally I would find it cool if you'd implement something like that, but I would not be mad if you didn't

Do you mean creating a stamp like the green stuff I drew in the provided image? So that it splits the sprite? Or am I misunderstanding what you meant? The idea is that the red block breaks in some pieces. Ofcourse you could randomize the selected stamp from a collection or something to make it look a bit less generic.

 

Ah, I thought you meant allowing a part of the sprite to chip off when something hits it, but the bit that gets chipped off matches the shape of the hole created.

The kind of fracturing shown in your picture can indeed be done using a large image like the green lines, but it may not be so efficient, and it won't be very flexible. An efficient way to do it would be to generate a Voronoi fracture map and split the image up based on the point count. This isn't implemented in D2D, but I will look into it

 

Ah yes, I have looked into Voronoi as well. Seeing as I'm just working on a game from a hobby point of view all these fancy stuffs I'm thinking of actually might take too much time. I think it would be a nice, pretty unique, feature for D2D, but that's just me talking

Is it possible to tie D2D in with my code that handles damage types vs materials? For example if I shoot a bullet at a sprite that's supposed to be concrete, I just want to apply impact velocity without stamping, whereas wood would be instantly stamped. That would require me to define some damage modifier (bullet vs concrete = 0, bullet vs wood = 0.9) or something. Would that require much work on my end? I don't think D2D has direct support for it from what I've read, ofcourse I might be mistaken, just overall damage resistance with the less opaque textures?

 

I think people have very different expectations which fracturing properties they want. So implementing this customizable or generic enough for various users might not be easy. Would love it though !

 

Sorry for not replying, I didn't see your edit.

You can implement this a number of ways. The easiest is to set up different layers for your materials, and pass the appropriate layer mask to your stamp. You can also do this manually by looking at the code behind StampAll and modifying it to your requirements.

Indeed. I have some good ideas for how to implement two types of efficient fracturing, once I'm done with this small side project I'll get right on it!

 

Hi, really enjoying this asset. One thing I am having trouble finding is if there is a way to have a sprite come apart in script format without having to apply a explosive object to it? Sorry if this is a basic question as I am still new to using the Unity platform.

Thanks!

 

Yes, if you take a look at the D2D_ExplosionStamp.cs script, you can see how applying an explosion to an object cuts holes in sprites. The most important bit is line 34, or the D2D_Destructible.StampAll method call.

Thus, if you want to do it manually in your script, just call D2D_Destructible.StampAll or D2D_Destructible.SliceAll, and if you need even more control then take a look at the code behind those methods to see how the stamping is handled for each individual sprite.

 

Hey guys, I've just submitted version 1.0.7 for review. It includes a bunch of bug fixes, and you can now make destructible sprites from sprites that belong to a multiple sprite, e.g. a sprite sheet.

Note: I changed the way the AlphaTex gets stored, so you will probably have to set them up again in your scenes (e.g. apply the desired amount of Halve Alpha Tex).

For the next version I plan to include sprite fracturing, and optimized splitting.

I've also put the price back to normal, so if you want to get it at the cheaper price then make sure you do it before the Asset Store team approves it!

 

This looks pretty cool, don't know how I missed it before. Would I be right in saying the maximum size of a single `chunk` which would act as one `object` would be the maximum texture size? e.g. 2048x2048? ie you can't have a single-acting object with multiple textures which `looks like` it's all one big object, and when you apply explosions it cuts out of any nearby meshes not just one?

Also what would be good to see is some kind of performance stress test... like maybe terrain filling the screen and tonnes of explosions happening at once with chunks flying off as separate objects etc?

Also if you use the polygon collider (grid) which chops the collider up into grid cells (or close to), I presume making an explosion which produces a `new chunk` would still incorporate parts from any grid cells that it overlaps?

 

Yes 4096x4096 is the largest single destructible sprite you can have, but you can essentially tile multiple sprites together if you need a larger scene. The destruction is applied to all sprites, so if you punch a hole between two (or more) destructible sprites then the shape will correctly be punched out in all your sprites, even if they're rotated or scaled differently.

The performance of the kit entirely depends on how smart you are about setting up the scene. If you set up a 2048x2048 sprite with splitting enabled and spawn tons of explosions then it will run poorly on most devices, but this is a very extreme example and I don't think any amount of code would optimize that enough. If you were to halve the alpha tex resolution a few times (effectively using a 512x512 or so destruction texture), and maybe splitting the sprite up manually a few times then such a scene would begin to run many orders of a magnitude faster. The 'Large Island' demo scene is an example of how you might use D2D in a worms-style with a fairly large terrain.

Yes, assuming I understand your question correctly, the polygon collider will incorporate parts from surrounding grid tiles as you might expect. The grid system basically just generates a collider based on a subset of the full destructible sprite, so if you spawn an explosion between two grid tiles then both cells will get updated with the new sprite data.

 

And then if a chunk is produced, like a new free-moving chunk, composed of parts of two or more grid cells, will that chunk then contain the relevant graphics and colliders from all of those cells?

 

Yes.

 

Dang, I was late to the party. This is totally what I'm looking for on an upcoming set of features. I just barely saw the beginning of this thread that said it was on sale, was reading the thread and saw this post. I hurried and checked the store page, and it was already 1.0.7b. Well, I'll keep an eye on it now, and if it goes on sale again I'll snatch it. (Or if I get to the part that I am ready to use it, which isn't too far out, I suppose.)

 

When an explosion is made, say, in a landscape, and has to cut out a shape, and if you aren't using half alpha resolution, does it have to look through every pixel in the entire large texture, or does it only look through the `cells` (when using the custom polygon colliders) that the explosion overlaps, to minimize processing?

Also along similar lines, when an explosion occurs in a grid cell (part of large landscape), do you only recalculate the affected cells and only submit colliders for those cells, or do you have to resubmit the entire grid of colliders to Unity in order to refresh it?

 

I see in the asset there are several pdf files... I'd like to see what they say before I decide on purchase.. could you possibly email them to me?

 

If you have a large sprite in D2D, depending on your settings it may use say 5x5 colliders. If you then spawn an explosion in the corer that overlaps two of these colliders, then D2D will only perform the calculations required for those two colliders. The other 23 colliders will be unchanged, and there will be no code run across the other pixels, so it should be very fast in this scenario.

One thing to note: if you have a splittable sprite (i.e. one that can break off into separate Game Objects), in this situation the splitting code needs to search through all the pixels in order to detect any new pixel 'islands', so this code will run slower on large images. However, the island searching code is much faster than any collider generation code, so it still won't be as bad.

Also don't underestimate the halving alpha resolution feature, the RGB channels remain untouched, and the shader does apply sharpening, so you can often get away with 1/2 or 1/4 the alpha resolution without any noticeable changes.

Sent you an e-mail.

 

Great thank you. Is there not some kind of acceleration structure you could use for a landscape, like a quad tree perhaps or nested grids, where you only need to check if certain sparse pixels are connected together (paths between them?), and then go into closer detail when you need to really make sure? So you don't have to scan the entire area? Or maybe keep some kind of cache of the results of the very first scan, and re-use that data so that you only have to modify small parts of it?

 

No, there's nothing elaborate like that. In my testing the code required to find the collider edges isn't an issue, setting the point list in the collider components is usually much more significant, but it's unavoidable if I want to keep compatibility with 99% of Unity projects.

 

So for a larger landscape, perhaps it'd help if the landscape were composed of several smaller chunks of land, like a grid... say if you had a large scrolling level 4x2 screens or something, make it out of perhaps 512x512 textures... if you could make it so that it `behaves` as if it were one huge texture, that would be great ... maybe you do that already? But I'm getting the impression that say if I have say 2 textures next to each other - two separate sprites/objects - and then I do an explosion whose shape would produce a `new separate object` which should be composed from parts of one texture and parts of another... it's not going to be able to do that? I need to be able to do this where the destruction spans multiple textures and where, when objects are broken off from it and become independent, it's not only efficient but also then that broken-off part moves as `one object`. Can it do that now, or would this require some extra programming/new feature?

 

This isn't supported. The main issue with supporting this is that it means I need to create a new sprite texture from the surrounding sprites, which may be of different scales, texture formats, etc, it also means that the destructible sprite component needs to store sprite data (e.g. so it can be stored in a prefab), which increases the complexity a lot.

 

Feature request?

You wouldn't have to disturb the normal breakable system, just add a new component type for handling large landscapes, like a landscape manager. It just sort of needs to be a `higher level` thing which wraps around the destructible sprites, so that e.g. it creates possibly multiple sprites from multiple textures but just keeps them all as child objects of a single gameobject, so that they move together?

 

If there's more demand for such a feature then sure, but I don't imagine many games need something so specific, and it would take a lot of time to implement.

 

hi,
Is it possible to slice the colliding (or not colliding ) parts of an object with another object?
For example,when hitting play ,an rigidbody start to falling down and hit nother object and Not touching parts will be sliced (remove)

Thanks

 

I'm not sure I fully understand your question. Could you make a simple image showing the before and after of what you want to happen?

 

Sorry for my poor English.I attached an image.

thkank you

 

Thanks! There's no automatic way to do this in Destructible 2D, because calculating that kind of split is very difficult for all shapes of colliders.

However, if your game is based on falling bricks like this, then it would be very easy to do with a little bit of code. Here's the process you would want:

1 - Detect a collision between the grey block (A) and the red block (B)
2 - Slice block (B) using two rays coming from the sides of block (A)
3 - Block (B) should now be sliced exactly as you expect