Shatter Toolkit

UPDATE: The toolkit is now $80!

Shatter Toolkit on the Asset Store
Website
Webplayer Demo

So, I’m finally finished with my latest project! Here is the description from the asset store:

The Shatter Toolkit enables you to easily shatter or split any game object dynamically in real-time, whether you want to smash walls or slice fruits. The toolkit creates the necessary geometry, fills the holes and instantiates the new game objects for you.

One line of code shatters or splits a game object and no scripting is required if you use the bundled helper-scripts.

FEATURES

  • Split game objects by specifying an array of planes
  • Shatter game objects by specifying a point
    – Internally splits the game object in randomly generated planes passing through the point
  • Fills the holes (cut area) of the mesh after a split, if enabled
  • Tweakable uv mapping for the cut area
    – WorldUvMapper - repeats a texture a number of times per world-unit
    – TargetUvMapper - maps the cut area to a specific part of the texture
  • Includes an advanced triangulator, useful in many areas of game development

If you have any questions, please post them here! Thanks!

Slicing things apart is so satisfying. Good job :slight_smile: I guess I can ask the obligatory mobile question. Have you tested this on Android / iOS and if so, how is performance?

Thanks!

I have tried an old version on my android phone (LG P990) and it worked well. Since then I have optimized it so I hope it will run smoothly on higher-end phones. I’m planning to submit a demo scene as an app to the android market as soon as I’ve tested it, so developers can try it out on their preferred phones. Hopefully it will work nicely on lower-end phones too, though I suspect they’ll be limited to fruit ninja style games.

Works very nicely. What’s the price?

That is beautiful!

Couple of questions:

  1. Could the results be saved? Level designers for FPS games, for example, could use that feature.

  2. Can the meshes have normalmaps and shadows? Can it go from baked lightmaps to realtime shadows? Basically, what are the limitations in terms of the materials we can deploy and the look we can have?

  3. What is the performance hit, for these objects, before they are affected by the operations? I.E., if I build an office building for a FPS and used it as a feature of the walls, am I going to come to a screeching halt, performance-wise?

  4. How is cleanup of the objects handled? I.E., we’ve just done a cinematic of a huge building getting slice in half by the Annihilator Ray… the dust has settled, and gameplay has resumed. Now we want all of the resulting rubble to become a single static object, for performance’s sake; can that be done? If we’re having a shootout in that theoretical office building, how can we gracefully cull the smaller fragments after a few seconds, to recoup performance lost?

Anyhow, this is one of the best demos I’ve seen of this thus far, really great work :slight_smile:

Really nice work

I am very interested too. Does it work on iOS ?? (is what concerns me most)

Thanks everyone!

150$

  1. When a shatter occurs the pieces are instantiated as new game objects (clones of the original but with new meshes), so you could save those, but I have not tried it. If it is possible to instantiate new game objects while in edit-mode you may be able to call the shatter/split methods from an editor script made especially for artists. If there are requests for this I can look into it.

  2. The toolkit takes cares of vertices, normals, tangents and uvs (the main uv layer) so normal / bump / parallax maps should work nicely. Realtime shadows should work as usual (there is no difference between the pieces and the original game object, except the mesh and the shatter tool itself). Baked lightmaps may be difficult to implement since many of the surfaces on a shattered game object did not exist when the bake took place, so those would be unlit.

  3. UPDATE: I totally misread the question! My answer here covers the new meshes of shattered game objects. See the post further down below for a correct answer.

The toolit generates new geometry, so the vertex/triangle count will increase when shattering an object, how much totally depends on the original mesh and where it was shattered. There is however no “wasted” or duplicate vertices or triangles, it is as optimized as it can be in a real-time scenario (it does not try to simplify the geometry, which would be too performance heavy).

  1. All ShatterTool instances (the script used to shatter/split objects) have a Generation property which defaults to 1. When a game object is shattered all the pieces will receive a Generation value of the original +1. So the first time an object shatters it’s pieces will have a Generation value of 2. This enables you to for example write a script that examines the ShatterTool.Generation property and say if it is above 3, you could destroy the game object after a couple of seconds.

