Preparing the Mesh

I. Obtaining the Mesh

1. Open the 07_Head.scn provided with the VTM's.

2. Select and delete the mirrored portion[+X,character's rightside] of the model.

3. Select the original working portion and create a temporary welded copy of it with Mirror Modeler tool.

4. Rename this object elf, realign to the Z plane[MM does an offset during process, return to Z=0.559], and then Insert a copy into an Object Library.

5. Close 07_Head.scn without saving any changes.

II. Aligning the Mesh to World Origin

1. Start a new scene, load a copy of the elf object from a Library, rename it back to elf.

2. With elf object selected, Left-click the Move axes to center button directly, or enter Axis Mode, then activate the tool. Selection box disappears and you are now inside the shape's hierarchy.

3. Once the axis moves to COM[center of mass], UP arrow out of the hierarchy, which reselects it in blue.

4. With mesh still selected, Normalize Location of the object. Elf's 'center' should snap to world origin. Values will be "0,0,0". Size 'should' be around "7.937,2.349,9.102". It is represented by the red wireframe mesh in the image.

5. Move the elf object to a Z value of 4.551, this will place the mesh's feet exactly on the ground plane. Adjusting your grid units may be needed, down to the millimeter[0.001].

6. Enter Axis Mode and Normalize Location of it, or manually enter X,Y,Z values of 0.

7. With the object's origin at 0,0,0, Uniformly Scale untill it's Z value is 2.701[character height]. This will be the shape's dimensions to construct the skeletal rig to. This mesh is represented by the white wireframe mesh in the image.

III. Applying Texture to the Mesh

1. With the elf still selected, Open the Material Editor and the Color Shaders Library.

2. In Color Shaders Library, double-click the Texture Map shader, the Color slot will load the 'Caligari' default .jpg texture.

3. Adjust the material's properties to the exporter's settings for the default 'neutral' texture.

4. Open the Materials Library and Insert a copy of this new material into the Library. This will provide a starting point for any future materials needed for default DTS texturing.

5. Click the Get Texture Map button in the Color slot, the Texture Browser opens; then, navigate to your intended bitmap's folder and double-click the bitmap or drag/drop it to load the texture into the Color slot of the Material Editor.

6. With elf still selected, click the Paint Object button, and the elf mesh object has the Material applied to it. The object is now textured with a default gS UV mapping. Normally, I think it would be the time to map the UV's, either in gS, or a 3rd party application. We, however; are moving forward.

IV. Locking Scale Transforms of the Mesh

Preface:

This portion, while brief, is nonetheless of extreme importance to remember; lest your shape reveal it's true scale once inside the engine. The size that it was before bringing the elf-character to it's target of Z=2.701, well; or whatever you decide to rig for,;). You'll be left wondering, "...why is my player 150' tall?", or, "...each terrain texture pixel is as big as me???" This is a native gS 'quirk' and this next section describes one method of working around this.

1. With elf still selected, File--Save As--DirectX*.X and Save as elf.x.

2. Hit SpaceBar then File--Load--Object, select the newly created elf.x, click Open, and now an object named elfMesh is loaded and selected in the Scene.

3. Check the axis of the mesh as previously outlined[something I find myself doing a lot] and then Insert a copy into an Object Library.

4. Start a new scene, load a copy of elfMesh into it from the still open Object Library. Click on the Scene Library browser button and then Insert a copy of this scene with a right click. With another right click on the thumbnail, Rename this scene as MESHscene.

5. Save a backup file somewhere or however you feel comfortable archiving this base scene, a copy of which should be used to construct the skeletal rig in, and take a nice stretching break.

V. Rigging/Binding/Weighting the Mesh & Naming Conventions

Since this portion of the process is covered rather expertly in the Buzz VTM's, it will not be represented here. There are a few caveats to remember when following the videos.

