DTS vs. DSQ: The Technical Side of Game Art
by Travis Vroman · 08/12/2009 (2:52 pm) · 14 comments
UPDATES!
I've been working with Torque now, and many of its versions since 2001. I've learned a lot over this period of time, and not just about the engine. I've learned things about game development in general. There's a lot more that goes into than people realize. Even the art side of development is highly technical. That said, I'd like to post some of what I have learned in Torque here to help others.
A recent problem I've run into involved DTS and DSQ files. It's one thing if you only need to animate transform-based attributes, such as object rotation, position or scaling. For that, DTS will do everything you need. It's when you have a model that requires vertex, texture, visibility or morph animation that you need to use DSQ. This is where my problem arose, since I've been avoiding this issue like the plague since I've started with Torque. Furthermore, I finally found my answers, but they were so spread all over the place that I figured it's time for all of this information to be in one place. I'd also like to thank the GG community, as many of you have helped me throughout the years.
Before I begin, I'd like to mention that in this article I use 3ds max 2008, and assumes you know how to model, texture, animate and rig. If not, you might need to brush up on those skills first. I'd also like to point out that there are more ways to do this than is written here, but I am going for a "simplest and best practice" approach. With all that out of the way, let's begin.
There are 3 main components to a rigged/skeletal animation for Torque. They are:
For the mesh, I prefer it to be an editable mesh, not an editable poly. It is possible to export using Editable Poly, but this can cause the exporter to crash max. Secondly, it is recommended that the Skin modifier be on top of the modifier stack, and is recommended that no other modifiers be present. Again, this is not a requirement, but is good practice. This is because the skin modifier affects the underlying mesh, and could affect other modifiers if they are present, yielding sometimes unpredictable results. So, your modifier stack should look something like this:

Also, it may not be linked to anything else in the scene. It needs to be in the scene root (or not linked to anything else). The mesh still needs to end in a number, which represents the Level of Detail (LoD) of the mesh, unless you are using the Multires modifier. However, since Multires is outside the scope of this article, I'll table that discussion for now.
The "bounds", or bounding box, should generally be linked to the base of the hierarchy root. In this case, it should be linked to our "user" node (more on that in just a moment). This is not necessary for static objects, but is still good practice.
Next, my technique involves the creation of a standard "dummy" object, which I have arbitrarily named "user". It may be named anything, so long as it does not end in a number.
Next, I link the bone structure to the "user" dummy object. I then create another dummy object to act as the detail node. This must be named "detail#", where # is replaced by the detail number you used at the end of your mesh above. This also gets linked to the "user" object.
You should now have a rig that looks something like this:

That's all that's required for the DTS mesh file.
Also note that this file does not require the bones to be animated, nor does it require an animation sequence node.
Save the file in max, then export it using the "whole shape" button in the standard exporter. I exported mine to "art/shapes/animatedObjects".
Create the Sequence Dummy Object:

Make sure to name the sequence node what you intend to call the animation. For this example, I'll name it "ambient".
Open up the Curve Editor from the top toolbar.

Once in the Curve Editor, do the following 3 things:
[ol]Select Add Keyframe from the toolbar. Locate "Object(Sequence II)" in the list, then select "Sequence Begin/End" from under it. Add keyframes at the beginning and end of the animation.[ol]
In my case, the animation goes from frame 0 to frame 15 (16 frames of animation). So my first key is on frame 0, while the last is on frame 15. This will vary depending on the length of your animation, but it necissary so Torque can detect what frames to use for your animation.
Here is a picture of the Curve Editor:

One last point I need to make before we move on is that the Sequence object should be within the bounding box as well as in the scene root (not linked to anything). It is not a requirement that the Sequence node be placed within the bounds box, but I find it to be good practice because it keeps the scene cleaner in my opinion. So, your hierarchy should be very similar to the one for the DTS, but with an additional node added. it should look something like this:

