Shatter Toolkit

Hello, thanks very much for uploading it

I have seen this and looks great, BUT there is some things that I do not like much and I wonder why:

1 - Sometimes the broken parts are too big

2 - The broken parts does not fall down when you hit with a ball, they are kept in place, and must hit sometimes 2 or 3 times until it falls down

3 - The broken parts just ONLY fall down from the wall, there is NO impact effect, the shatter does not give a effect like a broken part

May this be because the balls does not have enough force or enough speed?

Thanks for any possible answer to know why this is happening

 

The toolkit splits the game object using infinite planes, so if a game object is large, the pieces around the impact will also be large. For a wall in a game, I would probably pre-split a long wall into several game objects so that the extent along each XYZ axis is roughly the same.

The toolkit only splits the game object into pieces, if you want the pieces to be pushed away as well you'll have to apply an explosion force after the shatter occurs. When the ball hits the wall, the physics engine stops the ball and registers the collision which subsequently triggers the shatter. This is why only the next ball knocks the piece away. Maybe I should add a helper script for this, to make it easy. Also, if you lower the friction of the wall, the pieces will fall down more easily.

The second problem is easy to fix while the first problem is a lot more troublesome. Only cutting in infinite planes is a fundamental shortcoming of the toolkit but also one of the reasons I've been able to optimize it a lot. That said, I'm planning a big update to the toolkit (v2) that will hopefully solve this shortcoming

 

Yeah it would be nice to have more chunky pieces as opposed to angular bits!

 

I agree. If all goes according the plan, this will be improved in version 2

Version 1.61 is now released on the asset store. Let me know if you run into any other problems!

 

Oh that reminds me. We have an open world game and so these things need to restore after certain amount of time and when they're not in view, so I think its worth keeping the original mesh around. Could you add this functionality? Also a competing product to yours allows to define a plane which prevents shattering below or above the plane, which is really useful indeed. Wondered if that's a cool addition for 2?

 

Just noticed this in the Level 11 assets. The walls example scene reminded me a lot of Rayfire for 3ds Max.

But I also think more chunky bits would be preferable. I only ever used Voronoi destruction in Rayfire because it looks so good. I would love to see something similar in this asset.

Another thing that would be neat is a sphere of influence for the shattering. So instead of a cut going through the entire wall you're only shattering within the radius of the sphere. That way if you set it to only allow 1 cut depth per object it will only count inside the sphere of influence. The rest of the object would still count as the original object.

That way you can shoot a wall like this (3:45):

From the demo I got the feeling that you could end up with a huge chunk of the wall you couldn't shatter anymore. With a system like this you could shatter the same wall as many times as you want.

I haven't actually bought the asset, but something like this would make me buy it in a heartbeat.

 

I think this is best solved with a custom script and prefabs. The script could instantiate a new prefab whenever the old one has been shattered and left alone for a certain amount of time.

I will add this to my list of suggestions. If we're only talking about "at what points may a shatter be triggered" it should be quite straightforward. To always keep a certain part of a mesh intact, no matter which splitting planes are used in a shatter, is a much more involved task.

If everything goes according to plan, I'll add voronoi splitting in version 2. I think I've figuered out a way to get chunkiness, dynamic splitting and performance at the same time. We'll see

Yes, you can end up with a very large chunk of the wall in the first split. However, you can manually set how many times a game object can be shattered, so if you prefer good looks to performance, you can increase this number. Or you can just manually divide the wall into smaller modular pieces that each can be shattered using the toolkit.

Thanks for the interest in the toolkit!

 

I see, yeah. hmm. I think I'd rather hide the original and instantiate and pass the instantiated mesh to your system, leaving the original and it's particulars intact. I think that would be better than me keeping a copy of 20,000 meshes, all unique in this open world title, it's a problem waiting to happen I think. Any suggestions where in your code I would do so? I'm happy to wait til 2.0 comes out before making changes, obviously

Alternatively I'll have a look at wrapping your system somehow (I think it's pretty tough if not impossible keeping track of this many meshes so I'll have to instantiate the mesh + collider at impact time).

 

You could write a custom script that listens to the "PreSplit(Plane[] planes)" message that the ShatterTool emits before shattering (if the "Pre Split msg" checkbox is checked on the ShatterTool component). See the HiearchyHandler.cs helper script for an example on how to do this.

