The unsatisfying max2dts exporter
by Ulf Maagaard · in Torque Game Engine · 04/05/2005 (1:01 pm) · 17 replies
After battling the max2dts exporter for the last couple of days, I have rounded up some issues that are driving me mad. I've gotten to the point where I can export dts files. This took blood, sweat and tears, and has left me with a couple of unanswered questions:
1. It seems that you cannot have two meshes that differ only by a trailing number, as the exporter interprets the numbers as levels of detail. Example: I cannot have two meshes named finger1 and finger2, as the exporter interprets "1" and "2" as levels of detail, resulting in an identical name of "finger" for the two meshes (Under the assumption that the nodes also have the same size). Is this correct?
2. Being a complete newbie at 3dsmax and torque, I am concerned by the "renumber selection" option, which apparently assigns new trailing numbers to all meshes. In the example above, this obviously destroys the mesh name uniqueness. But even if this wasn't the case, would it not also destroy any animations/general functionality relying on the original mesh names? In short: Won't a new trailing mesh number destroy my animations?
3. If level of detail is merely optimization, why is it placed inside the mesh name, which has the critical demand of being unique? Why not stick to placing it in a dummy node, or move it away into the configuration file altogether?
4. From surfing around in the forum, it seems the max2dts exporter is raising a lot of questions from us newbies. In my opinion, the map2dts exporter is a very large bump in the road to understanding and appreciation of Torque. Do you know of a more fool-proof approach to exporting dts files?
1. It seems that you cannot have two meshes that differ only by a trailing number, as the exporter interprets the numbers as levels of detail. Example: I cannot have two meshes named finger1 and finger2, as the exporter interprets "1" and "2" as levels of detail, resulting in an identical name of "finger" for the two meshes (Under the assumption that the nodes also have the same size). Is this correct?
2. Being a complete newbie at 3dsmax and torque, I am concerned by the "renumber selection" option, which apparently assigns new trailing numbers to all meshes. In the example above, this obviously destroys the mesh name uniqueness. But even if this wasn't the case, would it not also destroy any animations/general functionality relying on the original mesh names? In short: Won't a new trailing mesh number destroy my animations?
3. If level of detail is merely optimization, why is it placed inside the mesh name, which has the critical demand of being unique? Why not stick to placing it in a dummy node, or move it away into the configuration file altogether?
4. From surfing around in the forum, it seems the max2dts exporter is raising a lot of questions from us newbies. In my opinion, the map2dts exporter is a very large bump in the road to understanding and appreciation of Torque. Do you know of a more fool-proof approach to exporting dts files?
#2
Still, I feel this is a workaround. I fail to see the reason for interpretation of trailing numbers as level of detail, when a dummy node at top of the node hierarchy would do the job just as well - without imposing cumbersome restrictions.
Maybe you or someone else could shed light on the apparant need for having individual detail levels for each single mesh part. And also, has anyone managed to automate the process (including automatic construction of the bounding box).
04/06/2005 (12:32 am)
Brian, thanks for your reply. I have also considered that option. However, since we've got very very many max files to export from, I want to make sure that my understanding of the limitations are correct, before we start adopting changes to existing naming conventions.Still, I feel this is a workaround. I fail to see the reason for interpretation of trailing numbers as level of detail, when a dummy node at top of the node hierarchy would do the job just as well - without imposing cumbersome restrictions.
Maybe you or someone else could shed light on the apparant need for having individual detail levels for each single mesh part. And also, has anyone managed to automate the process (including automatic construction of the bounding box).
#3
As for the trailing numbers of the LOD settings these numbers are linked to on screen size of your mesh in game or at least that is what I have been told. It hops from LOD to LOD based on these numbers. You have your detail nodes to set these properties it is only logics that you number the according LOD mesh the same as the detail nodes. So the level of detail is linked to distance that the viewer is from the object which in turn shows your model bigger or smaller on the screen. This activates the detail nodes showing the according meshes with less detail since from the appointed distance your model would be x pixels big so you wouldn't be able to see that detail anyway.
If you use the multi-res modifier you won't have this problem since the LOD meshes will be created on the go. You'll just have to make a snapshot from your original mesh and name it MULTIRES::meshnamehere. Look into the documentation it is all described there.
The exporter might feel unsatisfying to you but there is a lot that can be done with it if you know your way around.
04/06/2005 (1:28 am)
I don't quite understand the need of numbering your meshes in a scene but you probably have some kind of need for that. When doing a segmented model I usually use left and right as a ref. Something like handL, handR, armL, armR that works fine for me but like I said you probably have other use for it.As for the trailing numbers of the LOD settings these numbers are linked to on screen size of your mesh in game or at least that is what I have been told. It hops from LOD to LOD based on these numbers. You have your detail nodes to set these properties it is only logics that you number the according LOD mesh the same as the detail nodes. So the level of detail is linked to distance that the viewer is from the object which in turn shows your model bigger or smaller on the screen. This activates the detail nodes showing the according meshes with less detail since from the appointed distance your model would be x pixels big so you wouldn't be able to see that detail anyway.
If you use the multi-res modifier you won't have this problem since the LOD meshes will be created on the go. You'll just have to make a snapshot from your original mesh and name it MULTIRES::meshnamehere. Look into the documentation it is all described there.
The exporter might feel unsatisfying to you but there is a lot that can be done with it if you know your way around.
#4
As you correctly speculate, we have reasons for our existing naming conventions. I do not yet have enough knowledge of the engine to change the interpretation of trailing numbers as LOD, so we are working on an option in the exporter to append a "__lod" to node names.
I now understand the neccessary link between detail nodes and individual mesh nodes. But I still fail to appreciate this solution as nothing but a workaround. Besides what I have already mentioned, I am also concearned by the fact, that LOD apparantly has to be decided at a very early stage in development, and that LOD cannot be changed later on, without reexporting all animations. Is this correct?
04/06/2005 (1:55 am)
Pascal, thanks for your reply. I will look into multires.As you correctly speculate, we have reasons for our existing naming conventions. I do not yet have enough knowledge of the engine to change the interpretation of trailing numbers as LOD, so we are working on an option in the exporter to append a "__lod" to node names.
I now understand the neccessary link between detail nodes and individual mesh nodes. But I still fail to appreciate this solution as nothing but a workaround. Besides what I have already mentioned, I am also concearned by the fact, that LOD apparantly has to be decided at a very early stage in development, and that LOD cannot be changed later on, without reexporting all animations. Is this correct?
#5
Also keep in mind that when you do skeleton animations using the skin modifier to weight vertexes the actual mesh can be exported separate from the animation sequences.. So once you have all your sequences exported there is no need to get back on them once you export a changed mesh as long as you don't mess with your rig.
The way the exporter handles the LOD and a lot of other things is very logical to me, you just need to look into it's possibilities a bit more I think you will be surprised. Give it some time sooner or later it will click for you I know it did for me :)
04/06/2005 (5:49 am)
LOD can easily be changed any time you see needed. Keep in mind that you only animate your original mesh not the lower detailed once. So changing LOD settings just requires you to rename the detail nodes and the LOD meshes this can be done anywhere in the process. Also keep in mind that when you do skeleton animations using the skin modifier to weight vertexes the actual mesh can be exported separate from the animation sequences.. So once you have all your sequences exported there is no need to get back on them once you export a changed mesh as long as you don't mess with your rig.
The way the exporter handles the LOD and a lot of other things is very logical to me, you just need to look into it's possibilities a bit more I think you will be surprised. Give it some time sooner or later it will click for you I know it did for me :)
#6
Also, we've completed the "__lod" append option in the exporter, which has solved our initial problems concearning clashing naming conventions.
I will take your advice on giving things time and chances :-).
04/06/2005 (6:59 am)
Pacal, thanks for the encouragement and info, which puts my LOD suspicion at rest. I will keep your info in mind.Also, we've completed the "__lod" append option in the exporter, which has solved our initial problems concearning clashing naming conventions.
I will take your advice on giving things time and chances :-).
#7
I know that GG has recognised this problem and the way I know them they are probably working on something that will make all our lives a bit easier in the future.
04/06/2005 (7:14 am)
No problem man. We all know that the exporter can be a bitch because it has quite a steep learning curve.I know that GG has recognised this problem and the way I know them they are probably working on something that will make all our lives a bit easier in the future.
#8
We are now struggling with exporting animations from 3dsmax. I don't want to throw in the towel yet, because there is a lot more stuff to attempt. Instead, I just need to clear up two things:
1. It seems that the player.max file, which is included in the sdk, does not have animations included. Is this correct?
2. It seems there is not a single .max file included in the sdk, which would be valid to test export of dts and dsq files from 3dsmax. Is this correct?
Basically, I am looking for an example .max file, constructed to fulfill all the requirements for exporting dts/dsq files, as they are stated in the tutorials from GG. I want to test the exporter on such a file, in order to reassure myself, that this whole export process is in fact possible at all.
04/07/2005 (12:37 pm)
Back again with more questions :-)We are now struggling with exporting animations from 3dsmax. I don't want to throw in the towel yet, because there is a lot more stuff to attempt. Instead, I just need to clear up two things:
1. It seems that the player.max file, which is included in the sdk, does not have animations included. Is this correct?
2. It seems there is not a single .max file included in the sdk, which would be valid to test export of dts and dsq files from 3dsmax. Is this correct?
Basically, I am looking for an example .max file, constructed to fulfill all the requirements for exporting dts/dsq files, as they are stated in the tutorials from GG. I want to test the exporter on such a file, in order to reassure myself, that this whole export process is in fact possible at all.
#9
There is no example files with the SDK that demonstrates a complete working set of animations.
04/07/2005 (1:25 pm)
It is possible.. the Girl Pack content pack has a complete set of animations that work in the TGE.. at the moment, all of the animations are in the DTS, but setting them up to export as dsqs would be relatively trivial.There is no example files with the SDK that demonstrates a complete working set of animations.
#10
Sorry for dragging this issue around - but being able to export animations from the max file is essential to us.
Last couple of bonus questions: Has anyone had experience with dts/dsq export from lightwave? Also, can you recommend a place to look for art resources and interiors (valve 220 .map files or dif files).
04/07/2005 (3:11 pm)
Joe, thanks for the quick response. I just need to have you to confirm this: Girl pack only contains animations in dts files - there are no animations in the max files. Is this correct? If so, then even the girl pack won't give us a max file, from which we can both do both a dts and a dsq export.Sorry for dragging this issue around - but being able to export animations from the max file is essential to us.
Last couple of bonus questions: Has anyone had experience with dts/dsq export from lightwave? Also, can you recommend a place to look for art resources and interiors (valve 220 .map files or dif files).
#11
04/07/2005 (3:20 pm)
The girl pack has the animations in the max file (and maya files). The .max file will allow you to either export the DTS from it (with all animations in one DTS) or, so a save as on the max file for each sequence, and export each DSQ separately,
#12
In answer to my own question regarding free art resources, I recommend http://www.gamebeavers.org/
04/08/2005 (2:25 pm)
Thanks all, I am getting closer all the time :-).In answer to my own question regarding free art resources, I recommend http://www.gamebeavers.org/
#13
I've read tutorial VERY well, and 2 things that make me crazy -
"Objects must be embedded"
"Objects that have the skin modifier applied to them are recognized by the exporter as skin objects. They should be unlinked and floating in the scene (they do not have to be a part of the shape subtree)"
Any ideas????
04/10/2005 (12:08 pm)
Ulf, man, the same problem!Working with lightwave, converting to softimage->max (lw->max doesn't support weight maps). But the problem is- there is written, that objects in max must be embedded to convert. But skinned objects must be unlinked. So, i unlink skinned object, and it doesn't convert!I make my skinned object embedded, and it doesn't convert too!WTF! I've read tutorial VERY well, and 2 things that make me crazy -
"Objects must be embedded"
"Objects that have the skin modifier applied to them are recognized by the exporter as skin objects. They should be unlinked and floating in the scene (they do not have to be a part of the shape subtree)"
Any ideas????
#14
the example shape in the max file pack and the girl pack both have examples of a working scene in 3dsmax and maya
04/10/2005 (12:29 pm)
In 3dsmax, if an object (mesh) has a skin modifier on it, it needs to be unlinked (or you will get transform doubling). The 'shape' is the skeleton, and it must be set up according to the docs to create a valid DTS exportable scene (in the appendix of the docs)the example shape in the max file pack and the girl pack both have examples of a working scene in 3dsmax and maya
#15
Just an example - i have a sphere.Then i add 2 bones, assign them via a skin modifier to object. Create bounding box correctly, name it "bounds". What should i do to convert it?
04/11/2005 (9:38 am)
2Joe- can you give a link to appendix, where's written on proper skeleton setup?Just an example - i have a sphere.Then i add 2 bones, assign them via a skin modifier to object. Create bounding box correctly, name it "bounds". What should i do to convert it?
#16
If you're still having a head ache with lw2max2dts converters, you might want to see this link www.garagegames.com/mg/forums/result.thread.php?qt=28846
04/14/2005 (12:17 pm)
2UlfIf you're still having a head ache with lw2max2dts converters, you might want to see this link www.garagegames.com/mg/forums/result.thread.php?qt=28846
#17
11/25/2005 (1:11 am)
Well, we got the damn thing working in the end, so I am happy. Just a pointer to the next newbie stumbling across this thread with the same problems: USE the ShowTool Pro. Don't leave home without it. If a newly exported dts isn't playing animations, chances are that you'll find some missing nodes by looking at the dts in the ShowTool, compared to a working dts. And do mess with the .cfg file (should be located same place as .max file). And do only export anims from a unskinned biped-thing - it takes a split second, as opposed to a skinned mesh taking a minute. And do remember those damn start/end time points.
Torque Owner Brian Richardson
As far as trailing numbers go, you just need to accept the fact that the exporter needs to use the trailing numbers for information. I'd work my naming scheme around it. For your hand example, maybe naming it fingerOne, fingerTwo would work. Or even finger_1_mesh, finger_2_mesh. That way you and the exporter can get the pieces of info you need from them.
Hope that helps.