Horde3D Content Pipeline
The content pipeline is responsible for bringing game assets (i.e. models, animations, textures, etc.) from a digital content creation (DCC) tool into the running game. The general content pipeline of Horde3D has three stages. Artists create assets in their preferred DCC application, for example Blender or 3D Studio Max. These source assets are exported into a standardized intermediate format using an exporter plugin that is available for the DCC tool. From the intermediate format, an optimized runtime format is generated using a special compiler that is part of the Horde3D package. This final runtime format conversion can usually be performed automatically in a content build process.
Generating the runtime data from an intermediate format brings some advantages over directly exporting the assets into the final format. An obvious benefit is that the runtime format can be changed and optimized without the need to manually reexport all assets. Furthermore, different platforms may require a slightly different representation of the same data (e.g. little endian vs. big endian). With an automated content build process, some special processing can be performed specifically for each platform which can lead to greatly reduced loading times.
It is highly recommended to store not only the original DCC application source files but also the intermediate files in some sort of database or revision control system, so that the runtime data can be regenerated at any time. Storing the runtime data in a version control system is usually not required, as it can always be generated again, for example automatically in a nightly build process.
Models and Animations
For models and animations, Horde3D uses COLLADA 1.4 as intermediate format. Artists export their models using an appropriate COLLADA exporter that comes with the DCC package or is available as a separate plugin. The tool ColladaConv which comes with Horde3D can be used to compile the data to the optimized runtime format expected by the Horde3D engine.
ColladaConv is a command line tool which means that it can easily be used in a more complex build process. When running ColladaConv, the first command line argument which is expected is an input file or directory. If a directory is specified, ColladaConv will recursively process all subdirectories as well and recreate the same directory structure for the output. To process all files in the repository, a single dot can be used as input parameter.
ColladaConv works in passes when generating the runtime asset data, so one resource type is processed at a time. This means that you can run ColladaConv first for compiling all models and after that for processing all animations. The resource type to be converted is specified with the command line argument -type.
With the argument -base, it is possible to specify the base content directory (repository) where the intermediate source assets are located. All resource paths generated by ColladaConv will be relative to that base directory. The argument -dest is used to specify the output directory to which all files generated by ColladaConv will be written.
Materials are often modified by hand or with a scene editor, so it is usually not desired that they get overwritten automatically. For that reason, ColladaConv will not overwrite existing materials, except it is forced to do so with the command line argument -overwriteMats.
ColladaConv models/man/man.dae -base C:\MyRepository -dest C:\MyContent -type model ColladaConv animations -base C:\MyRepository -dest C:\MyContent -type anim
The first command line above will compile the model man.dae. It is expected that the asset is located in C:\MyRepository\models\man. The generated files will be written to C:\MyContent\models\man. As all resource paths are relative to the base folder and do not contain absolute paths, the destination directory could always be renamed or relocated later without breaking any references.
The second command line will process the directory C:\MyRepository\animations and compile all DAE files which are located in that directory, including the ones which are in subdirectories. The exact same subdirectory structure will be created by ColladaConv in the destination folder. So for example, if the input folder contains a file animations/human/walk.dae, ColladaConv will create the file C:\MyContent\animations\human\walk.anim. It is hence possible to compile the whole (animation) repository with a single ColladaConv call.
Command Line Arguments
The following is a list of all supported command line arguments. All arguments are optional, except for the input which always has to be the first argument.
|input||asset file or directory to be processed; use . to process all files and subfolders in the base directory (required)|
|-type model|anim||asset type to be processed; can be model (default) or anim|
|-base path||base path where the repository root is located; all generated paths will be relative to the base directory|
|-dest path||destination path to which compiled assets are output (path must exist)|
|-noGeoOpt||disables geometry optimization|
|-overwriteMats||forces update of existing materials|
|-lodDist1 dist||distance for LOD1 (default: 10)|
|-lodDist2 dist||distance for LOD2 (default: 20)|
|-lodDist3 dist||distance for LOD3 (default: 40)|
|-lodDist4 dist||distance for LOD4 (default: 80)|
The converter has support for discrete level of detail (LOD) meshes. By default, a mesh is considered as base LOD (LOD0). To define simplified LODs, a special naming convention is used. Use the postfixes _lod1, _lod2, _lod3 or _lod4 at the end of a mesh name to define the corresponding LOD level. The converter will automatically remove the postfix from the name and assign the specified LOD level to the output mesh. The command line arguments lodDist1 to lodDist4 can be used to define the distances from which on a detail level is activated.
At the moment there are some restrictions for COLLADA files to be compatible with the converter: All geometry should be stored as triangle data and animations have to be exported as sampled keyframe data.
At the moment, Horde3D does not provide a conditioning pipeline for textures. Textures are directly loaded by the engine from one of the supported image formats.