Super, smashing, great…

For the last few days I’ve been experimenting with smashable things in Unity and thought I’d share a few notes on how I’m going about it…

I started off putting a few bits and pieces together in my 3d package; there’s a keyframe-animated flower, a pot with a simulated shatter effect and a particle system with 1000 rigidbodies for soil.

 

 

A couple of things have to be addressed before recreating this in Unity. Firstly the shatter effect, in this particular instance I was able to bake the animation into each separate piece of pot, I could run the simulation several times until I was happy and then export the pieces with standard animation clips that Unity would understand.

For the soil I used the interior of the pot as an emitter and just increased the number of particles to create a solid looking mass. I then used Polygonizer to “skin” the particles and created several frozen meshes at key times from which I could create blend shapes. This meant I could use a fraction of the number of particles in Unity, and use the blend shapes to fill in the space.

I’ve previously had some difficulty getting animation clips on multiple objects to sync up properly but Unity’s new timeline seems to work really well. I just dragged the various clips on and used the recorder to set key frames to hide/reveal different elements on cue and set the blend weights. 

As happy as I was with the baked animation, I also wanted to try something a bit more interactive that would respond to player input and react to the environment, so I decided to try and recreate the shatter simulation using Unity’s physics system. For simplicity I’ve set aside the pot’s contents for the moment to focus on just getting the broken pot working.

The Pot Parent is an empty object, set up with a collider and rigidbody components, the child objects are the original solid pot mesh and the multiple, pre-cracked pot-pieces I generated from that mesh, now without their animation clips. 

Pot_Parent has two very simple Playmaker FSMs attached:

The first detects the mouse axis direction as a vector3 and applies this as a corresponding impulse force to its own rigidbody.

The second detects a collision, sends a Smash event to all child objects, detaches them and then destroys itself. I’ve used a Collide Tag to limit collisions to specific objects, this means the Parent_Pot can happily sit on the shelf collider without immediately shattering.

The Solid_Pot is just a mesh, it has no collider or rigidbody, it simply waits for a Smash event and destroys itself.

The Pot_bits all start off with their mesh-renderers set to inactive, they have rigidbodies and convex mesh colliders, set to kinematic and inactive respectively to begin with. Each individual Pot_Bit gets an identical FSM so I’m using a template:

Firstly, each part stores its own various components as variables; the rigidbody, the collider and the mesh-renderer, then the Pot Parent‘s. The parts then sit, invisibly, waiting for a Smash event.

Once the smash event is sent the rigidbody is set to non-kinematic, gravity is enabled and the mesh renderer is turned on. We also get the current velocity and angular-velocity from the parent object and set that locally, you can see the difference that makes here: 

 

As ever, if you have any questions, crits or corrections, leave them in the comments below.

You can also follow along on Twitter and Tumblr for more regular updates.