• there are other 3rd party plugins for animation available. JointMaster is but one of a few that will function within the GameSpace/TrueSpace environment.
  
  
• this work makes no recomendation on which system to keep in the toolset.
  
  
• this work will not explain GameSpace Animation, IK, or Clips in any great detail.
  
  
• all the official documentation, supplied by both GarageGames and the exporter's author, is superb in giving the fundamental background data on the format's requirements and setup procedures for existing modeling packages.
  
  
• the naming conventions used to name the Hingejoints are fine and needed to operate Puppeteer[if utilized for animating] correctly. This is not an issue, I feel. It's in needing to name all the Bone objects in the rig to a unique name for each. This is a native gS Bones system 'quirk'. Because of this, both exporters are only recognizing these objects and NOT the hingejoints in any noticeable fashion. This 'quirk' is exposed when exporting to Milkshape3d format and during the final examination of the shape inside the ShowToolPro. It will not be noticeable if utilizing the stock -showTool mod included with the demo. This is not a bug within the work of either exporter, nor will it affect any animations produced with any gS2gS shape/sequences and exported, only crossplatform DTS/DSQ combinations. The 'quirk' manifests itself in the form of the skeletal rig not appearing to be aligned as setup within the gS environment. What appears as the rotational driver in the rig of the DTS shape is actually the BONE object in GameSpace. Because of this fact, any deforming rig setup and named along the existing default Character Studio naming conventions and Bone locations; will not load the Max produced animation sequences correctly.
  
  

Now, onto the few additional steps in this portion; immediately after the rigging is complete and before binding is begun:

1. Insert a copy of the skeleton only into an Object Library, as a backup copy, or the artists' prefered BU method.

2. Once binding/weighting phase is completed, select and rename the skeleton object[which is now an IK Group, once binding is activated] to start01.

3. Insert a copy of this scene in a Scene Library with a right click and then rename it PLAYER with another right click on the thumbnail itself.

VI. Current Analysis & Nodes/MountPoints/DetailMarkers

At this point, the character's structure is complete. A mesh with default UV mapping and a bitmap material applied has been bound to a skeletal deforming system. This could now be utilized to produce animation sequences, however; the needed Nodes and MountPoints for player functionality are not yet within the shape and properly linked, nor are the detail markers in place to properly assemble the DTS/DSQ files. GameSpace does not generate any Null-type objects that can be used as markers/helpers to guide the exporter along the process. To this end, geometry must be used to generate the Node objects and is then ignored by the exporter's code. This is accomplished with a prefix of "_" in front of the detail marker and Node names. Something else to note is that during the weighting portion, geometry may have been edited to accomodate deformations. This may necessitate a back/forth process with UV mapping to ensure proper texture coverage and UV coordinate placement. This should be checked and completed prior to continuing the setup of the shape.

It's time to move onto Node construction and location for successful player-character functionality coded into the TGE demo build. Linking will be in the next section. I construct these Node objects as simply as possible. I also lock the scale transform as before and load a copy into a Library for future use. The step of locking the transform is perhaps not needed; being that all the exporter is looking for, is the location of the object. Also, to note; this method of locking is outlined in the exporter documents. There is a 3rd party plugin the performs this same function which is not outlined here. I have not run this thru any form of testing, and found the standard method to fit within my overall structure I'd planned[default copy of mesh, in an multiplatform format, at least for the mesh]. Suggestion of the alternative has come from a respected artist within the community.

