Blue Mars COLLADA compatibility guide

From Blue Mars Developer Guidebook

Jump to: navigation, search
There are security restrictions on this article

Contents

Introduction

The Blue Mars COLLADA asset importer was initially developed based on the specific COLLADA syntax used in the .dae files created by the original ColladaMaya and ColladaMax exporters, developed by Feeling Software. Additional constraints and extensions were applied to the syntax, in order to support specific data requirements of the Blue Mars file formats and software.

The purpose of this document is to provide syntax details of the COLLADA .dae file format recognized and interpreted by the Blue Mars COLLADA asset importer. This information is intended primarily for use by programmers, who are developing exporters and file conversion tools for DCC software packages, to support asset creation for the Blue Mars MMVW.

This document assumes that the programmer has experience with the essentials of data representation in COLLADA, and is not meant to be a self-sufficient guide to COLLADA.



Structure of a Blue Mars COLLADA .dae file

All Blue Mars COLLADA .dae files have the required structure:

<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1"> ... </COLLADA>

where the ellipses characters (...) represent variable element content.

The first element is the standard XML declaration. Note that all text strings - such as those used for attribute names, ids, sids, etc. - must be in the ASCII subset of UTF-8, to ensure compatibility with various Blue Mars software, although this is not always strictly enforced by the Blue Mars COLLADA asset importer.

The second element is the COLLADA root element, which specifies the schema version. The Blue Mars COLLADA asset importer supports COLLADA schemas 1.4.0 and 1.4.1. Older (pre 1.4) versions of the schema are not supported. COLLADA schema 1.5 is not currently supported, but may be supported in the future.

The content of the COLLADA root element must contain one, and only one, of each of the following child elements, in any order:

<asset> ... </asset>
<library_images> ... </library_images>
<library_effects> ... </library_effects>
<library_materials> ... </library_materials>
<library_geometries> ... </library_geometries>
<library_visual_scenes> ... </library_visual_scenes>
<scene> ... </scene>

If the asset contains a skeleton, or a set of morph targets, then the COLLADA root element content must also contain one (and only one) of the following child element:

<library_controllers> ... </library_controllers>

If the asset contains character animation data, then the COLLADA root element content must also contain one (and only one) of the following child element:

<library_animations> ... </library_animations>

All other <library_types> elements, such as <library_cameras> or <library_lights>, are not supported by the Blue Mars COLLADA asset importer and will generally be ignored.



The <asset> element

The <asset> element has no attributes, and the content of the element should be:

<asset>
  <contributor>
    <author>asset_creator</author>
    <authoring_tool>DCC_name_and_version</authoring_tool>
    <comments>comments</comments>
    <source_data>original_asset_filepath</source_data>
  </contributor>
  <created>creation_date_time</created>
  <modified>last_modified_date_time</modified>
  <unit meter="0.01" name="centimeter"/>
  <up_axis>Z_UP</up_axis>
</asset>

