This article's documentation is for Source 2. Click here for more information.

Asset System: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
mNo edit summary
m (Small grammatical corrections)
 
(25 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Please note: this page is a work-in-progress.
{{source 2 topicon}}


The Asset System is the mechanism by which {{source2|4}} 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.


=Function=


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 modify, update, and verify game files.  
The asset system serves as the file manager for {{source2|4}}. 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. When a file changes, the Asset System picks up on that change, and can communicate to the tools the exact nature of the change.


==Features==
The asset system is also responsible for queuing the ResourceCompilerSystem to recompile assets as edits occur. This is true for most assets with the exception of maps whose lengthy compile process does not warrant immediate recompilation.  
-CRC verification for all files.  


-Integrated Mod and Addon Support


==Structure==
The asset system implements inheritance rules when it comes to projects and sub-projects. For example, when creating a workshop addon for {{hla|4}} 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.  
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.  


==Function==


The asset system serves as the file manager for Source 2. On the content side, it is what allows the engine tools to dynamically update assets as they are changed. Changes to assets fire events within the Asset System to which tools can subscribe and listen. 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 later verification. The tools can listen for these events and perform actions accordingly. 
=Structure=
 
The asset system is based upon a two-sided structure. The Content side is where assets are created and edited. The Game side is where the compiled assets are located.
The asset system is also responsible for recompiling assets as they change. This is true for most assets with the exception of maps, which are simply a collection of geometry and references to other assets. (A map does not need to be recompiled in order to reflect a model change.)


The engine cannot use the content-side assets directly. They are only ASCII files which allow the editor to make changes quite easily. (There are several exceptions - VMAP files contain DMX data for the level geometry) The editor then composites the raw data (meshes, images, etc.) into a final preview which is displayed. The game side is created when the asset compiler processes the content-side file, and outputs the final asset. The engine can then load and render the game-side asset.


==Content Side==
==Content Side==
On the content side are the uncompiled game files (.vmap, .vmdl, .vmat, .vpcf, [[VTEX (Source 2)|.vtex]], 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 ([[Wikipedia: FBX|FBX]] meshes, [[TGA]] and [[PNG]] textures, [[WAV]] and [[MP3]] sounds, etc.) 


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.) 
A content side file does not contain actual asset data. It is an ASCII file with references to the raw files. The file is then parsed by the compiler, which generates the game-side files from the raw files, and from the settings described in the content-side file. As such, it is better to think of a content-side file as a linking point for raw assets. In the case of a model, a .vmdl links together meshes, materials, attachments, and animation data, which the compiler will then export as a .vmdl_c. Similarly, a .vmat file links together the raw texture images used to create the material, and then exports a .vmat_c file.  
 
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 folders tend to be larger in file size than the game side because it contains the raw files that the content-side files depend on. These files are not directly used by the engine, and are generally not included in the VPKs when the game is shipped.


==Game Side==
==Game Side==
Game-side files are the files used by the engine and included in the VPKs when the game is compiled and shipped. They are  suffixed with ‘_c’ to denote that they are the compiled version of their content-side counterparts. They are much more space efficient, as they contain only the information required by the engine. Game-side files cannot be edited by the tools.


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.  
Asset Compilation in {{source2|4}} is a lot like turning source code into machine code. Execution is trivial, but it is not easy to make edits to the program after it has been compiled. The same applied to a game-side file. It can easily be rendered, but editing the file is very difficult.


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.
[[Category:Source 2]]

Latest revision as of 06:10, 19 July 2025

The Asset System is the mechanism by which Source 2 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.

Function

The asset system serves as the file manager for Source 2 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. When a file changes, the Asset System picks up on that change, and can communicate to the tools the exact nature of the change.

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


The asset system implements inheritance rules when it comes to projects and sub-projects. For example, when creating a workshop addon for Half-Life: Alyx 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 asset system is based upon a two-sided structure. The Content side is where assets are created and edited. The Game side is where the compiled assets are located.

The engine cannot use the content-side assets directly. They are only ASCII files which allow the editor to make changes quite easily. (There are several exceptions - VMAP files contain DMX data for the level geometry) The editor then composites the raw data (meshes, images, etc.) into a final preview which is displayed. The game side is created when the asset compiler processes the content-side file, and outputs the final asset. The engine can then load and render the game-side asset.

Content Side

On the content side are the uncompiled game files (.vmap, .vmdl, .vmat, .vpcf, .vtex, 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 and PNG textures, WAV and MP3 sounds, etc.)

A content side file does not contain actual asset data. It is an ASCII file with references to the raw files. The file is then parsed by the compiler, which generates the game-side files from the raw files, and from the settings described in the content-side file. As such, it is better to think of a content-side file as a linking point for raw assets. In the case of a model, a .vmdl links together meshes, materials, attachments, and animation data, which the compiler will then export as a .vmdl_c. Similarly, a .vmat file links together the raw texture images used to create the material, and then exports a .vmat_c file.

The content side folders tend to be larger in file size than the game side because it contains the raw files that the content-side files depend on. These files are not directly used by the engine, and are generally not included in the VPKs when the game is shipped.

Game Side

Game-side files are the files used by the engine and included in the VPKs when the game is compiled and shipped. They are suffixed with ‘_c’ to denote that they are the compiled version of their content-side counterparts. They are much more space efficient, as they contain only the information required by the engine. Game-side files cannot be edited by the tools.

Asset Compilation in Source 2 Source 2 is a lot like turning source code into machine code. Execution is trivial, but it is not easy to make edits to the program after it has been compiled. The same applied to a game-side file. It can easily be rendered, but editing the file is very difficult.

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Asset_System&oldid=485626"