MileStone 3

It’s time for milestone 3. Which means the project should be done. Well here’s the work so far:

Here is the original model
so obese
IceCube reads the obj file and loads it into voxels.
And the model exported from voxels to vertices, opened in Blender.
Saves in a .obj file and a texture file. The texture file is simply a line, and the uv says which pixel to use for its colour (this ‘line’ below is actually the texture file for the model).




The conclusions, presentation and the runnable .exe file (as well as the source code) can be found in the MS3 folder.

Post mortem is for next week (MS4)

Last week

Production is at its final week.

Exporter and importer is now finished (as finished we have time for).
When exporting we save all the unique colours used in a texture file, looks like this (scaled up):

A correct mtl file is also created, so when loading these files into blender will display the model correctly with the right colours without further configuration:



The left model is the model in our program and the model to the right is the model in blender.
We had a few issues with Maya, since it reads the model correctly, and saves the material from the mtl file, but does not assign the materials.


The editor is now finished


Most settings can be accessed with both the editor and keyboard shortcuts to be as user friendly as possible. The only thing only accessible trough the editor is the colour picker.



We don’t really have time to start on something new, so we’ll work on polishing and small fixes here and there.
We’ve mostly ignored performance, but it’s time to get working on that.

In our original analysis we came to the conclusion that we’d make use of interval trees and hash tables to store chunks/voxels, then later in our blog we said we scrapped the idea because performance wasn’t an issue (only spend time on performance if it becomes an issue). Our performance report shows that should really use hash tables.

2 weeks left

The project is reaching its end and we are reaching our goals. The work on the importer is at its end and the exporter should be almost finished.

Currently we can load a model from a wavefront obj file and read which textures goes where from the mtl file.

so obeseobese master
(Special thanks to dragon_child for uploading the original model)

We are finalizing the work on the exporter. When exporting we generate a ‘texture’ containing all the colours of all the voxels. The UV coordinate of each voxel is set so it matches the colour on said texture. It should be visually seen next when when it’s actually done.

other updates:

  • support for undo and redo in the editor
  • some small changes to prevent some memory leaks.

Update week 4

We are progressing a bit faster than expected. The major features of the exporter and importer is already complete.

Here is a model (special thanks to and the user 3dregenerator for uploading it)
real thing


Here is the model imported into our program.


That didn’t look right. The bicycle is so small we have to scale it. Here is the resizing progress.
Looks pretty good. Except for the lack of textures and blocky shape. That is for next weeks work.


For now we have to make do with colouring it ourselves.


We have added a custom colour picker to the editor that can store and edit the current colour using HSV(hue, saturation, value).

Qt had a built in colour picker dialog, but it had some bugs that were not fixed in the latest version of Qt.


We can also save and load models using our own format, without loss of quality or colours.

Exporter and Shader

The editor has many new features, such as:

  • Changes and fixes to make the program more user friendly
  • Paint mode
  • Add/Remove large amount of voxels at the same time
  • Can receive the colour of selected cube

This week we have started on, and finished shaders.




In the future we probably want to add some kind of reflection on the voxels.



The work on the exporter has begun. Currently we can export vertices, UVs and normals. The UV is not editable in the editor and the exporter does not support it (yet?).

The first picture below shows the model in the editor.

And this picture shows the model loaded in another program. Oops, looks like different chunks mess up the location of the voxels.



After a little more work we got it working. Here is the model in Maya.

pic1 pic2

We do want to minimize the number of faces (vertices), which means the smaller voxels (seen in the picture with our model in Maya) will be merged into a larger one.



We have created a prototype that can handle voxels by adding or removing them with the help of a dynamic brush that specifies the area.


The large red cubes are the chunks.  The cubes within are the voxels.
When a voxel is placed, the chunk is calculating its mesh. So all the voxels aren’t drawn, but only the faces pointing out.


We have prioritized performance much less. Since we’ll only make a voxel modeller we don’t really need to support an arbitrary size of voxels on each direction. It has and will  save us a lot of developing time.


The full report on all these issues can be seen in our analysis in MS2.

Research and planning

You can take a look at our initial research at the Milestone 1 page,  but here is the updated research and planning.

Voxels will be stored in chucks. Chucks is an area consisting of voxels, pre-calculated what will be rendered from those voxels. When a voxel is added or removed the chuck, which the voxel is contained, will re rebuilt with the correct information for rendering. That information is saved so it do not need to be updated again.

Many of other voxel projects have problems with it running slowly on most systems, so while we don’t prioritize optimization early on, we decided we would have our code data oriented rather than object oriented.  Changing it later would only make it a hassle. We will use our own custom arrays to store the voxels and chucks.

Otherwise it seams there is no more research needed, unless we encounter a problem further in the project.

Milestone 1

Planning phase is over. You can check the results over at milestones page.

There has been slight modofications to our original idea, but nothing that will have any major impact on the project.

We will gradually update the work so far page so you can see actual work on our project in the form of screenshots.

Project planning begun

Welcome to our blog!


The first stage of planning has begun. A new blog post will come in a few days. with the details of our plans.


Project plans so far:

We will create a voxeliezed graphics engine. The said engine will render a terrain with voxels. The level editor can create and modify the terrain and later to be saved and loaded.
An exporter to export our level to a polygonal wavefront obj file. The obj file should be able to be opened with Blender and Maya.
The graphics engine should handle lightning, shadows and  textures.
The voxels should be smoothed to avoid making it look so blocky.

Level editor features:
Add light position.
A paintbrush with different size that can add and remove voxels, and apply textures to voxels.