Improving dtsUtility
by Andrew Grant · in Artist Corner · 08/17/2005 (5:59 pm) · 8 replies
The dtsUtility script leaves a lot to be desired from an artist's workflow perspective. I'll try to make some improvements to the script in the coming weeks to try and make it more useable.
The first thing to do is to speed up exporting. To do that, we hide all the geometry and then unhide after we're done. I put this in the exportshape() and exportsequence() functions.
Don't forget to unhide everything
Also, I noticed in the createBoundingBox script:
// Limitations
// Due to a BUG in Maya, all selected objects must be visible
// else the bounding box will be calculated incorrectly.
Er, why not unhide them?
The first thing to do is to speed up exporting. To do that, we hide all the geometry and then unhide after we're done. I put this in the exportshape() and exportsequence() functions.
// Hide scene shapes for speed
int $vis[];
$sceneShapes = 'ls -ni -type mesh';
for($i = 0; $i < size($sceneShapes); $i ++)
{
$obj = 'listRelatives -f -p $sceneShapes[$i]';
$sceneShapes[$i] = $obj[0];
$vis[$i] = 'getAttr ($sceneShapes[$i] + ".visibility")';
setAttr ($sceneShapes[$i] + ".visibility") 0;
}Don't forget to unhide everything
//Unhide hidden scene shapes for($i = 0; $i < size($sceneShapes); $i ++) setAttr ($sceneShapes[$i] + ".visibility") $vis[$i];
Also, I noticed in the createBoundingBox script:
// Limitations
// Due to a BUG in Maya, all selected objects must be visible
// else the bounding box will be calculated incorrectly.
Er, why not unhide them?
// unhide selected objects
int $vis[];
string $sceneShapes[];
for($i = 0; $i < size($sel); $i ++)
{
$vis[$i] = 'getAttr ($sel[$i] + ".visibility")';
setAttr ($sel[$i] + ".visibility") 1;
}
// do it
drawBoundingBox;
// rehide hidden selected objects
for($i = 0; $i < size($sel); $i ++)
setAttr ($sel[$i] + ".visibility") $vis[$i];
#2
I should say it 'leaves a lot to desire for THIS artist's workflow'. I'll keep you up to date with what I'm doing.
When exporting, I feel it's important to give a user all the important data that the exporter will use. The exporter window should tell the user where it will export to, the name of the file and the animation name. Most of the stuff in the sequence node should be displayed here so I won't be surprised. (at least the most common ones such as Cyclic) Also, I would assume the user will be exporting the current timeframe. (I only use one anim per file, more on that below)
I think I'll duplicate the Exporter Settings window and use it as the base for dtsExporter window.
I also don't think it would be too difficult to add a function to add the animation to a character's CS file when exporting. This will probably take a while to figure out the workflow, I'll let you know how it goes.
It seems like the exporter is built in such a way that it expects you to construct your maya scene in a way that reflects structurally the way the dts files work. Whether or not that's the case, it makes it more difficult then is necessary for the artist.
For instance, would it not be easier to have all the detail nodes parented to the world instead of base01? Any shapes under a detail node would be exported to that detail level. This should work exactly the same with geometry weighted to a skeleton and shapes that are not. This way we visually connect our shapes together with their detail level, and we also wouldn't have to worry about the shape names being numbered correctly. (Remember, Maya will renumber stuff when you duplicate objects, import scenes, etc)
What is start01 for?
Do we ever export geometry parented to a bone? Does that work? Are there DTS's that have skeletal deformed meshes and non-deforming meshes? That would make things more difficult.
Following are some things that would be difficult to change or re-impliment with a script, but aren't impossible.
I do not do the thing where you have many animations in one maya scene. It's too difficult to maintain a scene like that in my view. So sequence nodes in my workflow, are unnecessary and add complexity. The only thing they do that couldn't be done as custom attributes in the root null is let you have multiple animation names and ranges in a scene. I could make the dtsExporter window update the sequence node's attributes (and name) accordingly. (not hard)
CFG files. I hate them. I generally save many versions of my maya scene, and I want any special export options to go along with them. I don't want to be surprised with missing nodes when I export because I don't have a cfg file set up. I'm unaware of any reason not to use custom attributes in place of the .cfg file. For instance, add a boolean attribute AlwaysExport = true to anything you want to always export. When adding a cam or eye node in the scene, these should have these attributes set to true and thus export as would be expected for a first time user. A script could be made to automatically generate the cfg file (and destroy it - to be tidy) on export. (harder)
I'm still trying to figure out triggers. But I already find them displeasing. :)
08/17/2005 (9:56 pm)
Hi Danny,I should say it 'leaves a lot to desire for THIS artist's workflow'. I'll keep you up to date with what I'm doing.
When exporting, I feel it's important to give a user all the important data that the exporter will use. The exporter window should tell the user where it will export to, the name of the file and the animation name. Most of the stuff in the sequence node should be displayed here so I won't be surprised. (at least the most common ones such as Cyclic) Also, I would assume the user will be exporting the current timeframe. (I only use one anim per file, more on that below)
I think I'll duplicate the Exporter Settings window and use it as the base for dtsExporter window.
I also don't think it would be too difficult to add a function to add the animation to a character's CS file when exporting. This will probably take a while to figure out the workflow, I'll let you know how it goes.
It seems like the exporter is built in such a way that it expects you to construct your maya scene in a way that reflects structurally the way the dts files work. Whether or not that's the case, it makes it more difficult then is necessary for the artist.
For instance, would it not be easier to have all the detail nodes parented to the world instead of base01? Any shapes under a detail node would be exported to that detail level. This should work exactly the same with geometry weighted to a skeleton and shapes that are not. This way we visually connect our shapes together with their detail level, and we also wouldn't have to worry about the shape names being numbered correctly. (Remember, Maya will renumber stuff when you duplicate objects, import scenes, etc)
What is start01 for?
Do we ever export geometry parented to a bone? Does that work? Are there DTS's that have skeletal deformed meshes and non-deforming meshes? That would make things more difficult.
Following are some things that would be difficult to change or re-impliment with a script, but aren't impossible.
I do not do the thing where you have many animations in one maya scene. It's too difficult to maintain a scene like that in my view. So sequence nodes in my workflow, are unnecessary and add complexity. The only thing they do that couldn't be done as custom attributes in the root null is let you have multiple animation names and ranges in a scene. I could make the dtsExporter window update the sequence node's attributes (and name) accordingly. (not hard)
CFG files. I hate them. I generally save many versions of my maya scene, and I want any special export options to go along with them. I don't want to be surprised with missing nodes when I export because I don't have a cfg file set up. I'm unaware of any reason not to use custom attributes in place of the .cfg file. For instance, add a boolean attribute AlwaysExport = true to anything you want to always export. When adding a cam or eye node in the scene, these should have these attributes set to true and thus export as would be expected for a first time user. A script could be made to automatically generate the cfg file (and destroy it - to be tidy) on export. (harder)
I'm still trying to figure out triggers. But I already find them displeasing. :)
#3
Interestingly enough, one of the first iterations of dtsUtility that I wrote included a big exporter window with all the information in the scene. I removed it early on, because I was annoyed with having to open a large window every time I wanted to export a shape. I already have the settings I need set accordingly -- I don't need to be reminded of it every single time. However, I understand that each user will work differently, so this does become a matter of personal preference.
Auto-creating/editing .cs files would be very cool. However, if you get this working, be sure to have options to turn it on and off as needed. There will be times when I don't want to touch the .CS file.
I personally don't find the scene structure very difficult at all. All of the game exporters I have worked with have specific scene structure requirements that are not all that different from the Maya2DTS exporter's requirements.
Changing the scene hiearchy would require changing the way the exporter plugin itself is written. That's a pretty major code change, from what I understand, and is something that would require working with the DTSSDK.
Also, the scene structure requirements are similar for both the Max and Maya versions of the exporter. Drastically changing how the Maya exporter works would make it very confusing to share data and workflows between applications.
Also, parenting all necessary objects to base01 is a nice way of working. Anything not parented to base01 or connected to some object in that hierarchy is completely ignored by the exporter. This allows you to have several reference objects in the scene as you're working without worrying about having to delete things before exporting or maintaining multiple hierarchies.
Everything parented under start01 is part of the shape hierarchy. Basically, it's what you see on screen. Everything outside of it is ignored by the exporter (not counting skinned meshes).
08/17/2005 (11:12 pm)
Before I respond to the post, I want to make one thing very clear: I am an artist and not a programmer. I have no clue how to work with the exporter plugin's code. dtsUtility is just a MEL script for quickly setting up scene elements that the exporter looks for. Everything that dtsUtility does you can do by hand.Quote:When exporting, I feel it's important to give a user all the important data that the exporter will use. The exporter window should tell the user where it will export to, the name of the file and the animation name. Most of the stuff in the sequence node should be displayed here so I won't be surprised. (at least the most common ones such as Cyclic) Also, I would assume the user will be exporting the current timeframe. (I only use one anim per file, more on that below)
I think I'll duplicate the Exporter Settings window and use it as the base for dtsExporter window.
Interestingly enough, one of the first iterations of dtsUtility that I wrote included a big exporter window with all the information in the scene. I removed it early on, because I was annoyed with having to open a large window every time I wanted to export a shape. I already have the settings I need set accordingly -- I don't need to be reminded of it every single time. However, I understand that each user will work differently, so this does become a matter of personal preference.
Quote:I also don't think it would be too difficult to add a function to add the animation to a character's CS file when exporting. This will probably take a while to figure out the workflow, I'll let you know how it goes.
Auto-creating/editing .cs files would be very cool. However, if you get this working, be sure to have options to turn it on and off as needed. There will be times when I don't want to touch the .CS file.
Quote:It seems like the exporter is built in such a way that it expects you to construct your maya scene in a way that reflects structurally the way the dts files work. Whether or not that's the case, it makes it more difficult then is necessary for the artist.
For instance, would it not be easier to have all the detail nodes parented to the world instead of base01? Any shapes under a detail node would be exported to that detail level. This should work exactly the same with geometry weighted to a skeleton and shapes that are not. This way we visually connect our shapes together with their detail level, and we also wouldn't have to worry about the shape names being numbered correctly. (Remember, Maya will renumber stuff when you duplicate objects, import scenes, etc)
I personally don't find the scene structure very difficult at all. All of the game exporters I have worked with have specific scene structure requirements that are not all that different from the Maya2DTS exporter's requirements.
Changing the scene hiearchy would require changing the way the exporter plugin itself is written. That's a pretty major code change, from what I understand, and is something that would require working with the DTSSDK.
Also, the scene structure requirements are similar for both the Max and Maya versions of the exporter. Drastically changing how the Maya exporter works would make it very confusing to share data and workflows between applications.
Also, parenting all necessary objects to base01 is a nice way of working. Anything not parented to base01 or connected to some object in that hierarchy is completely ignored by the exporter. This allows you to have several reference objects in the scene as you're working without worrying about having to delete things before exporting or maintaining multiple hierarchies.
Quote:What is start01 for?
Everything parented under start01 is part of the shape hierarchy. Basically, it's what you see on screen. Everything outside of it is ignored by the exporter (not counting skinned meshes).
#4
Yes, you can export geometry parented to joints. You can also exported plain old mesh hierarchies. You just need to parent those meshes under start01.
There are times when you want all the animations in a single DTS file. For example, weapon animations are rarely shared, so it is not necessary to export separate DTS and DSQ files. Simply put all of the weapon's animations in a single scene -- i.e. load, reload, fire, etc. -- and export it as a single DTS file.
Simple animated shapes would work well as single DTS files also. Let's say you have a radar dish with several animations such as up down, full rotation, open and close (it's a fancy radar dish), explode, etc. You could export all of those animations as separate DSQ files, but it would be just as easy to include everything in a single file.
The use of .CFG files is a common workflow between Max and Maya. I think .CFG files are a good thing for being able to share common export settings between different applications as well as customizing export options for the same file without having to dig into custom attributes and whatnot. Yes, they can be a pain to deal with sometimes, but in the grand scheme of things, they are good to have around.
However, I am all for being able to edit .CFG files from within Maya. Automatically adding objects to the AlwaysExport list would be very cool.
The implementation of triggers in Maya is kind of a pain to work with. Unfortunately, this is another code-level issue.
08/17/2005 (11:12 pm)
Quote:Do we ever export geometry parented to a bone? Does that work? Are there DTS's that have skeletal deformed meshes and non-deforming meshes? That would make things more difficult.
Yes, you can export geometry parented to joints. You can also exported plain old mesh hierarchies. You just need to parent those meshes under start01.
Quote:Following are some things that would be difficult to change or re-impliment with a script, but aren't impossible.
I do not do the thing where you have many animations in one maya scene. It's too difficult to maintain a scene like that in my view. So sequence nodes in my workflow, are unnecessary and add complexity. The only thing they do that couldn't be done as custom attributes in the root null is let you have multiple animation names and ranges in a scene. I could make the dtsExporter window update the sequence node's attributes (and name) accordingly. (not hard)
There are times when you want all the animations in a single DTS file. For example, weapon animations are rarely shared, so it is not necessary to export separate DTS and DSQ files. Simply put all of the weapon's animations in a single scene -- i.e. load, reload, fire, etc. -- and export it as a single DTS file.
Simple animated shapes would work well as single DTS files also. Let's say you have a radar dish with several animations such as up down, full rotation, open and close (it's a fancy radar dish), explode, etc. You could export all of those animations as separate DSQ files, but it would be just as easy to include everything in a single file.
Quote:CFG files. I hate them. I generally save many versions of my maya scene, and I want any special export options to go along with them. I don't want to be surprised with missing nodes when I export because I don't have a cfg file set up. I'm unaware of any reason not to use custom attributes in place of the .cfg file. For instance, add a boolean attribute AlwaysExport = true to anything you want to always export. When adding a cam or eye node in the scene, these should have these attributes set to true and thus export as would be expected for a first time user. A script could be made to automatically generate the cfg file (and destroy it - to be tidy) on export. (harder)
The use of .CFG files is a common workflow between Max and Maya. I think .CFG files are a good thing for being able to share common export settings between different applications as well as customizing export options for the same file without having to dig into custom attributes and whatnot. Yes, they can be a pain to deal with sometimes, but in the grand scheme of things, they are good to have around.
However, I am all for being able to edit .CFG files from within Maya. Automatically adding objects to the AlwaysExport list would be very cool.
Quote:I'm still trying to figure out triggers. But I already find them displeasing. :)
The implementation of triggers in Maya is kind of a pain to work with. Unfortunately, this is another code-level issue.
#5
I am a programmer, with some wannabe artist skills as well. How are triggers currently done in Maya, and what could be done to improve them? I might just look at the code and see what might be required to improve that workflow.
08/18/2005 (4:13 pm)
Danny,I am a programmer, with some wannabe artist skills as well. How are triggers currently done in Maya, and what could be done to improve them? I might just look at the code and see what might be required to improve that workflow.
#6
What would be nice is to just use one single trigger custom attribute on the sequence node. To set trigger values, all you would need to do is set a key on the appropriate frame using the desired value (presently, 0 and 1 are all that are used). The exporter would then read that trigger attribute along with its keyed values. This is essentially how it's done with the Max exporter, and it is incredibly easy to use.
Adding the trigger attribute to the already long list of sequence node attributes is easy for me. Getting the exporter to read that attribute is another matter entirely. This is where I bow down to the all-mighty coding skills of the programmers in this community. :)
08/18/2005 (5:16 pm)
Right now, triggers are added as custom attributes to a sequence node. Normally, this isn't a problem, but the order of the trigger list is fixed and cannot be easily changed without completely redoing all of the triggers. For example, if you wanted to insert a trigger in the middle of the list, you would have to either delete all of the triggers and redo them or add the trigger in the appropriate position and then manually re-enter the numbers for the rest of the list. Kind of a pain.What would be nice is to just use one single trigger custom attribute on the sequence node. To set trigger values, all you would need to do is set a key on the appropriate frame using the desired value (presently, 0 and 1 are all that are used). The exporter would then read that trigger attribute along with its keyed values. This is essentially how it's done with the Max exporter, and it is incredibly easy to use.
Adding the trigger attribute to the already long list of sequence node attributes is easy for me. Getting the exporter to read that attribute is another matter entirely. This is where I bow down to the all-mighty coding skills of the programmers in this community. :)
#7
Thanks for all the great info, and for graciously humoring me. I want you to know that I appreciate all the work that you have done to create this tool. I hope I can help make it better. Here are some functions that I created today to help me get things working on our project today. They aren't incorporated into the dtsUtility window or anything yet, so I thought I'd just post them here.
These should be self explanatory:
-Andrew
08/18/2005 (9:50 pm)
Hey Danny,Thanks for all the great info, and for graciously humoring me. I want you to know that I appreciate all the work that you have done to create this tool. I hope I can help make it better. Here are some functions that I created today to help me get things working on our project today. They aren't incorporated into the dtsUtility window or anything yet, so I thought I'd just post them here.
These should be self explanatory:
global proc setAlwaysExportAttribute(string $node, int $flag){
if (!'attributeExists "alwaysExport" $node')
{
addAttr -ln "alwaysExport" -at bool $node;
}
setAttr ($node + ".alwaysExport") $flag;
}global proc alwaysExportSelected(){
$sel = 'ls -sl';
for ($obj in $sel)
{
setAlwaysExportAttribute($obj, 1);
}
}global proc string getCurrentCFG(){
$startDir = 'pwd';
$scene = 'file -q -sn';
$sceneDir = dirname ( $scene );
$sceneName = basename ( $scene, ".mb" );
$cfgFile = ($sceneDir + "/" + $sceneName + ".cfg");
return $cfgFile;
}Danny, I'll post some more questions/reactions to your lengthy and informative responses. Again, many thanks!-Andrew
#8
I'm getting this error: You don't have permission to access /mg/forums/result.thread.php on this server.
08/18/2005 (9:57 pm)
I think there's a problem with this forum software, it's not letting me post my whole message. Something in the code i'm trying to post is causing it to error out... Oh well.I'm getting this error: You don't have permission to access /mg/forums/result.thread.php on this server.
Torque Owner Danny Ngan
I'm happy to see that someone is taking the initiative to make additions/changes to dtsUtility.mel. I don't spend much time working with Torque-related projects, so I don't always have a chance to refine the script and general workflow issues. Whatever changes you do make, please send the updated script my way, and I'll add it to the file pack.
Out of curiosity, when you say "leaves a lot to be desired", what in particular bothers you? I modeled the functionality of the script based on how I work in Maya, but I realize that my workflow might not match up well with others'. Just want to know what to think about whenever I get a chance to revisit the script.