Detonator release today?


(Update: Apparently the Unity guys had some issues updating their site. Stuff should be up 9/17)

Well as of this writing it’s not out just yet, but it will be very shortly. I’m going to bed in a few minutes and the boys in Copenhagen will be getting up, and Detonator, if not all of the SOC projects, will be released tomorrow. I wanted to just make a quick post for anyone that ends up here and is looking for more info, wondering where development is headed, or finds bugs.

I plan on continuing development on the project and will be posting the code and the current dev build to some public source sharing service like or Google Code in the next couple of days. I’m SURE that people will find bugs and I’d like to stay on top of them as best I can. Really, there was minimal testing done on this project so if something acts weird, it probably is.

In the meantime, if you find a bug and don’t know what to do with it, drop it in the comments here. Thanks!

Detonator – Progress Point 5


(This post is mirrored on the Unity Technologies Blog as well.)

We’re just 9 days away from the August 31 deadline so it’s time for an update. The good news is that it’s almost done, and that means a ton of changes since the first concept Unity players that I posted on my blog (see Point3, Point2, and Point1). The main effort has been towards making Detonator entirely code driven. This involved creating a new particle component (DetonatorBurstEmitter) that calls some of the scriptable functions on the standard Unity particle system, but makes one shot emissions and the other sort of scaling effects easier to create.

So, what about actually using it? The simplest use case is to take a GameObject, attach a Detonator component to it (in code or in the Inspector), and either call Explode() in code or check the “Explode on Start” checkbox in the Inspector. That will do a whole bunch of stuff… create all kinds of emitters, a light, a force, all corresponding default materials, and then BOOM, you’re exploding. That usage case was a primary design goal and it’s met.


If you want to take it one step further, you can tweak parameters on the Detonator component. The default explosion has a 10m radius, and that can be changed to whatever you’d like – all effects scale accordingly. As anyone that works with particle systems knows, this is not a trivial thing because it needs to change particle size, emitter radius, velocity, emitter position, and forces all in unison.

Performance scalability is also a concern with effects, because, well, they can scale.  For that there’s the detail parameter, which affects the number of particles spawned, and even whether or not certain entire sub-components get created. Each piece has a detailThreshold parameter that lets you customize how your Detonator explosion scales to different performance specs. I’ll be looking into how this will hook into the global Unity quality settings as well – no promises for release but I’ll get it in shortly after if it doesn’t make it then.

After detail there’s color. Changing the color of the main Detonator component will have differing effect depending on its alpha value. Since using alpha purely for transparency didn’t make a lot of sense in this context, it instead serves as the color influence. So if you make your color Blue with 50% alpha, then colors of all sub-components will be 50% blended to that blue. Since the normal fireball is orange and other parts are white, this gives a nice non-uniform coloration. By the same token if you’d like to go for a stylized look, crank the alpha to 100%.

Duration can also be adjusted. This was tricky because just altering this naively made the explosions really dim, so the alpha values of all the emitters’ color animations try to stay more opaque when the duration is shorter. Everything is tuned to make changing parameters make sense. Of course, we’ll learn a ton more when people are using this en masse, but I’ve given it my best shot to start with.

So that is the main Detonator component. Many people will just use that, but underneath is a full-fledged explosion construction kit. For instance, DetonatorFireball is one of the sub components that a Detonator normally auto-creates. Instead, you can make your own by  dragging a DetonatorFireball script onto that same GameObject. You can add one, two, or ten of these and then get busy changing their relative positions, sizes, colors. You can even time when they go off (with randomness) to create startling layered effects. Then add some sparks, smoke, a glow, a light, or whatever you want. In just a few minutes I was able to make a pretty nice mushroom cloud. I can’t want to see what people do with this.


And for the artists out there like myself, you can switch out the materials and textures that your Detonator components use. Either replace them at the top level and let them cascade down to subcomponents, or replace them piece by piece, it’s up to you. I’d really like to see what is possible with stylized or toon explosions with this system.

