Sven van Huessen

Work / School / Year 2 / Block B

Asset Pipeline

This block I had to pick a topic, research it, program it, and write a blog post about it.

I chose to research the Asset Pipeline. This is an important part of a game engine. It is the process of importing, referencing, and exporting assets. This can be anything from 3D models to textures.

Below I will go over the steps of the Asset Pipeline and how I programmed it in my engine.

Importing

The first step starts by the artists. They create assets like textures and models in programs like Blender and Photoshop. These assets are then exported to a universal file format like .gltf or .png.

Then the artist want to see their assets in the game. But before they can do that, the assets need to be imported into the engine. To simplify this process I made a file browser window. This window shows all the files in the assets folder. The artist can then select the file they want to import.

Importing a .gltf

When importing, the engine does a couple of things:

  1. It checks if the file is already imported.
  2. Check if file format is supported.
  3. Load original "source" file into memory.
  4. Convert the file to a format that the engine can understand.
  5. Compress converted data and include meta data.
  6. Save the compressed data to the disk.
  7. Add the asset to the asset manager. And give it a unique ID.
  8. Asset is ready to be used in the game.

.gltf used in the engine

Referencing

Now that we have the assets imported into the engine, we want to be able to use them. In previous blocks I always just used a path to the asset. But this is not a good way to reference assets. Downside to using paths:

  • Assets might move.

    When the assets are moved to a different folder, the path is no longer correct. And would need to be updated in any script, asset, or scene that uses it.

  • Assets might be renamed.

    When the assets are renamed, the path is no longer correct.

  • Assets might be deleted.

    When the assets are deleted, the path points to nothing.

To solve this, every engine uses UUIDs (Universally Unique Identifier). This is a unique ID that is generated when the asset is imported. This ID is then used to reference the asset. This way the asset can be moved, renamed, or deleted without breaking the reference.

Exporting

The last step is exporting the assets. Combining everything into a single file that can then be included in the final build of the game. Engines might call this process "baking" or "packaging". This is where Asset Packs come in.

An Asset Pack is a single file that contains all the assets that are used in the game. This can be textures, models, sounds, etc. The compressed data is then put into a single file.

Asset Pack with metadata and compressed assets

Loading

Now that we have the Asset Pack, we can load it into the game!

Open Game, click play, scene loads, scene loading, scene still loading. Why is it taking so long? I just want to play the game!

It's loading all the assets! This is where Texture Compression comes in.

During the making of the asset pipeline, I noticed that loading assets can take quite a long time. Especially when loading high quality assets. I already talked a bit about compressing the assets when importing.

This is where my research on Texture Compression comes in. I got deeply interested in this topic and decided to write my blog post about it.

This blog can be read here. It goes over the different types of texture compression, how they work, pros and cons, and the speed-ups I got from implementing it.

DXT1 texture compression