das element’s Jonas Kluger breaks down the key steps to organzing your assets in the best way possible.
Let’s talk about asset management! Why do you want your assets organized?
They need to be quickly accessible and follow a unified pattern to smoothly integrate in the current task. In this article, we will discuss how we can achieve this and what issues need to be tackled along the way.
What are assets?
In the context of visual effects, an asset refers to any digital element or resource that is used in the production process. Assets can encompass a wide range of digital files and components that contribute to the overall visual enhancement of a project. These assets come in different types and can originate from different sources like previous projects, sent by clients or downloaded off the internet from third-party vendors.
We want to recycle existing work to save both time and money, which frees up time to focus on the creative part of our work. When everything is in an organized structure you will be well prepared and flexible with future changes.
For example, some VFX companies may work on ongoing long-term projects. Maybe a second season will be filmed in the future and it is wise to archive previous work. A well-managed asset library can be reused or repurposed across projects, saving time and money.
Another example would be that more and more tools are being released that use “AI” to generate images. These models are trained on massive amounts of data. It is important to notice that the better the training set the better the output. However, your data only becomes useful after organizing it into a format that can be used to teach the machine learning models.
The types of assets can range from elements like filmed footage or HDR images, animation rigs to 3D models with textures, shaders and simulation caches. Each one needs to be treated just a little bit differently in terms of proxy generation and we will discuss what needs to be taken into account and how organizing our asset library can be achieved.
Naming convention & folder structure
Every VFX company has different needs and workflows. However, the basic idea is always the same. You have some files which you want to place in a neat folder structure following a generally agreed scheme for folder and file names, aka. the naming convention.
This should sound very familiar when working on VFX shots. The same concept can be applied to an asset library. Having certain information in the file path, like the resolution of an element, can be helpful to get some basic information. However, it is wise to abstract more information like tags and metadata away from the file system and save these in a separate place. Similar to a project management software, the asset management tool will store most of its data in a database. As an artist you shouldn’t care where files are located. All you want to do is to interact with a user interface that contains all the information you need.
Separating the metadata from the files on disk allows you to have multiple categories for an element. If you would try to achieve this with a folder structure, you’d quickly run into issues. For example, take a movie file of a burning fireplace with a lot of smoke. Do you place it in the “fire” or in the “smoke” folder? Abstracting the tags and categories away from the file system allows you to easily deal with these cases.
It is important that files must not be renamed once they are ingested into the library. This avoids missing media when opening project files from years ago.
Single file vs. sequences
Another topic that is related to the naming convention is how the file is named on disk. We often deal with file sequences that include the frame counter in the file name. On the other hand we have movie files that do not require this frame counter. Pictures taken with an DSLR camera also have a sequential naming but the single image might not be related and needs to be added as individual files. However, sometimes they represent a sequence like bracketing images of an HDR or a stop-motion animation.
Unfortunately, it is not always clear what scenario we are dealing with. That’s why it is complicated to automate this task. At this point we still need the input from the user to tell the asset library how to deal with each of these cases. When adding an asset (like a matte painting) to the library that includes a frame counter in the file name, we might want to remove the frame counter since we no longer need it and to indicate to the artist that this is a single image. In other cases we want to keep the frame counter, even if it is only a single frame. There is unfortunately no definite answer as to what is the best solution for these cases since it is very much dependent on the company’s pipeline and workflows.
Example for single files: movie.mov / img_1001.jpg
Example for sequence naming: img.1001.jpg / img_1001.jpg
What is the exact file name of an element? There are different terms for files that can vary between operating systems and software applications.
We propose the following naming – let’s take this example file: img_1001.exr
Base name: img
Stem name: img_1001
File name: img_1001.exr
If the source is coming from our internal VFX pipeline, most of the time we want to remove the frame counter as well as any trailing characters like dots, hyphen or underscores to get the actual base name. When the images are coming from a DSLR camera we expect the file name to contain the frame number of the image (img_1234), otherwise we have multiple elements with the same name (img) and we can no longer differentiate them from one another.
In most cases we want to detect and show a warning if a file sequence has missing frames. However, when working with UDIM (U-Dimension) it is valid to have “missing frames” since the adjacent tiles are not named sequentially. Yet again, the user needs to tell the software how to deal with this scenario.
Category vs. tags
Let’s cover tags and categories. These are the keywords that artists will use to search for assets. We want to have different ways for a granular search of elements.
The processes in each VFX studio are somehow similar. The reason why we want to differentiate between all these categories, tags and synonyms is that we don’t have to reinvent the wheel over and over each time a studio wants to improve their asset management. Moreover, by using predefined terms we can avoid duplicated tags and spelling mistakes to keep your systems and database clean. There is no reason for two tags to exist if they both describe the same thing. Just think about singular or plural terms (fire & fires). They are the same thing, that’s why we can get rid of unnecessary duplications.
Categories are fixed classes that are persistent and will not change. A category is a class or division of things regarded as having particular shared characteristics like fire, smoke or debris.
You can use as many tags as you like to describe an asset. The tag (sometimes also called label) is attached to someone or something for the purpose of identification or to give other information. They can be considered dispensable, meaning “the more the better” in order to describe an asset as detailed as possible. Tags can tell you what you see, like smoke and fire, but can also be more descriptive like the quantity or the direction and speed (“fast at camera”).
Synonyms – same, same but different
The beauty of the VFX industry is that we come together from all over the world. Evolving on this union we want to find a common dictionary that unites all our languages and preferences. The asset library software “das element” for example, leverages descriptions and synonyms for each category from a public domain source.
Behind every Wikipedia page is one specific Wikidata item with a unique Wikidata identifier. The benefits from using data of this public domain knowledge base are description texts, synonyms and translations to different languages.
Since each category can be linked to one exact Wikidata page, we can unify one common understanding and vocabulary about what a certain category is called. No matter where you are from or what language you speak, you won’t have any issues finding the perfect element.
Wikidata is a central data storage behind the different Wiki projects. The Wikidata ID for each category looks something like this: Q3196 – This text is an identifier that can be used as a link to a human readable text in the Wikidata database.
Category hierarchy tree
Since most category names like smoke, fire and debris are commonly known to all artists around the world, “das element” built a system that underlines the importance of the understanding of this terminology. On one hand, the hierarchy tree is structured on the actual order of categories. On the other hand it is optimized for the commonly used vocabulary in the VFX industry. One concept is to organize everything into the top tier categories which makes the most sense for grouping certain types of elements like fire, smoke or destruction.
Since each category is linked to one another, we can visualize relationships between the categories to build an ontology and knowledge graph. In the future, this can help us to not only find similar assets that are currently available to use but also to come up with future machine learning based solutions.
Let’s have a look at the actual assets.
The source files can come in different file formats and file types. Ranging from old legacy film scan, like Cineon or DPX, as well as modern file formats that are not yet supported by most software applications, to anything found on the internet. In an ideal world we will get everything in the same file format and with the same colorspace. We don’t want artists having to deal with that sort of stuff. However, that is unfortunately not the case and achieving this is one of the biggest challenges to tackle.
The best practice is to get everything in the same file format and colorspace. This helps you to batch process all files in the future when newer systems like USD and MaterialX get integrated into your software applications.
These days, a good solution will be OpenEXR with the ACEScg colorspace. Converting movie files into a file sequence makes it easier to use for artists since each sequence can start at the same frame (e.g. 1001). Be aware, it will increase the required disk space. This needs to be taken into account for larger libraries or when you want to save everything in the Cloud.
For a quick preview of assets you want to generate thumbnails or, for example, a rendering of a turntable. You want to get an idea as well as a preview of what is happening inside a large movie or project file without having to open it. This just speeds up the process of working without having to wait until a big file is loaded with the corresponding software.
In some cases, a project file is an older software version and your studio might not have a license anymore. Or maybe the file is stored in some archive on LOT tapes and you are not certain if it’s even usable. Generating a good preview can save money, time and a lot of headaches.
The preview can have lower resolution, for example an 8 bit image like a simple jpg (or a newer version like HEIC) with Rec709 color space.
For video files it was quite common to use the H264 codec in a Quicktime container (.mov).
There are a few novel codecs that require less file sizes by producing better quality. E.g. HVV (aka h266) or AV1. Please be aware that newer codecs might not be supported by all applications and operating systems yet. To learn more – check out this article from Netflix.
Version & iterations
One thing to consider is how to deal with different versions and different variations.
An example for different versions would be a shot of a greenscreen. Version 0 (zero) could be the original material, Version 1 would be the first key. In some cases you want to rework the previous key due to some new keying techniques or similar. Now another artist will render out a new sequence that is called version 2. This concept sounds very similar from working on shots. It needs to be considered for an asset library as well.
Variations or iterations could be different resolutions for a 360° HDR image that might be saved in 4k, 8k or 16k resolution. They all have the same content but to increase performance when working with it, we want to switch between the different resolutions. Not to get confused with a proxy. A proxy for an HDR might be an 8 bit .jpg file, while the variations are still an .exr or .hdr. The same applies to different LODs (Level of Detail) for 3D assets.
Often you want to store additional arbitrary information for an asset, like the focal lens that an element was captured with. If you archive it for recent projects you might want to save data from your project management software, for example the show name, the artists or the facility that produced this asset.
When purchasing assets of the internet, it is also important to save the corresponding license information with that asset. Months or years down the line, no one might remember if you are allowed to use that asset for another project or if there are any other restrictions that need to be considered.
Depending on the file type, you are limited on the amount of metadata that can be linked to a file. Saving the metadata information in a database allows you to save as much information as you need.
UUID & ULID
When managing assets from multiple facilities of your company you want to keep track of when, where and by whom an asset was added to the library. Using the asset name can cause issues since names like “fire_0001“ can occur multiple times at different studios.
That’s why we can use so-called Universally unique identifier (UUID) to distinguish the different elements. These random generated IDs are unique across time and space and (depending on the version used) you can back reference when and where an element was ingested from.
If you save these IDs in the database, it is also wise to take a look at ULID (Universally Unique Lexicographically Sortable Identifier). 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 performance when querying information from the database.
Automation is great. However, there are some pitfalls that need to be avoided. One of the big issues of automation is human error and the naming of the source files. When a file is misspelled, it makes it hard to come up with a programmatically solution to capture certain mistakes.
Example: T_Grass_Sppecular.png with the word ‘Sppecular’ written with two “p“ instead of ‘Specular’. Or ‘Rougness.png’ instead of ‘Roughness’
Another problem is that file sequences can change their frame counter padding. For example from 3 (999) to 4 (1000). This often happens for sequences being rendered by Premiere Pro or After Effects. In most cases, these frames belong together, although that is not always the case.
It is also important to catch corrupt files before adding them to the asset library. When purchasing assets off the internet that come in ZIP files (or when copying a ZIP file), the extraction task can fail without anyone noticing and you end up with file sizes of 0kb. A simple file size check should help to deal with these cases.
Setting up an asset library for 3D assets is a huge endeavor with many pitfalls and let’s be honest, it is a lot more work than organizing 2D elements.
There are some 3d asset library tools out there, like Quixel Bridge and Kitbash Cargo. These tools work great because they use an already organized structure in the background from the vendors and their variety of assets. Using these systems work great as long as you stay within their ecosystem and don’t want to worry where and how your files are stored on disk.
If you need more control or want to organize assets from a different source, these systems no longer work as you have no control over their database. Yet again, you are stuck with finding an alternative and generic solution that offers you the flexibility to add any asset type you like.
If you already put in the effort to organize everything you should also consider doing it only once and be well prepared for the upcoming years. At the time of this article it will be a wise decision to explore the options that USD and MaterialX have to offer.
The 3D models come with different kinds of textures, each named differently but yet somehow it’s always the same kind of texture sets. A good practice is to get everything organized and unified to follow the same pattern. This makes it easier for artists to use the asset.
A 3D scene purchased from a vendor can contain either a single object with its corresponding textures or multiple assets with variations, e.g. like different shapes of pipes that can be used for 3D bashing. In the adjacent folders, there will be multiple textures, often with cryptic names for these assets and even in different resolutions like 2k, 4k, 8k.
Organizing all of these files into a neat structure can be a tedious task, even though it will save time for artists in the long run. Splitting up assets into individual files can help you down the line and speed up the process. Still, the initial time to set it up needs to be considered. To be honest, most of the elements might never be used in production again. On the other hand, it will save a lot of time when you are within crunch time and the assets are well organized. If you have the time and resources it is recommended to take care of your assets and set them up neatly.
From experience, the only way to automate this step is to use (Python) scripts to extract certain keywords to assign the texture files to its texture channel. In the script you can build some rule sets that allow you to batch process certain datasets of source material.
You should create previews of your 3D asset. This will speed up the time for artists to find and review them. Otherwise you spend too much time opening up your 3D application only to find out that it was the wrong file. A simple and less elegant option is to take a screenshot from the viewport to get an idea what a certain 3D file contains.
A more sophisticated approach would be to generate low resolution 3D models that include textures. Sometimes it is necessary to preview a model from a different angle to check if it’s useful for the current task.
Useful file formats are USDZ and GLB. USDZ is a variation of USD, with the big difference that all textures are merged into one single file, which makes it easier to manage the files on disk. An alternative is GLB (as a variant of glTF) which is already widely supported by web browsers and other applications.
The big challenge might be to create a low resolution version of your 3D model or scene. For large scale scenes it is often not possible to automatically reduce polygons of the 3D files as well as textures/shaders without having artists manually go in and manipulate the scene. Again, it is a question of time and resources that you want to spend on maintaining the library. There are some tools out there that can help with just that task like InstaLOD.
When adding new 3D assets, it is good practice to unify the scaling across all assets. It doesn’t quite matter as much what actual scale your company decides on, at least it should be the same across all files. Some studios choose a 1:10 scale (1 unit = 10cm).
Similar to OpenEXR sequences of 2D elements, using proxies for texture files allows you to quickly display a certain layer. The texture files can be small jpg or png files but can range to multiple gigabytes when working on high resolution textures for feature films.
It is highly recommended to look into the open standard MaterialX. The goal is to address the problem like assigning shading networks, patterns and textures to the corresponding geometry. This solution is useful when you want to be future proof.
There are other additional files like caches or VDB files that need to be stored alongside your assets. Again, investigating open file formats that are not software dependent can be a smart way to go in order to build a sustainable asset library for the coming years. In some cases you might be bound to a certain proprietary application. However, studios’ pipelines change over time and certain software packages might become obsolete.
About das element
The asset library software das element was first released in August 2021 by a company based in Munich, Germany. Rather than using one of the existing pieces of software that are roughly set to match as many needs and industries as possible, das element is molded to the requirements of studios.
Years of experience building and maintaining asset libraries went into developing this software. The focus is to combine the above mentioned concepts and take care of most of the issues that you will encounter along your way when building an asset library. Built with high industry standards, the software works completely offline which makes it great for air-gapped environments with tight security measures for feature films and TV series.
Due to its flexibility and configurability it can be used in a variety of user cases. From high end visual effects work, to fast paced commercial productions and even non VFX related projects like games or architecture visualization.
If you want to get a head start on managing your asset library you can find out more by visiting: www.das-element.comNeed After Effects and other VFX plugins? Find them at Toolfarm.