PDA

View Full Version : Is mel going away in Maya8?


DoctorMonkeyFist
05-23-2006, 01:09 PM
Well. I signed up for a mel scripting class and then I heard that autodesk was changing the language to python for version 8. I don't understand that but I don't want to learn mel if it's going to be irrelevant in six months. not to mention. What about all the scripts I use? Has anyone heard anything about this? Thanks.

mhovland
05-23-2006, 01:39 PM
I had heard rumblings about this around the office, but I don't think mel is going to go away. The entire underlying structure of Maya is based on mel. The UI is entirely mel, for instance.

I can see them using python as a wrapper to the API, this would allow you access to the API functionality without having to know how to program in C++.

nessus
05-24-2006, 01:26 AM
oh no, i'vs just learned maya7 and mel 5 months ago. but actually i dont care, MEL syntax itself is not that hard to learn at all, same thing applies for most of computer languages/scripts out there. its their libraries and command and attributes that takes time to be familiar with and master them. always rely on the help(F1) and reference.

frogspasm
05-24-2006, 07:50 AM
I can see them using python as a wrapper to the API, this would allow you access to the API functionality without having to know how to program in C++.

That'd be pretty freakin' sweet. XSI does this now too, right?

~M

Bonedaddy
05-24-2006, 08:32 AM
That doesn't make a ton of sense to me, as a huge number of companies rely on MEL for everyday tasks, and wouldn't upgrade if they would have to rewrite everything in a different language... but who knows, crazier things have happened!

A python wrapper would be friggin' awesome though.

MikeRhone
05-24-2006, 11:17 AM
They would never just 'do away with' MEL. It's the core of MOST (all?) Maya studios toolset. I have never been able to touch the API do to the programming knowledge required to even touch it, and the weak documentation (IMO). I have heard python is easier to jump into than C++, and if thats the case... Booyah! Getting into the API would open a whole new world for me. MEL is great, but it doesnt take long before you realize its limits.

Jason: You always seem to beat me to these threads. I might as well just start doing the *Quoted for agreement* thing. :hmm:

sunit
05-24-2006, 12:27 PM
python wrapper for MEL and the api:

http://cgkit.sourceforge.net/

-sunit

Robert Bateman
05-24-2006, 05:55 PM
mel's not going anywhere - absoultely everything is run through mel within Maya. As for phython bindings to the API, so far i've only heard very loose rumours about this - I've definately not seen any conrete anoouncement on this.

There is a phython binding for the API already, so use that if you think it will be useful. The problem with all of this of course, is that a python API binding is nowhere near as useful as a python equivalent of mel (the latter being 10 times more useful imho).

As an example, load the plugin, create a polycube, and then use the MFnMesh::deleteFace method to remove a face. The reality is that it will not work, because

Maya API != Faster version of mel

If you bind directly into the maya api, you are making life 10x harder for yourself, with no real gain (i.e. you might *think* it works like mel, but you'd be very wrong). If you are already an API user, then a python binding may prove to be useful (rapid prototyping). If you are not already an API user, then realise that the API only does a few specific things for you - mel is still the more useful out of the two.

MEL is great, but it doesnt take long before you realize its limits.

8 years and i've not hit it limits.... It's *far* more useful and *far* more powerful than the API. It's just not a true programing language, you should not be storing data in mel (use nodes in the DG) and you should not be performing complex computation in mel (use mel to connect nodes together in the DG to do the computation for you in nice chunks of optimised C++ code.... ). But yeah, the API is nothing like mel (you can't do GUI in the API for example), the API just allows you to add some new things into maya - you still use mel to connect the API stuff into the maya GUI....