1. Create a cube Primitive in the perspective viewport with the dimensions of .1x.1.x.1 and move it to world origin with the Obj Info Panel. Rename this object node and export to .X format and load a copy into a Library as done on previous steps[putting it's render property to wireframe/axis exposed], changing the name back to node before Insertion. Delete both source node objects and continue within this scene.

2. Load a copy of node, rename it _cam and locate it where you wish the 3rd person/death orbit camera to be placed.

3. Continue thru the list in the image, loading and locating each _mount* and node desired for functionality. The player character MUST contain the _cam and _eye. I have included a _mount3 node for developers favoring their Left Hand and interesting Item/baseShape mounting.

4. I place my _mount* objects with their axis just at the intersection of mesh and axis. Don't be overly concerned with the hands' node orientation at this point. It will be addressed further along.

5. The _detail128 object was located at a position of Y= -0.75. This location removes it from the bounds object that is constructed after a pose has been established.

6. Once all nodes, _mount*s, and the _detail128 have been created and placed, backup this scene as you wish.

Building the DTS Shape

VII. Linking Nodes in the Scene Editor

1. Open the Scene Editor, expanding it to a workable size. I normally hide the TrackKey panel of the dialog.

2. Select the _eye object and drag/drop it onto the *head bone in the start01 rig you've devised; it is now parented to that bone. The SE may not automagically refresh the dialog and/or show properly if the linkage was good. F5 or click the refresh button and inspect the results. The start01 object Tree may have to be collapsed/expanded by branch to complete this portion.

3. Continue selecting and linking each node object to it's intended parent in the IK group. This linking should be to the Bone objects and not the Hingejoint ones. I am not certain what will transpire if they are linked to either these objects or the elfMesh one.

4. Once all linking is complete and rechecked, backup this scene as prefered and continue.

VIII. Establishing the Root Pose & Aligning the Mount*s

1. Select start01[elf character] object and open the developer's prefered animation control plugin.

2. Never leaving Frame0, pose both the hands into a 'neutral' forward and palms inward posture. I manipulated only the joints from the shoulder down to the fingers, and got the hands to a position that had the palm as near inline with the Y plane as I wished. I also added a slight gripping hand gesture on the thumb.

3. With the character in this 'neutral' pose, the _mount*'s axes were visibly out of alignment with the parent's and/or the world's. To correct this; in the SE, select the _mount0 object, it will highlight blue within the Tree listing. However; without also having the Obj Info Panel open, you will not notice you have actually only selected it's parent object. Enter the perspective viewport thru prefered/stable method[I use scrollwheel mouse click] and use the Arrow keys to enter/navigate the hierachy; thus actually selecting the object.

4. Once the _mount0 is selected, manually reset it's rotations to 0,0,0[which produce World Coordinates] in the input fields, remember to record the value with a carriage return[Enter]. An alternative method is to directly Normalize Rotation of the object with that button[once the object, and not it's parent, has been selected].

5. Navigate the hierarchy to select the _mount3 object, and repeat this same procedure to align this object to the World Coordinates.

6. At this point, I stopped posing the character and left this 'neutral' pose the 'root', to continue the setup process for this project. Check all other node objects' axes against their intended 'root' orientations. It may be desired to continue posing the elf character to the developers' target 'root' position at this time.

IX. Bounding Box and Final Parameters[autoDetails & .CFG file]

1. With the start01 object selected and in it's exporting 'root' pose, enter and navigate the hierarchy[ArrowDown-once] until the elfMesh is active in the Obj Info Panel. Take note of it's Size. Enter Axis Mode of the elfMesh object, leave it exposed or note it's location, exit Axis Mode.

2. Hit Spacebar, create a cube Primitive with default settings in the perspective view[Size=2,2,2], exit Primitive tool.

3. Move and resize the cube Primitive object to fully enclose the start01 object[elf character] in the 'root' pose. Use the noted size taken earlier as reference to ensure complete enclosure of all Nodes that will be animated later. This will become the player's bounding box, representing the shape's location and orientation upon export. Once fully enclosing the character, Normalize Location of the axis. This is very important to remember!

4. Lock the scale transforms of the cube as previously done with the .X export/load process on the elfMesh and node objects. Rename the loaded object, ELFbounds render it in wireframe, expose it's axis and Insert a copy in a Library. Delete both the cube and cubeMesh source objects. Load a copy of the ELFbounds object from the Library and rename it to bounds.

5. At this point the loaded bounds object should be enclosing the elf character, be in wireframe, and have it's axis visible. Make certain that the axis of the bounds and the elfMesh[not start01] are at the same location! Check each in the Object Info Panel. If both axes are not in sync, when exported; I have seen the elfMesh snap to the bounds location, leaving the skeletal rig behind.

6. Load 3 node objects from a Library, name them, _detail64,_detail32, and _detail2 respectively. Move and arrange them along side the highest detail marker object, _detail128, that was created and located in a previous step.

7. Open the Object Notes of elfMesh and enter this data:

  numAutoDetails 4
  autoDetailSize0 128
  autoDetailPercent0 1.0 //elfMesh of 1744 Detail Polys(100%)
  autoDetailSize1 64
  autoDetailPercent1 .5 //elfMesh of 832 Detail Polys(50%)
  autoDetailSize2 32
  autoDetailPercent2 .25 //elfMesh of 399 Detail Polys(25%)
  autoDetailSize3 2
  autoDetailPercent3 .1 //elfMesh of 150 Detail Polys(10%)

This data takes advantage of the exporter's capability of generating the LOD's for the shape automatically for you, negating the task of manually producing & texturing the actual geometric meshes for the purpose. These settings provided give a basic indication of the difference in levels of detail that can be achieved, not necessarily the best for this particular shape.

