Voxels: Rasterizer 1.2

Eventually I submitted a new version of my Voxel conversion tool for Unity to be published on the Asset Store. The previous version had been taken off without warning in the summer of 2019 due to missing updates for newer Unity versions and modified guidelines for the usage of the logo. That second point is also the reason the package has been renamed.

Quickly after the store removal I started to make sure my rasterizer was still working with the latest version of the application. And that was the case but only for the standard pipeline unfortunately. At that time the Lightweight and the High Definition Render Pipeline had been introduced and the rasterizer did not read meaningful data from the results of the utilized camera. Because a major advantage of my solution was the ability to collect colors from source assets similar to how they are being rendered at runtime I wanted the support the new options, too.

I started to debug things, which was not easy because the APIs of those pipelines were not deeply documented. So I had to do research by trail-and-error, which took a lot of my spare time. And both scriptable pipelines required different approaches for manipulating the camera to get the results my tool needed. Hundreds of hours, which mainly happened on vacation and around Christmas, passed until a satisfying outcome loomed. In between there were months I couldn’t do anything because my job demanded my complete focus.

Voxelized HDRP standard scene
Comparison between the new HDRP standard scene and its voxelized outdoor room

After operating suitably another issue, which some customers experienced in their workflow, still remained. Despite indenting the mesh creator script only as an example people are using it heavily to create assets for their projects. And whenever they wanted to build a prefab of a generated voxel model data got lost. So, I enhanced the component to be able to create mesh, material and texture files and a prefab containing them.

At last I had to polish the sum into a releasable product by refactoring the source code, updating the artwork and the documentation. Finally, that whole process took about one and a half year. But as long as no such huge changes in the rendering routines of Unity will emerge once more in the near future updates of “Voxels: Rasterizer” should become more frequent again.

Voxels for Unity: Version 1.1

An update for my Unity plug-in has just been released at the Asset Store. It took me much more time to get a collection of new features and useful enhancements, which are worth to be published, than I had originally planned. Here are the key ones:

Voxels for Unity 1.1

  • Adaption to Unity 5.6 and 2017
  • Better results using PBR (physical based rendering) and HDR (high dynamic range)
  • Two fully working file exporter examples added: PLY (common point cloud format) and VOX (MagicaVoxel editor format)
  • Rasterizer enhanced by supersampling and multithreading options
  • API enhancement: Callback parameter to inform the executing script about the creation of new game objects
  • API extension: New class to decrease number of resulting materials in a processor to given amount
  • Multi-textured terrain included into the example scene
  • Bug fixes for minor issues

If you are interested in acquiring the extension to convert common Unity assets into Voxel objects or files, you can use the following link:

But if you have already purchased it or want to have a look into the manual before, here is the updated version:


 

Voxels for Unity: Release at the Asset Store

In fall the tool had been rejected by an administrator of the Unity Asset Store because they perceived it as a complete tool, which cannot compete with existing packages. Generated objects with high color variation had too many draw calls and the complete conversion process was taking too much time. After explaining that my extension focuses on the scanning step, that this step is done in a unique way by using the GPU so it would add a matchless feature to the store and that the generator scripts are only examples to show the ability to use it in existing or own frameworks, the administrator advised me to adopt the description, to change the title and maybe to include more examples. I really modified the statement and added a subtitle to underline the main function of the extension. But before I did a lot of work to improve some of the points, which had been criticized.

A mesh and a tree from the Asset Store had been converted to voxel objects. Half of a combined object had been voxelized and is displayed using a sphere for every cell.

First I tried to implement multi-threading and I could really accelerate the rasterizing by 100% for more complex tasks. Unfortunately sometimes there are errors in the result objects and I did not find the reason up to now. So I removed the option from the inspector but it is still available using an undocumented API command.
Next I included an iterator to access only filled cells and I changed the mesh processor script to utilize it. That way I improved the building time for voxel meshes. Moreover I added a new processor class to store coloration data into a 2D texture and implemented options in the mesh script to make use of them. Such data can also be stored per vertex now. Both ways are allowing the merge objects with high color variation much better and so massively reducing the draw calls. Thus I optimized the creation as well as the presentation.

As you can see in the manual I refactored the class Voxels.Converter to Voxels.Rasterizer because the former name rather described the whole execution. And I removed Voxel from scripts like Voxels.VoxelMesh so the duplicated labels vanished.

