Has mel in Maya 2008 been modified improved in code compared to previous maya versions i.e maya 5?
The reason why I ask I have a MEL book on Maya 5 but I am using Maya 2008.
Also I wanted to know what does pyhton scripting offer that mel does not?
Regards
Tony
From 5 -> 2008 there's been quite a bit of extra functionality added, but everything in your maya 5 book should be fine. From memory there was 1 or 2 little things that weren't backwards/forwards compatible, but it was pretty obscure things.
Re Python, I'm no python expert, but the python scripts I've seen look ugly. I really don't like the way you have to wrap python calls around mel calls to do just about everything.
QUOTE(saitek @ 01/04/08, 10:52 AM) [snapback]279150[/snapback]
Has mel in Maya 2008 been modified improved in code compared to previous maya versions i.e maya 5?
Some new commands yes. Some new slight change in parsing rules, but i havent seen a book thet goes this deep into mel.
QUOTE
Also I wanted to know what does pyhton scripting offer that mel does not?
Ok this is the thing people allways mess up thinking python is some singular thing. It isn't so its a hard equation to answer because we are not comparing 2 cars here we are comparing a car factory with a car. And thats not afeasible one word comparasion.
In short python offers PYTHON itsef This said python offers 2 SEPARATE avenues to maya. And they cant intermix. So python offers one binding to mel and one binding to the API.
So the interfaces are the same, and in scripting MOST of your code time works on the interfaces. They dont change. However outside of theese interfaces theres a huge amount of stuff that you COULD use. Most of this you could have used in maya 1 too without any much hustle. But its now it appers to significantly easer while it sint the same problems are there. On the other hand its easier to shoot you on the foot too. So what python has done is it has multipled the amount of good code being done by 1.1 and bad code by 10.
The core problem is the same! Not in programming, not in maya gui use. But in the raw deal that represents what the hell maya is doing. If you dont understand this you don't understand programming in maya. Be it mel, c++, Python, java, c#, ruby or WHATEVER. (and yes you can do java, c# or ruby development in maya if you wish)
Unfortunately not many books teach this, they teach the language as if it was any other programming language. But rather you should treat maya script interface like a SQL querry language.
dbiggs: right you are, because python cmds is mel then why the hell not ue mel for it? Dont make a difference in the world. The api binding on the other hand is a superb idea because c++ is so tedious.
Thats what I already thought!! :]
After seeing a tutorial for python-scripting I really thought what a crap! But of course python API is looking much more interesting.
@saitek: I think if you really like reading books: It will give you the basic idea. And that didn't change from then to now!
And kind of what joojaa said: Understanding the basic idea what Maya is about is ALL YOU NEED!
Ok i think when we are talking of maya python the WORD API is in big trouble, and comfuses peple out of the sky
See API = Aplication Programming interface.
Python has a
MEL API for a interface of mel.
But it also has a "C++ API" API, WTF? Well its the only way to describe it because its a binding to the C++ api and bindings of this kind are caled API's
PS: the David Goulds book is not all that good it Reads more like reference. Prettymuch all thats worth in the book is the introductory to how dag works.
if you think python code in maya looks ugly, check out pymel and you may be convinced otherwise.
although joojaa is very right to stress that python in maya offers two separate avenues, it is not right to say that they cannot intermix. if you are careful about how you use it, it is perfectly possible to use api code to bolster your python mel bindings.
now, joojaa, i know you are a purist who would definitely balk at the mention of mixing these two worlds, but i was wondering what technical reasons you can think of for not doing so? i know that actions performed with api in this way would not be undoable, so that is one thing to consider.
pymel currently uses api bindings in only one instance, and that is to get the name of the currently open maya file. this is because the mel (and therefore maya.cmds) 'file' command fails to return the scene name when the file opens with errors, while the api equivalent continues to behave properly.
-chad
Yes, but that just represents a module on top, nothing says i couldn't write my own parser for mel! Or a wrapper for every function i dont like (and i have several command wrappeers for faster array acces etc) I can and its as easy as in python, just nobody doing that.
Anyway pymel is much closer to the way I would have made maya python connections but still it is limitted partly by the so straightforward original port.
How the code looks like is actually no concern for me. Code always is ugly no matter what. Only no code is elegant.
Theres However ONE native feature thats is much better in python than in mel and thet is array passing to commands. Aplies to SetAttr specially.
QUOTE(Chadrik @ 01/04/08, 06:42 PM) [snapback]279178[/snapback]
now, joojaa, i know you are a purist who would definitely balk at the mention of mixing these two worlds, but i was wondering what technical reasons you can think of for not doing so? i know that actions performed with api in this way would not be undoable, so that is one thing to consider.
You can potentially break the threading modell, actualy i should have been more specific not like the api cant CALL mel or python script but thats kindof a situation that comes into play only in subset of api development.
Api is designed to do internals of nodes, display drawing and the occasional high performance converter. Now the AIM of it is to make nodes and calling mel isnide a node is INSANELY stupid. However node designers do some kind fo services on top of nodes to make them easier to handle, in commands its sane to use mel or python. But why then put it inside the api why not just call a procedure that resides on disk as script. Read following:
The other way around it represents quite a different problem, undo is one. See the idea of the API is t make a object that builds up in the stack that can then go both ways. Because it lives in the stack as a command. Then why not encapsulate thet stuff intoa command the way i was designed? Thisway you could undo, but as a bonus youd be able to call it in BOTH mel and python. Ok so it can be useful for calculation. But the talkback mechanism of mel is slow anyways, so the real question is. Why not make a node in firtsplace?
So the real question is Why would you want to glob two things that dont overlap? Especially in python because all you need is one extra file and your set. Especially if you use the communication channels designed. Is not much more code but its MUCH more flexible.
The primary concern on all this is: Do we really need one more scripting language, i mean really? Why not just do api stuff with it and be done. The fact that you make something EASY to write doesn't remove the enormous overhead thats associated with it. Easy to code is not equal to good coding in fact its often the opposite.
Let me stress out i dont have anything against python, i just have something against the code degeneration some people use it for. Bad code is bad no matter what you call it. I also have no claim in wich is better, because the fact is it depends on what you aim for.
PS: on a side note you can circumvent some of your problems by making significantly more of pymel commands that you then wrap up to your own style. Id do this but im too busy.
PPS: python modules are one thing that will make python scripts much harder for beginners. And for you to anticipate the python environ in the other end. This will lead you to the most annoying aspect of open source community dependency hunting.
QUOTE
dependency hunting
? whats that?
mean running after stuff thats not bundled with the given code and or not build in?
QUOTE(ewerybody @ 01/07/08, 12:16 PM) [snapback]279311[/snapback]
? whats that?
mean running after stuff thats not bundled with the given code and or not build in?
Yes, take gimp for example gimp is dependent on a few extra libraries, gtk mainly that you need to install separately for it to work out. Now problem inst this, problem is that quite a few OTHER apps use gtk too... now off course some of them use a different version of gtk so suddenly your in a situation where you need 3 different versions of gtk (or its sub dependecies) to run the apps you need and need to maintain the system so it doe sent fetch wrong one at wrong time. (and it takes a guru to sort all this out)
This can happen even if all dependencies are bundled since the installed one might override few facts of life.
Now in python this means you need to hunt for all the modules whatever script chooses to use and install them. Usually fine if you run on a 32 bit windows but ist a HUGE problem if your running 64 bits or wacky linux, very custom windows etc. In wich case you can end up needing to get a compiler that happens to work with said source compile it fix flags and so on. By no means impossibly hard but just not something for beginners.
Its a huge plus tough if yoru a hc coder like me. Otherwise its a VERY negative thing.