Check out the Readme for more information on how it works internally :slight_smile:

Thanks for the comments and questions!

I do not have the Unity iOS license so I can’t try it out just yet. I’ll begin testing the toolkit on android devices next week.

I am also interested this in comparison to Piecemaker.

I have not tried Piecemaker but my understanding is that it is designed to pre-compute the destruction and replace game objects during gameplay. Piecemaker seems to make it easy to customize the destruction beforehand, but seems to lack the benefit of shattering objects dynamically, exactly where they were hit by another object during gameplay for example.

The Shatter Toolkit is designed to do one thing fast, splitting meshes, and by splitting meshes multiple times in real-time during gameplay it simulates the shattering. It is not possible to customize the shattering (other than choosing the number of times to split an object) like in Piecemaker without writing scripts, but the game objects will shatter dynamically, where they were hit during gameplay.

I haven’t bought this package, because I currently can’t afford it, but this looks amazing, you’re going to make a lot of money of this. :wink:

If I understand everything correctly it should be extremely easy to make this work in the editor. Which is actually a good idea for, for instance, Iphone games.

Thanks! :slight_smile:

Yeah, I will look into creating a helper script for in-editor use.

Does the system work ok with two object (or more) that are intersecting each other (imagine a set up upright post going into the floors of a building)

this looks mint (but its not cheap (I’m a poor student) so I want to make sure it will do what I want before buying it

I could send you the FBX file if you want. I want to create a demolition ball (or ball you can throw) to demolish the building.

It will work as long as the geometry is closed, that is, every edge belongs to exactly two triangles. (If you want to fill the cut area, which is usually the case with solid meshes; otherwise there is no requirement on the mesh)

It sounds like you want to keep the upright post and the floors of the building in the same mesh and game object, and it should work, but I would recommend having separate game objects. This will let you shatter/split different parts of the building separately (the post could shatter while the floor stays intact) and you will be able to have different settings and uv mappers for the different parts of the building.

If you use rigidbodies and colliders the physics engine will push the objects apart but you could easily solve this by marking the post and floor as kinematic by default. Then, when shattering or splitting the post for example, you could make it non-kinematic. (Toggle the “Pre Split msg” checkbox on the ShatterTool to make it send a message before a split occurs, see the Readme for more information)

Thanks for the interest :slight_smile:

I totally misread this question the first time around :slight_smile: Here is the correct answer:

There is no performance hit at all. A game object’s ShatterTool instance only processes the mesh when a scene is first loaded and then does nothing until the game object is shattered/split.

Looks very nice.

Out of personal interest, how did you solve the mesh collisions?

Thanks! Piecemaker looks nice too, seems like we are approaching the problem in different ways :slight_smile:

I guess that you are talking about the fact that non-convex mesh colliders pass through each other? Here is my take on it:

It is possible to attach any collider to the original game object, and because it is cloned, all pieces will have the same type of collider. When using box or sphere colliders the pieces tend to intersect each other too much when shattered and launch each other far away though, so I recommend using convex mesh colliders for dynamic rigidbodies. When using convex mesh colliders the vertex count needs to be kept down but most objects stay below the limit or can easily be broken down into several game objects. What I think a lot of people forget is that there is a reason for the limit, any developer with performance in mind should not want to exceed it.

Using convex mesh colliders is in my opinion the best solution because they’re faster and easier to handle than non-convex mesh colliders, there is a reason most physics engines work exclusively with convex hulls. Non-convex mesh colliders shouldn’t really be used at all, except for large static meshes.

That’s my opinion at least :slight_smile:

Yeah, I create a convex collision mesh for my fractured parts, but its not very speedy, but thats maybe because I work very often with Highpoly objects (highpoly in the sense of the unity sphere which is very detailed).

Sorry for distrupting your thread, but it is a highly interesting topic to talk about.

No problem :slight_smile: interesting topic indeed, might be worth it’s own thread…