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. Unfortunately, due to changing file formats and me no longer being involved in the project, the visualizer is no longer accessible on the official website.

Development time: 1 month (March 2017-April 2017)
Roles: Programmer Unity (C#), front-end (Javascript), back-end (PHP), server logic (Python)

Technical Implementation

The visualizer is separated into four logical units of increasing size:

  • 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 these 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 of Minecraft gameplay.
  • 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 server 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 on the computers we tested the app on was luckily still enough given a realistic amount of buildings.

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 did 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.

Users of the viewer also had the ability to upload a screenshot of their buildings to Facebook. For this I utilized the Facebook SDK.