Exploder [RELEASED]

Hi,

so did you want to use mesh colliders at the first place? Or you want to use both box and mesh colliders afterwards?
Currently the fragment pool supports only one type of colliders, if you change it it will re-allocate all fragments.

 

Okay, I got some more example scenes and models with the same issue from other customers, I'll take a look.

 

Hi,

I ran the debugger (with mono) because unity freezes on exploding my mesh (i need to kill it via task manager) and found out there is a infinite loop calling crack and explode forever. here is a short stacktrace:

Exploder.CrackedObject.Explode () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackedObject.cs:40
Exploder.CrackManager.ExplodeAll () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackManager.cs:51
Exploder.Core.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\Core.cs:106
Exploder.ExploderObject.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:495
Exploder.ExploderObject.ExplodeCracked (callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:505
ShipHealth.explodeAfterCrack () in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:560
ShipHealth.OnCracked (time=0, state=Exploder.ExploderObject+ExplosionState.ExplosionStarted) in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:554
Exploder.CrackedObject.Explode () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackedObject.cs:40
Exploder.CrackManager.ExplodeAll () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackManager.cs:51
Exploder.Core.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\Core.cs:106
Exploder.ExploderObject.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:495
Exploder.ExploderObject.ExplodeCracked (callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:505
ShipHealth.explodeAfterCrack () in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:560
ShipHealth.OnCracked (time=0, state=Exploder.ExploderObject+ExplosionState.ExplosionStarted) in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:554
Exploder.CrackedObject.Explode () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackedObject.cs:40
Exploder.CrackManager.ExplodeAll () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackManager.cs:51
Exploder.Core.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\Core.cs:106
Exploder.ExploderObject.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:495
Exploder.ExploderObject.ExplodeCracked (callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:505
ShipHealth.explodeAfterCrack () in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:560
ShipHealth.OnCracked (time=0, state=Exploder.ExploderObject+ExplosionState.ExplosionStarted) in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:554
Exploder.CrackedObject.Explode () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackedObject.cs:40
Exploder.CrackManager.ExplodeAll () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackManager.cs:51
Exploder.Core.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\Core.cs:106
Exploder.ExploderObject.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:495
Exploder.ExploderObject.ExplodeCracked (callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:505
ShipHealth.explodeAfterCrack () in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:560
ShipHealth.OnCracked (time=0, state=Exploder.ExploderObject+ExplosionState.ExplosionStarted) in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:554
Exploder.CrackedObject.Explode () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackedObject.cs:40
Exploder.CrackManager.ExplodeAll () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackManager.cs:51
Exploder.Core.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\Core.cs:106
Exploder.ExploderObject.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:495
Exploder.ExploderObject.ExplodeCracked (callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:505
ShipHealth.explodeAfterCrack () in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:560
ShipHealth.OnCracked (time=0, state=Exploder.ExploderObject+ExplosionState.ExplosionStarted) in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:554
Exploder.CrackedObject.Explode () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackedObject.cs:40
Exploder.CrackManager.ExplodeAll () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\CrackManager.cs:51
Exploder.Core.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\Core.cs:106
Exploder.ExploderObject.ExplodeCracked (obj=(null), callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:495
Exploder.ExploderObject.ExplodeCracked (callback={Exploder.ExploderObject.OnExplosion}) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\ExploderObject.cs:505
ShipHealth.explodeAfterCrack () in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:560
ShipHealth.OnCracked (time=163, state=Exploder.ExploderObject+ExplosionState.ObjectCracked) in C:\Workspace\Spacegame\Assets\Scripts\Shipparts\ShipHealth.cs:554
Exploder.ExploderQueue.OnExplosionFinished (id=-237853563, ellapsedMS=163) in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\ExploderQueue.cs:157
Exploder.Core.Update () in C:\Workspace\Spacegame\Assets\Exploder\Exploder\Core\Core.cs:163

I am able to successfully explode cubes etc in my scene. But my spaceships will kill Unity I updated today to the current version - it was working quite well before, but I also changed some code....

Kind regards!

 

Ok I found my issue. onCracked is called twice - first after oncracked finished - second onexplosion finished. this produced an infinite loop, I fixed my code with:

private void OnCracked(float time, ExploderObject.ExplosionState state)
{
Debug.Log("Cracked in: " + time + " " + state);
if(state == ExploderObject.ExplosionState.ObjectCracked){
explodeAfterCrack();
}

}


Nevertheless, I see a new issue: In case my exploding Mesh has children (not tested if they have to be meshes also) then the Exploder is not working (I see no fragments). If I delete all objects below the exploding one - it works again

Edit: It happens with an asset from the store (Automatic LOD). I now use Simplygon for LOD stuff and the built-in LOD system - I have no problems now!

kind regards!

 

Hi! Just bought an asset and already integrated it in to the demo! Fantastic!

Just one thing I can't achieve: I need to modify fade-out behavior in the way that pieces Start to scale-out After specified time expires and scale-out in a short specified duration.

Please, direct me to where should I modify a source to achieve that?

 

Hi,

I see an issue here. Cutting the meshes (even the simplest one like unity 3D sphere) with the Exploder Option Script attached seems a bit erroneous. Sometimes it produces fragments with inner "structure" and sometimes just 2d planes. Most of the time both things together. I have a small example project where you can reproduce it - please tell me how I can send it to you!



Kind regards, Tino

 

Many many moons ago I asked if Exploder could be made pooling-compatible. Which here means that I pull a GameObject/mesh from a pool, explode it with Exploder and then return it to the pool in it's original un-exploded form, to be used again. Any plans on this?

How do users of Exploder currently handle this? Do you all just accept memory allocations and slight hickups in gameplay?

 

I use Exploder with pooling my enemies with CoreGameKit and don't destroy the original mesh, and then reenable the mesh when I spawn it again. I fracture it right away again and the performance is pretty good.

 

I do the same thing! Performance is good! I use PoolManager from asset store and I am happy with it: https://www.assetstore.unity3d.com/en/#!/content/1010

 

Is it possible to add different fragment shapes & if so to randomize fragment sizing ?

 

Hi! I have a model that is fractured with invisible insides (while other similar models from the same pack are fractured normally) Tried every option there with no luck. What should I do next?

 

No response since Dec 30...
Thats no good.

 

The more I use it the more it disappoints... Like for example... Generated meshes are not destroyed! they stay in memory and constantly leak leak leak...

Profiling your asset eh?

It took 2 lines of code to fix but 3 hours to figure out and half an hour to find a right place.

For those who use it, here is my fix - in fragment.cs on update when fragment is to deactivate call DestroyImmediate with allowDestroyAsset flag on sharedmesh

 

!!!

And if dontUseTag is set to true it keeps adding multiple copies of Explodeable component to each freaking fragment every time it is spawned. Allocating 320B on MonoBehaviour every explosion for each fragment. Its easy to calculate how it takes over a heap overtime..

It is not hard to fix, but here goes another 4 hours of profiling...

 

Hi,

my apologies for not answering back as I couldn't work on Exploder recently. I greatly appreciate your time you spent founding these bugs. I have incorporated the fixes into today's update, you can download the latest version 1.6.3 in few hours.

To answer your questions:

1) The fade-out code is in the Fragment.cs in Update method as you have probably found, you can add extra timeouts to start/end the fade-out process.

2) The fragments with invisible sides could happen with meshes that are not properly closed. The model is cut successfully but the routine for finding contours failed and wasn't triangulated. You can send me the mesh model and I can look if that's the problem or something else.

Best,
RG

 

Hi, I tried the same ExploderOption script but I can't reproduce it, best if you can PM me link with drop box or other way so I can download your mini test project with the issue.

 

Hi,

currently the mesh is cut by randomized plane, a very simple algorithm but looks more realistic. I could use something more sophisticated, for example make fragments more rectangular. But I think it would be better if you can give me some examples.

 

Hi! Glad to see you appear. Nice fixes, thats appreciated)

 

Hi , Got one question about how the mesh is being cut.
Is it possible to specify the angle of the cuts?
For example i would like to make my mesh explode into lets say minecraft blocks ( 90° angle cuts)

 

Hi,

similar question has been asked by @Banksy. I think rectangular cuts (90 degrees) makes sense, I will do some experiments with angles and post screenshots here.

 

I was trying to use both. I think there should be a warning that this isn't supported when you try to do it, or it gives the behavior I described.

 

I will add the warning. Thanks for the feedback.

 

Hi,

I have uploaded new version 1.6.4 with rectangular cutting option, you can find it under "Cutting plane angle" parameter.
By default it is set to "Random" which is the same as current version.

Example screenshot of exploding simple cube:

 

Amazing work, this is just what i needed <3

Edit:Have you uploaded 1.6.4 to unity store or is it uploaded somewhere else as a beta version,because it still says 1.6.3 on unity store

 

Usually it takes several hours for an update to appear on Asset Store. Just wait a bit and check later.

 

Ok ,thanks . Didn't know about that.

 

Works perfectly , just as i wanted it to be .Thank you very much.
But have an issue when the object is being destroyed.Sometimes it doesn't cut/explode the object.Everything works fine but it only creates one fragment.

 

Is it happening with the new object or one of the fragments?

 

Hi, if I am on earlier version, much earlier, what is the recommendation to upgrade, should I delete all exploder content and then install? Just curious/asking in case I run into any issues on another project of mine.

 

Hi,

if you have one of the earliest version, it will be probably better to delete exploder directory and import it again, because the code has been changed a lot over the years.

The API should be the same except instead of calling Explode(...) you have two choices:

ExplodeObject(gameObject, ...) - this will explode "gameObject" only
ExplodeRadius(radius, ...) - this will explode all objects in the radius, same functionality as Explode(...)

 

Hi, you might want to try the new version 1.6.5 (in a few hours). I added fallback for failed rectangular cuts. The rectangular cut was failing mostly on spherical-shaped meshes, it should be okay now.

Let me know if you have more problems.

 

Works fine

 

Hi,
Sorry to bother you again , but i don't understand the feature uniform distribution.
It says that "Exploder will create number of fragments per object equally regardless of object distance from the center" , yet when i enable it, it doesn't change a thing,mesh is being cut the same way even if its unchecked.
Now for the more confusing part is that , when i check disable triangulation (with uniform distribution checked aswell) exploder does what the uniform distribution says, but.. i get fragments with holes in it(open mehses) as presented in the attachment.

 

Hi, I will check it out, it could be a bug. But in general the uniform distribution is useful only for exploding objects in the radius - ExplodeRadius(...) method. But I think it's not explained anywhere.

 

Hi,

get version 1.6.6. The distribution is better now.

 

I must be misunderstanding the basics of how to use this asset. Looking at the examples included it looked like this should work. What am I missing? I'm using this section of code:

private ExploderObject exploder;

void start()
{
exploder = Utils.ExploderSingleton.ExploderInstance;
}

void OnTriggerEnter(Collider other)
{
if (other.tag == "Exploder") {
Debug.Log("Explode " + other.gameObject.name);
exploder.ExplodeObject(other.gameObject);
}
}

NullReferenceException: Object reference not set to an instance of an object
Exploder.Demo.RigidProjectile.OnTriggerEnter (UnityEngine.Collider other) (at Assets/Scripts/Projectiles/RigidProjectile.cs:43)

 

Hi, looks like you name your "start" method with lower case, it should be "Start()" and not "start()". Let me know if you have more problems.

 

Thanks, I stared at that typo for so long without noticing.

 

Meshes are still the same, polys are missing if "Disable triangulation" is checked.(Keep in mind that distribution is only working if triangulation and distribution is checked)
Addition to that, i am getting the same exploding pattern if there is lets say 5 same duplicated boxes
In attachment you can see the same pattern of exploding fragments on the same objects. Ive circled these 3 objects so its easier to see the difference which there is none.

 

Hi,

Disabled triangulation results into missing polys, that's expected behaviour, because no triangles will be generated after cut. This option is for users who don't care about missing polys, just to get some quick explosion effects. Also performance-wise it is by far the most fastest method.

But the distribution shouldn't be affected by disabled triangulation, that's something I will look at. And I think I can randomise the rectangular cuts to break the pattern. Thanks for the feedback.

 

Hi,

is it possible to somehow add my own script to all the fragmented gameobject parts?

 

Hi,

yes, it is possible, with the current version you just create an empty game object with your script attached and assign it as "Fragment Prefab" in the inspector.

By the way I am working on a new version that will handle this slightly differently, but I will post the description here as soon as it gets released.

 

Hey,

Any chance you can implement something like "Pre-calculate". It would be similar to crack but without allocating it's fragments. So basically only the calculations. It would help us to be able to calculate every explode on start and then just call it when it happens, since we are reusing a lot of items.

Thanks in advance.

 

It seems highly unlikely. As far as I understand it today, from a technical point those "calculations" would be not so much different from the fragments themselves. So there is almost no reason to have that extra step.

What would be possible and nice to have is pre-calculations/allocations on per object basis. Like if you have 10 enemies, you can once (or twice or more times to have some variety) calculate and allocate their fragments (maybe in editor or on scene load) and then just spawn from pool (or instantiate a copy) when that exact object is to be exploded. That defies a bit a very basis of "exploder" as it is meant to be exploding stuff from different points but gives mobile users a huge leg up.

Currently I'm seeing quite a spikes on mobile, even thou my models are true low poly (~500) and I tweaked exploder for days. Best optimisations currently performance wise are triangulation disabling, manually stopping physics when fragments are expected to settle down, and tweaking fragments count on distance from camera basis.

So there are two bottlenecks: physics and cracking. First is not too hard to overcome. Second is harder as it needs something different to be implemented in the exploder itself or using its components.

I would probably do physics emulation on distant objects later in the project.
And that pre-calculation thing from above, if author won't go for something of that sort himself.

 

Hi,

not sure if I understand you correctly but isn't the "Crack" feature you are looking for?

https://docs.google.com/document/d/...a9ZJvjwtl7bU/pub?embedded=true#h.ozdfi95wq4wq

 

Hi, thats not it. Crack function cracks each object individually and is bound by pool size. I want to crack object of a certain type once (or several times) and store cracked objects to instantiate or spawn from pool on explosion of that particular type of object.

Say I have 2 units - tanks and jeeps. I want to crack tank twice and jeep twice so I would have 4 * X fragments stored somewhere. Then I assume that I will have no more than 10 units of each type simultaneously in the scene what leads my to pool 20 * 4 * X fragments.

When tank is exploded I spawn object with pre-cracked fragments of a tank in to the scene and simulate explosion. When explosion is done, object is despawned and fragments get their initial transforms back. And again and again. No cracking during runtime.

If I assume that I would have a lot of units and memory is my limit then I might choose not to pool, but to have 4 * X fragments stored and clone them on explosions (this is speculated scenario, don't know if it will be efficient or needed)

In other words - I need to crack units not on object instance basis but on a "type" basis. Each "type" of unit gets his 1-N pre-craked objects to spawn into the scene when needed.

 

Okay, I understand. I think it's possible to do this by not allocating fragments on crack, keeping the new meshes only in memory and applying them in run time to available fragments. If done this way the number of cracks wouldn't be limited by pool size.

 

Hi! I'm struggling a bit understanding an answer. Can you please guide me a little bit on how it would be better/faster to implement? What classes should I modify and a general direction to how?

My current idea looks like this:

1. Modify fragment to store initial localTransform
2. Make an ExploderManager with an array of prefabs to crack.
3. Make manager to crack each prefab several times by instantiating it and exploding with Exploder either on scene start or in editor
4. Save N copies of a fragmented mesh
5. Ditch the Exploder at runtime and just call EploderManager.Spawn, ExploderManager.ApplyForces
6. On timeout despawn fragments and restore their local transforms

 

Hello! Completely new to this plugin, I so rarely use paid plugins (student, not much money) but this one is so amazing, I couldn't pass beside.
Little questions though:

Any way to set up the number of fragments for each exploding object separately.
And second question: I set my items to have explosion on collision, but sometimes the explosions just go way too fast and everything get reduced to molecules instantly. (my fragments are set to explode too, but I wasn't expecting they'd blow this well)
Is there a way to set it up so explosions can't happen too soon right after another?

Or is my script wrong?

using Exploder.Utils;
using UnityEngine;

namespace Exploder.Demo
{
public class Boom : MonoBehaviour {

//if collision with an item of the right tag at the right speed, goes boom
void OnCollisionEnter(Collision collision) {

if (collision.relativeVelocity.magnitude > 1 && collision.gameObject.tag != "Untagged") {

ExploderSingleton.ExploderInstance.ExplodeObject(this.gameObject);
}
}
}
}

thanks in advance, and thank you again for this amazing package! ^^

 

Hi,

your approach is basically an editor version of Exploder, generate prefabs, save them and use them in run-time when needed. I don't want to go this way since it's no longer a "real-time" explosion and there are other competitive assets on the store doing this.

I was thinking more like modifying the current crack flow:

1) call CrackObject and calculate fragment meshes as usual
2) don't assign the new meshes to fragments but keep them in memory (modifications in PostprocessCrack.cs)
3) call ExplodeCracked later, get the meshes from memory and assign them to available fragments from the pool

Then I can crack one object 1x on start and call ExplodeCracked as much as I want. This approach is probably a little bit less performant than your approach but it doesn't break the current flow.