Skip to content

Asset Pipeline Philosophy

Jump to bottom
Przemog1 edited this page Nov 2, 2020 · 2 revisions

The asset namespace

According to our plans to split the library into 1 lib per-namespace and have a strict dependency DAG between them, anything in the asset namespace can only depend on:

  • core
  • io (renamed to system in the future)
  • glsl (if we create such a namespace)

This is to ensure that assets are fully CPU objects, which can be manipulated without and irrespective of any video subsystem/implementation such as OpenGL, Vulkan, CUDA, OpenCL etc.

Its a hard requirement to enable offline preprocessing, or server-side manipulation on GPU-less servers.

What is an asset

The following are required properties of an asset:

  1. If it does not come from an extension (nbl::ext namespaces) then it must be serializable into/from .baw file format
  2. It must be referencable by at least one other asset type, unless its a "top level asset" (ICPUMesh and derived right now, as we move towards more data driven rendering, this would be a render-graph root)
  3. It must be a valid self-contained object independent of its "parents" (the assets that reference it), essentially if we cut the top of the asset DAG, we get valid independent DAGs.

BAW File Format Requirements (Non Archive Format)

The following also constrain the definition of an asset due to required property of an asset :

  1. There is only one root asset (can be any asset type)
  2. There are no "dead-ends", nothing not needed by the root asset is present in the file
  3. The full chain of dependent assets needed for a root asset are present
  4. There are no "logical gaps" in the chain above, i.e. all dependent assets can be chained up (there is no missing information) by the loader without programmer intervention or a-priori knowledge of any parameters or relationships.

Examples (not limited to):

  1. Only one ICPUMesh in the whole file
  2. If the root asset is an ICPUTexture then there are no ICPUBuffers that are not indirectly or directly refereced by that one ICPUTexture which is the root asset
  3. If root asset is ICPUMesh then an appropriate number IMeshBuffers is present with correct handles, and so are the ICPUBuffers etc. etc.
  4. The created ICPUTexture needs to reference the created CImageSubImageDatas which must themselved be valid assets on their own.
Clone this wiki locally