COLLADA or DTS (T3D)
by M. Jackson · in Artist Corner · 12/31/2010 (5:05 pm) · 20 replies
After reading through basically everything I can get my hands on as far as documentation on T3d, I am left with a question. Most of the documents detailing how a model should be prepared for T3D include, as their last step in the modeling program, the exportation of the model to DTS. However, the "Collada Test" sub-forum indicates that COLLADA models are converted into DTS format by the engine at load time. This seems to indicate that having a DTS exporter in the modeling package is more than a bit superfluous.
My own experiments on this matter have basically confirmed this observation, but I have not yet imported a full character with animation. So, my question is, is a DTS exporter needed for animations or am I also missing something with non-animated meshes?
Also, as a side question, what is the reasoning for creating a collision box for a non-animated model rather than set "collisionType" to "Visible Mesh"?
My own experiments on this matter have basically confirmed this observation, but I have not yet imported a full character with animation. So, my question is, is a DTS exporter needed for animations or am I also missing something with non-animated meshes?
Also, as a side question, what is the reasoning for creating a collision box for a non-animated model rather than set "collisionType" to "Visible Mesh"?
About the author
#2
As far as the collision type, I expected as much. It simply seems easier to use Visible Mesh on walls and such.
Thank you for your quick response.
12/31/2010 (5:39 pm)
Ok, good. I've been using Blender 2.55 with good results for objects and architecture, but have yet to delve into character exportation. The worst case scenario is that I have to load the 2.49 version to run my animations through the exporter as there does not seem to be any functioning 2.5x exporter (a rant more appropriate elsewhere).As far as the collision type, I expected as much. It simply seems easier to use Visible Mesh on walls and such.
Thank you for your quick response.
#3
Here is what I see as main differences;
1. cached dts files will be larger than dts files. Most times 140% up to 200% in certain cases. (I read that this was reduced a bit..so maybe an extra 120% to 160% (?) )
So; increased filesize over standard DTS export
2. Dae and cached DTS allows for use of a secondary UV channel..which is a huge bonus for dae!
3. DTS allows for use of a cfg file at time of export to cull/omit/control scene configuration ..while.. DAE files use a T3D importer that uses the tsShapeConstructor to process and build the model accordingly. (or use "export selected" function from the source app)
4. DTS animations are exported as separate dsq files from the source application.
DAE animations are exported as 1 blob animation file that you then process in T3D's shape editor. A tsShapeConstructor is used to control the source of the animation data.(note: it may be possible to export dsq files from the dae sources inside of T3D's shape editor, I have never checked nor tried.)
5. DAE files are human readable(text) so they can be edited on the fly depending on your knowledge of the DAE format. DTS are not human readable but if you get things right in the first place, you won't need to edit files like a noob!!!! :P
I think that's a fair assessment.
..both have benefits & caveats when compared to the other!
// my take on it;
- I use DTS for everything that does not need a secondary UV channel. It helps to keep the art file sizes down, memory use down(from what I have seen on my project due to very few tsShapeConstructors rather than 40+). I am not sure if there is any gain or loss with DAE use for animations as I prefer to export dsq files straight from 3dsMax.
12/31/2010 (6:01 pm)
dae nearly fully compares to dts since the release of T3D 1.1 Beta3.(note: as far as I can see) ..but there are somethings to acknowledge.Here is what I see as main differences;
1. cached dts files will be larger than dts files. Most times 140% up to 200% in certain cases. (I read that this was reduced a bit..so maybe an extra 120% to 160% (?) )
So; increased filesize over standard DTS export
2. Dae and cached DTS allows for use of a secondary UV channel..which is a huge bonus for dae!
3. DTS allows for use of a cfg file at time of export to cull/omit/control scene configuration ..while.. DAE files use a T3D importer that uses the tsShapeConstructor to process and build the model accordingly. (or use "export selected" function from the source app)
4. DTS animations are exported as separate dsq files from the source application.
DAE animations are exported as 1 blob animation file that you then process in T3D's shape editor. A tsShapeConstructor is used to control the source of the animation data.(note: it may be possible to export dsq files from the dae sources inside of T3D's shape editor, I have never checked nor tried.)
5. DAE files are human readable(text) so they can be edited on the fly depending on your knowledge of the DAE format. DTS are not human readable but if you get things right in the first place, you won't need to edit files like a noob!!!! :P
I think that's a fair assessment.
..both have benefits & caveats when compared to the other!
// my take on it;
- I use DTS for everything that does not need a secondary UV channel. It helps to keep the art file sizes down, memory use down(from what I have seen on my project due to very few tsShapeConstructors rather than 40+). I am not sure if there is any gain or loss with DAE use for animations as I prefer to export dsq files straight from 3dsMax.
#4
After a quick check on the size of the Gideon character's dts file (333kb), I don't think I would let the size increase sway me. That being said, it does sound as if processing animations could be rather cumbersome in the shape editor as compared to simple exportation. Either way I feel some further experimentation in my future.
12/31/2010 (7:16 pm)
Thank you for your detailed answer, eb.After a quick check on the size of the Gideon character's dts file (333kb), I don't think I would let the size increase sway me. That being said, it does sound as if processing animations could be rather cumbersome in the shape editor as compared to simple exportation. Either way I feel some further experimentation in my future.
#5
..and now at least ye be semi-well informed! :P
Good luck to you.
12/31/2010 (8:25 pm)
to sway or not to sway..that is the question. ..and now at least ye be semi-well informed! :P
Good luck to you.
#6
...second UV channel: big deal...how many modeling packages support this 'feature'?
DAE is verbose...too much so. Human readable; and there's the issue!
DTS was the original art format, still is...nice, compact, network art format....
Now, don't get me wrong; I've done some 'shizzle' with DAE....was there when it[concept for Torque] was merely a 'gleam' in the eyes of the beholder; just don't think it's the 'answer' to the art pipeline.
I've loaded a DAE file with DSQ files....now, this is a 'fact'!!
NB: I would use it[DAE] for the base figure[to get that 'magic' 2nd UV channel] and use DSQ's for animation data....there, how's that for an answer!! It's not the software, it's the Artist that makes it all happen....
01/01/2011 (10:31 am)
Hands down: DTS is better than DAE; of course it's only 'this' artist's opinion, won't try to sway you that it's 'fact'....second UV channel: big deal...how many modeling packages support this 'feature'?
DAE is verbose...too much so. Human readable; and there's the issue!
DTS was the original art format, still is...nice, compact, network art format....
Now, don't get me wrong; I've done some 'shizzle' with DAE....was there when it[concept for Torque] was merely a 'gleam' in the eyes of the beholder; just don't think it's the 'answer' to the art pipeline.
I've loaded a DAE file with DSQ files....now, this is a 'fact'!!
NB: I would use it[DAE] for the base figure[to get that 'magic' 2nd UV channel] and use DSQ's for animation data....there, how's that for an answer!! It's not the software, it's the Artist that makes it all happen....
#7
IFL is a great deal,I'm using it in T3D 1.0.
I still don't understand why it was removed from T3D.With IFL and without IFL I get the same fps,the performance is the same.
Morph animations have been removed after TGE 1.3,because GG said that the new bone system is a better choise.
Morphs are a lot faster than skins.
I have on my list to get back morph animations for my project when I have some free time.
01/01/2011 (2:29 pm)
DTS also supports IFL and morph animations.IFL is a great deal,I'm using it in T3D 1.0.
I still don't understand why it was removed from T3D.With IFL and without IFL I get the same fps,the performance is the same.
Morph animations have been removed after TGE 1.3,because GG said that the new bone system is a better choise.
Morphs are a lot faster than skins.
I have on my list to get back morph animations for my project when I have some free time.
#8
and I add for emphasis:
IFL removal and morph animation removal were over-the-top bad decisions.
01/01/2011 (2:53 pm)
+1 at Rex and Ivan. I agree on everything both said.and I add for emphasis:
IFL removal and morph animation removal were over-the-top bad decisions.
#9
using the dae format allows a secondary UV, but that is of questionable importance. Its initial human readability is of little consequence because it is translated into dts code, but that resulting file is some amount larger. Additionally, animation sequences may be difficult to parse out into separate files.
DTS files are generally preferred. Animations are automatically separated into DSQ files by the exporter. And so on and so forth.
So, I can now say that I understand this a bit more, but I'm still not seeing a clear benefit either way. I feel that using DAE files are appropriate for static objects and buildings, but it would be beneficial if I were to run anything with animation through the exporter (despite the pain of running my files through a previous version of Blender for exportation).
01/02/2011 (2:17 am)
Ok, so let me recap to make sure that I understand all of this.using the dae format allows a secondary UV, but that is of questionable importance. Its initial human readability is of little consequence because it is translated into dts code, but that resulting file is some amount larger. Additionally, animation sequences may be difficult to parse out into separate files.
DTS files are generally preferred. Animations are automatically separated into DSQ files by the exporter. And so on and so forth.
So, I can now say that I understand this a bit more, but I'm still not seeing a clear benefit either way. I feel that using DAE files are appropriate for static objects and buildings, but it would be beneficial if I were to run anything with animation through the exporter (despite the pain of running my files through a previous version of Blender for exportation).
#10
I just installed Blender 2.56, upgrading from 2.49 - and I'm have having a better time with 2.56. But with no DTS exporter and this thread maybe I am making the wrong choices.
I notice in T3D (b3) that you can set the collision on the shape editor to 'bounds'. Unless you need to enter the shape this seems OK with my level.
My question, will using bounds improve performance over visible mesh? It seemed to be the case for me but that was maybe wishful thinking and the frame rate increase was not dramatic.
Happy New Year :-)
Andy
01/02/2011 (10:25 am)
Interesting thread. I have been using DAE (with ~3 LOD levels) routinely for a while but the comment on performance with visible meshes is concerning (thanks Steve!).I just installed Blender 2.56, upgrading from 2.49 - and I'm have having a better time with 2.56. But with no DTS exporter and this thread maybe I am making the wrong choices.
I notice in T3D (b3) that you can set the collision on the shape editor to 'bounds'. Unless you need to enter the shape this seems OK with my level.
My question, will using bounds improve performance over visible mesh? It seemed to be the case for me but that was maybe wishful thinking and the frame rate increase was not dramatic.
Happy New Year :-)
Andy
#11
Nearly all of the time; Yes.
- Will it be noticeable to you on your dev machine; possibly not...will it be noticeable to someone else playing on less of a comp; possibly yes.
Test the gain amount by duplicating a model 1000 to 5000 times using visible mesh collision, then do the same with box/bounds collision.
Make sure the test model is somewhat complex. otherwise you enter into the other side of "Nearly all of the time; Yes." which is "some of the time; no".
This is something you can teach in theory but to pass the concept of calculating the final product/mesh/onject needs,.. well, that simply needs experience in the matter.
01/02/2011 (2:16 pm)
"will using bounds improve performance over visible mesh?"Nearly all of the time; Yes.
- Will it be noticeable to you on your dev machine; possibly not...will it be noticeable to someone else playing on less of a comp; possibly yes.
Test the gain amount by duplicating a model 1000 to 5000 times using visible mesh collision, then do the same with box/bounds collision.
Make sure the test model is somewhat complex. otherwise you enter into the other side of "Nearly all of the time; Yes." which is "some of the time; no".
This is something you can teach in theory but to pass the concept of calculating the final product/mesh/onject needs,.. well, that simply needs experience in the matter.
#12
And just for reference:
Admittedly I use an older version of Blender for DTS (and the older animation system - haven't had time to learn the new one!), I tend to use DAE export for pureLight lightmapping.
I used custom collision meshes for all my buildings in my last demo. I've got a lot of "trim" like window ledges and doorframes - stuff that don't need collision. Each building ended up with something between 150 and 300 collision meshes ... which was a real pain in the arse to make.
Visible Collision really does depend on your model, lots of small polys means lots of collision surfaces to calculate - also visCol doesn't like very long and thin surfaces, it prefers squarish.
Having said that, I've also made a HUGE corridor crawl level, entirely made with Visible Collision. There are 63 sections of it, but they're all fairly low poly.
In the end, lots of collision polys touching the player at any one time is bad. This goes as much for terrain (set squareSize to 0.1, throw in players/Ai, watch performance die) as it does for standard meshes. But because people tend to want things to look beautiful (more tris!) it's often a good idea to have seperate collision meshes (less tris!).
[edit]
Also watch out for bad rotations in Blender with DAE. Make sure when you create a node/empty/object/mesh that you do so from overhead view (numpad7) so that it starts with 0 0 0 rotation - this has caught me out before because it only affects DAE and not DTS.
01/02/2011 (2:27 pm)
Bounds is just a big square (or rectangle), so yeah, you should get superior performance - but you can model your own collision meshes in DAE.And just for reference:
Admittedly I use an older version of Blender for DTS (and the older animation system - haven't had time to learn the new one!), I tend to use DAE export for pureLight lightmapping.
I used custom collision meshes for all my buildings in my last demo. I've got a lot of "trim" like window ledges and doorframes - stuff that don't need collision. Each building ended up with something between 150 and 300 collision meshes ... which was a real pain in the arse to make.
Visible Collision really does depend on your model, lots of small polys means lots of collision surfaces to calculate - also visCol doesn't like very long and thin surfaces, it prefers squarish.
Having said that, I've also made a HUGE corridor crawl level, entirely made with Visible Collision. There are 63 sections of it, but they're all fairly low poly.
In the end, lots of collision polys touching the player at any one time is bad. This goes as much for terrain (set squareSize to 0.1, throw in players/Ai, watch performance die) as it does for standard meshes. But because people tend to want things to look beautiful (more tris!) it's often a good idea to have seperate collision meshes (less tris!).
[edit]
Also watch out for bad rotations in Blender with DAE. Make sure when you create a node/empty/object/mesh that you do so from overhead view (numpad7) so that it starts with 0 0 0 rotation - this has caught me out before because it only affects DAE and not DTS.
#13
Since you and I seem to be in the same boat, I will share that all standard models and animations made with 2.5x can be opened by 2.49 without any loss. What is not forwardly compatible (I think that is the right term here) is the particle system, some of the light settings, and I'm sure a few other more advanced features that I've never bothered with. Thus, I would recommend simply using 2.49 for its export function while doing all the real work in 2.5x so long as you are actually more productive in the newer version.
@Steve: I get around the rotation issue by hitting ALT+R with the object selected (clear rotation). That saves a great deal of time and stress when dealing with armatures as well; simply finish initial bone placements then, in edit mode, select all bones and clear their rotation before parenting to the mesh or twiddling with any other properties.
EDIT: wow, did I seriously say parenting to the mesh...
01/02/2011 (5:30 pm)
Andy,Since you and I seem to be in the same boat, I will share that all standard models and animations made with 2.5x can be opened by 2.49 without any loss. What is not forwardly compatible (I think that is the right term here) is the particle system, some of the light settings, and I'm sure a few other more advanced features that I've never bothered with. Thus, I would recommend simply using 2.49 for its export function while doing all the real work in 2.5x so long as you are actually more productive in the newer version.
@Steve: I get around the rotation issue by hitting ALT+R with the object selected (clear rotation). That saves a great deal of time and stress when dealing with armatures as well; simply finish initial bone placements then, in edit mode, select all bones and clear their rotation before parenting to the mesh or twiddling with any other properties.
EDIT: wow, did I seriously say parenting to the mesh...
#14
thats exactly what I've been struggling to do,
could you expand how you did this?
01/03/2011 (3:02 pm)
@Rex,Quote:
I've loaded a DAE file with DSQ files....now, this is a 'fact'!!
NB: I would use it[DAE] for the base figure[to get that 'magic' 2nd UV channel] and use DSQ's for animation data
thats exactly what I've been struggling to do,
could you expand how you did this?
#15
Instead of specifying the DTS heading and path, use DAE instead.
Somewhere I have the example I sent off to Matt F. eons ago, when the early Collada testing was happening; I'll see if I can locate it.
OF course, this was all done, before beta3 or any 1.0 Release beta for that matter, can't guarantee same results. Chris R. should be able to outline the precise steps for a DAE loading of DSQ....
01/03/2011 (5:46 pm)
Use a TSShapeConstructor singleton to load the shape with animation, just like a DTS shape. Of course, your DAE needs to be exactly like your DSQ rig...which isn't 'easy' but as a 3D graphic Artist, I accomplished it.Instead of specifying the DTS heading and path, use DAE instead.
Somewhere I have the example I sent off to Matt F. eons ago, when the early Collada testing was happening; I'll see if I can locate it.
OF course, this was all done, before beta3 or any 1.0 Release beta for that matter, can't guarantee same results. Chris R. should be able to outline the precise steps for a DAE loading of DSQ....
#16
Found it....above is my constructor scripting to do the dirty work...
Notice how I head the datablock[may be 'singleton' now and not work??]and then point to the DAE binary with appropriate pathing...the rest is simple 'loading' of DSQ files, may even allow for extra nodes in DSQ file when loading with upgrades to the DTS format with version 26.
Again, Chris R. is the writer of the Collada loader and may prove a better resource for this functionality I did see working some time ago.
Good Luck!
What I did was to export a KORK DAE with same bone structure as the default DSQ sequences...and it worked!
01/03/2011 (5:58 pm)
function TorqueOrcDae::onPreload(%this)
{
%this.dumpShape();
}
datablock TSShapeConstructor(TorqueOrcDae)
{
baseShape = "./cherryCola_KORK.dae";
sequence0 = "~/data/shapes/players/animations/player_root.dsq root";
sequence1 = "~/data/shapes/players/animations/player_forward.dsq run";
sequence2 = "~/data/shapes/players/animations/player_back.dsq back";
sequence3 = "~/data/shapes/players/animations/player_side.dsq side";
sequence4 = "~/data/shapes/players/animations/player_lookde.dsq look";
sequence5 = "~/data/shapes/players/animations/player_head.dsq head";
sequence6 = "~/data/shapes/players/animations/player_fall.dsq fall";
sequence7 = "~/data/shapes/players/animations/player_land.dsq land";
sequence8 = "~/data/shapes/players/animations/player_jump.dsq jump";
sequence9 = "~/data/shapes/players/animations/player_diehead.dsq death1";
sequence10 = "~/data/shapes/players/animations/player_diechest.dsq death2";
sequence11 = "~/data/shapes/players/animations/player_dieback.dsq death3";
sequence12 = "~/data/shapes/players/animations/player_diesidelf.dsq death4";
sequence13 = "~/data/shapes/players/animations/player_diesidert.dsq death5";
sequence14 = "~/data/shapes/players/animations/player_dieleglf.dsq death6";
sequence15 = "~/data/shapes/players/animations/player_dielegrt.dsq death7";
sequence16 = "~/data/shapes/players/animations/player_dieslump.dsq death8";
sequence17 = "~/data/shapes/players/animations/player_dieknees.dsq death9";
sequence18 = "~/data/shapes/players/animations/player_dieforward.dsq death10";
sequence19 = "~/data/shapes/players/animations/player_diespin.dsq death11";
sequence20 = "~/data/shapes/players/animations/player_looksn.dsq looksn";
sequence21 = "~/data/shapes/players/animations/player_lookms.dsq lookms";
sequence22 = "~/data/shapes/players/animations/player_scoutroot.dsq scoutroot";
sequence23 = "~/data/shapes/players/animations/player_headside.dsq headside";
sequence24 = "~/data/shapes/players/animations/player_recoilde.dsq light_recoil";
sequence25 = "~/data/shapes/players/animations/player_sitting.dsq sitting";
sequence26 = "~/data/shapes/players/animations/player_celsalute.dsq celsalute";
sequence27 = "~/data/shapes/players/animations/player_celwave.dsq celwave";
sequence28 = "~/data/shapes/players/animations/player_standjump.dsq standjump";
sequence29 = "~/data/shapes/players/animations/player_looknw.dsq looknw";
sequence30 = "~/data/shapes/players/animations/player_dance.dsq dance";
sequence31 = "~/data/shapes/players/animations/player_range.dsq range";
};Found it....above is my constructor scripting to do the dirty work...
Notice how I head the datablock[may be 'singleton' now and not work??]and then point to the DAE binary with appropriate pathing...the rest is simple 'loading' of DSQ files, may even allow for extra nodes in DSQ file when loading with upgrades to the DTS format with version 26.
Again, Chris R. is the writer of the Collada loader and may prove a better resource for this functionality I did see working some time ago.
Good Luck!
What I did was to export a KORK DAE with same bone structure as the default DSQ sequences...and it worked!
#17
I am currently thinking it may just be wiser to go back to the vendor and ask them to export a DTS file and DSQ for me instead, as at my current level of capability that's plenty to keep me busy.
As a side note, I'm glad to see you still posting, Rex--my perception of you as a most knowledgeable authority on the subject remains confirmed. Have you ever thought of writing down some of your experience in a formal fashion? I'd buy your book in a heartbeat!
01/05/2011 (6:36 pm)
I'm trying to get the Collada->animations working at the moment on a model I bought last week. I haven't been able to quite "get it" yet, instead I throw a script error although I followed the example given in Michael's docs with some precision. I am currently thinking it may just be wiser to go back to the vendor and ask them to export a DTS file and DSQ for me instead, as at my current level of capability that's plenty to keep me busy.
As a side note, I'm glad to see you still posting, Rex--my perception of you as a most knowledgeable authority on the subject remains confirmed. Have you ever thought of writing down some of your experience in a formal fashion? I'd buy your book in a heartbeat!
#18
-Because getting the dae and the source dts for dsq´s to match is not easy when the dae import into T3D throws nodes around. -We can't all be as good at matching them up as Rex ;-)
@ Netwyrm
Documentation: the documentation section have been approved, but have been seriously neglected the past 6 months regarding the art pipes into T3D.
so thanks to guys like EB and REX (and others who pitch in) for helping us noobs angin and again!
01/10/2011 (7:22 am)
As I recall there is a dae2dts.exe (for download in the account) which was meant for stripping .dsq sequences from the .dae file. Has anyone ever got this to work?-Because getting the dae and the source dts for dsq´s to match is not easy when the dae import into T3D throws nodes around. -We can't all be as good at matching them up as Rex ;-)
@ Netwyrm
Documentation: the documentation section have been approved, but have been seriously neglected the past 6 months regarding the art pipes into T3D.
so thanks to guys like EB and REX (and others who pitch in) for helping us noobs angin and again!
#19
Mike
02/07/2011 (9:35 pm)
Someone correct me if I'm wrong, but I think there is another difference between DTS and DAE files. To animate trees in the T3D Forest Editor you must paint the vertices of the trees. You have to use DAE for this as DTS doesn't support vertex colors.Mike
#20
02/08/2011 (5:50 am)
correct, vertex colors are not supported by any public DTS exporters at this time. 
Associate Steve Acaster
[YorkshireRifles.com]
Collada Test subforum was when it was experimental for the older TGEA engine.
CollisionType set to visible can be expensive processor-wise, kinda depends on how you model. Lots of small polys means lots of collision surfaces to calculate. A few wide, square polys means less to calculate. A seperate box-like mesh for collision means faster collision/less resources. There's some info on replacing your colmeshes with fast scripted collision in the support->documentation->T3D section.