|09 September 2005||#1|
Join Date: May 2005
Huge MEL Scripts - can they do harm to Maya environment ?
I'm planning to do a MEL code generator in Java for automating tasks like spreading an object in scene, randomize attributes of multiple objects at once, and other stuff like that. It is working in a pipeline like this:
JMEL code->Java interpreter->MEL code
where JMEL is a specialized programming language I've recently designed. It's not implemented yet. It can do a lot of useful stuff, like spreading a tree object on a grid to create a forest, with input bitmap images controlling density, scale etc.
This program can generate thousands of lines of MEL code, or even more, where a lot of objects are translated, scaled one by one.
This is the problem:
can Maya execute without problem so many lines of code in a single script, without beeing disturbed? If my procedurally generated scripts would cause problem to Maya MEL interpreter, this could cause big instability problems, and would make my language useless.
Thank you, and sorry for my english.
"Realize that more magic exists in making magic than in watching it."
|09 September 2005||#2|
Join Date: Jul 2002
The largest problems you will run into will be speed (or lack thereof), the ability to debug, and the consumption of memory.
Of course these are all dependent:
memory -- how long the script is for a single tool (it would be possible to have a mel script that is 120,000 lines long and only source a procedure when needed)...but you would have to hope that the user doesn't put all of the procedures into memory during a single session...there is no way to clear global variables in a single maya session
speed -- use the API or get used to slowness for complex and iterative/recursive operations
debug -- imagine if you get a bug in your melscript. Is it a problem with the interpreter? or the java code? or is it a user-error? It would be quite time consuming to hunt down the smallest of errors.
It sounds like quite a task to write a scripting language for a scripting language. If you have some method figured out that writes bug-free melscript then you are home free. If this is not the case you may want to consider writing your scatter tool in C++.
|09 September 2005||#3|
Lord of the postsportfolio
Ghost VFX, Cph
Join Date: Sep 2002
I assume you have a good reason for writing your own java interpreted language (maybe to utilize java functions that don't exist in mel?), so I won't go into the hazards of that.
As for the size of mel scripts, I can only add that I don't think it would be a problem in most cases - the .ma format is actually script which executes the nessecary mel commands to recreate a saved scene (at least I assume so after looking at a few .ma files in a text editor), and maya files can be really huge without causing problems.
|09 September 2005||#4|
Lord of the posts
Join Date: Aug 2004
well, if it spits out code like :
move 1 0 0;
move 2 0 0;
move 3 0 0;
etc, then i'd suggest it'd not be the greatest idea, but it will work. The only problem you may run into is an issue with construction history. To avoid those issues, you probably want to use a minimal subset of mel, ie crateNode / getAttr /setAttr / connectAttr.
The Maya Ascii file is a good example. It only uses 9 mel commands (check the file formats section of the maya help - devloper resources). Infact, writing out a maya ascii file may be the way to go (though it's not pleasant). You'd probably want to do things like flush the undo queue etc after importing etc, and try to avoid calls that generate construction history..... (ie, sphere will generate a nurbSphereCreator node, a transform, and the nurbs object itself)
generally though, it'd be nicer to write an output that uses loops and other control structures (ie functions, switch statements etc).
|09 September 2005||#5|
Join Date: Jul 2002
If you creating or modifying insane amounts of objects, try to do it as several commands and insert flushUndo after each command has run, so memory isnt filled up.
|09 September 2005||#6|
Join Date: Sep 2003
Thread automatically closed
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
|Thread Closed share thread|