This also means that the number of dependencies for the Qt libraries on the target system can be reduced.

When dealing with 3D assets, there is a need to process the assets created in digital content creation applications like Maya, 3ds Max, or Blender into a format that makes sense for the rendering engine.

This is analogous to 2D asset conditioning pipeline where a designer creates an image in Adobe Illustrator (an.ai file), and before you use it in your application you convert it to PNG format.

Assets created in digital content creation applications are typically stored in data formats that reflect the needs and capabilities of that tool, and not the application you intend to use them.

The saved file will likely contain an abundance of extra data that is not relevant to your application leading to a larger storage need, as well as more time to load and put into use at runtime.

As an example, if we look at the data stored in a Blender file (.blend) in addition to containing geometry data, there is information specific to the Blender editor and renderer.

Information like the layouts of the editor, undo stack, modifiers, levels of detail etc.

There is also other really expensive things like high polygon models that are sculpted and used for baking additional assets like normal maps.

So even for a very simple model the file saved by the editor could have much unnecessary data that just takes up space in your deployment bundle, and in some cases the data it has is not in the most efficient format for how we will use it.

These exporters are useful in the sense that they can strip out much of the excess data that is tool specific.

But while formats like COLLADA makes it easier to transfer 3D assets between content creation tools, they still dont store data in a format facilitating efficient loading and usage.

In addition, getting assets in the desired format is just not always possible.

For instance, receiving a 40 MB car model in OBJ format from the design department is less than ideal, to put it mildly, but sometimes unavoidable in practice.

It would be nice if developers could progress with the project regardless, without having to deal with asset loading times of several minutes.

So stripping the asset of unnecessary data, and converting what is left to a format that can be easily and efficiently used by the rendering engine.

It is now possible to use any of the above formats directly in your application at runtime, despite the inefficiency.

This is enabled by use of the Open Asset Import Library (libassimp).

We bundle this as a 3 rd party library with the Qt 3D module and provide a scene parser plugin that uses it to load a Qt 3D scene from an asset file.

This approach can be seen as using non-conditioned assets, or runtime conditioned assets, and will not be ideal for resource sensitive applications, especially on mobile and embedded platforms.

The glTF format like the COLLADA format is a Khronos-defined (draft) standard, but unlike COLLADA, glTF is designed for the efficient transmission and loading of 3D scenes and models for applications.

Assets bundled as glTF have geometry data, textures, and shaders all bundled in such a way that it is easy for Qt 3D to upload those assets to the GPU, and make use of them in the Qt 3D scene.

Because of this we choose glTF as the format to use for our asset conditioning tool.

It is a host tool in the same way as qmake or moc, in that is built and run on the host machine.

Collada To Gltf Converter For Mac