Maybe it will become more or maybe not.

(sorry for the frame rate drop from when I was recording, first time recording in HD)

The timer had been set and the team broke into pairs. The paired teammates discussed their approach and generally speaking one team member per pair was at the keyboard while the other observed what was on screen.

Aaron and Sunil were charged with the sea mines. Nick and Mikko were working on the dock and general game framework. While Salpy and Michael worked on the sea itself.

What resulted after just a little over 2 hrs of development was a functional prototype that was tracing key game events. Really the game was less polished then everyone wanted to see it but in truth the objective had been met in a little over the allotted time. As much as i wanted to blow a whistle and pull the plug on the workstations a la Top Chef, a terrific vibe was present that felt too good to arrest.

The team is working on a tight deadline this week and probably into the next but there is a collective will to post the game once we’ve had a chance to give it that little TLC it needs.

Stay tuned!

We are treating this more as an experiment and than a race because we primarily want individuals assigned to aspects of the game’s programming they have the least experience in.

A clock will start running after a quick 10 minute briefing at which the game concept will be broken down and assignments made to team members. Few graphics will be provided and the team will be encouraged to create effects and interpret the game design document.

Here is a crude diagram showing the game:

I will be writing a follow-up post in a week where i look forward to sharing the experience. Heck we might even stream it live over ustream!

Click on the example below to see how look maps work:
(Please open the article to see the flash file or player.)

Since some Voxel models can have 10,000+ voxels (or 3d pixels) it could be very intensive to for example tint every single voxel.

To put it into perspective imagine looping through 10,000+ colours and calculating their new colour every single frame, and then along with that also calculating new positions for 10,000+ particles. Traditionally this is how things would be done each particle contains it’s own colour.

Instead what I’ve done with the Voxel Engine is create a separate look map. A look map is essentially an array of colours and then each voxel (or 3d pixel) has an index that points to a colour in a look map.

Think of an image on the internet most likely every single pixel in the image is not going to be a completely different colour but instead colours are repeated. This is the basic idea behind the “look map” to have a colour pallette to create an image.

In the above example you may have noticed that when you were clicking on different colour swatches you would see the colours in the voxel model also change. We were essentially changing colour values in the look map without changing the index at which each voxel is pointing at.

Look Maps Do More

Ok so every single Voxel Model has a LookMap. During the rendering process what actually happens is that when the renderer is rendering a model it will grab that models look map and tell it to render “something” at a specific 2d position.

So what that means is that the LookMap actually performs the physical rendering. This allows us to do some amazing things…

For instance in the above example you can see small squares not pixels being rendered. What’s actually happening is that this models look map is a “FillRectLookMap”. Essentially instead of rendering pixels (PixelLookMap) it’s rendering rectangles or squares.

Of course there is also a “BitmapLookMap”. Check out the example below where instead of drawing pixels or rectangles we are drawing bitmaps:
(Please open the article to see the flash file or player.)

Again since we are using lookmaps we can quickly and easily change which bitmap is being rendered for which voxel. Another note is that because we only have 10 bitmaps to render and entire model we are using a lot less memory than each Voxel having it’s own BitmapData that would be rendered.

At this point in the development cycle for the Voxel Engine I find it’s a good time to just play around with the engine. This way the engine gets debugged and I also get to see what works and what doesn’t work from a coding perspective.

Adrian and Pablo really wanted me to make a drawing app. So the recording above is what I’ve got so far. It’s not perfect but I think you can get some pretty nice results using it.

I’d also like to mention that my nose isn’t that crazy and I have quite a bit more facial hair.

Below is a diagram describing the different pieces of the voxel engine:

There are four major parts to the Voxel Engine:

• VoxContainers
• Lookmaps
• Renderers
• Z-Sorters

VoxContainers

In the same way as Sprite is the basis for anything you do in Flash, VoxContainers are the basis for everything you do in the Voxel Engine. VoxContainers contain Voxel Data (both position and colours).

Voxcontainers are further divided into two types of containers Parsers and ParticleContainers.

Parsers are used to parse Voxel Data. For instance the Radio Head dataset for House Of Cards which is a bunch of CSV files. One of the parsers in the Voxel Engine is a CSVParser that is specifically designed to parse the House Of Cards dataset.

ParticleContainers are used to “particlize” parsed voxel data. In other words you take the data from a parser pass it to a ParticleContainer and then your voxels can start moving. (I’m sure I’ll discuss this process more in a future post)

LookMaps

Earlier I mentioned that VoxContainers contain position and colour data for colours. Well in actuality a VoxContainer contains positions, LookMaps, and look indices.

Basically a LookMap has an array of colours and each voxel has an index (look indices) that points to a specific colour in a LookMap.

It may seem pointless to have LookMaps however they are a crucial step for the Voxel Engine. (again more about that later)

Renderers

Renderers are the part that make voxels visible. It basically takes a VoxContainer and renders it out to screen using it’s position data and LookMaps.

Z-Sorters

Z-Sorters are used to sort the Voxel Data before it’s rendered. Simply it makes things look right, Voxels that are far back in Z-Space aren’t rendered in front of ones that are closer.

Z-Sorters were specifically broken out because this way they are not tied to the renderer. This way if a newer better sorting method (hint hint Adobe) comes out we can use that instead. Or if we want to implement some sort of culling of voxels it can be implemented here.

But wait there’s more…

These are the major portions of the Voxel Engine but there are definately more pieces to the Voxel Engine and I hope to talk about those in future posts.

We are displaying every fifth slice from this MRI image or so to keep the head proportional. (otherwise the head would be super wide):

If you want to see the actual page, Click here to get a taste.

I will definitely be looking into the canvas a bit more, but like Mikko said, i don’t think this is the “Flash Killer” just yet. But hey, I’ve got no problem experimenting with it. Its a nice break from Flash anyways.

What to build next…

I know that makes no sense but basically I started thinking with all this hype around HTML5 and Canvas I better try to build something in HTML5 and Canvas in order to know what it’s all about. With HTML5 and Canvas being touted as the “Flash Killer” I decided to try and see if it was possible to build the Voxel Engine using Javascript and the Canvas tag.

Here is a short video of the Javascript Canvas based Voxel Engine running in Safari:

You can see it in action by clicking below.
However we recommend that you use Safari or Google Chrome:
Click Here To See It in Action

This was an interesting experiment but from this I can say that right now HTML5 and Canvas is NOT yet the “Flash Killer” it’s being touted as. The performance on this experiment is quite a bit lower than what Flash can produce. I mean it doesn’t even run in Firefox, and this is the core of the problem with HTML and Javascript for years, browsers just aren’t built the same.