DTS importer for blender

#1 Hm, I don't think there's an IMporter for .dts. Only exporters.

#2 Importers have generally gotten the "kabosh" around here. Bottom line: If the developers want their models to be manipulated, they'll include the source. Otherwise, it's piracy protection.

-Eric

#3 There are no DTS importers for any modelling program, most likely to prevent users from easily editing the models - heck, I don't know why, but there are none :) So basically you just gotta save all your models as blender's format and edit them using that, and export them to DTS when it's ready for the game.

#4 Hmmm it makes since. But still rather annoying.

#5 Not totally true. There is at least one fully working .dts importer for Blender, but it's not for public consumption.
That will tell you that you can write your own...
the one I'm thinking of is from a screenie J. Ritter (iirc) posted a while back, about having integrated pyTorque and Blender, which allowed him to have a TGE viewport in Blender (again iirc), which allowed him to import the .dts from a memory dump or somesuch.
Totally doable, it's just the community's opinion (and I concur) that opening that particular can of worms, if not Pandora's box, would not be a "Good Thing" (hehe ;)) for the community, raising some IP piracy issues as mentioned by other posters.
Feel free to code your own for your own private use, but don't expect most of the core community to approve of a public release of such a tool...

#6 Here is my take on the issue :

Firstly, any game model format is just another method for storing your model. Usually when you export your model to say, dts, you loose alot of editor specific information. However, the exporter also adds information and/or stores it in a different way to aid the game engine in loading / rendering it faster.

It is inevitable that at some time, providing your game is popular enough, that people *may* want to edit the game (aka modding).
The good thing to do would be to release "source" to some of these models and/or documentation to aid modders to mod your game, in the form of an "sdk".
However, some developers prefer not to go down the mod route, and wish to protect their content for various reasons.

This is where the importer issue comes in.
With an importer, your customer can just click, drag, and hey presto, you have the game model imported into your favourite modelling app. No need to wait for the developer to release any "sdk", and you don't even need to ask for permission (in a technical sense).
Some developers certainly would not like it if one of their customers produced "Billy Bob's Hacked up character" mod for the game they so hardly worked on. If the mod is bad, then it can be damaging for the game's reputation too.

Now, lets consider another situation.
What if you, "Developer X", have been working hard on making your high poly, cool looking character model.
You are so excited that your character model works in-game that accidentally press the "delete" button.
You suddenly realise that your characters arms don't move round correctly, so you decide to load it up again to change it.
Oh dear. The file has gone! All that hard work has gone to waste. All you are left with is your model in dts format!. You didn't even make any backups!!!

This is where an importer can be useful. You can recover your lost work from the game model files.
However, in this process, you will loose editor specific information (and soon). But isn't it better than having a buggy game model that you can't change?

Importers can be both useful and a bad idea at the same time.

Lastly, on the security side, i would say that it is a bad idea to rely on the model format to secure your models. If you really want to secure your content, encrypt it or something.
Nobody is going to steal your models anyway, unless they are lazy. Its not that hard to spot your model in another game, is it?

#7 I think that DTS is meant to be a write-only format. There are certainly cases where importing it could be handy. But I think that it's not worthwhile to have a bunch of DTS importers running around, when we're still working on getting a full uptodate set of DTS _exporters_.

#8 I think the issue of an importer stems from not having a working player model in Blender format. If a player model were in blender format then someone could "see" how it was done for Blender. I know that there is one for Max and I actually converted that model to DXF then imported it into Blender. However, you lose all the bones and nodes. I have not as yet attempted to tackle the player model just yet. I have built a hover vehicle with one mount point.

That brings me to a different questions: Can you animate a mount point? Since in Blender the mount points are bones. Can you cause the rider to rock back and forth by creating animations for mount point bones?

Thanks,
Frank

#9 Frank,

I am in the progress of making a character rig for blender, though i am unsure how long it will take me to finish.

