For some, creating videogames is like magic.
Well for us, it’s Magica…
No? No one? Okay.
It’s a bad joke, alright, but it is also true: over time a software called MagicaVoxel has become central in our work.
My name is Julien Gatumel and I’m a 3D artist, writer as well as Head of Communication in Sandbloom Studio. As I’ve been in charge of adapting our workflow from using blender to MagicaVoxel, in this devblog I wanted to share a few things about what this software is, why we decided to use it and most of all, what issues we have found with it and how we worked around them.
If you are interested in using MagicaVoxel yourself or if you are just curious about it, I hope this post will be helpful.
What is MagicaVoxel?
MagicaVoxel is, as it’s creator puts it: ‘A free lightweight GPU-based voxel art editor and interactive path tracing renderer’. It’s a free to use software that is constantly growing and in development by @ephtracy on twitter.
It’s indeed very lightweight and it’s ideal to create assets in a voxel aesthetic (meaning, in short, creating 3D art with cubes). The software is in version 0,99,6 at the time I’m writing this and although it has a few issues (that I’ll be addressing later), I would very much recommend it.
You can check it out here: https://ephtracy.github.io/ and/or keep reading to have a more in depth review.
Why do we use it?
Yes, why use MagicaVoxel for a full game dev project and not go for a famous “giant” of 3D modelling like 3D Max, Blender or Maya? Well, the short answer is because they weren’t as good ( and by a long shot) to what we were looking for. The are other softwares specifically made for Voxel modelling (Qubicle, Voxedit) but we finally decided to go with MagicaVoxel.
At first we actually considered going a whole other route. As a company we are used to working with blender. And this is still what we use for a lot of elements (animations, rigging and certain models specially for VFX). But we soon realized that it was not viable for modelling in a voxel artstyle. This is because there are no proper tools in blender to model using cubes. Creating single cubes and duplicating them one by one to create complex models was, of course, out of the question. It would take too much time and would not be precise at all. We then discovered a modifier called remesh that allowed to convert any 3D model into cubes and for a moment we thought we had something.
But there were two main problems. On one hand, using this modifier creates a lot of useless triangles/faces. We could clean this up but it would take a lot of time. And even then it would not be worth it as using this method gave little control over the modelling of the objects. It turns an “organic” object into a cubic one but you cannot easily edit the geometry and cube placement.
We also explored different plugins for Blender that helped a bit but in the end none of them gave us the fluidity and the control that MagicaVoxel brought to the table.
But this was not the end of our problems.
How do we incorporate this into our workflow?
Using MagicaVoxel as a Voxel (or Pixel) artist to create unique pieces is a dream come true. It is very simple and gives lots of options to create, including transparency, emissive materials and a lot more.
Without much limitations (except for the size of the canvas and maybe the color palette) you can create anything very easily. Shortcuts are seen in the bottom part of the screen when you hover over a tool, all is accesible in one screen, there are mirror and symetry tools to make the process easier and generally it is very intuitive.
But there is a reason why we considered more options before jumping on MagicaVoxel.
MagicaVoxel is not necessarily optimized for gamedev at the moment (and that’s normal but it’s problematic nonetheless) and importing models created with this software to Blender revealed a couple of issues.
If we were to create a model to render on its own, without including it in a bigger context (such as is a game as ours ), there would be no problem, as we wouldn’t have to care about polygon count, UV mapping and others. But in our line of work, all these “behind the scenes” elements are crucial. If these elements are not taken care of, there can be problems. For example, visual effects might not work, or objects might have too many faces, ultimately making the game run slower than we want it to.
I will here try to explain these issues, why they are problematic for gamedev and how we worked around them or we adapted to the situation.
Before anything, a quick overview of the MagicaVoxel possibilities. There are a lot of options, shortcuts and tools to make modelling better but in general it all turns around three main elements.
You have a limited working space (per object) and there you can add cubes, you can remove them and you can paint them. If it sounds simple it’s because it is. And yet the amount of complexity you can achive with it is enormous.
Now for the problems. When you create a model with MagicaVoxel, a dedicated material is created as well. This uses a texture called Palette, that is 256 pixels long and 1 pixel high, effectively dividing this image into 256 different colored pixels. Each one of these corresponds to the ones you set in your palette inside MagicaVoxel.
When you use the paint tool in MagicaVoxel, what it does is it automatically assigns the painted cube to the relevant pixel in the UV map. In a traditional software like blender, you tend to first unwrap a model in a flat surface and then paint it manually (with photoshop, substance painter or similar). Here, MagicaVoxel automatically “unwraps” the model to this 256 x 1 image, making it so that each and every face created with the software is mapped in a single pixel.
When you don’t need to use properly unwrapped UV s for your models, like if you want to apply a special shader that takes UV into account, this «issue» is not actually one. In fact, the palette system is pretty good and is used sometimes in gamedev in one way or another because it allows you to theorically have all the models in your game using the same material and texture. But this has a catch: if you change colors in the process of painting your models in MagicaVoxel, this creates another texture even if you only change one of 256 colors. If you don’t, your new model won’t be seen in the right color. This all requires and additional layer of organization when working to be sure all objects are painted int the right color from beginning to end. In our case, we created a list in excel specifying what colors in our palette are used for what.
So, for all non-UV dependent models (shaders, animated characters mainly), we use the palette texture/materials. When we need to use UV s though, we need to import the object into blender and map it manually. This is a longer process but generally does not take up too much. After this, we use Blender’s Addon Layer Painter to paint characters or the Amplify shader addon in Unity for shaders that use UV info.
This is an interesting subject. As said before, modelling with MagicaVoxel for renders is a whole other story than using it for game dev.
First, each time you use a new color, the software creates triangles and faces to make their palette system work. So each time you use different colors on an object, you are creating faces. For a single object it’s not so bad but it quickly adds up inside a project and ultimately it can be problematic and slow our game down.
As a solution, we try to limit the amount of different colors we use on a model if possible. For example, small objects do not need to have tons of detail in a game and elements that are far away from the player (and always will be) do not need a lot of detail either.
Second, vertices in objects exported from MagicaVoxel are not properly welded. All flat surfaces are welded together but the rest are separated. This might not be an issue in certain cases at first but it creates a lot of useless vertices and will cause problems with animations and shaders.
In the same vein, depending on how you model in MagicaVoxel, you might find that there are «ghost» artifacts or polygons inside of your object. This augments the polygon count with elements that you won’t ever see and that also be troublesome for animations.
Also, there is no effective option to erase a face inside MagicaVoxel. All sides are painted and in some cases you might have no interest in having certain faces existing. For example, a big mountain next to the path might be seen only from one side in your game. The other is irrelevant so we are wasting resources.
The solutions for all of these, fortunately, are not difficult although they take some time.
Our process is the following: we export models from MagicaVoxel directly to Unity. There we test the scale, the colors and the overall look. If there is need of corrections we go back to MagicaVoxel. If not, we import the models to Blender and do all required corrections.
Welding vertices is very quick and only requires just a couple of steps. Namely selecting all vertices and welding them by distance. (This usually causes a problem with normals and we have to tell our mesh to «shade flat»).
Eliminating “ghost shapes” inside of meshes require a bit more of exploration and manual elimination. Basically you will have to look for all things that have been created by error and/or you don’t need to see in your game and erase them. The same goes for faces that will not be seen in the game.
There are a few more steps that can be taken (the decimate modifier for example) but some are too destructive and modify the colors without reducing poly count enough to be even considered.
Finally, and this is an issue coming from the voxel aesthetic and not the MagicaVoxel software, it might not seem at first but modelling in voxel might be problematic in terms of optimization, especially is you want to work with a lot of detail, as you create a ton of polygons with tiny cubes. In that sense, it is a quite more demanding aesthetic than low poly. There is unfortunately no quick solution in this case. The best thing to do is to be careful and to know when to favor optimization or detail.
There are other issues, notably one about shadows. Certain meshes made with MagicaVoxel, when put in Unity and illuminated, project shadows with “square” holes in them. This happens, as far as we’ve investigated, because of the normals of models in a voxel aesthetic. We have found as a temporary solution that establishing the meshes to have “double sided” shadows solves this issue, but this is not optimal at all so we are looking to find a better solution.
This might seem as a lot of negatives regarding MagicaVoxel, but as I’ve said before the software is still in development and even knowing all this we chose to go with it. It is extremely nice and easy to use while obtaining great results.
So, summing up, I would reccomend MagicaVoxel without thinking twice. There is a lot of pixel art out there (both in games and in art) but Voxel is criminally underrepresented nowadays. More artists in this world are needed. Just know that, if you’re gonna use it for gamedev you will need to take some things into account.
Thanks to all of you for reading this. I hope this peaked your interest and don’t hesitate to come over to our discord to discuss more of this and to our twitter and instagram (@sandbloomstudio) to check out what we’re up to.
And obviously, let us not forget to, again, thanks @ephtracy for creating this software.