Assets need to be quickly accessible and follow a consistent pattern so that we can complete our creative tasks efficiently. In this article, we take a closer look at how we can achieve this and what problems need to be solved along the way.

What are assets?

In the context of visual effects, an asset refers to any digital element or resource used in the production process. Assets can include a wide range of digital files and components that contribute to the overall visual enhancement of a project. There are different types of assets that can come from different sources, e.g. from previous projects, supplied by clients or downloaded from the internet by third-party providers.

It makes sense to reuse existing assets so that we can focus on the creative part of our work. If we bring these into an organised structure now, we are well prepared and can react flexibly to future changes.
For example, some VFX companies are working on ongoing long-term projects. Perhaps a second season will be shot in the future, so it is advisable to archive previous work. A well-managed asset library can be reused across projects, saving time and money.

Another example is that more and more tools are coming onto the market that use “AI” to generate images. These models are trained using large amounts of data. The better the training data, the better the result. However, this data only becomes useful when it is put into a format that can be used to learn the machine learning models.

The types of assets range from elements such as film footage or HDR images to animation rigs and 3D models with textures, shaders and simulation caches. Each of these elements needs to be treated a little differently in terms of proxy generation. Let’s take a look at what needs to be considered and how the organisation of our asset library can be achieved.

Naming convention and folder structure

Every studio has different needs and workflows. However, the basic idea is always the same. We have a number of files that we want to store in a clear folder structure that follows a commonly agreed scheme for folder and file naming, also known as a “naming convention”.

If you work on VFX projects, this should sound very familiar. The same concept can be applied to an asset library. Certain details in the file path, such as the resolution of an element, can be helpful to get some basic information. However, it is advisable to store additional information such as tags and metadata in a separate location rather than on the file system. Similar to project management software, the asset management tool also stores most of its data in a database. As an artist, however, it shouldn’t matter where the files are located. Artists just want to interact with a user interface that contains all the information they need.

For example, by separating the metadata of files on the server, we can assign multiple categories to an item. If we tried to map this with a folder structure, we would quickly run into problems. Take, for example, a film file of a burning fireplace with lots of smoke. Do we put it in the “Fire” folder or in the “Smoke” folder? If we abstract tags and categories from the file system, we can easily deal with such cases. It is also important that files are not renamed once they have been added to the library. This prevents the media from no longer being found when older project files are opened.

Single file vs. sequences

Another issue related to the naming convention is the way the file is named on the server. We are often dealing with file sequences that contain the frame counter in the file name. On the other hand, there are film files that do not need this frame counter. Images taken with a DSLR camera also have sequential naming, but the individual images may not be related and must be considered as individual files. In other cases, however, they represent a sequence, such as bracketing images of an HDR or a stop-motion animation.

Unfortunately, it is not always clear which scenario we are dealing with. Therefore, it is complicated to automate this task. At this point, we still need the user’s input to tell the asset library how to handle each of these cases. If we add an asset (e.g. a matte painting) to the library that contains a framecounter in the filename, we may want to remove the framecounter as we no longer need it and to indicate to the artist that it is a single frame. In other cases, we may want to keep the frame counter, even if it is a single frame. Unfortunately, there is no clear
Answer to the question of what is the best solution in these cases, as it very much depends on the company’s pipeline and workflows.

Example for single files:
movie.mov/img_1001.jpg
Example for a sequence:
img.1001.jpg/img_1001.jpg

What is the exact file name of an element? There are different names for files, which can vary depending on the operating system and software application. We suggest the following name:

img_1001.exr

Base name: img
Stem Name: img_1001
File Name: img_1001.exr

If the assets come from our internal VFX pipeline, in most cases we want to remove the frame counter and any subsequent characters such as dots, hyphens or underscores to get the actual base name. If the images come from a DSLR camera, we expect the file name to contain the frame number of the image (img_1234). If this were not the case, the files would all have the same name (img) and we would no longer be able to tell them apart.

