<
>

This project is a web app specifically designed to display Minecraft cubes inside the browser in 3D and in realtime using WebGL.

I made the visualizer during my semester break where I worked at TU Darmstadt at the faculty of Architecture. They were looking for a programmer experienced in Unity who was willing to bring their Minecraft mod to the web browser. I was also responsible for the communication between the Minecraft server, the database and the visualizer.

The visualizer was part of the IBA_GAME|20.000 BLOCKS which experiments with the use of Minecraft as an architectural tool to be used by inexperienced people. It was made for the IBA Heidelberg, a public forum which plans the structure of a new residential area in Heidelberg.

Development time: 1 month
Roles: Programmer app (C#, Javascript), back-end (PHP), server communication (Python)

A teaser trailer can be seen here, the full visualizer will be put online soon.

The visualizer is separated into four logical units:
  • A block which is mapped 1:1 to an actual Minecraft block. When starting the app the database sends a list of all used buildings inside the loaded map and how they are assembled using cubes.
  • A building is the smallest packet of information we handle during execution. It has properties like a name, instructions how to build it, a location etc.
  • A neighbourhood is a parcell within the world which contains all the buildings built by the players during one round.
  • A world which is a 11x27 grid of neighbourhoods. Once a world has no empty neighbourhoods anymore the server archives it and start a new one.


The python scripts on the Minecraft wrap up a finished match into an XML file with player names, built buildings, time, statistics and so on and upload them to the database where the data is split up again and stored in an easily accessible manner. When the visualizer is now started it gets a list of all worlds and loads the newest one including buildings and which blocks they consist of. Each building's mesh is then generated over the next few frames.
At the end all neighbourhoods are filled with these meshes that all share the same material. This of course could make perfect use of instanced rendering but at the time Unity did not support it on the HTML5 build target. Thus I had to rely on sheer horse power which was enough for realistic scenarios still involving hundreds of buildings at a time.

Unity uses its internal IL2CPP converter system to translate the written C# code to C++ which in turn is put through the Emscripten compiler which outputs Javascript (asm.js). As such we do not have the ability to use threading to load off bits of the parsing work. Usually in our semester projects CPU power is not that much of a concern compared to the GPU but this time it was the other way around. Thanks to WebGL I had nearly native execution times on the graphical side of things but parsing and loading took a lot of time.
This is why the visualizer employs an internal task system which manages a single job at a time (e.g. 'parse building #01') across a defined number of frames. I balanced the job system to the point where the user would experience no lag during runtime parsing while still having the world load at fast speeds of under 2 seconds.