Currently, there is a DTS importer and exporter available for Blender 2.75b available here: https://github.com/portify/io_scene_dts
Install like any other Blender plugin and the exporting/importing of DTS shapes becomes available as well as importing DSQ external animation sequences. Unfortunately, it seems most shapes in Tribes 2 currently do not import at all due to importer bugs, but the exporter appears to work well enough.
From my current experience, non-animated shapes to be ported into Tribes 2 require very little engine specific rigging to work via the DTS exporter above. However, there is some things you have to do for the export to be valid.
The Tribes 2 engine requires that you have your rendered mesh in at least Detail32 to render as a no-collision object.
To add collision information, you simply add extra meshes to the blender scene and add them to group Collision-1 which the Tribes 2 engine interprets as the group where all collision information resides. Note that you generally should use only cubes, as while more sophisticated meshes do work, the engine will exhibit some bugs regarding collisions against such meshes.
There are various empties that the Tribes 2 engine will interpret in different ways for specific use cases. Remember that empties are not just positions but also rotations as well, so if things are facing the incorrect direction in-game, then perhaps check the afflicted empty's rotation.
Mount points are simply empties that the engine will use to determine where a given object will be mounted relative to the shape and these mount points are indexed in the scripting language with a simple integer. This integer is used to determine which mount point is referred to in the shape, whose name is subsequently mount# where # is the input integer. Therefore mount points follow the naming convention mount0, mount1, etc. Note that the game scripting assumes that for n player mountable points, you will rig the shape so that 0 to n mount points correspond to all mountable positions in the vehicle where mount0 is the pilot. Mounts n + 1 and onwards can be used for whatever else up to the maximum mount point count of 16.
Weapons use muzzlePoint which is simply what the name implies – all projectiles fired from the weapon will originate from this position in the direction the empty is facing.
Anything that will be mounted to objects as images will use an empty called mountPoint which is the point at which the the mounting shape will originate at. For example, if the mountPoint is on the hilt of the sword and when the weapon is given to someone, the weapon will be held in their hand by the hilt. If placed somewhere along the blade, then the weapon will be held by the blade instead. Just like muzzlePoint above, the rotation of the empty is important.
Materials ignore texture information specified within blender and instead opts for using the material name to lookup the base texture – therefore a material with a name of skins/vehicle_air_pyroguns will trigger the Tribes 2 engine to search for a texture skins/vehicle_air_pyroguns.png (or bmp) and render that for the geometry covered by a given material. Furthermore, the following material properties are actually paid attention to when exported (that I know of):
Furthermore, ensure that your textures have resolutions that are a power of two on both width and height because the Tribes 2 engine otherwise will attempt to resize them and break UV mappings in the process.
Written here are notes that don't fall into the above categories and are generally speculations or questions about the way the exporter/Tribes 2 engine behaves.
Some shapes included with Tribes 2 count detail groups as such:
However, Detail32 seems to be the only one (from my current porting experiences) that holds any sort of ground. Further, there are shapes included with Tribes 2 that appear to break this convention by using Detail_# instead where # isn't necessarily a multiple of 2.