7. Close the Notes of the object. Save the scene. This portion of the process is complete.

.CFG file:
The exporter has configure settings which apply to the process by default. Exporting in this manner is perhaps fine for a base DTS shape, which is intended to have the entire list of needed Nodes present. Animation sequences, which are intended to control specific Nodes on an as-needed basis, need some method of further detailing the data. The .CFG file is used in this manner and is recommended to be used on all shapes produced; to ensure exactly the information needed is exported, resulting in more efficient shapes for the engine's overhead of keeping track of the data. The exporter documentation explains this very well and that portion should be examined for further details, as to what lists and parameters can be utilized.

X. Maintaining the Scene for future use and Exporting

Preface:

The scene is nearly ready for export, there is one final assembly step to take; creating the base01 grouping. I have found all my player character DTS export scenes to become corrupted after this final step. I cannot expertly explain the cause of this effect or the proper workflow to have this not happen during the DTS hierarchy build. This may have something to do with animating the hierarchy before it's prepared in the DTS requirements; however, I have also had this occur having set the shape up in the hierarchy and then animating. This corruption manifests itself when the scene in question is reopened upon the next session or file launch. It appears something like this; whereby the mesh assumes the Skinning Pose and the rig continues to assume any keyframes.

I do know how to keep the file from becoming corrupt in this manner after exporting and also how to 'fix' a scene, once this has occured. This technique was demonstrated to me by the exporter's author, Matt Summers. He was very generous with his time and knowledge of GameSpace/TrueSpace to get my scene to remain source material and even went so far as to export, into separate .DSQ's, my series of quick default animation sequences I had created to test the pipeline. Matt also described the differences in the methods we both used.

The 'workaround' involves NOT saving the scene after the export is successful; necessatating a rebuild of the hierarchy for each export. The 'fix' is to enter the SE, and drag/drop the start01[once properly selected!] IK Group back onto the Scene Animation parent, thus removing it from the hierarchy created. Save the scene after the returning start01 to Scene Animation, and then close the file. Upon reopening, it should be returned to it's previous state.

1. After saving and backing up the PLAYER*.scn in the preceeding step, Insert a copy of this current scene to a Scene Library. It should increment the file name with a trailing number. Rename this scene PLAYERexport. I do this to keep a final exporting scene isolated from the previous copy and work all exports out of this file, since corruption may occur. This scene will become the Source Material for any player and/or sequences needed for this shape; until/unless this file proves unusuable later.

2. Open the SE to view the Scene Animation parent and all sub objects within the scene. At this point, there should be the bounds object, 4 _detail* marker objects, and the start01[elf player-character].

3. Select and then drag/drop the start01 object onto the _detail128 marker object. This will create a new IK Grouping with the default name, NoName,1, and perhaps collapse the object Tree. Refresh as needed and check the linkage. Rename, NoName,1, to base01.

4. Continue dragging/dropping the remaining marker objects onto this new IK Grouping[base01], until all that remain as children of Scene Animation are the bounds object and the base01 grouping object.

5. Recheck the hierarchy one final time, and with a left mouse click, activate the DTS2 exporter dialog. A right mouse click will bring up the DSQ dialog; this dialog is used to produce that fileType later, once this reference shape is constructed.

6. Name this file, player, and click Save. If no errors in setup have occured, within a short time, the Done message box appears, signaling a successful export. Short time may be a relative term, based upon the complexity of the shape, the operating system/hardware, and if any animation sequences are being embedded within the DTS shape. This shape, running thru a AMD Athlon 1.2 w/512Mb RAM on a WinOS, took approximately 25 seconds. If animations were being included[or when producing only DSQ information]; this time might stretch to, perhaps 15 minutes. This would be a single sequence of no more than 15-20 frames. While the process is underway, no progress meter is available and on this system, the Save dialog grays out nearly completely.

XI. Examination in ShowTool