So what needs to still be done? I still need to reimplement a few components that were in the concept effect… namely the chunk emitter (which sprays any gameobject you’d like with trailing smoke) and the physics force (which acts on rigidbodies and even sets them on fire if you want). The UI of the main Detonator could use some spicing up, but that would mean reimplementing material slots through the drag and drop API, which might not be worth it at this stage. The main thing the UI would do is put buttons in to create each subcomponent so one wouldn’t need to manually drag scripts onto it. It feels like that would add a nice level of polish so I’ll have a look.

Detonator Progress Point 3

This version features better particle growth thanks to a tip on particle Size Grow parameter animation courtesy of Rune at Unity. I was having a real problem getting the behavior I was looking for out of the Size Grow parameter, and it turns out that if you alter that parameter over time, you can get the exponential growth with damping that’s needed for an explosion.

I also converted the textures to grayscale so that they can be color shifted by the system. It takes a little bit of the richness out, but I think we can get it back later. The payoff in color customizability will definitely be worth it.

Detonator Progress Point 2

Well I got some good feedback from the last progress snapshot. We have a mailing list for the various folks to talk and a few of the guys, Rune, Jonas, and Joachim all chimed in with their thoughts on the first go…

So for this update I worked on making the explosions expand better, tweaked some of the color to make things more varied, and added a cool feature where the explosion will automatically ignite any object that it hits through the physics system (thanks Rune for the idea). I also adjusted the background so the smoke is more visible. Also note that the explosion is currently about 10m in diameter… thus the floatiness of the physics. In the end it will be scalable to different sizes, but I figured if we’re gonna start with anything, we’ll start big. :)

Unity Detonator: Progress

Well I’ve spent a few nights now working on Detonator. So far I’ve been getting the feel of the Unity particle system and seeing where its strengths are. Before I go to bed tonight, here’s a little demo scene to kick things off. Nothing parametric yet, but we’ve got to have a nice base effect to work with, right?

Besides the basic particle emitters, there’s a light and a rigidbody explosive force that get spawned. The look is really a first pass, just trying to get all the pieces in. I still need to add chunks flying out with trails, some beams, and get all the particles sorting right. There’s also a bit of flicker between the smoke and other particles that should be worked out. Still, I was happy to see the performance is good even on my old Macbook.

I’ve been thinking about animated textures too. Not sure if they’ll be necessary, but I’d like to try them out. If anyone knows of a tool to convert a movie to a Unity animated texture, let me know. Iterating on that seems like a pain without a good tool.


Unity Summer of Code – Detonator

I wrote a proposal for a parametric explosion system for the Unity Summer of Code… and it was one of four accepted out of over a hundred! I’m excited to be working with Unity engineer Jonas Echterhoff as my mentor – and I’ll definitely need his help. Here’s the announcement:

And here’s the proposal:


Great explosions can make a game. Bad explosions can ruin a game. As important as they are, they are difficult to do well because they are composed of art and complex behavior that’s not easily consolidated into a single object. Explosions also have a high degree of randomness, yet within a domain that is not easily described and is often violated.

That said, Unity developers of all types could make great use of a system that allows for efficient creation and iteration of explosion effects.

For artists, the system will provide a means to harness and iterate on complex behavior that is normally hidden behind coding barriers. Artists can think in terms of “size” and “intensity” of the explosion as a whole, while also drilling down to tweak details. Detonator is more than just a collection of particle emitters.

For programmers, creating an explosion with great visual quality will no longer hinge on finding pre-existing particle libraries or an artist friend. Detonator will provide solid results from the start. It will also allow easier binding of game logic to explosion parameters by providing meta-parameters that combine several emitters, models, lights, into a single “Intensity” or “Duration” value.


  1. Allow non FX-specialists to easily experiment with different looks for their explosions.
  2. Tie explosion parameters to game events and parameters. ie – have one explosion for damage, one for destruction, all calling the same script but based on remaining hitpoints of the gameobject
  3. Tie explosion physics to global parameters such as gravity and wind so they can be tweaked and altered at run time in one place.
  4. Allow the creation of named explosion presets (prefabs) – this will enable code to spawn type of explosion based on incoming weapon
  5. Create a method where the explosion render complexity scales according to frame rate, total particle count, priority, etc. and provide global and per prefab complexity values for easily tying to code.
  6. Let the developer decompose the explosion into its component pieces if he wants to use the system as simply a baseline for further art.

