Smart-Page.net

Surely you have already heard of Conway‘s cellular automaton – the Game of Life.

For those who haven’t, it’s a simulation of cells interacting with their neighbors by following a simple rule set on an infinite, two dimensional grid.

So let’s add a dimension -> view the game of life in 3D!

The Game of Life has become famous not only in theoretical computer science, for it is Turing Complete, generates the most interesting patterns and is easy to implement.
In flash it can be done in ‘one line’ of code by means of a convolution filter.

So since 1970 the Game of Life has been explored by almost every programmer, it’s no surprise its “Glider” pattern became the official “Hacker Emblem” in 2003.

Customarily it’s visualized by a 2D representation of the board/grid – however, it can be applied to 1D and 3D space as well.

While I find 3D versions/rule sets to be interesting too, there is a much simpler way to lift the game into three dimensions that also generates more beautiful patterns:
Simply plotting the (visible) game grid´s state over time on the third axis perfectly visualizes the process and generates amazing shapes… or at least very interesting greebles

Why Unity?

The only issue is the amount of cells to draw – visualizing a small 10*10 field over 100 generations already means handling up to 10k cubes or sprites.

And I had an even higher amount in mind, so flash wouldn’t get me anywhere this time.

First I thought about building a standalone app, then using Processing or Py4D…

There it hit me – Unity! As long as OpenGL isn’t native to the web, Unity 3D is definitely the best way to deliver intensive 3D games/apps via the browser.

As Unity offers C# as scripting language I immediately feel at home. Unity 3D reviewed in one word: Awesome!

The draw call issue

But there is always a stumbling block hidden somewhere.

Since I am generating a lot of cubes (cells) on every frame, unity has to do a huge amount of draw calls – one for each object.
The frame rate on my machine (Q6600, GF8600) dropped right into the basement.

The simple solution to this issue was to generate the complete generation of cubes and to fuse them to one single mesh using Mesh.CombineMeshes.
Normally this is done on startup – for the exact purpose of reducing draw calls – and I thought it could also be used at runtime for this scenario.

As objects are limited to 65k vertices, it wasn’t possible to merge the complete scene into one mesh, but that might have quickly become too time intensive as well.

So finally I was able to animate/display more than a million vertices.

Conclusion

The app now draws a 50*50 grid over a time of 200 generations – press space to reset the game and seed a new field of life cells.

Admittedly, it takes a lot of resources – a graphic adapter with at least 128MB is essential as the simulation might end up with 1.5 million vertices.

Hope you get to see some interesting patterns – have fun!