Without appearing as an advertisement for[and receiving no compensation for mentioning] the new ShowTool Pro, produced by David Wyand, I will say it's the best tool for examining the exported files around. It does so much to even begin listing, most if not all of the important tests you would eventually check needing the engine environment. The existing -showTool MOD of the engine can be used, but no real checking of Nodes exists, except to read the log output file dump.DMP which is generated with each export. This is something I would do first after closing GameSpace, but now with a .DMP export option inside STP viewer; I open it directly and begin examining instead. Developers utilizing the stock viewer can take time now to examine this file if they wish. Having successfully exported a player.dts file, place a copy it and it's texture inside the ~/data/shapes/player folder of the developer's example demo; having first renamed or moved the existing player.dts supplied to preserve it. The following steps assume the using of ShowTool Pro and the few features of the stock viewer can probably be interpolated from them.

1. Begin by loading a copy of the new player.dts shape into the viewer. A new Project Directory may need to be created thru the [modify] default heading. The shape should appear textured and centered in the viewer.

2. Click Shape Properties from the menu selections on the left and bring up the dialog with properties divided among 3 tabs, Tree, TSDump, and Rendering. The Tree outlines the shape's hierarchy including the Detail, Subshapes, and Skins branches. The TSDump is the exporting option mentioned earlier along and realtime output with Refresh option. The Rendering tab gives material special properties information. Check the Tree tab's output for proper Node inclusion and parenting. Close Shape Properties dialog.

3. Open the Detail Levels dialog. If the LOD data from earlier was used, the controller should have 4 detail levels, numbered 0,1,2,3, slotted along the controllers track. In the data input earlier, we specified 4 autoDetail levels; they are represented and switched with the slider and checking the box labeled, "Detail levels controlled by slider". Current Distance is used as the method if left unchecked. Cycle/scrub thru the detail levels, watching as the mesh has faces removed by the engine with each new level of detail. Close Detail Levels dialog.

NOTE:

...these next few steps are only accomplishable within the ShowTool Pro enviroment. MOD users need to move into the next section, Proof Testing inside the Engine.

4. If using a Project Directory that includes the entire shapes folder, load the crossbow.dts from the demo or that from, RealmWars, a community-based Torque Project.

5. Once a crossbow.dts weapon has been loaded, switch the current object to player.dts and open the Mount Objects dialog.

6. Choose the crossbow.dts item from the dropdown list, select the mountPoint node, select the mount0 node from Current Object: list, and then click Mount>>. Move the Mounting dialog aside and check the object mounted and it's mounting point. The weapon should be held in the right hand. Go ahead and Mount>> another crossbow.dts from the list. This time, select mount3 as the target Node. Now, there should be dual crossbows, mounted one in each hand, on the player.dts now. My demonstration images even go as far as mounting a flag.dts to the CTF mount1 Node. This character seems ready for combat and defending the standard!

7. Once examination is complete, close the viewer, and begin the final step of dropping the shape in as the Player.

XII. Proofing inside the engine

The shape viewers are great tools for examining the properties of the exported DTS/DSQ files. It is not enough to rely upon them to authenticate the shape. This must be accomplished with the code intended for the shape's functionality inside the engine.

After checking the shape's properties via one of the DTS/DSQ model viewers available; the absolute proof testing of the character comes from dropping the player.DTS shape into the engine as the intended Class of object, the Player, and using the code within it's Datablock.

Here, you see the player.dts in the form of our example shape, the elfMesh standing inside the engine, with a weapon[.DTS & .jpg courtesy of Eric 'Esop' Johnson] mounted to it's coded weapon slot[0]. This shape contains no animations, yet has not crashed the engine, due to recent strengthening of the code base. With no additional animations present; the player defaults to the 'Root' pose for each calling in code. Thus, we have successfully integrated a shape representing the PlayerDatablock. From this position; it would be time to generate some action sequences to get more functionality from our datablock's shape. These would be exported as .DSQ files and merged with the reference .DTS at runtime with the assistance of a validation script accompanying the shape in it's repository.

The steps necessary to complete this last portion are a matter of engine scripting, designed by each developer. Simply create a Server and load a mission. With the elfMesh as an avatar, the player enters the mission with no sequences. Run is a rigid slide, due to no sequences, as is side, and backwards. Jumping will move the player it's coded values without the aid of any animation. Switching weapons will load them into each appropriate weapon slot. After checking any further mountings, exit the mission and engine; continue further development. This guide has completed it's design of demonstrating how to bring the elfMesh created in the Buzz/Caligari VTM's from the gameSpace modeling application to the Torque Game Engine as a DTS-formatted shape.