As part of the process of building Detonator, we’ll define what an explosion is and create taxonomy for all of its components. The system will consist of 4 layers.

  1. Layer 0 – The raw gameobjects and scripts
  2. Layer 1 – Per component parameters
  3. Layer 2 – Per explosion parameters
  4. Layer 3 – Detonator System wide parameters

Example Layer 0:

  1. Particle Emitters
  2. Scripts
  3. Lights
  4. Models
  5. Animations

Example Layer 1:

  1. Flash – A screen space flash
    1. Color
    2. Duration
    3. Size
  2. Screen Shake
    1. Intensity
    2. Period
    3. Seed
  3. Sparks – Ignited, small debris that shoots straight out
    1. Number
    2. Color
    3. Size
    4. Length
  4. Debris – Larger chunks that can trail a particle effect
    1. Number
    2. Model(s)
    3. Size
    4. Color
    5. Trailing Particle
  5. Shockwave – A scaling model (sphere, cylinder)
    1. Size
    2. Duration
    3. Color
  6. Light – A point light that animates with the duration of the explosion
    1. Intensity
    2. Radius
    3. Color
  7. Fire – The main body of the explosion
    1. Texture
    2. Color
    3. Size
    4. Duration
    5. Pieces
  8. Smoke
    1. Texture
    2. Color
    3. Size

Example Layer 2:

  1. Size
  2. Intensity
  3. Smokiness
  4. Gravity
  5. Chunkiness
  6. Complexity

Example Layer 3:

  1. Gravity
  2. Wind
  3. Complexity

So, follow along. With any luck Detonator will turn into something the community will make good use of.

Arctic Thunder Sleds

At the tail end of my stint at Inland Productions, I did a few snowmobiles for their port of Midway’s Arctic Thunder to the PS2 and XBox, but I left for Sony before it was completed.  These vehicles were additions to the ones from the arcade version and were my own concepts, models, and textures. Basically they are tricked out, over the top, arcadey snowmobiles.




Maxscript – PaintOBB

When I was at Vicarious Visions working on Spiderman 3, artists were responsible for building collision geometry. More often than not, a bounding box was the recommended collision type.

Once we started doing Interiors with the system, it became apparent that folks needed a better way to make an OBB and AABB for selected geometry, so I created a tool in Maxscript that let them easily do so. I can’t share the code, but below is a video that I made while I was working there to introduce the PaintOBB tool to the artists on the team.

The idea was to let the artist invoke the tool, then paint over faces on the selected model. The tool would then generate a first pass bounding box based on the selection. Then the user would move their mouse along the desired axis, and the box would shrink wrap to fit around the geometry, creating the most efficient OBB with minimal work.


EA’s Ultimate Hunt Challenge

Here’s some artwork from one of my first titles. You’ll see a bunch of what look like satellite imagery. These were overhead maps that the player would use to choose their starting location. Some were 8 miles by 8 miles if I remember correctly. Others were a little closer up, like 1 mile by 1 mile. These were really fun to build. I’d receive an ugly looking snapshot of the world like this:

What I'd Get

What I’d Get


What I’d Make From That

Then I’d take it into Max, get the heightmap for the level, displace it, light it, and then use that for a shade map. Then I’d take the whole thing into Photoshop and start painting it up. Sometimes I’d do it up and make a spec map on the water or bump maps on the forests and rerender it.

Then there is a sheet of tile textures that I did for a winter level. The system for this game was actually kind of cool, and was a precursor to systems I would use years later on Spiderman 3. It was a tiling and instancing system that allowed the world to be miles across. So those little square textures would each be one quad on the map. Then using a tile builder, a roughly 16×16 quad tile would be populated with trees and other entities. Then that tile would be arranged on the world map.

The upside of this is a huge world. The downside is that the world was quite repetitive. Anyhow, it was a hunting game. It was 1999. People liked this kind of thing.

Last there were a few low poly models in there too. I show those just to say hey, I made a bunny in under 100 triangles. Those models were even rigged and animated. I’ll see if I can dig it up, but I have a sick bunny hopping loop that this portfolio is sorely lacking.