DAE

COLLADA DAE (.dae) is a popular common model format. Because it can support model rigging, it is ideal for sharing rigged character models. Because it uses XML, a model's format can be viewed with any text editor, and the structure can be validated by comparing it with the official COLLADA DAE schema. The two most common versions of the DAE schema are 1.4 and 1.5.

DAE is one of the two preferred model formats on The Models Resource.

Limitations

Because of its XML structure, DAE models tend to have higher file sizes than other formats. Also, while not strictly a limitation of the format itself, some modeling programs use either loose or outdated interpretations of the schema when handling DAE models. This leads to models that seem to work fine for the original exporter but not in other programs.

Structure

Data is divided up into several "library" nodes and can be found in any sequence under the root node.

asset

The asset node contains various data about when the file was created, who created it, and which axis is up. This section is can usually be ignored.

library_images

The library_images node defines the texture paths for all images used by the model's materials. See the Texture Paths section for details on how to fix problems with these paths. If this section is empty or missing, it means the model will not load any textures at all and needs to be re-exported.

library_effects

The library_effects node defines properties for all of the model's materials, such as which colors and images to use. This section is important but is too complex to be manually fixed, so re-exporting is usually recommended.

library_materials

The library_materials node defines all of the material names. This section is important but doesn't usually have any problems.

library_lights

The library_lights node defines all of the light objects. If this node exists, it usually means that the scene was not cleaned before being exported. This section can be deleted if all of the light nodes in the scene are also removed.

library_cameras

The library_cameras node defines all of the camera objects. Like with lights, if this node exists, it usually means that the scene was not cleaned before being exported. This section can be deleted if all of the camera nodes in the scene are also removed.

library_geometries

The library_geometries node defines all of the model's meshes and their polygons. This is the largest section, containing all vertex points, UV coordinates, and sometimes even colors. It is possible to identify meshes with more than one UV map by looking for an input node with the semantic value "TEXCOORD" and a set value greater than zero. Editing this section is not recommended due to its complexity.

library_controllers

The library_controllers node defines all of the model's joints and rigging. Problems with joint binding can be found here, but editing this section is not recommended due to its complexity.

library_visual_scenes

The library_visual_scenes node defines the scene hierarchy, such as where each mesh is located and how it is oriented. The visual scene's nodes tie together materials and geometries defined in the other sections. Some model programs have been known to inappropriately use the same ID for both the scene itself and a node within the scene, resulting in problems when loaded to other programs.

scene

The scene node defines the scene being loaded. There is usually just one scene. This section can usually be ignored unless the ID of the scene node is being edited.

Common Problems

Wrong Format

As mentioned above, not all programs strictly adhere to the COLLADA DAE schema when creating models. This can lead to models loading with empty or broken materials, misplaced parts, or broken UVs. In the worst cases, the model will simply fail to load at all or crash the program. Users with knowledge of XML can attempt to fix these issues by validating the structure against the schema and correcting the errors it highlights.

Texture Paths

Some modeling software will use absolute file paths when defining the name of the texture. This will cause the textures to fail to load when the model is imported if the user does not have the exact same folder structure as the one defined in the model file. For the textures to be able to load properly, the file path should point to the texture's location relative to the model file.

Because DAE uses XML, it is possible to fix the issue using any text editor, such as Notepad or Notepad++, even if the user is not familiar with XML. Texture definitions are stored under the library_images node, which is usually located at the top of the file. Inside it is a series of image nodes, one for each texture being used, and inside each of those is a init_from node. The user simply has to change any absolute file paths to relative paths.

Before:

<init_from>
    <ref>C:\Users\Owner\Desktop\King Dedede\FitDedede_Hammer.png</ref>
</init_from>

After:

<init_from>
    <ref>FitDedede_Hammer.png</ref>
</init_from>

Note: Not all DAEs will use the exact structure given in this example, but it should still be obvious as to where the path is.