In most cases, we want to recognise and display a warning if images are missing in a file sequence. With UDIMs (U-Dimension – more on this at FXGuide under is.gd/fxguide_udim), however, “missing frames” are permissible, as the neighbouring tiles are not named consecutively (texture.1001.exr, texture.1011.exr, etc.). Here too, the user must tell the software how to handle this scenario.

Category vs. tags

We want to have different options for a detailed search for elements. This is where tags and categories come into play. These are the keywords that artists will use to search for assets.
This process is similar in every studio. The reason we want to differentiate between all these categories, tags and synonyms is so that we don’t have to reinvent the wheel every time a studio wants to improve their asset management. Also, by using pre-defined terms, we can avoid duplicate tags and misspellings to keep our systems and databases clean. There is no need for two tags if they both describe the same thing. For example, singular or plural terms are often one and the same, so we can avoid unnecessary duplication.

Category: Categories are fixed classes that are constant and do not change. A category is a class or subdivision of things that have certain common characteristics, such as fire, smoke or explosions.

Tag: We can use as many tags as we want to describe an asset. A tag (sometimes called a label) is attached to a person or thing to identify it or to provide additional information. They can be considered dispensable, i.e. “the more the merrier”, to describe an asset in as much detail as possible. Tags can indicate what you see, e.g. smoke and fire, but also descriptive information such as the amount, direction and speed (“fast approaching the camera”).

Synonyms – same same but different

The beauty of the VFX industry is that we come together from all parts of the world. From this connection, we want to develop a common vocabulary that unites all our languages. The asset library software “das element”, for example, uses descriptions and synonyms for each category from a publicly accessible knowledge database.

Wikidata ID

Behind every Wikipedia page is a specific Wikidata entry with a unique Wikidata ID. The advantages of using data from this publicly accessible knowledge database are additional information such as descriptive texts, synonyms and translations into different languages.
Because each category can be linked to a unique Wikidata page, we can create a common understanding and vocabulary of what a particular category is called. No matter where you’re from or what language you speak, you’ll have no trouble finding the perfect item.
Wikidata (wikidata.org) is a centralised data repository for the various wiki projects. The Wikidata ID for each category looks something like this: Q3196 – This text is an identifier (ID for short) that can be used as a link to a human-readable text in the Wikidata database.

Tree diagrams of the category hierarchy

Since most category names such as smoke, fire and explosions are known to all artists around the are known to all artists around the world, the asset library software “das element” has developed a system that emphasises the importance of this terminology. On the one hand, the hierarchy tree is structured according to the actual order of the categories. on the other hand, it is optimised for the vocabulary commonly used in the VFX industry. One concept is to organise everything into super-categories, which makes the most sense for grouping certain types of elements such as fire, smoke or explosions.

As each category is linked to another, we can visualise the relationships between the categories to create an ontology and a knowledge graph. This can help us in the future not only to find similar assets that are currently available, but also to develop future solutions based on machine learning.

Assets

Let’s now take a look at the assets themselves. The source files can be in different file formats and file types. The spectrum ranges from old film Old film scans such as Cineon or DPX, to modern file formats that are not yet supported by most software applications, to anything that can be found on the internet Internet. In an ideal world, we get everything in the same file format and with the same colour space. We don’t want artists to have to deal with these things. Unfortunately, that’s not the case, and achieving this is one of the biggest challenges to overcome. It’s best to save everything in the same file format and colour space. This will make it easier for us to batch process all files in the future when newer systems like USD and MaterialX are integrated into our pipelines.

Today, a good solution is OpenEXR with the ACES colour space. Converting video files into image sequences makes it easier for artists to use, as each sequence can start with the same frame (e.g. 1001). But be careful! This increases the amount of memory required. This must be taken into account for larger libraries or if we want to store everything in the cloud.

For a quick preview of assets, we also want to create proxies or, for example, a rendering of a turntable. We want to get an idea and preview of what is happening in a large film or project file without having to open it. This speeds up the work process without having to wait for a large file to be loaded with the appropriate software.

In some cases, a project file is an older version of software that a studio may no longer have a licence for. Or maybe the file is stored in an archive on a LOT of tapes and you’re not sure if it’s even usable. A good preview can save money, time and a lot of headaches.