I resubmitted the package on Thursday. In fall it took about two weeks to get a rejection notification but this time “Voxel for Unity: Rasterizer” has gone live within a day and can be purchased at the Asset Store now.

Voxels for Unity: Tutorial

I added a tutorial video to YouTube. It shows how to add the extension to your objects, so they get converted to voxel meshes. Moreover you can see how to set up materials for best outcome and how important properties of the plug-in impact the result.



Please turn on the sub-titles, if you want to get more information!

COLLADA – A powerful file format for digital content creation

COLLADA is an XML file schema, which allows users to exchange 3D assets between various DCC applications like “Autodesk® 3ds Max®“, “Autodesk® Maya®” or “SOFTIMAGE®|XSI™” and other interactive 3D applications. It was originally initiated by Sony Computer Entertainment® America (SCEA) to create a development format for “PlayStation® 3” and “PlayStation® Portable” projects and became a standard of The Khronos Group, which also holds the OpenGL standard.

There are a lot of problems to transfer data from one 3D application to another, because every software uses proprietary file formats, which are optimally suited to the features the application supports. Most programs also support other file formats like “Wavefront Object“, which however can only store a small set from the features list. That way it is often only possible to convert model data like polygon meshes with a single texture coordinate set and more complex data like multiple texture sets or animations get lost. Even commercial converters are not able to translate every asset completely.
So for realtime 3D or game development programmers were forced to abstain from features, which were not supported by the file formats their team was using but which became more and more important with increasing game quality. Or you had to write an exporter or importer for every 3D application, which the artists were using. Just a single im- or exporter can be a lot of work.

A solution would be a standard file format that every application can read from and write to. The first attempt was “FBX®“, which is now owned by Autodesk®. It became free to use but a long time it does not solve important issues like exchanging multi-textures between programs because the existing plug-ins were not able to do that, even though the format itself could handle it. And there is no source code to extend the plug-ins by yourself. You still had to write your own for every application.
Today “FBX®” is the most common format for asset exchange between DCC applications but not important for game programming.

In October 2006 the COLLADA format had been published. It was and is open source, easily readable XML and extendable. But there were no plug-ins and no programming kits. Because “FBX®” has got a C++ SDK it was easier to write im- and exporters for that format than for COLLADA at this time. Fortunately some month later a SDK was released and the first plug-ins for programs appeared. Today many 3D applications support the format but not all major ones like “LightWave 3D®“, which we are using. However native support is announced unofficially for the current main version.

We have already implement a COLLADA file loader into a character animation plug-in for “Viz|Artist 3.0™” called “Action Model“. And currently I am using COLLADA as standard development format for “TigerHeart” II projects.
Files are being read using the SDK and converted to “TigerHeart” objects. These can now be modified using C++ and will also be changeable in a editor later. After that object data can be stored back without destroying original COLLADA data that was not converted or modified. In doing so multiple applications can access a COLLADA file, modifying its data without loosing something that was useless for a program. A sound editor may use some 3D data for setting effects but it cannot utilize textures. Although it does not destroy those texture objects by overwriting the original file at export time, because only new and modified data is updated to the COLLADA file database. That is no standard behavior for the COLLADA runtime but can be easily integrated using the SDK.

COLLADA has got also disadvantages. Because the format is very flexible, diverse programs can store their data differently. The programmer has to adapt his software for every utilized application. And even then an update of an application or its plug-in can force him to change his code. But this is being done lots of times faster than to write an im-/exporter for every proprietary file format.
Many common file formats have got the second downside. They are very slow to load and save because much data has to be interpreted multiple times. It does not really matter at editing time but loading time is essential for interactive programs and games. Programmers are able to accelerate reading texture file content using an own format and they also are able to do it with all other data. Generally speaking it is important to convert as few as possible and often to minimize bandwidth.
COLLADA files and other development assets could be converted before they are regularly used by the project or when they are finalized. That depends on the time you are saving during the development. In any case they should be converted before the product is delivered to the customer.

I believe that COLLADA will become the standard game development format one day, if no other competitive format occurs. Currently it is already utilized by some big names like Sony®, Google™, “3ds Max®”, “Maya®”, “Unreal® Engine” or “XSI™”.