Difference between revisions of "Asset System"

From Valve Developer Community
Jump to: navigation, search
Line 28: Line 28:
 
It's better to think of content-side files as linking points for the raw source files used to create them. Most of the content-side assets require these source files in order to open properly. In the case of a model, the mesh, and material need to exist in order for the content-side file to load properly into the editor. The same goes for a material file. All of the textures and texture maps used to create that texture must be present in their raw forms. A compiled texture will not suffice, as that is a game-side file. A compiled material can use a compiled texture, but an uncompiled material cannot use a compiled texture.  
 
It's better to think of content-side files as linking points for the raw source files used to create them. Most of the content-side assets require these source files in order to open properly. In the case of a model, the mesh, and material need to exist in order for the content-side file to load properly into the editor. The same goes for a material file. All of the textures and texture maps used to create that texture must be present in their raw forms. A compiled texture will not suffice, as that is a game-side file. A compiled material can use a compiled texture, but an uncompiled material cannot use a compiled texture.  
  
The content side tends to be larger in file size because it contains all of the raw meshes used for models, as well as lossless TGA texture maps and other raw files that the content-side assets depend on. These assets are completely useless to the engine. Again, it’s better to think of the content-side files as linking points; they are references to raw files, which they themselves are compiled alongside the other assets.  
+
The content side tends to be larger in file size because it contains all of the raw meshes used for models, as well as lossless TGA texture maps and other raw files that the content-side assets depend on. These assets are completely useless to the engine. Again, it’s better to think of the content-side files as linking points; they are references to raw files, which are compiled into the final game-side assets.
  
 
==Game Side==
 
==Game Side==

Revision as of 04:21, 22 October 2020

The Asset System is the system by which Source 2 manages its files. An asset is any file that is used as part of a game, whether it be a model, mesh, texture, material, or map. The asset system is a key part of Source 2, and is what allows the engine and engine tools to read, write, update, and verify game files.

Features

  • CRC verification for all files.
  • Integrated Mod and Addon Support


Function

The asset system serves as the file manager for Source 2. It is what the engine uses to keep track of what resources are loaded into memory. It is also what allows the engine tools to dynamically update assets as they are changed. Changes to files fire events within the Asset System to which tools can subscribe and listen to. Each file in the content directory is monitored for changes. When a file changes, the Asset System picks up on that change and fires the appropriate events. It will also recalculate a CRC hash for verification in the case of data corruption.

The asset system is also responsible for queuing the ResourceCompilerSystem to recompile assets as they change. This is true for most assets with the exception of maps whose lengthy compile process does not warrant recompilation.


The asset system implements certain rules when it comes to projects and sub-projects. For example, when creating a workshop addon for Half-Life: Alyx the asset system creates special folders specifically for that addon. The addon inherits all of the existing assets found in the Half-Life: Alyx game directory (hlvr). Assets can be overridden, meaning that existing models, materials (and any other asset) can be changed by the addon and used instead of the original hlvr assets.


Structure

The structure of the Asset System is based upon the internal structure used by Valve for asset management in Source 1. It is split two different sides known as the Content Side and the Game Side.

Content Side

On the content side are the uncompiled game files (.vmap, .vmdl, .vmat, .vpcf, etc). These are the files that are edited by the engine tools to create the maps, models, textures, particle effects that the game will use. Additionally, this side contains all raw source files for these assets (FBX meshes, TGA textures, WAV and MP3 sounds, etc.)

It's better to think of content-side files as linking points for the raw source files used to create them. Most of the content-side assets require these source files in order to open properly. In the case of a model, the mesh, and material need to exist in order for the content-side file to load properly into the editor. The same goes for a material file. All of the textures and texture maps used to create that texture must be present in their raw forms. A compiled texture will not suffice, as that is a game-side file. A compiled material can use a compiled texture, but an uncompiled material cannot use a compiled texture.

The content side tends to be larger in file size because it contains all of the raw meshes used for models, as well as lossless TGA texture maps and other raw files that the content-side assets depend on. These assets are completely useless to the engine. Again, it’s better to think of the content-side files as linking points; they are references to raw files, which are compiled into the final game-side assets.

Game Side

Game-side files are the files actually used by the engine. These files are the files that will be compressed into the VPKs and shipped through the Steam app depot. They are usually suffixed with ‘_c’ to denote that they are the compiled version of their content-side counterparts. They are much more space efficient as they do not contain the raw dependencies required by the content-side files. They are also compressed and contain their own CRC hashes for validation.

Game-side files cannot be edited by the tools. They are natively viewable, but not editable as they are a binary file that is specific to the engine. They only contain enough data for the engine to use them properly. Additionally, these files tend to be standalone (with the exception of .vmat_c, which still depends on the compiled .vtex_c files). They do not include any of the necessary source files for editing.