Objexport Through Mel

[kiranmaya2]

hey .im trying to write a mel script..where all objects ...that mesh nodes will be export as .obj individually...
that means a 3 nodes of maya will have to export 3 .obj files

my script is :
[codebox]
//main proc is here
window -title "obj EXPORT MEL SCRIPT" -wh 500 400;
columnLayout ;
text -l "Destination Path of Meshes:-" ;
$tf1 =textField -w 234 -tx "f:/irrLicht/media/" ;
button -l "Export the Meshes" -command ("exportObj(textField -q -text " + $tf1 + ")");
showWindow;

proc exportObj(string $path)
{
$allMeshes =ls -typ "mesh";

for($mesh in $allMeshes)
{

$conCat=($path+$mesh+".obj");

//obj export
select -r $mesh;
pv_performAction $conCat "OBJexport" ;

file -f -typ "OBJexport" -es ($conCat) ;
print ($conCat+"\n");

}

};
[/codebox]
i got problem ......as unable to write the c:/scene/house.obj

[thanasis_scifi]

I cant write everything down, but here are some guidelines to avoid problems such as this.

Try to have more organized code. Separate your UI creation commands from your working procs

NEVER have UI elements created without a fixed name. What's the point of creating a textfield with a random name? How can you refer to the data it holds? I can see what you are doing with storing the name on the $tf1 at once, but it is way cleaner and manageable to write the name in the creation command. Also it is so much easier to query the textfield.

Your string variable $tf1 is undeclared. If you were to run the exact code you post here on a fresh maya session it would not work.

You dont need to create a window, use the filebrowserdialog in directory mode to get the name of the folder, and store the path to a string.

Then use a prompt dialog to input the filename of the obj to be exported.

In a nutshell (look in the MEL command reference for the flags and options )

global proc exportObj ()

{
string $path = fileBrowserDialog ;

string $name = promptDialog;

//use the export command

}

Check what the $allMeshes stores inside. I have a feeling that the way you have it written, it stores shape name and not the trensform name. If so, use a listRelatives -parent to get the transform, cause that's what you need to use in the export command.

I'm sorry I can't check your code right now to spot the problem. If I have any flaws in the above please correct me.

[joojaa]

QUOTE(thanasis @ 12/11/07, 07:42 PM) [snapback]277899[/snapback]
How can you refer to the data it holds?

You don't actually need to know the name of a control to work upon it, first theres the # syntax that can pass the name for you secondly you can parse the objects form the layout. So you might directly just work with array index numbers. On dynamic enough GUI's this is imperative as you cannot even KNOW the names in advance, yet alone how many there happen to be.

[thanasis_scifi]

That's really cool Joojaa, I'll look into that, cause I came across a case where I couldn't find a way to have UI elements get created/queried dynamicaly.

[kiranmaya2]

thanks a lot thanasis..my problem is sloved now..........
well tf1 is not a random one........it is text field 1...and tf2==textField2.

[rob-bateman]

QUOTE(thanasis @ 12/11/07, 09:42 AM) [snapback]277899[/snapback]
NEVER use UI elements with a fixed name.

fixed.

Basically i disagree (a lot on this point). If you want to write useful & re-usable scripts, don't ever assign a name to a text box, window, layout or whatever.

a) You can't re-use the GUI creation code in another script - since you'll have a naming clash and the script will not run.
It's a pain if you later have to rename that GUI's name - it'll touch an annoying number of places in your scripts.
c) As your custom toolset grows it becomes impossible to keep track of what GUI names you've used, and what any given GUI item is actually called. It causes some nasty debugging headaches.