Then, when the message is triggered, you could save a copy of the original mesh somewhere else (in for example another game object that it instantiates) and remove the custom script component (so that it is not carried over to the shattered pieces of the game object).

I would name the first script that listens to the PreSplit message something like "SaveBackupOnShatter" and the script where it is saved (and that later handles the instantiation of the original game object) something like "OriginalBackup".

 

Sweet. So whats the ETA for 2? Hurry up would you, you're responsible for that AAA feel in my game

 

Hehe

I can probably start working on it at the end of June and, if everything works out, it should be ready at some point during the summer.

 

Hello, I just bought your product. And I can not understand how to use a shot in the UFPS, could you tell?

 

I have looked at the 2 online demos and this asset looks great, well done! I am wondering though how explosion destruction would exactly work using this asset. The demos show click destruction and collision based destruction, but how about radius based explosions? Eg. if a grenade is thrown or rocket fired at an object how will the destruction deal with the damage fall off to the object based on the explosion radius? Also is there a setting for the speed/force at which the split parts would fling apart? Since for example if an explosion destroyed an entire group of objects you would not only want them to shatter but to fly apart based on the explosion force. One final question, does this also work for terrain assets such as trees?

 

I haven't used UFPS so I'm not sure what the correct way to implement this is, but judging from the UFPS manual it seems like the workflow should be similar to creating a pullet prefab from scratch.

You could follow that guide, but instead of adding a mesh for the projectile prefab, you could attach a custom script that shatters any closeby game objects. Something like this (untested):

Code (CSharp):

1. ...
2. public float radius = 0.1f;
3.  
4. public void Start()
5. {
6.   Collider[] hitColliders = Physics.OverlapSphere(transform.position, radius);
7.   foreach (Collider c in hitColliders)
8.   {
9.     c.SendMessage("Shatter", transform.position, SendMessageOptions.DontRequireReceiver);
10.   }
11. }
12. ...
13.  

Thanks for buying the toolkit! Just let me know if you run into any problems

 

Thanks

No, the toolkit only handles the actual geometry splitting and object instantiation, but it should be easy to add an explosion script in a custom script. Simply send a "Shatter(Vector3 location)" message to any game object with a ShatterTool component (See the MouseShatter example script), and then apply an explosion force to any rigidbody within a radius from the "location" point (For example using Rigidbody.AddExplosionForce()). I'll consider adding a helper script and/or example of this in the next version of the toolkit.

I'm not sure actually, I haven't tried. I can make a quick test tomorrow.

Hope this helps!

 

Thanks for your response. Yes please add an example script as I think that explosions would be a common feature that users of this asset would need. I look forward to discussing your results for the terrain trees as I'm not quite sure how this would work.

Also, I wanted to ask a little about performance of this system. When I tried the demos of systems such as Fracture Pro and Fracturing & Destruction the framerate on my system really took a hit after a few explosions. However when trying out the demos for the Shatter Toolkit even after throwing close to 100 balls in the wall demo the framerate was still fine and I couldn't see any performance hit. Does the Shatter Toolkit use some sort of pooling system for the fragments or how is the performance so good?

 

I am a bit biased so I will not comment on the performance of other solutions

The main difference it seems though, is that the Shatter Toolkit uses a much more lightweight/simple splitting technique, and that it is heavily optimised for this particular task. It's a balance between quality and performance and I suspect that the Shatter Toolkit is more towards the performance spectrum. That said, if you think it looks comparably good, I think I've succeeded.

However, as I wrote before, I plan to add Voronoi shattering in version 2 and this should hopefully make the Shatter Toolkit the best of both worlds

Nope, there is absolutely no pre-computation or pooling. There are a number of factors involved here:

1. The actual splitting is extremely optimised.
2. Very small pieces are removed early on in the process.
3. There is a limit to how many times a piece can be shattered. As triangle count increases very fast, it is important to limit the "depth" of the process. You can manually set this value by changing the "Generation Limit" property of the Shatter Tool component.
4. I try to keep the complexity of the objects to be shattered in the example scenes fairly low. The vase is the most advanced model in there and even though it is not just a two-sided model, the triangle count is still low.

Thanks for the interest in the toolkit!

 