Export using the "Sequence" button. Again, I exported mine to "art/shapes/animatedObjects".
Okay! That's all for the modeling section! One more step to go to get this working in game!
There are several approaches to do this, but this is the one that I have found to work best for me. First, create a folder in the "scripts/server/" directory called "animatedObjects". Within that folder, create a new .cs script file called "animations.cs". Open up that file and add the following code:
Replace "animatedObjects" with the name of the folder you saved the dts and dsq in. Once this is done, go ahead and save the file and close it.
One last thing is that we need to reference the new script file so it executes. Open up "scripts/server/scriptExec.cs" and add the following code below "exec("./players/player.cs");":
Now you should be able to load up a level and drop in a shape from under the "AnimatedObjects" category, and it should automagically animate when dropped in.
I hope this article has helped you to be able to get rigged, animated shapes into Torque. Comments and feedback are welcome and encouraged.
Happy Torquing!
- Several things were pointed out as being unclear or incorrect, so I have fixed them below. A thanks goes out to Matt Fairfax and Logan Foster for the corrections!
- Updated a few of the images to reflect the article changes.
I've been working with Torque now, and many of its versions since 2001. I've learned a lot over this period of time, and not just about the engine. I've learned things about game development in general. There's a lot more that goes into than people realize. Even the art side of development is highly technical. That said, I'd like to post some of what I have learned in Torque here to help others.
A recent problem I've run into involved DTS and DSQ files. It's one thing if you only need to animate transform-based attributes, such as object rotation, position or scaling. For that, DTS will do everything you need. It's when you have a model that requires vertex, texture, visibility or morph animation that you need to use DSQ. This is where my problem arose, since I've been avoiding this issue like the plague since I've started with Torque. Furthermore, I finally found my answers, but they were so spread all over the place that I figured it's time for all of this information to be in one place. I'd also like to thank the GG community, as many of you have helped me throughout the years.
Before I begin, I'd like to mention that in this article I use 3ds max 2008, and assumes you know how to model, texture, animate and rig. If not, you might need to brush up on those skills first. I'd also like to point out that there are more ways to do this than is written here, but I am going for a "simplest and best practice" approach. With all that out of the way, let's begin.
There are 3 main components to a rigged/skeletal animation for Torque. They are:
- DTS File - This is the mesh itself that will be animated.
- DSQ File - This is the animation file that corresponds to the above DTS.
- Script - This is what allows the object to animate within Torque.
The DTS File
Here we have our mesh to be animated. However, it requires more than just the mesh. It requires a somewhat specific hierarchy, which is quite different from the typical DTS hierarchy. There are also a few specific requirements of the mesh itself as well.For the mesh, I prefer it to be an editable mesh, not an editable poly. It is possible to export using Editable Poly, but this can cause the exporter to crash max. Secondly, it is recommended that the Skin modifier be on top of the modifier stack, and is recommended that no other modifiers be present. Again, this is not a requirement, but is good practice. This is because the skin modifier affects the underlying mesh, and could affect other modifiers if they are present, yielding sometimes unpredictable results. So, your modifier stack should look something like this:

Also, it may not be linked to anything else in the scene. It needs to be in the scene root (or not linked to anything else). The mesh still needs to end in a number, which represents the Level of Detail (LoD) of the mesh, unless you are using the Multires modifier. However, since Multires is outside the scope of this article, I'll table that discussion for now.
The "bounds", or bounding box, should generally be linked to the base of the hierarchy root. In this case, it should be linked to our "user" node (more on that in just a moment). This is not necessary for static objects, but is still good practice.
Next, my technique involves the creation of a standard "dummy" object, which I have arbitrarily named "user". It may be named anything, so long as it does not end in a number.
Next, I link the bone structure to the "user" dummy object. I then create another dummy object to act as the detail node. This must be named "detail#", where # is replaced by the detail number you used at the end of your mesh above. This also gets linked to the "user" object.
You should now have a rig that looks something like this:

That's all that's required for the DTS mesh file.
Also note that this file does not require the bones to be animated, nor does it require an animation sequence node.
Save the file in max, then export it using the "whole shape" button in the standard exporter. I exported mine to "art/shapes/animatedObjects".
The DSQ File
This file is pretty much the same as the last, with a few exceptions. What I prefer to do is save the mesh file as a new file, named slightly different to denote it as an animation. Working from there, we now need to animate the bones. Once this is done, one needs to create a sequence node. This is different from a dummy object, so I'll detail it below.Create the Sequence Dummy Object:

Make sure to name the sequence node what you intend to call the animation. For this example, I'll name it "ambient".
Open up the Curve Editor from the top toolbar.

Once in the Curve Editor, do the following 3 things:
[ol]
In my case, the animation goes from frame 0 to frame 15 (16 frames of animation). So my first key is on frame 0, while the last is on frame 15. This will vary depending on the length of your animation, but it necissary so Torque can detect what frames to use for your animation.
Here is a picture of the Curve Editor:

One last point I need to make before we move on is that the Sequence object should be within the bounding box as well as in the scene root (not linked to anything). It is not a requirement that the Sequence node be placed within the bounds box, but I find it to be good practice because it keeps the scene cleaner in my opinion. So, your hierarchy should be very similar to the one for the DTS, but with an additional node added. it should look something like this:

Export using the "Sequence" button. Again, I exported mine to "art/shapes/animatedObjects".
Okay! That's all for the modeling section! One more step to go to get this working in game!
The Script
First off, I should mention that much of this section is not needed when using Torque 3D, but is required for TGE/A. For a brief explanation of Torque 3D's usage, see Matt Fairfax's post below.There are several approaches to do this, but this is the one that I have found to work best for me. First, create a folder in the "scripts/server/" directory called "animatedObjects". Within that folder, create a new .cs script file called "animations.cs". Open up that file and add the following code:
// Datablock Definition.
datablock StaticShapeData(FlagAnimDB)
{
shapeFile = "art/shapes/animatedObjects/flaganim.dts";
category = "AnimatedObjects";
};
// When the shape is added to a scene.
function FlagAnimDB::onAdd(%this,%obj)
{
%obj.playThread(0,"ambient");
}
// When the shape is loaded into memory.
function FlagAnimDTS::onLoad(%this)
{
%this.addSequence("art/shapes/animatedObjects/flag_ambient.dsq", "ambient");
}
// Set up the shape for use with DSQ animations.
singleton TSShapeConstructor(FlagAnimDTS)
{
baseShape = "art/shapes/animatedObjects/flaganim.dts";
};Replace "animatedObjects" with the name of the folder you saved the dts and dsq in. Once this is done, go ahead and save the file and close it.
One last thing is that we need to reference the new script file so it executes. Open up "scripts/server/scriptExec.cs" and add the following code below "exec("./players/player.cs");":
// Load up our custom animations script.
exec("./animatedObjects/animations.cs");Now you should be able to load up a level and drop in a shape from under the "AnimatedObjects" category, and it should automagically animate when dropped in.
I hope this article has helped you to be able to get rigged, animated shapes into Torque. Comments and feedback are welcome and encouraged.
Happy Torquing!
About the author
Attended the Art Institute of Fort Lauderdale for Video Game Art and Design. Strong background in traditional visual arts. Strong programming skills, particularly in real-time solutions.
#2
08/12/2009 (3:46 pm)
Personally, I use just standard max units, as I find it to be far less confusing than using inches and such. As long as you remember that 1 unit = 1 meter in Torque, you're good to go :)
#3
08/12/2009 (3:54 pm)
Oh, thats good to know! Thanks Travis
#4
08/12/2009 (5:02 pm)
Great stuff! Very good writeup, Travis! Keep up the great work!!
#6
This is handy since you won't have to set up a StaticShape datablock or create the "onAdd" callback script.
08/12/2009 (11:45 pm)
With Torque 3D Beta 5, you can add a mesh to the scene from the Library (which adds it as a TSStatic) and, if it has a sequence named "ambient" (either embedded or merged in with a DSQ or another mesh), then it will automatically start playing the animation once the object is added to the scene.This is handy since you won't have to set up a StaticShape datablock or create the "onAdd" callback script.
#7
Actually there are a few errors with your information that need to be noted because they are incorrect or missing crucial information that will likely throw a monkey wrench into the process if other people try to go through this...
1) DSQs can be used for any transform animation be it simple or complex, they cannot contain any animation data that is not transform based (ie. visibility, morph, uvw, vertex, etc.). Usage generally depends on whether you want to share the animation with other files and whether or not you can cleanly animate the mesh/model in 1 file or you need multiple.
2) Editable Poly class objects actually export fine. There are sometimes issue with it a skin modifier and the Multire modifier that can cause a crash at the end of the export command which crashes Max, but the data exports correctly.
3) The skin modifier does not need to be at the top of the modifier stack, its simply a good practice to do so since the skin modifier deforms the underlying mesh and as such can affect data on modifiers above it.
4) While meshes with a skin modifier do need to be in the scene root (or 'free floating' as you incorrectly call it), it does not need a trailing number for the LOD if you are using Multires. This is very important to note.
5) When creating dummy nodes, its a good practice to create them in the top viewport so that they do not inherit any rotational transforms upon creation (which can happen when you do it in other viewports). This is very important to note since rotation transforms can cause your model to import at odd angles.
6) In most cases Bounds should be linked to the DTS hierarchy root (ie Base01 or Bip01 or whatever your start node is). It is acceptable for it to not be linked in cases of static objects, but in the case of character models you very rarely want the bounds not to be linked to DTS hierarchy.
7) With the CFG file you do not need to include the mesh you choose to export in the list. The exporter will know to export the mesh data to your DTS file if a) the mesh is linked to the DTS Hierarchy or b) the mesh uses a skin modifier that references bones listed in the DTS hierarchy. Listing the mesh in the CFG actually doesn't do anything, nada, nill, squat.
8) Sequence markers do not need to be placed within the Bounds shape.
@Stephen
If you are exporting to DTS right out of your DCC app, 1 unit = 1 metre regardless to what you have your world or scene units set to. The DTS exporters do not care about your scene scale, just the raw data that it sees.
If you are going to export to Collada then the scene units are very important as Collada saves itself out with a scale variable.
One other note, never ever use display units. Not unless you have a desire to become frustrated.
@Matt
That's a great change.
08/13/2009 (7:55 am)
@TravisActually there are a few errors with your information that need to be noted because they are incorrect or missing crucial information that will likely throw a monkey wrench into the process if other people try to go through this...
1) DSQs can be used for any transform animation be it simple or complex, they cannot contain any animation data that is not transform based (ie. visibility, morph, uvw, vertex, etc.). Usage generally depends on whether you want to share the animation with other files and whether or not you can cleanly animate the mesh/model in 1 file or you need multiple.
2) Editable Poly class objects actually export fine. There are sometimes issue with it a skin modifier and the Multire modifier that can cause a crash at the end of the export command which crashes Max, but the data exports correctly.
3) The skin modifier does not need to be at the top of the modifier stack, its simply a good practice to do so since the skin modifier deforms the underlying mesh and as such can affect data on modifiers above it.
4) While meshes with a skin modifier do need to be in the scene root (or 'free floating' as you incorrectly call it), it does not need a trailing number for the LOD if you are using Multires. This is very important to note.
5) When creating dummy nodes, its a good practice to create them in the top viewport so that they do not inherit any rotational transforms upon creation (which can happen when you do it in other viewports). This is very important to note since rotation transforms can cause your model to import at odd angles.
6) In most cases Bounds should be linked to the DTS hierarchy root (ie Base01 or Bip01 or whatever your start node is). It is acceptable for it to not be linked in cases of static objects, but in the case of character models you very rarely want the bounds not to be linked to DTS hierarchy.
7) With the CFG file you do not need to include the mesh you choose to export in the list. The exporter will know to export the mesh data to your DTS file if a) the mesh is linked to the DTS Hierarchy or b) the mesh uses a skin modifier that references bones listed in the DTS hierarchy. Listing the mesh in the CFG actually doesn't do anything, nada, nill, squat.
8) Sequence markers do not need to be placed within the Bounds shape.
@Stephen
If you are exporting to DTS right out of your DCC app, 1 unit = 1 metre regardless to what you have your world or scene units set to. The DTS exporters do not care about your scene scale, just the raw data that it sees.
If you are going to export to Collada then the scene units are very important as Collada saves itself out with a scale variable.
One other note, never ever use display units. Not unless you have a desire to become frustrated.
@Matt
That's a great change.
#8
@Travis: Nice work Mate :)
08/13/2009 (8:49 am)
@Logan: In your corrections you state:Quote:4) While meshes with a skin modifier do need to be in the scene root (or 'free floating' as you incorrectly call it), it does not need a trailing number for the LOD if you are using Multires. This is very important to note.My understanding from the documentation is that you are required to define the LOD meshes for the exporter using that trailing number and from what you're saying this is not necessary. Would you mind clarifying that point a bit further for me?
@Travis: Nice work Mate :)
#9
If you are using the Multires modifier you store the mesh LOD level and the Multires degredation % in the object properties of the mesh. It makes things a bit easier to setup quick and dirty LOD that works well most of the time.
You can still go ahead and create the LOD meshes and use trailing numbers if you want. But IMHO its best only when you need specific looking LOD results that Multires fails at.
One major benefit of using Multires is that the engine will actually blend between your LOD shapes (or at least it did back in TGE) to provide a smooth transition with no 'popping'.
08/13/2009 (9:24 am)
@JamesIf you are using the Multires modifier you store the mesh LOD level and the Multires degredation % in the object properties of the mesh. It makes things a bit easier to setup quick and dirty LOD that works well most of the time.
You can still go ahead and create the LOD meshes and use trailing numbers if you want. But IMHO its best only when you need specific looking LOD results that Multires fails at.
One major benefit of using Multires is that the engine will actually blend between your LOD shapes (or at least it did back in TGE) to provide a smooth transition with no 'popping'.
#10
If your NOT using MultiRes to create your LOD levels, then you need to
suffix your meshes with the lod level you want (ie 3 if you only have 1
LOD level), along with your detail helper.
If you are using MultiRes to create your LOD's, then you do not suffix
your mesh with a lod number (you take a 'snapshot' of your mesh, and name it
MultiRes::YOURMESH) the exporter takes care of the lods, you do need
to create your relevant detail helpers, and either by using the lod helper
script, or manually, setup your lod info in your meshes properties>User Defined
eg:
@Logan, I have used your docs to learn all this stuff :D but maybe its time
for a small update to them (unmessdts not needed now? , plus the info you
posted here)
fosters.realmwarsgame.com/maxdts/
Cheers,
Hewster
08/13/2009 (9:26 am)
@JamesIf your NOT using MultiRes to create your LOD levels, then you need to
suffix your meshes with the lod level you want (ie 3 if you only have 1
LOD level), along with your detail helper.
If you are using MultiRes to create your LOD's, then you do not suffix
your mesh with a lod number (you take a 'snapshot' of your mesh, and name it
MultiRes::YOURMESH) the exporter takes care of the lods, you do need
to create your relevant detail helpers, and either by using the lod helper
script, or manually, setup your lod info in your meshes properties>User Defined
eg:
MULTIRES::DETAILS = 1.0,0.8,0.5,0.35,0.2,0.15,0.1,0.8 MULTIRES::SIZES = 400,200,120,50,25,15,10,3
@Logan, I have used your docs to learn all this stuff :D but maybe its time
for a small update to them (unmessdts not needed now? , plus the info you
posted here)
fosters.realmwarsgame.com/maxdts/
Cheers,
Hewster
#11
That is a wonderful update, certainly simplifies things. Torque 3D is a helluva lot easier to use with many things in that regard. However, it unfortunately does not work that way for TGE/A, which this tutorial is meant to fit as well as T3D.
@ Logan:
What I meant by "complex" animation is really morph animation, such as a flag, though I wasn't as detailed as to other reasons to use DSQ. If you don't mind, I'll use this snippet instead to explain what I mean.
I mentioned Editable Mesh for two reasons, one of which you said here. a.) I'd rather not promote a technique that causes max to crash, and b.) I've actually had circumstances where the mesh would not function properly if I left it as a editable poly. So, I figured, it's easier for people to get the hang of if you go the safe route.
Agreed. However, being that it's good practice to leave it at the top, I don't like to say things like "well, you COULD do it this way, but it's not a good idea and can mess things up because etc. etc." I believe this can make explanations/tutorials confusing for newcomers.
Dually noted. Free floating was probably not the best choice of words, I'll revise it to make my point more clear. Also, for the purpose of this tutorial, I omitted the Multires discussion as level of detail wasn't the main focus of the article, but I'll add something in there about it.
This I was never aware of. I personally haven't run into any issues with it, but it's a very important point to note. I will add this as well.
I'll remove this from the article entirely. Just an extra step I've been taking all this time (apparently unnecessarily). thanks for the heads up.
Agreed. However, this is another "in good practice" point. My reasoning behind this is to simplify matters for newcomers. I generally place everything within the bounds shape. So while it doesn't need to be there, I still think it's a good practice. I'll update the article here to reflect as much.
I'll be submitting an update with all of these changes. Thanks so much for pointing these things out! :D
-Travis
08/13/2009 (2:01 pm)
@ Matt:That is a wonderful update, certainly simplifies things. Torque 3D is a helluva lot easier to use with many things in that regard. However, it unfortunately does not work that way for TGE/A, which this tutorial is meant to fit as well as T3D.
@ Logan:
Quote:1) DSQs can be used for any transform animation be it simple or complex, they cannot contain any animation data that is not transform based (ie. visibility, morph, uvw, vertex, etc.). Usage generally depends on whether you want to share the animation with other files and whether or not you can cleanly animate the mesh/model in 1 file or you need multiple.
What I meant by "complex" animation is really morph animation, such as a flag, though I wasn't as detailed as to other reasons to use DSQ. If you don't mind, I'll use this snippet instead to explain what I mean.
Quote:2) Editable Poly class objects actually export fine. There are sometimes issue with it a skin modifier and the Multire modifier that can cause a crash at the end of the export command which crashes Max, but the data exports correctly.
I mentioned Editable Mesh for two reasons, one of which you said here. a.) I'd rather not promote a technique that causes max to crash, and b.) I've actually had circumstances where the mesh would not function properly if I left it as a editable poly. So, I figured, it's easier for people to get the hang of if you go the safe route.
Quote:3) The skin modifier does not need to be at the top of the modifier stack, its simply a good practice to do so since the skin modifier deforms the underlying mesh and as such can affect data on modifiers above it.
Agreed. However, being that it's good practice to leave it at the top, I don't like to say things like "well, you COULD do it this way, but it's not a good idea and can mess things up because etc. etc." I believe this can make explanations/tutorials confusing for newcomers.
Quote:4) While meshes with a skin modifier do need to be in the scene root (or 'free floating' as you incorrectly call it), it does not need a trailing number for the LOD if you are using Multires. This is very important to note.
Dually noted. Free floating was probably not the best choice of words, I'll revise it to make my point more clear. Also, for the purpose of this tutorial, I omitted the Multires discussion as level of detail wasn't the main focus of the article, but I'll add something in there about it.
Quote:6) In most cases Bounds should be linked to the DTS hierarchy root (ie Base01 or Bip01 or whatever your start node is). It is acceptable for it to not be linked in cases of static objects, but in the case of character models you very rarely want the bounds not to be linked to DTS hierarchy.
This I was never aware of. I personally haven't run into any issues with it, but it's a very important point to note. I will add this as well.
Quote:7) With the CFG file you do not need to include the mesh you choose to export in the list. The exporter will know to export the mesh data to your DTS file if a) the mesh is linked to the DTS Hierarchy or b) the mesh uses a skin modifier that references bones listed in the DTS hierarchy. Listing the mesh in the CFG actually doesn't do anything, nada, nill, squat.
I'll remove this from the article entirely. Just an extra step I've been taking all this time (apparently unnecessarily). thanks for the heads up.
Quote:8) Sequence markers do not need to be placed within the Bounds shape.
Agreed. However, this is another "in good practice" point. My reasoning behind this is to simplify matters for newcomers. I generally place everything within the bounds shape. So while it doesn't need to be there, I still think it's a good practice. I'll update the article here to reflect as much.
I'll be submitting an update with all of these changes. Thanks so much for pointing these things out! :D
-Travis
#12
Ya I probably should give Mich Perry a poke on IRC and see if this is something that would fit into his documenation plans (especially with Joe gone, I don't know if there are any swamp guide left with regard to the DTS format and art). He and Lara have done a great job of updating the documentation and providing new training videos.
I know we have actually pitched GG on the idea of providing extra documentation for some official 'kits' that we have proposed to them for Torque3D, since this is something people really seem to appreciate when working with something new.
08/13/2009 (3:09 pm)
@HewsterYa I probably should give Mich Perry a poke on IRC and see if this is something that would fit into his documenation plans (especially with Joe gone, I don't know if there are any swamp guide left with regard to the DTS format and art). He and Lara have done a great job of updating the documentation and providing new training videos.
I know we have actually pitched GG on the idea of providing extra documentation for some official 'kits' that we have proposed to them for Torque3D, since this is something people really seem to appreciate when working with something new.
#13
08/14/2009 (7:18 am)
@ Logan & Hewster: Thanks guys, very informative and so is your site Logan. As soon as I get back from holidays, I'll be trying Multirez out :)
#14
You don't discuss the use of the .CFG file though and a little rundown on that with an example would be a good rounding off for the article.
10/19/2009 (7:57 pm)
Nice post Travis, helped clear a few noob issues for myself.You don't discuss the use of the .CFG file though and a little rundown on that with an example would be a good rounding off for the article.

Torque Owner Stephen Scott
Algitt Studios LLC
Question though, Does it matter what units you are using? Because I noticed that most of the premade guys (Soldier, Orc, etc) use centimeters, but others like The Elf, use Meters, and I think the Jill Pack uses Inches. So does it matter, what unit you are using, and if not, do you have to scale in the script instead (I know you can do it in the World Editor as well)?