The preview can have a lower resolution, for example an 8-bit image like a plain JPEG (or a newer version like HEIC) with Rec709 colour space. For video files it was common to use the H264 codec in a Quicktime container (.mov). There are some new codecs that require less file size with better quality. E.g. HVV (also known as h266) or AV1. Please note that newer codecs may not yet be supported by all applications and operating systems.

Version & Iterations

You should consider how to deal with different versions and variants. An example of different versions would be a recording of a green screen. Version 0 (version zero) could be the original material, version 1 would be the first key. In some cases, you might want to rework the previous key due to new keying techniques or something similar. Now another artist will render a new sequence, which is called version 2. Similar to versioning renderings of VFX shots, this concept can also be applied to an asset library.

Variations can be different resolutions for a 360° HDR image that is available in 4k, 8k or 16k resolution. They all have the same content, but in order to work more efficiently, we want to switch between the different resolutions. However, variations should not be confused with proxies. A proxy for an HDR image can be an 8-bit jpg file, while the variations are still an .exr or .hdr file. The same applies to different LODs (Level of Detail) for 3D assets.

Metadata

Often we want to store any additional information about an asset, e.g. the lens an element was shot with. If we are archiving it for current projects, we may want to store data from our project management software, e.g. the name of the show, the artist or the location of the studio that created this asset.

When purchasing assets from the internet, it is also important to store the relevant licence information with the asset. Years later, no one may remember if you are allowed to use this asset for another project or if there are other restrictions you need to be aware of. Depending on the file type, the amount of metadata that can be linked to a file is limited. By storing the metadata in a database, we can store as much information as we want.

UUID & ULID

When managing assets from multiple studios within an organisation, we want to keep track of when, where and by whom an asset was added to the library. Using the asset name can lead to problems, as names such as “fire_0001” can occur multiple times in different studios.
We can therefore use so-called universally unique identifiers (UUID – is.gd/wiki_uuid) to differentiate between the various elements. These randomly generated IDs are temporally and spatially unique (depending on the version used) and we can trace back when and from where an element was entered. If we store these IDs in the database, it is also advisable to take a look at ULID (Universally Unique Lexicographically Sortable Identifier – more on this at github.com/ulid/spec). The big difference to UUID is that the timestamp is the front part of the ID, which makes the IDs alphabetically sortable. This can increase the performance of database queries.

Automation

Automation is great. However, there are some specifics that need to be considered. One of the biggest problems with automation is human error and the naming of source files. If a file is misspelled, it is difficult to find a solution with a Python script to catch certain errors. Example: T_Grass_Sppecular.png with the word “Sppecular” with two “p” instead of “Specular”. Or the spelling error “Rougness.png” instead of “Roughness”.

Another problem is that the frame counter can change in a continuous image sequence. For example, from 3 (999) to 4 (1000). This often happens with sequences that are rendered by Premiere Pro or After Effects. In most cases, these frames belong together, but this is not always the case.

Name.998.exr
Name.999.exr
Name.1000.exr
Name.1001.exr

It is also important to recognise corrupted files before adding them to the asset library. When buying assets from the internet that come in ZIP files (or copying a ZIP file), the extraction may fail without anyone noticing and we end up with file sizes of 0kb. A simple file size check should help to detect such cases. Some helpful tools are node-based systems that can be used to create automation pipelines. For example: Gaffer(gafferhq.org), NXT(is.gd/git_nxt) or iograft(iograft.com).

3D assets

Creating an asset library for 3D assets is a complex undertaking with many hurdles, and let’s face it, it’s a lot more work than organising 2D elements. There are a few software solutions for 3D asset libraries, such as Quixel Bridge(quixel.com/bridge) and Kitbash Cargo(is.gd/kitbash_cargo). These tools work great because they use an already organised structure in the background from the vendors and their variety of assets. Using these systems is only possible as long as you stay within their ecosystem and don’t want to worry about where and how the files are stored on your hard drive.