I did a quick test and I would say that it works, but isn't ready for production. The biggest problem is that the tree is just a single object, leaves and all. It works fine when I only have a trunk and some branches (see image below), but when I add leaves, only the leaf material will be carried over and the whole tree will be green, since the toolkit only supports one material per object. This limitation should be fixed in version 2 of the toolkit.

Another problem with the tree being just one object is that there is no good collider to choose for it. In my test, I made the original tree have a non-convex mesh collider and a kinematic rigidbody. When it was shattered for the first time, the piece closest to the ground was left kinematic while the other pieces were activated (non-kinematic and convex collider). This worked ok.

 

Thanks for trying that out. Perhaps an alternative could be to instead of slicing the actual terrain tree itself, to destroy the terrain tree and instantiate a replacement tree (which doesn't have material issues) which could also get sliced if need be straight after. I found an interesting post with a demo here: http://forum.unity3d.com/threads/destroyable-trees.28855/

Also I have noticed that in the table demo the legs of the table get shattered separately from the table top. Is there some sort of parent hierarchy to this, how does it work exactly? I am wondering whether it is possible to shatter objects that are attached to other non-shatter objects. For example lets say I have a lamppost that can be shattered which is attached to the ground. If a collision occurs with the lamppost the top half could snap of, but the remaining lower half would not move and continue being attached to the ground. Would this be possible?

 

Yes, the table legs are attached as children. The HierarchyHandler helper script handles the detaching and attaching of the game objects when it is shattered.

This should be possible. I did a similar thing when I tried shattering the tree in the post above. You can do it by writing a custom script (look at the HierarchyHandler for an example) that subscribes to the PreSplit and/or PostSplit messages of the ShatterTool. On PostSplit, add a rigidbody to all pieces of the lamppost except the one closest to the ground.

 

By the way, the Level 11 sale ends tomorrow guys!! If you have been thinking about buying the toolkit, now is the time

 

Ok I will have a look at those scripts and let you know if I have any questions

 

Hello,
I bought your Asset yesterday, and I like it.
I already bought 3 destructions Assets : DestroyIt, Ultimate Destruction and Exploder.

Your asset is very simple, and works great on Mobile.

I have only a performance problem when I destroy a Wall 100 times, one of your script consumme a lot.
Before to start to optimize your script, what do have in your todo list?

I made a apk for Android User :http://deathanddust.com/apk/Shatter.apk

 

Thanks for the feedback, I'm glad you like it!

Right now, my todo list looks something like this:

• Implement first draft of version 2
  • New features (don't want to specify which until I know how feasible they are)
  • Equal or better performance (hopefully better!)
• Handle read/write=false meshes and static objects gracefully
  
• Helper scripts
  • Improve mouse cut (continuous cutting)
    
  • Incorporate HierarchyHandler into ShatterTool
  • Explosion helper script
  • Sword helper script
• Improve docs
• Make "too thin"-threshold customizeable
• "No-shatter" areas of game objects
• 3d texture mapping?
• Support for 2d physics?

 

From the looks of the demo scene, each mesh is completely enclosed, and does not intersect another mesh. What would happen if a destructible mesh started the scene intersecting a non-destructible mesh? Would it be possible to simply freeze the pieces that intersect a static mesh, or perhaps make them ignore static meshes?

 

The toolkit does not handle this automatically, but it should be easy to create the desired behavior using a custom script.

If the object only has a ShatterTool component, nothing will happen if it intersects a static game object at startup (other than that it will be pushed out if it has a rigidbody component). If it also has a ShatterOnCollision it might get shattered as startup (depending on the trigger impact velocity set), and the pieces that still intersect will be shattered recursively or only be pushed out if the Generation limit has been reached.

 

Thanks for the asset!

I had to modify it to support multiple materials and added final hull optimization, but anyway it saved me huge amount of time.

I use convex meshes only, so it was pretty easy to add the optimization stage. Even if it takes an extra millisecond, it makes further operations on the mesh much faster.

Spoiler: images

 

Thanks, I'm glad that you find the toolkit useful!

The next update (which I'm about to start working on) will drastically reduce triangle count and it will work for any mesh (convex or not) while hopefully performing better than the current algorithm, so stay tuned

 

In my project I split objects pretty often and there may be many of them. Theoretically, what do you think about using hulls based on polygons instead of triangles?

The cube from my previous post would look like this:

Spoiler: Image

26 polygons vs 92 triangles

My guess is that polygon-based hulls
1. would consume a bit less memory,
2. would be faster to slice,
3. would be easier (and faster?) to optimize after slicing. In case of convex hulls they wouldn't require any optimization. In case of non-convex hulls I'm not sure.

 

Yes, this is exactly what I'm planning for version 2. It should improve performance and triangle count when splitting an object multiple times (which is almost exclusively the case). I'm working on it

 

Has there been any progress on version 2?

I'm asking because I bought this and in it's current form it's a bit more limited than I had hoped. So I'm wondering if I should dive into it myself and try to implement some features or wait for version 2. The code looks clean and understandable.

There's 2 features I would really like to see:

- Voronoi splitting or something similarly "chunky".
- The ability to "dig" through objects. Not sure if that's outside the scope of this asset, but I imagine something like mesh substraction. Imagine you have a wall and when you hit it with a projectile you subtract a sphere from the wall. When you hit it again you subtract another sphere. Just like Worms, but in 3D in other words. This could also be combined with splitting the subtracted mesh to create debris from the explosion. The biggest issue with this would be handling the colliders. There would have to be multiple colliders per mesh because you could have a spherical hole in a cube.

The biggest issue with the current splitting is that you can get some extremely tiny and buggy pieces with a geometry limit of anything higher than 2. To circumvent this somewhat I'm modelling my geometry as sizable chunks and only using a geometry limit of 2 so I have some controls of the size of the resulting pieces after splitting.

Edit: Make that 3 features, but this one I feel like I can implement myself fairly easily.

- With the current split method you would think it was perfect for a glass type shatter, but the rotation of the planes seem to be random. There should be an option to make all the planes have the same angle. This would be perfect for thin walls, glass etc.

Something like this I guess:

Code (csharp):

1. public void ShatterAlongVector(Vector3 point, Vector3 direction) {
2.     if (!IsLastGeneration) {
3.         // Increase generation
4.         generation++;
5.  
6.         // Split the hull using randomly generated planes passing through the point
7.         Plane[] planes = new Plane[cuts];
8.  
9.         for (int i = 0; i < planes.Length; i++) {
10.             Quaternion rotation = Quaternion.AngleAxis(Random.Range(0f, 360f), direction);
11.             Vector3 rotatedVector = rotation * Vector3.right;
12.             planes[i] = new Plane(rotatedVector, point);
13.         }
14.  
15.         Split(planes);
16.     }
17. }

That only works if the object is not rotated because I just realized I'm completely clueless when it comes to vectors. Took me an hour to manage this and I'm not even sure what I'm doing or what to call the function. The only thing I know is that it's surely wrong.

The idea is that all the cut planes are perpendicular(?) (again no clue what the terminology is) to the normal of the surface to shatter so it shatters like a glass window or similar.

Edit2: If you have a gameobject with a ShatterTool component as a child of another gameobject then the shatter pieces will spawn at the world space position equal to the local space position of the child. So if you have a parent with a child at local position x,y,z = 0,0,0 (which is fairly common I feel) the shatter pieces will always spawn at the world origin. This seems like a pretty major oversight. But it's probably easy to fix?

 

I'm sorry, but I'm a bit conflicted about this asset. On one hand the code is very easy to understand and extend on my own, and it's not very much of it, but on the other hand I can't imagine a lot of people are able to use this asset in their projects in it's current state. It's somewhat limited and there's some bugs and oversights in there. I would really appreciate it if you're still working on it.

To fix the apparent glaring oversight of not spawning the shattered pieces in the correct position all I had to do was change line 361 in ShatterTool.cs from this:

Code (csharp):

1. GameObject newGameObject = (GameObject)Instantiate(gameObject);

to this:

Code (csharp):

1. GameObject newGameObject = (GameObject)Instantiate(gameObject, transform.position, transform.rotation);

Without this change there's no way of having prefabs where the objects to shatter are child objects of the prefab.

Also here's my final code for the "pizza slice" cutting (Thanks to greg harding on these forums):

Code (csharp):

1. public void ShatterAlongSurfaceNormal(Vector3 point, Vector3 normal) {
2.     if (!IsLastGeneration) {
3.         // Increase generation
4.         generation++;
5.  
6.         // Split the hull using randomly generated planes passing through the point
7.         Plane[] planes = new Plane[cuts];
8.  
9.         for (int i = 0; i < planes.Length; i++) {
10.             // Generate a tangent to the surface normal.
11.             Vector3 tangent = Vector3.Cross(normal, Vector3.up);
12.             if (tangent.sqrMagnitude <= float.Epsilon) tangent = Vector3.Cross(normal, Vector3.forward);
13.             tangent.Normalize();
14.  
15.             // Rotate the tangent randomly across the surface.
16.             Quaternion rotation = Quaternion.AngleAxis(Random.Range(0f, 360f), normal);
17.             Vector3 randomTangentVector = rotation * tangent;
18.  
19.             planes[i] = new Plane(randomTangentVector, point);
20.         }
21.  
22.         Split(planes);
23.     }
24. }

It makes sure all the cuts are parallel to the surface you're cutting so you get perfect "slices". Great for windows etc. It would be awesome to be able to cut in circles around the initial point as well to get more of a web look which would be more realistic, but that's surely a lot more involved. Especially considering everything in this asset is centered around infinite planes at the moment.

 

Sorry for the late reply!

Unfortunately not yet. I'm still finishing my current ocean rendering project (it took longer than expected to finish) but I will start working on version 2 of the Shatter Toolkit as soon as possible once this is complete.

This is the number one feature I have planned.

As you say, I think this is outside the scope of the project.

Yes. I hope that voronoi splitting and moving from triangles to general polygons (should greatly reduce the triangle count after several splits) should improve the performance and quality considerably.

This is why I exposed the Split() method, so that custom splitting functions could be implemented. My reasoning for not including more "default" splitting types is just because I think it's difficult to decide what is general enough for all games and what is more focused on a specific use case. I will think about generalising this for version 2 as well.

Thanks for noticing this, I will look into it for version 2 as well! When I last looked at parent-child hierarchies I had to de-couple the children from the parent before the split (this is what the HiearchyHandler.cs does) in order to not end up with duplicates of the whole hierarchy. When the hierarchy is de-coupled (and later re-assembled), all shattered game objects are top-most nodes and the problem you describe does not occur. Unity might have changed how duplication of game objects is handled in recent versions and I have to double check this, and that I haven't misunderstood something.

I'm definitely committed to completing version 2, and I really want to start working on it asap. This will be a free update to the existing toolkit, not a seperate "pro" version or anything.

Awesome! Thanks for sharing!

 

Sounds great.

I realize I was a bit harsh in my previous posts as it felt like everything I tried to do with this asset failed or caused errors, but I guess it was just the child position problem and me trying to use it on some less than ideal meshes.

I'm having a lot of fun with it, but I'm not sure how viable dynamic destruction is in an actual game though. It seems to cause some major hitching and a lot of garbage when you destroy multiple objects at once. Do you have any plans or ideas on how to optimize it?

 

No problem, I totally understand the frustration. Just to be clear, was the parent-child problem something on your end (regarding less than ideal meshes), or is it still a problem with the toolkit in your opinion? I really want to start working on the update asap, I have so many things to improve

Yea, version 2 should be a lot faster! I might also look into moving the splitting to a seperate thread to avoid the hitching that occurs when too much is happening at the same time.

 

The current splitting can produce very thin pieces if 2 cutting planes are very close together. And in some cases the resulting piece which should have spawned between the 2 cutting planes seem to be removed rather than instantiated. I don't know why this happens or if it's a problem with this asset or Unity. Perhaps the resulting piece is thinner than Unity can handle or allow? Not a huge issue, but it can be noticeable when it happens. I try to stick to meshes that are more square or cubical in shape to get better looking pieces.

I'm pretty sure the child problem is a problem with the asset and not something I'm doing. I had a wall gameobject with the shattertool script on it. Then I put a lot of these walls as children of another gameobject to group them in the hierarchy. This parent gameobject was at 0,0,0 and everything worked well. Then I duplicated that parent gameobject and moved it to a new position, i.e. not 0,0,0. When I destroyed the walls under this new parent the destruction didn't work at all and I couldn't understand why until I saw that the pieces were instantiated at 0,0,0.

At least that's how I think I initially discovered the issue. But my fix described above seems to work perfectly with no drawbacks, at least as far as I can tell. Having a more complex prefab with multiple shattertool gameobjects as children and placing that prefab in a position that's not 0,0,0 caused the same problem I think.

 

Hello all.

I was wondering, what are the performances on mobile, for a simple lowpoly scene? Could you (or someone) provide a demo with an FPS counter for android? The link provided by Menfou for his android demo is dead.

I already bought 3 "fracturing" assets from the store, and either the performances are terribles, or it doesn't do exactly what I need, so this time I'm trying to be sure before buying.

How is it going for the new version you're working on?

Thanks

 

Hello,

I upload a simple scene with ShatterToolkit, available here :
http://deathanddust.com/apk/ShatterToolKit.apk

If you want a specific scene, let me know.

 

You actually delivered Thanks a lot Menfou, the apk is perfect!

And indeed, it seems to run very well on mobile, I don't even see any FPS drop with the slicing tool. Very well, I guess that's a must buy for me then.

 

The toolkit removes pieces that are too small or too small relative to the other pieces being generated. To change the behavior, open the FastHull.cs file in the Core/Library/Hull folder of the Shatter Toolkit and tweak the values at line 10 and 11. These values are in the local-space of the model.

Code (csharp):

1. protected static float smallestValidLength = ...;
2. protected static float smallestValidRatio = ...;

The plan is to make these values user-definable in the next version.

Cool, thanks for taking the time!

 

Is there anyway to keep the material on sub meshes when the mesh is shattered?
Right now when the mesh shatters, all the sub meshes become the same material

 

No, unfortunately not. This is a feature I have at the top of my todo-list for version 2.

At the moment, you can only use one material per mesh renderer component and you have to manually split any mesh containing submeshes into separate game objects (with one material each) if you need multiple materials.

 

Hi everyone! I just wanted to give you an update on what's going on with the Shatter Toolkit.

Basically, I want to start working on version 2 as soon as possible, but I have a bit too much on my plate at the moment. I'm attending my last year at university and the plan is to do my master thesis this spring. During this period I will hopefully be able to work, albeit slowly, on the update during my free time. I will be too busy to get any work done in november and december I'm afraid. I would love to be able to work on the toolkits and do freelance work for a living but I want to finish university first. Also, the income from the toolkits cover only a very small part of my expenses so I can't take a pause from studying. Kind of a chicken and egg problem

I will post more frequent updates here when I start working on the update, so keep an eye out. In the meantime I hope that the current version works well enough for your needs!

 

In my project I've switched completely from triangles and indices to polygons and no indices.

The slicing algorithm implementation became very simple (all my hulls are convex): 100 lines of code for slicing a single polygon, 30 lines for slicing a hull, 40 lines for filling the holes and a couple of simple helper functions that I had anyway.

The output geometry no longer requires extra optimization. Here is a square box after 21 slices:

 

This works really nice, but my big beef with this asset is that the pieces are all cloned copies of the parent. Is there a way to make the pieces be a completely different gameobject? I'd like the pieces to be non-interactive physics objects which eventually disappear--but instead they are just copies of the parent object with a different mesh.

 

Duh---just figured out how to do this. Didn't expect the code documentation to be so nice. Was able to use the Generation member to turn off collision and other scripts on my fragments. This is an EXCELLENT asset.

 

Thank you! I will improve the docs for version 2, it shouldn't be necessary to go into the code to figure that out

 

Hi again,

Just a heads-up, the Shatter Toolkit will be 40% off on Mars 4th!

Also, I've added a roadmap page to my website where you can see what I'm currently working on and what's up next, if you're interested: http://gustavolsson.com/roadmap/.

 

I bought this a while back and am excited to use it in my current project.

What I need to do is have a light shatter and fall to the ground (without being hit or otherwise interacted with by the player). So it needs to be hanging there, shatter and then fall.

I've tried having the ShatterTool script on the object along with a separate line with

Code (csharp):

1. GetComponent<ShatterTool>().Shatter(transform.position);

but alas no dice. Could I get some guidance on how best to do this?

 

Do you get any errors in the console? Also, make sure you have attached a UvMapper and ColorMapper to the same object.

If the light is stationary before the shatter, you need to add a rigidbody component to it or make an existing rigidbody component non-kinematic before calling the Shatter() method. That is the easiest way to do it at least.

Code (csharp):

1. gameObject.AddComponent<Rigidbody>();
2. gameObject.GetComponent<ShatterTool>().Shatter(transform.position);

Please let me know if this solves your problem. Thank you for using the toolkit!