Anyhow, on a personal note, I don't think it's worth using any other scripting language in maya other than mel. You know, languages with structures and all that, might seem useful (I definately don't think that), but really it'll just encourage you into *really* bad practices.... (like storing data, and doing complex computations....)

MikeRhone
05-24-2006, 06:56 PM
I admit, my programming knowledge only goes as deep as self taught MEL-ness, When I meant MEL has its limits, I was reffering to adding specific functions that are difficult/impossible to do straight out of MEL and DG nodes. There are a few things I considered attacking in the past that (I would assume) could only be done via the API. Ideas off the top of my head:

Clusters that also have a baseCluster. (Same funtionality as a lattice-baseLattice relationship)
Several new deformer types.
Animateable blendshapes (Via keyable inputs) - Not the artisan way that was added in recent versions, but a method to allow for selectively wiping on/off areas of blendshape influence.
Pose space deformation - A moot example, as Michael Comet already has succeeded in coding this plugin, but AFAIK it was nessesary for him to go outside of MEL for this.
New types of particle systems, fields etc - Many different ideas in my head here.

My knowledge of the API is limited, but I suspect that it is the icing to MEL's cake. After saying all this, would having "Python as a wrapper to the API" mean that you could code for the API via python, without having to be well versed in C++?

DoctorMonkeyFist
05-25-2006, 07:30 AM
I'm not sure what to make of all this. My programming ability is about the same as my flying ability. I don't even know what API means or any programming language for that matter. I assume a wrapper is a program that translates commands in one program to another. And I can't really understand how maya could do away with mel because the whole program is written around it and it would crumble alot of pipelines. So python is like a wrapper plugin but Maya will still be based on mel right? I'm not retarded, just ignorant.

sunit
05-25-2006, 11:40 AM
There is a phython binding for the API already, so use that if you think it will be useful. The problem with all of this of course, is that a python API binding is nowhere near as useful as a python equivalent of mel (the latter being 10 times more useful imho).

well, the above link includes python bindings for both MEL and the API.

-sunit

Hirni_NG
05-25-2006, 01:45 PM
Why should MEL go away if a Python API binding is added in Maya 8, the API and MEL cover different things in Maya. The only thing that will change is that one does not use C++ to write plugs but Python instead, nothing else. It is time that Maya gets the API exposed in a another Language than C++, it will make the life of a lot of programmers easier.

Hell, writing a new shading node with 20 lines of code, thats what I m talking about!!!

Mudvin
07-14-2006, 04:49 PM
Actually Python is a good language, and not that complex(as well as perl). I think they will just _add_ python, not _replace_ mel.

ntmonkey
07-15-2006, 11:20 PM
Rumblings around my neck of the woods as well. Again, I'm with the genenal consensus that MEL isn't going away. Not having to know C++ to have access to the API is great, as C++ can be a pain the arse for us non-uber techy guys. The additional factor of Maya going Python is the notion that you open up lines of communication between apps such as MotionBuilder, XSI, and maybe RF4(not entirely sure on this one). This sort of connectivity opens up a lot of appA to appB sorta functionality that I'd love to see. Enough of this "My app is better than your apps stuff" and start embracing the tools that get the job done.

Exciting times indeed.

peace,

-Lu

butCherHeLL
07-17-2006, 11:16 PM
they wont change ?

they can't. no ability.
otherwise they shall write a new one instead of buying maya : D

neuromancer1978
07-20-2006, 06:35 AM
MEL won't go away simply because simply put - it's GUI is MEL. If you strip away all the MEL you basicly have a basic 3D program that really won't do much at all. Autodesk would have to totally rewrite Maya altogether in order for MEL to disappear and honestly why would they? Too much of a waste of time and effort when the app works fine as it is now.

As for Python? Well it's been done already at ILM so it can be done for the public release. And if memory serves correctly I believe I ran into a MEL script once that called on Python to do......something...... so it can be done within MEL too so that is an added bonus.

I have heard both sides of MEL, that it rocks, or it sucks. Honestly I like it even though I can hardly program it.

gga
07-31-2006, 06:37 PM
Python is old news :) Here's what removing a face with the api looks in the upcoming rubyMEL 0.9 (part of the upcoming mrLiquid v0.8).


# Run a mel command to create a plane
`polyPlane -sx 3 -sy 3`

#
# Use the api to remove a face from selected object
#

require 'maya/api/all'

include Maya::Api

sel = MSelectionList.new
MGlobal::getActiveSelectionList( sel )

path = MDagPath.new
sel.getDagPath( 0, path )

m = MFnMesh.new( path )
m.deleteFace( 2 )


For something like this, using the API wrapped through ruby has no benefit. You do get benefits once you do stuff you cannot do with mel, like creating new nodes. Here's for example a port of the api's demo yTwistDeformer into ruby with the api of rubyMEL 0.9:


