Exporting to Fbx: 3ds Max, Maya, and Blender

Important note on coordinate axes

As described in the "2.1. Coordinate axes" of the main guide, the truck is oriented along the OX axis in the game.
The OY axis is pointing up. The OZ axis is pointing to the left.

This orientation corresponds to the (x, y, -z) axes in Maya:

And, in 3DS Max, to the (x, z, y) axes:

In Blender, the axes are the same as in 3DS Max. So, the orientation of the game corresponds to the (x, z, y) axes orientation in Blender:

Thus, to correctly export your truck, the forward axis of your truck should be looking in the direction of the OX axis during the export.

Export Settings in your 3D editor should match the screenshots below exactely. Be sure to refer to the correct section that corresponds to your 3D editor software package.

After exporting, when you come to specify truck properties in XML, you should take into account the difference in orientation of the axes as described above.

For example:
If the coordinates of the center of the wheel of your truck in 3Ds Max or Blender are (1; 2; 3), then in the XML description of this wheel you need to specify "(1; 3; 2)" as the value of the Pos attribute:
Pos="(1; 3; 2)"

Preparing the scene in 3ds Max

In 3Ds Max, bones, helpers or meshes can be used as the skinning bones.
However, for the SnowRunner engine:

• a helper has no difference from a bone, indeed - it is just a frame.
• but, a mesh is viewed by this engine as a frame with a cdt object.

The SnowRunner engine uses two types of frames:

• Frames of the physical model (“physical frames”) - these frames must have a cdt shape.
• Non-physical frames - a non-physical frame cannot have a shape. It is also a must.

We recommend that you use one of the following approaches for setting up a truck in 3ds Max:

• Approach #1: Editable Poles for physical frames; Bones or helpers for non-physical frames.
• Approach #2: All frames can be made using bones. Necessary cdt-meshes should be added as children of corresponding bones. Names of these meshes should start with “cdt”.
• Approach #3: If you reuse the setup from MudRunner, then you need to remove shapes on the non-physical bones. For example, You can do this using the DeleteMesh modifier, for example.

Before export, we recommended that you use the Reset xForm utility for all objects.

All materials must have the correct names. Only Latin characters, digits, and “_" are allowed. Names should not contain special characters (with the exception of “_").

You only need to export skinned meshes, bones, and cdt meshes. Therefore, we recommend you to use Export > Export selection.

Export settings should be as follows:

Preparing the scene in Maya

The unit settings in the scene should be as follows:

Export settings:

Preparing the scene in Blender

NOTE: This document provides settings for Blender 2.82.

Scene settings

To ensure that the units in the scene and in the game both match, the settings in Blender should look like the following:

With these settings, the import of the fbx-template can be done with the default settings of the importer.

Setup of the truck

In the scene, the truck should be located in the direction of the X axis.

The orientation of the bones is important for the description of the truck behavior. Therefore, to achieve simpler and more convenient XML descriptions, we recommend you to build a skeleton using Keep Offset Parent.

Collision objects can be parented to physical bones as follows:

Armature

The architecture of the skeleton in Blender is different from the same architecture in most 3D tools. When exporting to Fbx, the system creates an additional Armature node, which is the root node of the skeleton. All skinned meshes are at the same level of hierarchy with this node.

The picture on the left displays the hierarchy after conversion from Maya or 3dsMax. The picture on the right shows the hierarchy in Blender.

Due to the creation of the additional Armature node, the engine converter cannot parent the skinned geometry under the root bone and so forcibly creates the RootNode node by itself.

Wrong workaround for the Armature issue

In XML, you can explicitly specify the root bone using the ModelFrame attribute. In this case the extra nodes will be ignored.

However, in the case of this approach, the root frame will actually remain in the spawn point, since the root node remains in place. So, the system will incorrectly identify the coordinates of the truck. This will lead to the incorrect operation (for example, in the game, the zones on the map will not open).

Correct workaround for the Armature issue

Nodes that are not described in XML are ignored (they are forcibly attached to the parent nodes). Therefore, we may consider the RootNode, which was created during conversion, as a root physical bone. To work correctly in Havok, this node must have a collision object. So, for correct operation, you need to change the hierarchy and re-parent the cdt mesh: move it from its current position under the root bone and put it at the level of hierarchy where the Armature skeleton is:

In fact, we will have the RootNode as a physical bone responsible for working in Havok and the BoneRootNodeSkin as a skinning-bone responsible for the deformation of the geometry.

In the case of this approach, an explicit description of the root bone in XML is not necessary, but if you want to do it, then you need to remember that the RootNode is always the root.

Export Settings

To avoid exporting unnecessary components, use Export Selected Objects and disable the addition of leaf bones. The settings for this are shown below: