Character Geometry File (.gcg)

Golaem Character Geometry (gcg) file is meant to replace FBX character geometry storage. It provides a huge speed boost over FBX, by skipping unnecessary features handled by the FBX format and enabling multithreaded processing. 

A GCG file stores the following data:

  • skeleton definition (bones joint orient and names)
  • A bindpose (position, orientation)
  • A pose to be displayed by default at import (position, orientation, scale)
  • A list of meshes. Each of the meshes holds its vertices positions / normals / UVs / skinning information, triangle definition, vertex caching (baked geometry) and blendshapes definitions.

Its definition can be found in the Golaem Geometry API SDK file glm_crowd_io.h, as GlmGeometryFile struct. It can be read/written via glmReadGeometryFile() & ​glmWriteGeometryFile() functions. The GlmGeometryFile struct must be reset to 0 priori to use it, for example via a memset.

Supported Features

The following features are supported in the GCG format:

  • linear, dual quaternions and blend skinning methods
  • mesh based blendshapes, in-between blendshapes, negative weight blendshapes
  • per face multi materials
  • vertex animation caches


The speed boost comes at a cost, and here are the limitations to use this format:

  • Bindpose unicity: the bindpose must be unique over the meshes exported
  • Blendshapes can only be based on deformed mesh targets. Driving other type of nodes with blendshapes is not handled and should be baked into meshes to work with Golaem.
  • Skeleton scales: the bindpose may have a scale only on root, any other bone must have a local scale at 1. The presentation (current pose) may have a scale on root only. This scale impacts the scale of the character at import.
  • Valid skinning: the skinning should be applied on bones defined in the Character File, mapped or not. However a fallback to parent bones in hierarchy is present.
  • Each geometry mesh can only have a single baked animation on it. It will be detected by Golaem via history and cacheFile nodes.
  • No deformers on meshes, that would impact vertices count between original and skinned mesh 
  • The GCG file does not store any shader information (anyway, this is matched at previz / render time through our asset management process)
  • Note on internal process : gcg does not handle more than a shader per mesh, thus multi-materials meshes will be split into several meshes at export time.
  • Cloth meshes should can be defined as multi-material : GCG splits multi-material meshes in several mono-material meshes internally. As cloth vertices come from third party Apex / nCloth, there is no simple way to split the output vertices in several meshes.