| |
|
|
|
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 engine's capability of producing the LOD's for the shape automatically for you, negating the task of manually producing 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.
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 explanation 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[weapon/texture courtesy of 3d artist Eric 'Esop' Johnson@ InspiredGames.net] 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. These would be exported as .DSQ fileType 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.
|
|
|
HOME