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: http://blogs.unity3d.com/2009/07/22/unity-summer-of-code-takes-off/

And here’s the proposal:

Detonator

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.

Subgoals/Thoughts:

  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.

sarge

indigo

Sleds_Thumb

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.

PaintOBB_Thumb

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

Overhead_nebraska425

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.

 

Syphon Filter PS2 Weapons

Construction Details

From about 2000-2003 I did a bunch of stuff with weapons on Syphon Filter Omega Strain for the PS2, including weapons modeling, weapon integration with the character hardpoint system, weapon FX, and some scope artwork. There were around 60 different gun models and they came together at about 3 a day,  built in 3DSMax and averaging around 300 triangles. Our texture budget on SFOS was amazingly tight, since it was a 4 player online-coop game where each character could have a completely different outfit and weapons. I opted for what at the time was a novel texturing approach used by Metal Gear Solid where the highlights and shadows and specular reflections were painted in and high frequency details were often left to geometry. To up the vertex count to support this detail, it was vital to have efficient tristripping, so I’d just shoot a planar projection through the side of pieces of the gun to keep all the verts continuous.

Here’s a short clip showing one of my favorites to model, the FN-P90 – Watch Video

The weapons were also very visible to the player because of the hardpoint system. When characters stowed their guns, they’d go to one of four places on the skeleton – back, thigh right, thigh left, or chest. Since it is a third person game, the back hardpoint would really shove the gun right in the player’s face, so detail was important to maintain. Still, the texture resolution in multiplayer mode was set to half that of single player, and things would tend to get blurry. Luckily the geometry did much of the work, and considering that the models were all lit by the world, this didn’t end up being that bad.

FX

Weapon FX had a bunch of different components. The gun flare was an actual model that was turned on and off, and was positioned via the gun’s skeleton. Yes, guns in this game had skeletons! Initially, the game design was more of an online RPG and had called for a crazy weapon customization system where players could purchase scopes, silencers, and the like. Most of these elements were dropped in the final design, but the gun skeleton was still used for a few things:

  • A bone to align the character’s trigger hand to dynamically
  • A bone where the support hand would go
  • Positioning of the gun flare
  • A bone for FX to emit from

As far as the FX, smoke particles were created and would shoot out of the tip of the gun. A light was also turned on with each shot. Turns out that the system also supported spawning a particle emitter on the bullet as well. And another one when it impacted! This was crazy, the amount of calculation that was being done. Bullet hits were tracked per bone, with ellipsoids around each one. You could shoot a guy in the arm, leg, head, and it would all be tracked. The character programmer even turned the vertex color red wherever a guy was hit. You know, cause that’s what blood looks like.

So, with that in mind, we got busy with the system late one night and hacked up a flamethrower, and it was awesome. It still is one of the only flamethrowers in-game that I’ve seen that properly splash fire on a surface that it hits. Here’s a Youtube playthrough that had to deal with them. Our designers made this last mission of the game nearly impossible.

 

 

Pumps!

Ok so this is a funny project to show for me for a few reasons. First, it is O-L-D. I did these before I was even in the game industry, right out of college. Second, I’m not a mechanical modeler by trade, but I can certainly do it if called on, and I like showing that. We all have favorite projects and this is one of mine. It was done in 3DSMax v2 or somewhere around that vintage.

It was a real blitzkrieg of a schedule, and I was holed up in my studio for a month or so modeling these things with just brochures for reference. There was rarely a good orthoganal shot and no measurements besides broad dimensions. And on top of that I was working on a Pentium-Pro 200 which was a 10th the speed of an iPhone!

Also of note was that this was way before the days of your fancy newfangled Global Illumination renderers. This is pure Max scanline baby. And of course it still took 10 minutes to render each shot.

Still, it was fun. The project was for training software for this pump manufacturer, and I also had a hand in the UI design as you can see in the last shot. There were animations as well but they weren’t very interesting, just showing a line traversing a cross section of the pump.

I still get excited when I’m out and come across a pump.

3DSMax Lipsync Rig – Convert Bones to Morph

LipSyncRig

This example shows a relatively low-poly head rigged with bones for the standard lipsync viseme targets. This was matched to a system called Animeter that has since been bought and sold a bunch of times. Anyway, the standard targets still apply now.

So, the way this guy works is that we have a head model that is rigged and animated to a different morph target every 5 frames. The script creates a button in the head object’s rollout called “Create Morpher Head”. When the artist hits the button, Max snapshots the head along the timeline to create morph targets. It then assigns the targets to a base head with the Morpher modifier. Then you’re ready to roll.

The advantage to this is that since morphs are always topology dependent, we can’t tweak the model very much without ruining the rig. So instead, we make modeling changes to the skinned head and regenerate the morph targets from there. This can save artists a bunch of time.

Below is the source for the script.

?View Code MAXSCRIPT
makeHeadCA = attributes makeHead
(
	parameters main rollout:params
	(
		makeHeadBtn type:#boolean ui:makeHeadBtn
	)
	rollout params "Make Morpher"
	(
		button makeHeadBtn "Create Morpher Head"
		on makeHeadBtn pressed do
		(
			headBasis = $
			nameArray = #("head_player_none_male","Eat","Earth","If","Ox","Oat","Wet","Size","Church","Fave","Though","Told","Bump","New","Roar","Cage","EyebrowRaiseLeft","EyebrowRaiseRight","BlinkLeft","BlinkRight","LookUp","LookDown","LookLeft","LookRight","EyebrowRaiseBoth","BlinkBoth")
 
			sliderTime = 0f
			headPosX = 0.5
			headDone = 1
			global headMorphs = #()
			--snapshot the main head
			for i = 1 to nameArray.count do
			(
				newHead = snapshot headBasis
				headPosX = headPosX + .5
				newHead.name = nameArray[i]
				newHead.pos.x = headPosX
				append headMorphs newHead
				sliderTime = sliderTime + 5f
			)
			sliderTime = 0f
 
			--now add the morpher plus the targets
			mainHead = headMorphs[1]
			addmodifier mainHead (morpher())
			global theMorpher = mainHead.morpher
			select mainHead
 
			for i = 1 to (headMorphs.count - 1) do
			(
				print ("adding " + headmorphs[i+1].name)
				WM3_MC_BuildFromNode mainHead.morpher i headMorphs[i+1]
			)
		)
	)
)
 
CAs = custattributes.getdefs $head_basis.skin
if CAs.count > 0 then
(
	for i = 1 to CAs.count do
	(
		custattributes.delete $head_basis.skin i
	)
)
custAttributes.add $head_basis.skin makeHeadCA

Syphon Filter PS2 Characters

I was the Lead Character Artist on Syphon Filter: The Omega Strain at Sony Bend. In addition to heading up concepts, modeling, texturing, and rigging of all game and movie characters for the studio’s first PS2 title, I worked very closely with the Lead Character Programmer in creating a state-of-the-art character customization system and corresponding pipeline. Below are some samples of artwork and in-game shots.

Syphon Filter PS2 Marketing

As this game was wrapping up, I was asked to make some renderings for use by the gaming press. I already had the characters created for movie rendering, though they are game-resolution with high-res textures. I did get some help –  Shane Pierce, the concept artist at Sony at the time, and now of Epic, did quick black and white layout sketches for a couple of the shots and painted the tower in the background of one of them as well.

Each shot took about a day from start to finish and they were featured in Maxim, Play, GamePro, and other international gaming magazines. One of the shots was even used as the box cover art for the European SKU of Omega Strain.