Ragora's Place

A place where things happen.

User Tools

Site Tools


documents:t2dts

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

documents:t2dts [2019/12/04 23:26] (current)
Robert MacGregor created
Line 1: Line 1:
 +====== Tribes 2 DTS Authoring ======
  
 +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.
 +
 +===== Working the Exporter =====
 +
 +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.
 +
 +==== Mesh Groups ====
 +
 +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.
 +
 +==== Empties ====
 +
 +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 ====
 +
 +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):
 +   * Transparency
 +
 +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.
 +
 +===== Notes =====
 +
 +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.
 +
 +==== Detail Groups ====
 +
 +Some shapes included with Tribes 2 count detail groups as such:
 +   * Detail2
 +   * Detail8
 +   * Detail16
 +   * Detail32
 +   * Detail64
 +
 +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.
documents/t2dts.txt · Last modified: 2019/12/04 23:26 by Robert MacGregor