If you need more control or want to organise assets from a different source, these systems no longer work as you have no control over the database. Again, we need to find an alternative and generic solution that gives us the flexibility to add any asset type.

Technology

If you have already gone to the trouble of organising everything, you should also consider doing this just once and being well prepared for the years to come. It’s worth researching what options USD and MaterialX offer.

The 3D models come with different types of textures. These are often named differently, even though they represent similar things. Here too, it is recommended to structure and standardise everything so that it follows the same pattern. This makes it easier for artists to use the asset.
A 3D scene purchased from the internet can either contain a single object with associated textures or multiple assets with variations, e.g. different shapes of pipes that can be used for kitbashing. The supplied folders contain multiple textures, often with cryptic names and different resolutions such as 2k, 4k, 8k.

Organising all these files into a clear structure can be a tedious task, but will save artists time in the long run. Splitting assets into individual files can help us speed up the process. However, the initial time required to set it up needs to be considered. To be honest, most of the elements may never be used again in production. On the other hand, valuable time is saved in the crunch time if the assets are well organised
are well organised. If you have the time and resources, it is advisable to take care of the assets and organise them properly.
Experience has shown that the only way to automate this step is to use (Python) scripts to extract certain search terms and assign the texture files to the corresponding texture channels. In the script you can create some rule sets to process the files in a batch process.

Additional files and previews

It is worth creating previews of 3D assets. This way the artists can find them faster and get a simple preview. Otherwise you spend too much time starting the 3D software only to realise it was the wrong file. A simple and less elegant way is to take a screenshot of the viewport to get an idea of what a particular 3D file contains.
A more sophisticated approach would be to create 3D models with low resolution and textures. Sometimes it is necessary to look at a model from a different angle to check whether it is useful for the current task.

Useful file formats are USDZ (is.gd/usd_usdz) and GLB (is.gd/gltf_glb). USDZ is a variant of USD, with the major difference that all textures are merged into a single file, which makes it easier to manage the files on the server. An alternative is GLB (as a variant of glTF), which is already widely supported by web browsers and other applications.

The big challenge could be to create a low-resolution version of the 3D model or scene. For large scenes, it is often not possible to automatically reduce the polygons of the 3D files as well as the textures/shaders without artists having to edit the scene manually. Again, it’s a question of time and resources and what effort you want to put into the library. There are some tools like InstaLOD(instalod.com) that can help with exactly this task.

Scale of the scene

When adding new 3D assets, it makes sense to standardise the scaling for all assets. It doesn’t really matter which scale you choose, at least it should be the same for all files. Some studios choose a scale of 1:10 (1 unit = 10 cm).

Textures

Similar to OpenEXR sequences of 2D elements, using proxies for texture files allows you to quickly display a specific layer. The texture files can be small jpg or png files, but can also be several gigabytes in size if you are working on high-resolution textures for feature films. It is therefore advisable to familiarise yourself with the open standard MaterialX (materialx.org). The aim is to solve the problem of assigning shading and textures to the corresponding geometry. This approach can be useful if you want to be optimally equipped for 3D in the future.

Caches

There are other additional files such as cache or VDB files that need to be saved along with the assets. In some cases, you may be tied to a specific proprietary software. However, studio workflows change over time and certain software packages may become obsolete. Again, it’s worth looking at open source file formats that aren’t dependent on a specific software to build a sustainable asset library for years to come.

About das Element

The asset library software “das element” was first released in August 2021 by a software company based in Munich. Rather than using one of the existing software solutions that are broadly tailored to as many needs and industries as possible, “das element” is customised to the requirements of VFX studios.
Years of experience in building and maintaining asset libraries have gone into the development of this software.

The focus is on combining the above concepts and taking care of the problems you will encounter when building an asset library. Developed to the highest industry standards, the software works completely offline and is therefore ideally suited to the stringent security measures of feature films and television series. Due to its flexibility and configurability, it can be used in a wide range of applications. From high-end visual effects work to fast-paced commercial productions and even non-VFX related projects such as games or architectural visualisation. If you want to start managing your asset library, you can find more information at: www.das-element.com