However, what i have done is basically copy the standard Biped skeleton from a reference milkshape player. Not quite got an animation on it yet, since blender has a horrible limit on the ipo names :(

#10 On a sidenote, it is currently not possible to import skeletons (or armatures, or nodes, or whatever you want to call them) into blender.

Frank,

It is possible to animate mount points, since are basically just regular nodes (like all the bones are).

#11 James,

Great, if you need someone to test the armature let me know. Remember, watch out for animations that are inverted like I found in the Z axis (in the IPOs it is Y for some reason, even though it affects the Z).

I have also noticed some wierd things with Blended animations. I have one that has two blocks that are animated with 3 animations. The bottom bone is the root for the other bones and has the bottom block attached to it. The upper block is attached to the next bone up. If I animate the bottom bone the whole thing turns as expected. If I animate one of the top animations with the bottom animation the bottom block jumps up with the top block. When I turn on all three the bottom block stays where it should and the two top blocks blend correctly.

I am not sure how to better explain it. I can send you the blend and dts if you are interested. BTW: this is all post export. I am turning the animations on and off using a script to control the animation sequences. It may just be my lack of understanding the animations that are blended.

Thanks,
Frank

#12 Frank,

Send me the dts and i'll have a look :)

#13 Greetings!

If you're interested, this topic had been debated by the community last January here:

www.garagegames.com/mg/forums/result.thread.php?qt=8897

- LightWave Dave

#14 I have been thinking about this DTS importer business. It seems to me a lot of people are assuming that if you don't make an importer it will be unlikely it will get made. This is a mistake.

History tells us that persistent people can make very complex pieces of code with little or no information. Example: the first public BSP tree compiler for Doom was made by a programmer that wanted to make levels not just move objects around. Lesson: you cannot rely on the DTS format to "protect" your work.

If you want protection you should consider encryption to hide the formats until game play. One way to do this is a virtual filesystem that hides the decryption algorithms to access an encrypted volume of data. Another protection method is to change the filenames to a different extension. Or develop your own model format.

No matter how you look at it the DTS format is "open". All it takes is a license to Torque to get it. If someone is truly out to steal artwork for use in another game then there is nothing you can do to prevent it other than creating a proprietary system to guard it.

There are some ways you can protect your data using the format in a non-standard way in addition. One could change the byte ordering of data at a low level location in the DTS class for a "protected" shape (or some other obfuscasion scheme). Some "flag" could be used to inform the program that this is a protected shape. So unless the "rouge dts importer" knows this proprietary format they can't get the data easily. This would also allow consumer produced shapes to be used in the game. It would keep the protection sheme from breaking compatability with existing "standard" dts shapes.

To recap: You cannot rely on a published format to protect your data unless that format provides explicit protections.

There is my 2 cents, er... wooden nickels?
Frank

P.S. It should also be noted that ID did not suffer from someone being able to get at their content. I would hazard to say that this enhanced their success tremendously. Releasing "some" control over content may be in your favor.

#15 I wonder if we will be able to continue to monitor ourselves. It seems pretty inevitable that someone will make a .DTS decompiler.

#16 Frank - You have some good points. As I recall, though, the reason that DTS importers are less than optimal is that DTS is not a good format for editing. It's already assumed that if people have Torque source they can read and manipulate them.

"If you want protection you should consider encryption to hide the formats until game play... Or develop your own model format." Torque does that. ;)

But the goal is not to keep model data secure. DTS has the nice side effect of making it slightly trickier for people to modify game assets, and combined with the CRC checking, is an effective cheating deterrent, but this is just gravy.

The point of DTS is to provide an efficient means of getting model data into the game. It's not a format that is meant for editing. And given that, it seems sort of silly to make converters to let people edit it, when almost any legitimate user is going to have access to the source art which is much more useful for editing.

Why not focus on something more useful, like an interior editor or a good max2dif exporter, or any of the other things the community is clamoring for?

People have already written DTS decompilers and importers, and there are rare situations where they are immensely useful. Most of the time, though, they're not very relevant.

If you want to write one, go ahead. GG's not going to stop you. But I don't think that there's a lot need for it or a lot of good applications for it, and that it brings with it the possibility for a lot of confusion and misuse.

#17 Again, compliments on the great work with the exporter script, but I have one small (I hope!) question.. just what IS needed in order for a model to be used as a player object, besides the mesh? I seem to have no problems creating objects that are merely static or have simple animations (havn't tried anything large yet), but each time I try creating a player model it locks up either at the end of lighting, with no errors in the command log file. Are there any required armature/mesh objects in order for a player to be spawned? (so far the ones I've made for player spawning have contained no animation, and I *believe* the scripts are correct). Any help would be greatly appreciated.

#18 Jeff,

I don't think you require any specific bones in your model, except for things like cam, mountX, and eye.

As for animations, i think you need certain animations to be present in your model for it to work as a player.

Try following the player model tutorials for 3dsmax, and adapt them for blender.

#19 Thank you James, you just made my week, got it to finally load in game.. did a search for more 3dsmax tutorials and found a new one (well, new to me).