#!/usr/bin/env ruby
#
# Simple script to add a new deformer node as a plugin
#
# Author:: Gonzalo Garramuno
# Copyright:: 2006
# License:: Ruby
# Status:: Tested to work OK.
#

begin
require 'maya/api/all'
require 'mathn'
rescue LoadError => e
$stderr.puts e
$stderr.puts e.backtrace
$stderr.flush
exit(1)
end

include Maya::Api

#
# Main Plug-in Information
#
PLUGIN_VENDOR = 'Aura'
PLUGIN_VERSION = '1.0'

#
# A simple deformer plugin named 'yTwist'.
#
class YTwistDeformer < MPxDeformerNode
#
# Name of the deformer
#
def self.name
'yTwist'
end

## Maya's typeID for node
@@id = MTypeId.new( 0x8000e )

## Node attributes
@@angle = nil
@@outAngle = nil


#
# Main function for command
#
# Result: MStatus
#
def deform( block, iter, mat, multiIndex )
status = MStatus.new

angleData = block.inputValue( @@angle, status )
MCHECK status, 'Error getting angle data handle'
magnitude = angleData.asDouble

envData = block.inputValue( YTwistDeformer::envelope, status )
MCHECK status, 'Error getting envelope value'
env = envData.asFloat()

#
# iterate through each point in the geometry
#
while not iter.isDone
pt = iter.position
ff = magnitude * pt.y * env
if ff != 0.0
cct = Math::cos(ff)
cst = Math::sin(ff)
tt = pt.x*cct - pt.z*cst
pt.z = pt.x*cst + pt.z*cct
pt.x = tt
end
iter.setPosition( pt )
iter.next
end

return status
end

#
# This is not ruby' standard initialize function, but maya's
# static initialize function for the MPxNode.
#
# Result: MStatus
#
def self.init
nAttr = MFnNumericAttribute.new
@@angle = nAttr.create( 'angle', 'fa', MFnNumericData::KDouble )
nAttr.setDefault(0.0)
nAttr.setKeyable(true)
status = addAttribute( @@angle )
MCHECK status, 'Could not add angle attribute'

status = attributeAffects( @@angle, YTwistDeformer::outputGeom )
MCHECK status, 'Could not have angle effect outputGeom'
return status
end

#
# Factory method for command
#
# Result: new YTwistDeformer
#
def self.creator
return self.new
end

#
# Deregistration of command
#
# Result: MStatus
#
def self.deregister
obj = MGlobal::pluginObject
plugin = MFnPlugin.new(obj)
status = plugin.deregisterNode( @@id )
if status != MStatus::KSuccess
status.perror('deregisterNode')
end
return status
end

#
# Registration of command
#
# Result: MStatus
#
def self.register
obj = MGlobal::pluginObject
plugin = MFnPlugin.new(obj, PLUGIN_VENDOR, PLUGIN_VERSION)
create = method(:creator)
init = method(:init)
status = plugin.registerNode( name, @@id, create, init,
KDeformerNode )
if status != MStatus::KSuccess
status.perror('registerNode')
end
return status
end
end



#
# Main Entry function for Plugin.
#
def initializePlugin
YTwistDeformer::register
end

#
# Main Exit function for Plugin.
#
def uninitializePlugin
YTwistDeformer::deregister
end

#
# A simple test of using the deformer...
#
if $0 == __FILE__
begin
initializePlugin
puts 'sphere'
sphere = `sphere`
puts 'Create deformer'
deformer = `deformer -type #{YTwistDeformer::name}`
puts 'Created deformer #{deformer}'
uninitializePlugin
rescue => e
$stderr.puts e.to_s
$stderr.puts e.backtrace
end
end

Pixaloop
01-15-2007, 09:16 PM
Actually Python is a good language, and not that complex(as well as perl). I think they will just _add_ python, not _replace_ mel.

How did you see this coming!? :thumbsup:

Python scripting is also new in Maya 8.5. This popular open-source programming language helps accelerate facility-specific custom script development and plug-in prototyping, extending and automating Maya production pipelines. Python scripting offers a powerful alternative to Maya software's native scripting language, MEL, while featuring the same deep level of integration with the Maya command engine. Python scripting further augments the creative control gained with Maya Nucleus, giving scriptwriters the ability to efficiently manipulate, customize and automate the software.

CGTalk Moderation
01-15-2007, 09:16 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.