Mdl, md2, md3, etc. support
by Bil Simser · in Torque Game Engine · 07/02/2003 (9:12 pm) · 12 replies
Hi guys,
I've been looking at the md3 support that Lord Varmint added to the Torque engine. While it's beta and needs to work some bugs out, I'm curious if the dts format is really that cumbersome/difficult/inefficient to work with or do people just want choices. I mean, is it worth taking the time to code in support for other game formats (not just md3 but maybe md2, etc.) or should I just stick with the dts format.
Pros:
-many models available in various formats could be used in Torque games (assuming the creators of the original models are ok with that)
-don't need the source models (max, 3ds) to work with in order to use model. Can use the mdx format directly (although you could argue that you can export from whatever format it's in using say Milkshape into 3ds then import into MAX and generate the dts file, but that can be onorous).
Cons:
-extra coding needed to support new formats as they become available (e.g. not sure what format they're using for Doom III)
-engine may not be optimized for this format and would need a lot of fixes to get it tuned right
For example would it be worth it (and feasible) to do direct 3ds conversions right in the engine or should there only be one native format (dts) in the engine and the various tools to get there (an mdx -> dts converter for example, although you could import into milkshape the quake format then export using the dts exporter). Additionaly is it even valuable to support formats other than md3 or is that the best one to keep. MDL and MD2 are both antiquated and not as flexible as MD3 but there are other formats (like converting Unreal -> DTS for example).
Just wondering if it's worth pursuing any of this.
Thanks!
I've been looking at the md3 support that Lord Varmint added to the Torque engine. While it's beta and needs to work some bugs out, I'm curious if the dts format is really that cumbersome/difficult/inefficient to work with or do people just want choices. I mean, is it worth taking the time to code in support for other game formats (not just md3 but maybe md2, etc.) or should I just stick with the dts format.
Pros:
-many models available in various formats could be used in Torque games (assuming the creators of the original models are ok with that)
-don't need the source models (max, 3ds) to work with in order to use model. Can use the mdx format directly (although you could argue that you can export from whatever format it's in using say Milkshape into 3ds then import into MAX and generate the dts file, but that can be onorous).
Cons:
-extra coding needed to support new formats as they become available (e.g. not sure what format they're using for Doom III)
-engine may not be optimized for this format and would need a lot of fixes to get it tuned right
For example would it be worth it (and feasible) to do direct 3ds conversions right in the engine or should there only be one native format (dts) in the engine and the various tools to get there (an mdx -> dts converter for example, although you could import into milkshape the quake format then export using the dts exporter). Additionaly is it even valuable to support formats other than md3 or is that the best one to keep. MDL and MD2 are both antiquated and not as flexible as MD3 but there are other formats (like converting Unreal -> DTS for example).
Just wondering if it's worth pursuing any of this.
Thanks!
#2
Seeing as TGE is for Indies, Is it feasible to think they dont have 3000 (more I think) to buy a tool such as 3DSMAX; Id love to see TGE Offically support other formats, other then DTS.
07/03/2003 (8:52 am)
I also would like more model formats. Seeing as MS3D Doesnt directly support DTS. & I dont think Iv seen anyone get a MS3D created Character model, Into TGE, Without the use of 3DSMAX. Seeing as TGE is for Indies, Is it feasible to think they dont have 3000 (more I think) to buy a tool such as 3DSMAX; Id love to see TGE Offically support other formats, other then DTS.
#3
Edit: Reread the first post. I think the latter choice is better, that way there is only one file reader to keep in sync with the 3space system's featureset.
07/03/2003 (12:45 pm)
A tiny bit of history: The D in DTS stands for Dynamix. It's an in-house format that they used in many of their 3d games... Therefore, it might be more worthwhile to write convertes to/from DTS, rather than converting the engine itself to read the formats.Edit: Reread the first post. I think the latter choice is better, that way there is only one file reader to keep in sync with the 3space system's featureset.
#4
10/28/2003 (7:17 am)
I think it would be nice to see a more poerful exporter. Or maybe an importer in the torque engine that could add appropriate collision information to the mesh that is being added. Something .ase and how it works in unreal. At the moment dts can be very annoying. But I'm new to it. 
#5
I haven't had much opportunity to create many models for use in Torque, but the reason is mostly because of the "clunky" workflow. Anything that would make the workflow smoother, so asset creation is faster, would definitely be an improvement.
MD2 and those other formats aren't that hard to implement, but integrating them into this existing engine that already uses another format may be more difficult than using them in an engine that was written from scratch.
10/28/2003 (5:49 pm)
I would like to be able to use UnrealEd instead of Quark or Hammer, but we're not talking about map editors right now. :DI haven't had much opportunity to create many models for use in Torque, but the reason is mostly because of the "clunky" workflow. Anything that would make the workflow smoother, so asset creation is faster, would definitely be an improvement.
MD2 and those other formats aren't that hard to implement, but integrating them into this existing engine that already uses another format may be more difficult than using them in an engine that was written from scratch.
#6
10/28/2003 (6:30 pm)
Erm wait aren't you not allowed to use ID's formats in commercial games without obtaining a licence? Not sure about this tho but someone might want to check that out.
#7
The big one is that importing other types straight into the engine involves reading the data and then converting it to the internal format of the enigne for optimization reasons. If, god forbid, that internal layout ever changed you have a lot more work to do. If its just a stand-alone converter then you don't have that problem.
It is also easier to maintain a converter, and add to it.
It isn't neccesariyl difficult to do it in the engine, it just is more practical and better abstractino to do it as a converter.
Nowe granted you will get those who whine about having a converter, but you know the old saying; You can please all of the people some of the time, and some of the people all of the time but you can never please all of the people all of the time.
10/28/2003 (6:46 pm)
Typically a stand alone converter is your best bet for a few reasons.The big one is that importing other types straight into the engine involves reading the data and then converting it to the internal format of the enigne for optimization reasons. If, god forbid, that internal layout ever changed you have a lot more work to do. If its just a stand-alone converter then you don't have that problem.
It is also easier to maintain a converter, and add to it.
It isn't neccesariyl difficult to do it in the engine, it just is more practical and better abstractino to do it as a converter.
Nowe granted you will get those who whine about having a converter, but you know the old saying; You can please all of the people some of the time, and some of the people all of the time but you can never please all of the people all of the time.
#8
This is an often repeated rumor, but it's false. It's impossible to legally protect a file format without a patent, and ID software has gone on record as saying they don't care much regardless.
That said, I think it would be rather silly to support more than one format in the engine. That's twice the code to maintain for no really compelling benefit.
On the other hand, dropping DTS completely in exchange for a more widely used format with comparable features would be a really good idea. If Torque used the same format as HL2 or Doom 3, the modding communities would be writing all these exporters we need for us.
10/29/2003 (6:42 am)
Quote:Erm wait aren't you not allowed to use ID's formats in commercial games without obtaining a licence? Not sure about this tho but someone might want to check that out.
This is an often repeated rumor, but it's false. It's impossible to legally protect a file format without a patent, and ID software has gone on record as saying they don't care much regardless.
That said, I think it would be rather silly to support more than one format in the engine. That's twice the code to maintain for no really compelling benefit.
On the other hand, dropping DTS completely in exchange for a more widely used format with comparable features would be a really good idea. If Torque used the same format as HL2 or Doom 3, the modding communities would be writing all these exporters we need for us.
#9
Forget about UnrealEd...Epic is fiercly protective of it and has no interest in allowing it to be used for games that are not based on the Unreal engine. I have had several clashes with Tim Sweeney and Mark Rein on this issue.
Both the dts and the dif formats need to go. They are unwieldy, inflexible, and nearly impossible to document fully. Honestly, I would go both routes...use a nice clean file format that is easy to write converters/exporters for but also have a clean internal interface in the engine to make writing new read/write functions trivial so that other propietary formats can easily be used if people so desire.
10/29/2003 (8:38 am)
You have to pay id software $5000 if you use any of the tools based off their code (like the various versions of radiant, most of the bsp compilers, and most of the model exporters) to create anything in a commercial project. This unfortunately doesn't leave you with many options.Forget about UnrealEd...Epic is fiercly protective of it and has no interest in allowing it to be used for games that are not based on the Unreal engine. I have had several clashes with Tim Sweeney and Mark Rein on this issue.
Both the dts and the dif formats need to go. They are unwieldy, inflexible, and nearly impossible to document fully. Honestly, I would go both routes...use a nice clean file format that is easy to write converters/exporters for but also have a clean internal interface in the engine to make writing new read/write functions trivial so that other propietary formats can easily be used if people so desire.
#10
I think that if you havent got an artist with Max and good technical knowledge to be able to setup and rig the characters in a way that DTS export works for, then its REALLY hard to get anything in for a character.
I once even thought of doing this work, but looked at the DTS format as it was and quickly decided it would be too much effort for no reward.
If we have a simpler intermediate format (i.e. a documented file format with simpler specs) then creating exporters that work will be trivial and are much more likely to happen.
But I think this is a thing for GG to decide. As it is, I am doing a space game, and that has NO characters in it to cause me trouble. Ive been happily exporting my own meshes without any problems.
So I'm ok to take a "wait and see" attitude :)
Phil.
10/29/2003 (8:59 am)
I'm with matt there. I think I said this when GG first opened, and I'm still of the same opinion, torque would be much better off if there were loaders for other popular game formats (halflife 1 mdl was my case in point at the time).I think that if you havent got an artist with Max and good technical knowledge to be able to setup and rig the characters in a way that DTS export works for, then its REALLY hard to get anything in for a character.
I once even thought of doing this work, but looked at the DTS format as it was and quickly decided it would be too much effort for no reward.
If we have a simpler intermediate format (i.e. a documented file format with simpler specs) then creating exporters that work will be trivial and are much more likely to happen.
But I think this is a thing for GG to decide. As it is, I am doing a space game, and that has NO characters in it to cause me trouble. Ive been happily exporting my own meshes without any problems.
So I'm ok to take a "wait and see" attitude :)
Phil.
#11
Once Quake3 is GPL'd it would be very worthwhile to replace map2dif with the Quake3 BSP generation tools... heck, it's worthwhile to do it with the Quake2 stuff...
As far as MDL, MD2, MD3... give me skeletal or give me death... I've used Cal3D on commercial projects (as have others)... it's reasonable... Halflife has a decent model format too...
I like DTS's power, but it is unwieldy as others have said.
-J
10/29/2003 (9:06 am)
You do not have to pay id software a dime for using the Quake2 BSP generation tools on a commercial product... the GPL says so... Once Quake3 is GPL'd it would be very worthwhile to replace map2dif with the Quake3 BSP generation tools... heck, it's worthwhile to do it with the Quake2 stuff...
As far as MDL, MD2, MD3... give me skeletal or give me death... I've used Cal3D on commercial projects (as have others)... it's reasonable... Halflife has a decent model format too...
I like DTS's power, but it is unwieldy as others have said.
-J
#12
10/29/2003 (10:50 am)
Mark: ahh ok thanks for clearing that up. I guess I was getting mixed up with their tools licence and model ideas. 
Torque Owner Mike Stoddart