where:

  • asset_creator should be the name of the artist and/or company which created the asset (ex. John Smith, Avatar Reality). The <author> element is optional, but recommended for identifying the original creator of the asset.

  • DCC_name_and_version should be the name and version of the software package(s) used to generate the asset and export the asset to the COLLADA .dae file (ex. Maya 2008 | ColladaMaya v3.05B). The <authoring_tool> element is optional, but strongly recommended, since the Blue Mars COLLADA asset importer may use this information to make software-dependent assumptions regarding the content and implementation of the .dae file.

  • comments may be any additional information to be included with the asset (ex. exporter options). The <comment> element is optional, and generally ignored by the Blue Mars COLLADA asset importer.

  • original_asset_filepath should be the filename and path of the original asset, in URI format (ex. file:///C:/Documents%20and%20Settings/User/bag.ma). The <source_data> element is optional, but recommended for identifying the original asset file from which the COLLADA .dae file was generated.

  • creation_date_time should be the date and time that the COLLADA .dae file was originally created, in the extended ISO8601 date/time format: yyyy-mm-ddThh:mm:ssZ (ex. 2009-04-22T07:02:59Z). The <created> element is required.

  • last_modified_date_time should be the date and time that the COLLADA .dae file was last modified, typically by a separate COLLADA conditioner. This date/time may be the same as the creation date. The <modified> element is required.

  • The <unit> element should represent that the asset units are in centimeters, since this is the base unit used for assets by the Blue Mars software. The <unit> element is required.

  • The <up_axis> element should represent that the asset was created with a Z-up orientation, since this is the orientation used in the Blue Mars software. The <up_axis> element is required.

For example:

  <asset>
    <contributor>
      <author>Leonardo DaVinci</author>
      <authoring_tool>Maya 2008 | ColladaMaya v3.05B</authoring_tool>
      <comments>ColladaMaya export options: bakeTransforms=1</comments>
      <source_data>file:///C:/Documents%20and%20Settings/Jason/Desktop/Models/hockey_mask.ma</source_data>
    </contributor>
    <created>2008-02-09T07:02:59Z</created>
    <modified>2008-02-09T07:02:59Z</modified>
    <unit meter="0.01" name="centimeter"/>
    <up_axis>Z_UP</up_axis>
  </asset>



The <library_types> element

The content of each of the <library_types> elements must consist of at least one child element of the specified type. For example:

<library_images>
  <image> ... </image>
  <image> ... </image>
  .
  .
  .
  <image> ... </image>
</library_images>

The following is a list of the supported <library_types> elements, and their corresponding child elements:

<library_images>         -->  <image>
<library_effects>        -->  <effect>
<library_materials>      -->  <material>
<library_geometries>     -->  <geometry>
<library_controllers>    -->  <controller>
<library_animations>     -->  <animation>
<library_visual_scenes>  -->  <visual_scene>



The <image> element

Each <image> element must have an id attribute:

<image id="string">

where string is the unique identifier used by other COLLADA elements to locate the <image>.

For example:

  <image id="bag_diffuse">

The content of each <image> element must consist of one, and only one, child element, which is an <init_from> element. The content of the <init_from> element is a URI or filepath, which contains the filename of the texture image:

<image id="string">
  <init_from>URI_or_path/filename</init_from>
</image>

For example:

  <image id="bag_diffuse">
    <init_from>file:///J:/Maya/Texture/bag.tif</init_from>
  </image>
  <image id="bag_diffuse">
    <init_from>C:\Maya\Texture\bag.tif</init_from>
  </image>

Note that for exporting specifically to Blue Mars, the texture image filename is the only part of the URI or filepath that is required in the <init_from> element content. Texture images in Blue Mars need to be placed in a game-specific, relative directory/folder location, which probably differs from the original location of the image file, as used in the DCC software. Thus, the Blue Mars COLLADA asset importer will automatically strip the schema, authority, and path information from the filepath in the <init_from> element, when generating a Blue Mars asset material (.mtl) file.

In addition, all texture images in Blue Mars are required to be in DirectDraw Surface (.dds) format, which must be separately created by the 3D artist, from the original texture map images. As a convenience feature, the Blue Mars COLLADA asset importer will automatically change the filename extension of all references to texture image files to .dds, when generating a Blue Mars asset material (.mtl) file.

For example, the <init_from> content:

file:///J:/Maya/Texture/bag.tif

would become:

bag.dds

Note that all texture images must be have a width and height, in pixels, which is a power of 2, such as 16x16, or 256x512.



The <effect> element

Each <effect> element must have an id attribute:

<effect id="string">

where string is the unique identifier used by other COLLADA elements to locate the <effect>.

For example:

  <effect id="bag_fx">

The content of the <effect> element is convoluted in design and can be overly complex. Fortunately, Blue Mars compatibility is limited to simple 2D texture maps and does not support nor require most of this complexity. The required content of the element is:

<effect id="string">
  <profile_COMMON>
    <newparam sid="surface_sid">
      <surface type="2D">
        <init_from>image_id</init_from>
      </surface>
    </newparam>
    <newparam sid="sampler_sid">
      <sampler2D>
        <source>surface_sid</source>
      </sampler2D>
    </newparam>
    .
    .
    .
    <technique sid="common">
      <lighting_model>
      .
      .
      .
      </lighting_model>
      <extra>
        <technique profile="FCOLLADA">
          <bump>
            <texture texture="sampler_sid" texcoord="bind_semantic"/>
          </bump>
        </technique>
      </extra>
    </technique>
  </profile_COMMON>
</effect>

The <newparam> elements : samplers and surfaces

A pair of <newparam> elements is required for each texture map used in the <effect> element: one is the sampler; the other is the surface.

<newparam sid="surface_sid">
  <surface type="2D">
    <init_from>image_id</init_from>
  </surface>
</newparam>
<newparam sid="sampler_sid">
  <sampler2D>
    <source>surface_sid</source>
  </sampler2D>
</newparam>

Each <newparam> element must have an sid attribute:

<newparam sid="string">

where string is the unique identifier used by other COLLADA elements to locate the <newparam>. For example:

  <newparam sid="bag_diffuse_sampler">

The surface <newparam> element consists of a single <init_from> element, the content of which should be the value of the id attribute of the <image> element, which specifies the image file for the texture map.

The sampler <newparam> element consists of a single <source> element, the content of which should be the value of the sid attribute of the corresponding surface <newparam> element.

The sid attribute, sampler_sid, of the sampler is used by the <lighting_model> (see below) to assign the texture map sampler to the appropriate component (eg. diffuse, specular, bump, etc.).

The <lighting_model> element

The following COLLADA lighting model elements are recognized by the Blue Mars COLLADA asset importer:

<constant> ... </constant>
<lambert> ... </lambert>
<phong> ... </phong>
<blinn> ... </blinn>

However, due to the more sophisticated and customized shader mechanics of the Blue Mars software, the basic type of the lighting model is actually irrelevant and ignored. The choice of lighting model only determines which lighting components (eg. diffuse, specular, etc.) can be defined for the <effect>:

  <constant> <lambert> <phong> <blinn>
<emission> yes yes yes yes
<ambient> no yes yes yes
<diffuse> no yes yes yes
<specular> no no yes yes
<shininess> no no yes yes
<transparent> yes yes yes yes
<transparency> yes yes yes yes

All other lighting component elements are not recognzied by the Blue Mars COLLADA asset importer and are ignored.

Note that the exact interpretation of these lighting components in the Blue Mars software will be dependent on the material/shader setup, as applied in the Sandbox2 editor. The purpose of the Blue Mars COLLADA asset importer is simply to attempt to interpret these components into a reasonably approximate equivalent in a Blue Mars material file, for use with the material editor in the Sandbox2 editor.

The content of the <lighting_model> element may contain one of each lighting component element type, depending on the specific lighting model:

<lighting_model>
  <emission> ... </emission>
  <ambient> ... </ambient>
  <diffuse> ... </diffuse>
  <specular> ... </specular>
  <shininess> ... </shininess>
  <transparent> ... </transparent>
  <transparency> ... </transparency>
</lighting_model>

Each of the lighting component elements should contain a single child element. The allowed type of child element is dependent on the lighting component.

The <emission>, <ambient>, <diffuse>, and <specular> elements may contain a single <color> element, which specifies a 4-channel RGBA floating point value. All RGBA values are normalized, such that 0 = no color, and 1 = full intensity. The alpha value should always be set to 1.

<emission>
  <color>r g b 1</color>
</emission>

<ambient>
  <color>r g b 1</color>
</ambient>

<diffuse>
  <color>r g b 1</color>
</diffuse>

<specular>
  <color>r g b 1</color>
</specular>

The <diffuse> and <specular> elements may contain a single <texture> element, to specify the use of a texture map.

<diffuse>
  <texture texture="sampler_sid" texcoord="bind_semantic"/>
</diffuse>

<specular>
  <texture texture="sampler_sid" texcoord="bind_semantic"/>
</specular>

The texture attribute, sampler_sid, should be set to the value of the sid attribute of the sampler <newparam> element, which references the texture map image. The texcoord attribute, bind_semantic, is not strictly required by the Blue Mars COLLADA asset importer, inasmuch as it is used inconsistently by early COLLADA exporters. Currently, the Blue Mars COLLADA asset importer will ignore it, so it may be set to any value.

The <shininess> element should contain a single <float> element, which specifies a value between 0 and 255. The default value for this component should be set to 10 when exporting assets for use with the Blue Mars software.

<shininess>
  <float>value</float>
</shininess>

The <transparent> and <transparency> elements

The <transparent> element is required for all lighting models, even for completely opaque materials. Each <transparent> element must have an opaque attribute. For materials which are completly opaque, the opaque attribute may be set to either A_ONE or RGB_ZERO. For materials which are partially, or fully transparent, or utilize a transparency map, the opaque attribute must always be set to A_ONE, since the Blue Mars software does not support the RGB_ZERO transparency model.

For completely opaque materials, the content of the <transparent> element should be a single <color> element. The content of the <color> element should always be set to 0 0 0 1.

<transparent opaque="A_ONE">
  <color>0 0 0 1</color>
</transparent>

or

<transparent opaque="RGB_ZERO">
  <color>0 0 0 1</color>
</transparent>

For partially or fully transparent materials, the content of the <transparent> element may be a single <color> element, or a single <texture> element.

When using a <color> element, only the alpha component of the <color> element's RGBA content is actually used, where a value of 0 indicates fully transparent, and a value of 1 indicates fully opaque.

<transparent opaque="A_ONE">
  <color>0 0 0 alpha</color>
</transparent>

Independent transparency texture maps are not supported by the Blue Mars software, but, rather must be incorporated into the diffuse texture map, in the alpha, or mask, channel of the RGBA texture map image, such that a normalized alpha value of 0 (black) indicates fully transparent and a value of 1 (white) indicates fully opaque. The existence of the <texture> element, in the <transparent> element, is used as a simple flag, to indicate to the Blue Mars COLLADA asset importer that a transparency map channel exists in the diffuse texture map.

<diffuse>
  <texture texture="diffuse_RGBA_image_sampler_id" texcoord="bind_semantic"/>
</diffuse>

<transparent opaque="A_ONE">
  <texture texture="diffuse_RGBA_image_sampler_id" texcoord="bind_semantic"/>
</transparent>

The <transparency> element should contain a single <float> element, which specifies a value between 0 and 1. When processed by the Blue Mars COLLADA asset importer, this value is applied as a multiplier to the transparency values derived from the <transparent> element. Generally, as the value of <transparency> approaches 0, the material will become more transparent.

<transparency>
  <float>value</float>
</transparency>

The <extra> element : bump mapping

Bump, or normal, mapping is not supported by the COLLADA 1.4 or earlier schemas. Feeling Software, during development of the original ColladaMaya and ColladaMax exporters, added bump map support via the addition of an <extra> element, in their FCOLLADA profile. This became the early de facto standard for implementing bump map support in COLLADA, and is the method currently supported by the Blue Mars COLLADA asset importer.

The structure of the <extra> element is as follows:

<extra>
  <technique profile="FCOLLADA">
    <bump>
      <texture texture="sampler_sid" texcoord="bind_semantic"/>
    </bump>
  </technique>
</extra>

An example of the <effect> element

  <effect id="bag_fx">
    <profile_COMMON>
      <newparam sid="bag_diffuse_surface">
        <surface type="2D">
          <init_from>bag_diffuse_texture_image</init_from>
        </surface>
      </newparam>
      <newparam sid="bag_diffuse_sampler">
        <sampler2D>
          <source>bag_diffuse_surface</source>
        </sampler2D>
      </newparam>
      <newparam sid="bag_bump_surface">
        <surface type="2D">
          <init_from>bag_bump_texture_image</init_from>
        </surface>
      </newparam>
      <newparam sid="bag_bump_sampler">
        <sampler2D>
          <source>bag_bump_surface</source>
        </sampler2D>
      </newparam>
      <technique sid="common">
        <phong>
          <emission>
            <color>0 0 0 1</color>
          </emission>
          <ambient>
            <color>0 0 0 1</color>
          </ambient>
          <diffuse>
            <texture texture="bag_diffuse_sampler" texcoord="HANNEL"/>
          </diffuse>
          <specular>
            <color>0.8 0.8 0.8 1</color>
          </specular>
          <shininess>
            <float>10</float>
          </shininess>
          <transparent opaque="A_ONE">
            <texture texture="bag_diffuse_sampler" texcoord="HANNEL"/>
          </transparent>
          <transparency>
            <float>1</float>
          </transparency>
        </phong>
        <extra>
          <technique profile="FCOLLADA">
            <bump>
              <texture texture="bag_bump_sampler" texcoord="HANNEL"/>
            </bump>
          </technique>
        </extra>
      </technique>
    </profile_COMMON>
  </effect>



The <material> element

Each <material> element must have an id attribute:

<material id="string">

where string is the unique identifier used by other COLLADA elements to locate the <material>. For example:

  <material id="bag_material">

The content of each <material> element must consist of one, and only one, child element, which is an <instance_effect> element. The url attribute of the <instance_effect> element should reference an <effect> element in the <library_effects>, via its id attribute, prefixed by the # character.

<material id="string">
  <instance_effect url="#effect_id"/>
</material>

For example:

  <material id="bag_material">
    <instance_effect url="#bag_fx"/>
  </material>

Limitations on <material> elements

Due to internal limitations in the Blue Mars software, the number of materials per exported file may not exceed thirty-one (31) materials.



The <geometry> element

Each <geometry> element must have an id attribute:

<geometry id="string">

where string is the unique identifier used by other COLLADA elements to locate the <geometry>. For example:

  <geometry id="bag_geometry">

The content of the <geometry> element is another victim of COLLADA design overkill, emphasizing unnecessary flexibility and complexity over compatibility. Blue Mars compatibility is limited to a relatively strict subset of the possible <geometry> element content combinations and permutations. Thus, the content of each <geometry> element must adhere to the following structure:

<geometry id="string">
  <mesh>
    <source id="position_source_id">
    .
    .
    .
    </source>
    <source id="normal_source_id">
    .
    .
    .
    </source>
    <source id="texture_coordinate_source_id">
    .
    .
    .
    </source>
    <vertices id="vertices_id">
      <input semantic="POSITION" source="#position_source_id"/>
    </vertices>
    <primitives material="material_id" count="number_of_primitives>
    .
    .
    .
    </primitives>
  </mesh>
</geometry>

The <source> element

Blue Mars software requires all geometry vertices to have a position, a normal, and a texture coordinate (even if the object uses a single, solid colored material). All values are expected to be floating point values.

In COLLADA, these values are stored in the <source> elements, which must have the following structure for position and normal values:

<source id="source_id">
  <float_array id="source_array_id" count="number_of_array_values">x0 y0 z0 x1 y1 z1 x2 y2 z2 ... </float_array>
  <technique_common>
    <accessor source="#source_array_id" count="number_of_XYZ_coordinates" stride="3">
      <param name="X" type="float"/>
      <param name="Y" type="float"/>
      <param name="Z" type="float"/>
    </accessor>
  </technique_common>
</source>

For texture coordinate values, the <source> element must have one of the following structures:

<source id="source_id">
  <float_array id="source_array_id" count="number_of_array_values">s0 t0 p0 s1 t1 p1 s2 t2 p2 ... </float_array>
  <technique_common>
    <accessor source="#source_array_id" count="number_of_STP_coordinates" stride="3">
      <param name="S" type="float"/>
      <param name="T" type="float"/>
      <param name="P" type="float"/>
    </accessor>
  </technique_common>
</source>
<source id="source_id">
  <float_array id="source_array_id" count="number_of_array_values">s0 t0 s1 t1 s2 t2 ... </float_array>
  <technique_common>
    <accessor source="#source_array_id" count="number_of_ST_coordinates" stride="2">
      <param name="S" type="float"/>
      <param name="T" type="float"/>
    </accessor>
  </technique_common>
</source>
<source id="source_id">
  <float_array id="source_array_id" count="number_of_array_values">u0 v0 u1 v1 u2 v2 ... </float_array>
  <technique_common>
    <accessor source="#source_array_id" count="number_of_UV_coordinates" stride="2">
      <param name="U" type="float"/>
      <param name="V" type="float"/>
    </accessor>
  </technique_common>
</source>

The P value in the STP coordinate is ignored by the Blue Mars COLLADA asset importer.

The source attribute of the <accessor> element should use the id attribute, source_array_id, of the <float_array> element, prepended by the # character.

The value of the stride attribute multiplied by the value of the count attribute of the <accessor> element should be equal to the value of the count attribute of the <float_array> element.

Note: The Blue Mars COLLADA asset importer does have an option to create faux 2D texture coordinates for geometry which does not have these values. However, this option was primarily designed for use with pre-existing COLLADA .dae model files which cannot be rebuilt or regenerated with correct texture coordinates. The option works only for geometry which uses solid-colored materials.

The <vertices> element

The <vertices> element is simply an indirection reference for the position <source> element:

<vertices id="vertices_id">
  <input semantic="POSITION" source="#position_source_id"/>
</vertices>

where the source attribute of the <input> element should be set to the id attribute of the position <source> element, prepended by the # character.

The <primitives> element

The following COLLADA primitive collation elements are recognized by the Blue Mars COLLADA asset importer:

<triangles material="material_id" count="number_of_triangles"> ... </triangles>
<polygons material="material_id" count="number_of_polygons"> ... </polygons>
<polylist material="material_id" count="number_of_polygons"> ... </polylist>

<triangles> elements are the native primitive element used by the Blue Mars COLLADA asset importer; <polygons> and <polylist> elements are converted to <triangles> elements by a pre-processing triangulator step in the importer. Although the triangulator is robust, it is not recommended for general asset creation use, due to two (2) factors: (a) the number of triangles created may exceed the per object limits of the Blue Mars software, and (b) the results of the triangulator may not be optimal, esp. from an aesthetic point of view. It is recommended, therefore, that triangularization be performed prior to export, in the DCC software, where the results may be checked by the asset creator, prior to export to a COLLADA .dae file.

All <triangles>, <polygons>, and <polylist> elements are required to have a material attribute, which references the id attribute of a <material> element, and a count attribute, which indicates the number of triangles or polygons defined by the <primitives> element.

<triangles material="material_id" count="number_of_triangles">
<polygons material="material_id" count="number_of_polygons">
<polylist material="material_id" count="number_of_polygons">

The content of the <primitives> element is dependent on the primitive type and must be structured, accordingly, as follows:

<triangles material="material_id" count="number_of_triangles">
  <input semantic="VERTEX" source="#vertices_id" offset="0"/>
  <input semantic="NORMAL" source="#normal_source_id" offset="1"/>
  <input semantic="TEXCOORD" source="#texture_coordinate_source_id" offset="2" set="1"/>
<p>v0 n0 t0 v1 n1 t1 v2 n2 t2 ... </p>
</triangles>

<polygons material="material_id" count="number_of_polygons">
  <input semantic="VERTEX" source="#vertices_id" offset="0"/>
  <input semantic="NORMAL" source="#normal_source_id" offset="1"/>
  <input semantic="TEXCOORD" source="#texture_coordinate_source_id" offset="2" set="1"/>
  <p>p0v0 p0n0 p0t0 p0v1 p0n1 p0t1 p0v2 p0n2 p0t2 ... </p>
  <p>p1v0 p1n0 p1t0 p1v1 p1n1 p1t1 p1v2 p1n2 p1t2 ... </p>
  <p>p2v0 p2n0 p2t0 p2v1 p2n1 p2t1 p2v2 p2n2 p2t2 ... </p>
  .
  .
  .
</polygons>

<polylist material="material_id" count="number_of_polygons">
  <input semantic="VERTEX" source="#vertices_id" offset="0"/>
  <input semantic="NORMAL" source="#normal_source_id" offset="1"/>
  <input semantic="TEXCOORD" source="#texture_coordinate_source_id" offset="2" set="1"/>
  <vcount>vc0 vc1 vc2 ... </vcount>
  <p>v0 n0 t0 v1 n1 t1 v2 n2 t2 ... </p>
</polylist>

The <input> elements are references to the <vertices> element, and to the normal and texture coordinate <source> elements. The source attribute of the <input> elements should be set to the id attribute of the <vertices> element, or of the appropriate <source> element, prepended by the # character.

Limitations on <geometry> elements

  • The Blue Mars software is limited to a technical maximum of 65,535 vertices, normals, texture coordinates, triangles, etc. in a single object.
  • The Blue Mars file format units are in centimeters, with a XYZ resolution of 0.005 cm. This means that any vertices which have x, y, and z values within 0.005 cm of each other will be considered to be equivalent and may be merged together. Merging of vertices may result in degenerate triangles and result in errors in the Blue Mars software.

An example of the <geometry> element

  <geometry id="bag_geometry">
    <mesh>
      <source id="bag_geometry_position">
        <float_array id="bag_geometry_position_array" count="12">5.4 -5.4 0 0 5.4 0 -5.4 -5.4 0 0 0 5.4</float_array>
        <technique_common>
          <accessor source="#bag_geometry_position_array" count="4" stride="3">
            <param name="X" type="float"/>
            <param name="Y" type="float"/>
            <param name="Z" type="float"/>
          </accessor>
        </technique_common>
      </source>
      <source id="bag_geometry_normal">
        <float_array id="bag_geometry_normal_array" count="12">0 0 -1 1 0 0 -1 0 0 0 -1 0</float_array>
        <technique_common>
          <accessor source="#bag_geometry_normal_array" count="4" stride="3">
            <param name="X" type="float"/>
            <param name="Y" type="float"/>
            <param name="Z" type="float"/>
          </accessor>
        </technique_common>
      </source>
      <source id="bag_geometry_texcoord">
        <float_array id="bag_geometry_texcoord_array" count="6">0.0 0.0 1.0 0.0 1.0 1.0</float_array>
        <technique_common>
          <accessor source="#bag_geometry_texcoord_array" count="3" stride="2">
            <param name="U" type="float"/>
            <param name="V" type="float"/>
          </accessor>
        </technique_common>
      </source>
      <vertices id="bag_geometry_vertices">
        <input semantic="POSITION" source="#bag_geometry_position"/>
      </vertices>
      <triangles material="bag_material" count="4"> 
        <input semantic="VERTEX" source="#bag_geometry_vertices" offset="0"/>
        <input semantic="NORMAL" source="#bag_geometry_normal" offset="1"/>
        <input semantic="TEXCOORD" source="#bag_geometry_texcoord" offset="2" set="1"/>
        <p>0 0 0 1 0 1 2 0 2 0 1 0 1 1 1 3 1 2 0 3 0 2 3 1 3 3 2 1 2 0 2 2 1 3 2 2</p>
      </triangles>
    </mesh>
  </geometry>



The <controller> element

Each <controller> element must have an id attribute:

<controller id="string">

where string is the unique identifier used by other COLLADA elements to locate the <controller>. For example:

  <controller id="dress-skin">

The content of the <controller> element has two (2) forms, which are recognized by the Blue Mars COLLADA asset importer: one which is used to bind a skin to a skeleton; the other which is used to specify a set of morph targets.

The Blue Mars asset file format will only support a single skin/skeleton, or a single morph targets set, per file. Thus, the Blue Mars COLLADA asset importer will only process one skin binding <controller> element, and only one morph targets set <controller> element, per asset file.

The structure of the content of the skin binding <controller> element must be:

<controller id="controller_id">
  <skin source="#skin_geometry_id">
    <bind_shape_matrix>m0 m1 m2 m3 ... m15</bind_shape_matrix>
    <source id="joint_source_id">
    .
    .
    .
    </source>
    <source id="bind_pose_source_id">
    .
    .
    .
    </source>
    <source id="weight_source_id">
    .
    .
    .
    </source>
    <joints>
      <input semantic="JOINT" source="#joint_source_id"/>
      <input semantic="INV_BIND_MATRIX" source="#bind_pose_source_id"/>
    </joints>
    <vertex_weights count="number_of_vertices">
      <input semantic="JOINT" source="#joint_source_id" offset="0"/>
      <input semantic="WEIGHT" source="#weight_source_id" offset="1"/>
      <vcount>vc0 vc1 vc2 ... </vcount>
      <v>v0j0 v0w0 v0j1 v0w1 ... v1j0 v1w0 v1j1 v1w1 ... </v>
    </vertex_weights>
  </skin>
</controller>

The structure of the content of the morph targets set <controller> element must be:

<controller id="controller_id">
  <morph method="NORMALIZED" source="#base_geometry_id">
    <source id="target_source_id">
    .
    .
    .
    </source>
    <source id="weight_source_id">
    .
    .
    .
    </source>
    <targets>
      <input semantic="MORPH_TARGET" source="#target_source_id"/>
      <input semantic="MORPH_WEIGHT" source="#weight_source_id"/>
    </targets>
  </morph>
</controller>

The morph targets set <controller> element is used with a skin binding <controller> element. The source attribute of the <skin> element of the skin binding <controller> element should be set to the value of the id attribute of the morph targets set <controller> element, prepended by the # character.

The <source> element

Skin binding <controller> elements require three (3) <source> elements, which specify the skeleton joints, the bind pose matrix for each joint, and the per vertex per joint weight value.

The <source> element used to specify the skeleton joints must have one of the following structures:

<source id="source_id">
  <Name_array id="joint_array_id" count="number_of_joints">name0 name1 name2 ... </Name_array>
  <technique_common>
    <accessor source="#joint_array_id" count="number_of_joints" stride="1">
      <param name="JOINT" type="Name"/>
    </accessor>
  </technique_common>
</source>

<source id="source_id">
  <IDREF_array id="joint_array_id" count="number_of_joints">id0 id1 id2 ... </IDREF_array>
  <technique_common>
    <accessor source="#joint_array_id" count="number_of_joints" stride="1">
      <param name="JOINT" type="IDREF"/>
    </accessor>
  </technique_common>
</source>

The first structure uses the <Name_array> element, which references the skeleton joints via the name attribute of the <node> elements in the <visual_scene> element. The second structure uses the <IDREF_array> element, which references the skeleton joints via the id attribute of the <node> elements in the <visual_scene> element.

The <source> element used to specify the bind pose matrices must have the following structure:

<source id="source_id">
  <float_array id="bind_pose_array_id" count="16_x_number_of_joints">j0m0 j0m1 ... j0m15 j1m0 j1m1 ... </float_array>
  <technique_common>
    <accessor source="#bind_pose_array_id" count="number_of_joints" stride="16">
      <param name="TRANSFORM" type="float4x4"/>
    </accessor>
  </technique_common>
</source>

Each bind pose matrix is a 4x4 matrix, and there should be one bind pose matrix per joint. Thus, the value of the count attribute of the <float_array> should be equal to 16 multiplied by the number of joints.

The <source> element used to specify the per vertex per joint weight values must have the following structure:

<source id="source_id">
  <float_array id="weight_array_id" count="number_of_weight_values">w0 w1 w2 ... </float_array>
  <technique_common>
    <accessor source="#weight_array_id" count="number_of_weight_values" stride="1">
      <param name="WEIGHT" type="float"/>
    </accessor>
  </technique_common>
</source>

Morph targets set <controller> elements require two (2) <source> elements, which specify the morph target geometry, and a per target weight value. The Blue Mars software does not use the per target weight value, and it is ignored by the Blue Mars COLLADA asset importer, during processing.

The <source> element used to specify the morph target geometries must have the following structure:

<source id="source_id">
  <IDREF_array id="morph_target_array_id" count="number_of_targets">id0 id1 id2 ... </IDREF_array>
  <technique_common>
    <accessor source="#morph_target_array_id" count="number_of_targets" stride="1">
      <param name="MORPH_TARGET" type="IDREF"/>
    </accessor>
  </technique_common>
</source>

The structure uses the <IDREF_array> element, which references the morph target geometries via the id attribute of the <geometry> elements in the <library_geometries> element.

The <source> element used to specify the per target weight values must have the following structure:

<source id="source_id">
  <float_array id="morph_weight_array_id" count="number_of_targets">0 0 0 ... </float_array>
  <technique_common>
    <accessor source="#morph_weight_array_id" count="number_of_targets" stride="1">
      <param name="MORPH_WEIGHT" type="float"/>
    </accessor>
  </technique_common>
</source>

Since the Blue Mars software does not use the morph weights, it is sufficient to set the value to 0, for each morph target.

A partial example of the skin binding <controller> element

  <controller id="body_skin">
    <skin source="#body_geometry">
      <bind_shape_matrix>1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1</bind_shape_matrix>
      <source id="body_skin_joints">
        <Name_array id="body_skin_joints_array" count="62">Bone1 Bone2 Bone3 ... </Name_array>
        <technique_common>
          <accessor source="#body_skin_joints_array" count="62" stride="1">
            <param name="JOINT" type="Name"/>
          </accessor>
        </technique_common>
      </source>
      <source id="body_skin_bind_poses">
        <float_array id="body_skin_bind_poses_array" count="992">1 0 0 0 0 1 0 0 0 0 1 100.0 0 0 0 1 ... </float_array>
        <technique_common>
          <accessor source="#body_skin_bind_poses_array" count="62" stride="16">
            <param name="TRANSFORM" type="float4x4"/>
          </accessor>
        </technique_common>
      </source>
      <source id="body_skin_weights">
        <float_array id="body_skin_weights_array" count="4179">1 0 0 0 0 0 0 0 0 0.28 0 0.72 ... </float_array>
        <technique_common>
          <accessor source="#body_skin_weights_array" count="4179" stride="1">
            <param name="WEIGHT" type="float"/>
          </accessor>
        </technique_common>
      </source>
      <joints>
        <input semantic="JOINT" source="#body_skin_joints"/>
        <input semantic="INV_BIND_MATRIX" source="#body_skin_bind_poses"/>
      </joints>
      <vertex_weights count="1023">
        <input semantic="JOINT" source="#body_skin_joints" offset="0"/>
        <input semantic="WEIGHT" source="#body_skin_weights" offset="1"/>
        <vcount>5 5 8 7 7 8 ... </vcount>
        <v>1 1 7 2 2 ... </v>
      </vertex_weights>
    </skin>
  </controller>

A partial example of the morph targets set <controller> element

  <controller id="head_morph">
    <morph method="NORMALIZED" source="#head_base_geometry">
      <source id="head_morph_targets">
        <IDREF_array id="head_morph_targets_array" count="2">eyebrow_up_geometry jaw_down_geometry</IDREF_array>
        <technique_common>
          <accessor source="#head_morph_targets_array" count="2" stride="1">
            <param name="MORPH_TARGET" type="IDREF"/>
          </accessor>
        </technique_common>
      </source>
      <source id="head_morph_weights">
        <float_array id="head_morph_weights_array" count="2">0 0</float_array>
        <technique_common>
          <accessor source="#head_morph_weights_array" count="2" stride="1">
            <param name="MORPH_WEIGHT" type="float"/>
          </accessor>
        </technique_common>
      </source>
      <targets>
        <input semantic="MORPH_TARGET" source="#head_morph_targets"/>
        <input semantic="MORPH_WEIGHT" source="#head_morph_weights"/>
      </targets>
    </morph>
  </controller>
  <controller id="head_skin">
    <skin source="#head_morph">
      <bind_shape_matrix>1 0 0 0 0 1 0 2.0 0 0 1 100.0 0 0 0 1</bind_shape_matrix>
      <source id="head_skin_joints">
        <Name_array id="head_skin_joints_array" count="2">Bone1 Bone2</Name_array>
        <technique_common>
          <accessor source="#head_skin_joints_array" count="2" stride="1">
            <param name="JOINT" type="Name"/>
          </accessor>
        </technique_common>
      </source>
      <source id="head_skin_bind_poses">
        <float_array id="head_skin_bind_poses_array" count="32">0 0.1 0.9 3.5 0 0.9 0.2 9.2 1 0 0 0 0 0 0 1 ... </float_array>
        <technique_common>
          <accessor source="#head_skin_bind_poses_array" count="2" stride="16">
            <param name="TRANSFORM" type="float4x4"/>
          </accessor>
        </technique_common>
      </source>
      <source id="head_skin_weights">
        <float_array id="head_skin_weights_array" count="57">1 0.4 0.5 0.2 ... </float_array>
        <technique_common>
          <accessor source="#head_skin_weights_array" count="57" stride="1">
            <param name="WEIGHT" type="float"/>
          </accessor>
        </technique_common>
      </source>
      <joints>
        <input semantic="JOINT" source="#head_skin_joints"/>
        <input semantic="INV_BIND_MATRIX" source="#head_skin_bind_poses"/>
      </joints>
      <vertex_weights count="446">
        <input semantic="JOINT" source="#head_skin_joints" offset="0"/>
        <input semantic="WEIGHT" source="#head_skin_weights" offset="1"/>
        <vcount>1 1 1 1 ... </vcount>
        <v>1 0 1 0 1 0 ... </v>
      </vertex_weights>
    </skin>
  </controller>



The <animation> element

Each <animation> element must have an id attribute:

<animation id="string">

where string is the unique identifier used by other COLLADA elements to locate the <animation>. For example:

  <animation id="L_Thigh_node_transform">

The content of the <animation> element must have the following structure:

<animation id="animation_id">
  <source id="input_source_id">
  .
  .
  .
  </source>
  <source id="output_source_id">
  .
  .
  .
  </source>
  <source id="interpolation_source_id">
  .
  .
  .
  </source>
  <sampler id="sampler_id">
    <input semantic="INPUT" source="#input_source_id"/>
    <input semantic="OUTPUT" source="#output_source_id"/>
    <input semantic="INTERPOLATION" source="#interpolation_source_id"/>
  </sampler>
  <channel source="#sampler_id" target="node_id/transform"/>
</animation>

The <source> element

The <animation> element requires three (3) <source> elements, which specify the input (time), the output (transform), and the interpolation method.

The <source> element used to specify the input (time) must use the following structure:

<source id="source_id">
  <float_array id="input_array_id" count="number_of_time_steps">t0 t1 t2 ... </float_array>
  <technique_common>
    <accessor source="#input_array_id" count="number_of_time_steps" stride="1">
      <param name="TIME" type="float"/>
    </accessor>
  </technique_common>
</source>

The input to an animation are time steps. Time steps are specified in seconds, must start at 0 seconds, and must be uniformly spaced. Since animation in Blue Mars software uses a 30 frames per second (fps) rate, the time step increment must always be 0.033333 seconds (1/30 second).

The <source> element used to specify the output (transform) must use the following structure:

<source id="source_id">
  <float_array id="output_array_id" count="16_x_number_of_time_steps">t0m0 t0m1 ... t0m15 t1m0 t1m1 ... </float_array>
  <technique_common>
    <accessor source="#output_array_id" count="number_of_time_steps" stride="16">
      <param name="TRANSFORM" type="float4x4"/>
    </accessor>
  </technique_common>
</source>

The output from an animation are transforms. Transforms are 4x4 matrices, applied to a <node> element, specified by the <channel> element of the <animation> element.

Note that the value of the count attribute of the <float_array> element should be 16 multiplied by the number of time steps.

The <source> element used to specify the interpolation method must use the following structure:

<source id="source_id">
  <Name_array id="interpolation_array_id" count="number_of_time_steps">LINEAR LINEAR ... </Name_array>
  <technique_common>
    <accessor source="#interpolation_array_id" count="number_of_time_steps" stride="1">
      <param name="INTERPOLATION" type="Name"/>
    </accessor>
  </technique_common>
</source>

The only interpolation method supported by the Blue Mars software is linear interpolation, so every value in <Name_array> element should be LINEAR.

The <channel> element

The target attribute of the <channel> element uses an irregular construct:

target="node_id/transform"

node_id is the value of the id attribute of the <node> element, which is being animated, in the <visual_scene>. The node_id must be postfixed with the string "/transform".

A partial example of the <animation> element

  <animation id="L_Thigh_node_transform">
    <source id="L_Thigh_node_transform_input">
      <float_array id="L_Thigh_node_transform_input_array" count="301">
        0 0.033333 0.066667 0.1 0.133333 ... </float_array>
      <technique_common>
        <accessor source="#L_Thigh_node_transform_input_array" count="301" stride="1">
          <param name="TIME" type="float"/>
        </accessor>
      </technique_common>
    </source>
    <source id="L_Thigh_node_transform_output">
      <float_array id="L_Thigh_node_transform_output_array" count="4816">0.9 0.1 0.1 0 0.1 0.9 0 0 0.1 0.1 0.9 7.9 0 0 0 1 ... </float_array>
      <technique_common>
        <accessor source="#L_Thigh_node_transform_output_array" count="301" stride="16">
          <param name="TRANSFORM" type="float4x4"/>
        </accessor>
      </technique_common>
    </source>
    <source id="L_Thigh_node_transform_interpolations">
      <Name_array id="L_Thigh_node_transform_interpolations_array" count="301">LINEAR LINEAR LINEAR ... </Name_array>
      <technique_common>
        <accessor source="#L_Thigh_node_transform_interpolations_array" count="301" stride="1">
          <param name="INTERPOLATION" type="Name"/>
        </accessor>
      </technique_common>
    </source>
    <sampler id="L_Thigh_node_transform_sampler">
      <input semantic="INPUT" source="#L_Thigh_node_transform_input"/>
      <input semantic="OUTPUT" source="#L_Thigh_node_transform_output"/>
      <input semantic="INTERPOLATION" source="#L_Thigh_node_transform_interpolations"/>
    </sampler>
    <channel source="#L_Thigh_node_transform_sampler" target="L_Thigh_node/transform"/>
  </animation>



The <visual_scene> element

The <visual_scene> element must have an id attribute:

<visual_scene id="string">

where string is the unique identifier used by <scene> element to locate the <visual_scene>. For example:

  <visual_scene id="default_scene">

The content of the <visual_scene> element consists of one or more root <node> elements:

<visual_scene id="visual_scene_id">
  <node id="node_id" name="node_name" type="node_type">
  .
  .
  .
  </node">
  <node id="node_id" name="node_name" type="node_type">
  .
  .
  .
  </node">
  .
  .
  .
</visual_scene>

The <node> element

The <node> element must have an id attribute:

<node id="string">

where string is the unique identifier used by other COLLADA elements to locate the <node>.

The <node> element may also have a name attribute, which is used to identify and enable certain Blue Mars software features, such as physics proxies and occlusion objects. Please refer to the Using the Blue Mars COLLADA asset importer documentation for more information.

The <node> element may also have a type attribute, which may be set to either NODE or JOINT. <node type="JOINT"> elements are used to define skeletons. If the type attribute is not explicitly specified, then the type defaults to NODE.

For example:

  <node id="Teapot_node">

  <node id="Teapot_proxy_node" name="Teapot_proxy">

  <node id="Teapot_proxy_node" name="Teapot_proxy" type="NODE">

  <node id="L_Thigh_node" name="L_Thigh" type="JOINT">

The <node> element may contain any, or all, of the following child elements:

  • one <matrix> element; or one or more <translate>, <rotate>, and/or <scale> elements
  • one <instance_geometry> element; or one <instance_controller> element
  • one or more <node> elements

The <matrix> element

The Blue Mars COLLADA asset importer allows for one, and only one, transformation <matrix> element to be specified per <node> element. The <matrix> element cannot be mixed with <translate>, <rotate>, and <scale> elements in a <node> element.

The <translate>, <rotate>, and <scale> elements

The Blue Mars COLLADA asset importer will process a series of order-dependent <translate>, <rotate>, and <scale> elements into a transformation matrix. The <translate>, <rotate>, and <scale> elements cannot be mixed with a <matrix> element in a <node> element.

The <instance_geometry> element

The Blue Mars COLLADA asset importer recognizes only one <instance_geometry> element per <node> element.

The <instance_geometry> element must use the following structure:

<instance_geometry url="#geometry_id">
  <bind_material>
    <technique_common>
      <instance_material symbol="material_id" target="#material_id"/>
      .
      .
      .
    </technique_common>
  </bind_material>
</instance_geometry>

In the <instance_geometry> element, the value of the url attribute should be set to the id attribute of the appropriate <geometry> element, from the <library_geometries> element, prepended by the # character.

The <technique_common> element must contain one or more <instance_material> elements.

In the <instance_material> element, the value of the target attribute should be set to the id attribute of the appropriate <material> element, from the <library_materials> element, prepended by the # character. The symbol attribute is ignored by the Blue Mars COLLADA asset importer.

The <instance_controller> element

The Blue Mars COLLADA asset importer recognizes only one <instance_controller> element per <node> element.

The <instance_controller> element must use the following structure:

<instance_controller url="#controller_id">
  <skeleton>skeleton_root_node_id</skeleton>
  <bind_material>
    <technique_common>
      <instance_material symbol="material_id" target="#material_id"/>
      .
      .
      .
    </technique_common>
  </bind_material>
</instance_controller>

In the <instance_controller> element, the value of the url attribute should be set to the id attribute of the appropriate <controller> element, from the <library_controllers> element, prepended by the # character.

In the <skeleton> element, the content of the element should be set to the id attribute of the skeleton root <node> element in the <visual_scene> element.

The <technique_common> element must contain one or more <instance_material> elements.

In the <instance_material> element, the value of the target attribute should be set to the id attribute of the appropriate <material> element, from the <library_materials> element, prepended by the # character. The symbol attribute is ignored by the Blue Mars COLLADA asset importer.

Limitations on <visual_scene> elements

  • Scaling factors in <matrix> elements and/or the use of <scale> elements is allowed by the Blue Mars COLLADA asset importer, but strongly discouraged, inasmuch as it might cause unexpected problems in the Blue Mars software. It is recommended that all scaling transformations be pre-baked into the position values of the vertices before export.

A simple example of the <visual_scene> element

  <visual_scene id="default_visual_scene" name="bag">
    <node id="bag_node" name="bag_node" type="NODE">
      <matrix>1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1</matrix>
      <instance_geometry url="#bag_geometry">
        <bind_material>
          <technique_common>
            <instance_material symbol="bag_material" target="#bag_material"/>
          </technique_common>
        </bind_material>
      </instance_geometry>
    </node>
  </visual_scene>

A partial skeleton example in the <visual_scene> element

  <visual_scene id="default_visual_scene" name="Jacket">
    <node id="Jacket_node" name="Jacket" type="NODE">
      <rotate sid="rotateZ">0 0 1 0</rotate>
      <rotate sid="rotateY">0 1 0 0</rotate>
      <rotate sid="rotateX">1 0 0 0</rotate>
      <instance_controller url="#Jacket_controller">
        <skeleton>skeleton_root_node</skeleton>
        <bind_material>
          <technique_common>
            <instance_material symbol="Jacket_material" target="#Jacket_material"/>
            <instance_material symbol="button_material" target="#button_material"/>
          </technique_common>
        </bind_material>
      </instance_controller>
    </node>
    <node id="skeleton_root_node" name="skeleton_root" sid="bone0" type="JOINT">
      <rotate sid="rotateZ">0 0 1 0</rotate>
      <rotate sid="rotateY">0 1 0 0</rotate>
      <rotate sid="rotateX">1 0 0 0</rotate>
      <node id="skeleton_c_node" name="skeleton_c" type="JOINT">
        <translate sid="translate">0 0 107.312</translate>
        <rotate sid="rotateZ">0 0 1 0</rotate>
        <rotate sid="rotateY">0 1 0 0</rotate>
        <rotate sid="rotateX">1 0 0 0</rotate>
        <node id="skeleton_l_node" name="skeleton_l" type="JOINT">
          <translate sid="translate">-28.4868 -16.589 -37.3234</translate>
          <rotate sid="rotateZ">0 0 1 0</rotate>
          <rotate sid="rotateY">0 1 0 0</rotate>
          <rotate sid="rotateX">1 0 0 0</rotate>
        </node>
        <node id="skeleton_r_node" name="skeleton_r" type="JOINT">
          <translate sid="translate">28.4868 17.3942 37.3234</translate>
          <rotate sid="rotateZ">0 0 1 0</rotate>
          <rotate sid="rotateY">0 1 0 0</rotate>
          <rotate sid="rotateX">1 0 0 0</rotate>
        </node>
      </node>
    </node>
  </visual_scene>
  



The <scene> element

The <scene> element has no attributes. The content of the <scene> element must consist of one, and only one, child element, which is an <instance_visual_scene> element pointing to the active visual scene:

<scene>
  <instance_visual_scene url="#visual_scene_id"/>
</scene>

where visual_scene_id should be the value of the id attribute of the active <visual_scene> element, in <library_visual_scenes>.



Build details

The Blue Mars COLLADA asset importer was built using COLLADA-DOM 2.2, compiled for COLLADA schema 1.4, using Visual Studio C/C++ 2005.



Reserved names

The Blue Mars COLLADA asset importer creates <extra> elements, with <technique profile="ARCRY">, to store intermediate data. This profile is thus reserved and should not be used when exporting data to Blue Mars.



Compatible DCC software and exporters

The DCC software packages and exporters listed below have been successfully tested for compatibility with the Blue Mars COLLADA asset importer.

  • Autodesk Maya 2008 with Feeling Software ColladaMaya 3.05B exporter plug-in
  • Autodesk 3ds Max 2008 with Feeling Software ColladaMax 3.05B exporter plug-in
  • Autodesk Maya 2009 with NetAllied Systems ColladaMaya NextGen 0.9.5 exporter plug-in
  • Autodesk 3ds Max 2009 with NetAllied Systems ColladaMax NextGen 0.9.5 exporter plug-in



Incompatible DCC software and exporters

The DCC software packages and exporters listed below have no, or limited, compatibility with the Blue Mars COLLADA asset importer, and are not generally recommended.

  • FBX DAE exporter plug-in for Autodesk Maya and Autodesk 3ds Max



Copyright © 2008-2009 Avatar Reality, Inc.


Return to Blue Mars Asset Creation

Problems with this wiki page? Contact us either by: Support Email or Support Ticket System

Blue Mars Guidebook Privacy Policy
Blue Mars Guidebook Community Guidelines

Personal tools