So a KdTree is a type of “spatial partitioning” data structure. You feed in a bunch of spatial data and the KdTree organizes it in a way that makes certain queries really fast. In particular nearest neighbour searches.

I originally started toying with this after trying to get my skin weight loading script a bit smarter when dealing with radically different geometries. Searching within a tolerance doesn’t work well if the geometries can be vastly different. After all, some verts could be right next to each other, while others have matches further away. Weighting the further points helps, but it can screw up the points that have more exact matches.

So how do we solve this? Well I use an algorithm that finds the closest point, grabs the distance to this closest point and given a ratio looks for others within this radius. You give the search function a factor – it defaults to 2 – and it sees if there are any other points within that radius. So basically the tolerance is dynamic, not fixed. So if the closest point is very close, the search radius used is very small. However if the closest point is very far away, then all points within a much larger radius get considered. It turns out this works really well when transferring vertex data like skin weighting between radically different geometries.

Anyway, this is totally possible to do using the binary search, but because we’re now searching twice (finds the closest then the tolerance search) we now need every single bit of speed we can extract – hence my delving into faster ways of searching. Of course, I should probably be doing this all in c++, but… Maybe next.

Let me finish off with some numbers. On my 3 year old, dual core 2Ghz laptop, given a 10k point KdTree, I can run 10k queries on the data in about 2.2 seconds given similar inputs, or if the data is vastly different it takes about 7 seconds. As you can see, the early out test I wrote about in the previous post can make the code up to 4 times faster. By contrast, the binary search algorithm takes about 25 seconds.

So one of the shortcuts I put in is detecting exact point matches. The closest point search needs to ultimately determine the squared distance to the query point. So I figured I’d put in a test to see if that distance was zero, and because the search function is recursive, the easiest way to bail on the recurse stack is to wrap the top entry point in a try:except block, and throw a known exception when an exact match is detected. All good.

But I was being a bit lazy and was declaring the class within the closest point function. Ie the code looked something like this:

def getClosest( self, queryPoint ):
	class ExactMatch(Exception): pass
	def search( node, depth ):
		...
		if dist == 0: raise ExactMatch  #short circuit test
		...

	try:
		search( self.rootNode, 0 )
	except ExactMatch: pass
	...

You get the idea. Anyway, so I use this for matching two pieces of arbitrary but similar geometry – so getClosest gets called heaps. Like 5-20k times. Adding this test saved a heap of time in the cases where lots of points were the same, but it also seemed to slow the case where none of the points were the same a lot. Way more than I expected. Or so I thought.

So after a bit more investigation I realized it wasn’t the extra test I had added, it was the ExactMatch class declaration that was doing it.

Lo and behold, declaring classes is SUPER slow. Like really really slow. You should try it out. Go on – here is some example code

import time
s=time.clock()
for n in range( 1000000 ):
	class ExactMatch(Exception): pass
print '%0.3g' % (time.clock()-s)

Now try running that same code and instead of declaring a class, instantiate a list or something. On my machine its around 30 times slower to declare this empty class than it is to instantiate a list.

Anyway – hardly a big deal, but something to keep in mind.

NOTE: feel free to use the kdtree code above, but you’ll either need to either use the Vector class here, provide a get_magnitude method on your own Vector class, or tweak my code to get rid of the need for a get_magnitude call all together. Its only used in a single place, but I’m lazy and couldn’t be bothered writing the extra line or two of code that it needs to be fully independent.

Oh, the code also assumes that vector points in the tree are indexable. Ie you can get at the “X” component of a point using someVector[0]. My Vector class inherits directly from list because accessing vector members this way is way faster than having to define an attribute or worse, property.

The good thing about my implementation however, is that its really small and self contained.  Its a single script.  Its fairly gratuitously commented, and there is a page with some tips, tricks and general high level discussion about it here.  It a nutshell it tries to make UI authoring more like writing UI code in WX or QT.

Anyway, for those interested take a look at it here.  Enjoy!

[edit:] to be more explicit – new can only be called once because it is responsible for actual instance creation.  new does the actual object creation whereas init just takes the new instance and initializes it.  Initialization methods on multiple parent classes can both do complementary things on the same instance, so being able to split out initialization from construction makes a lot of things possible if you’re working with multiple parent classes.  Its not as useful with single inheritance – arguably it makes things more confusing.  But multiple inheritance its a godsend.

Seems kinda weird to me.  Any python gurus out there that know why this is?  I’ve never really understood why python has both a __new__ and an __init__.  Why not just ditch one of them and be done with it?

I never realized how badly you could screw up an auto completer.  Do these people use their own software?!

I took linear algebra in school, but it didn’t seem at all applicable to life at the time so its since been purged from my brain.  My lack of 3d math skills has always been one of my weaknesses, and I try to rectify that whenever the opportunity arises.  Anyway this guy has some videos that have helped, and I figured others would probably benefit as well.

So last week I decided to bite the bullet and learn what I could about these sorts of things.  I started off with the dependency problem because testing seemed useless without an understanding of what to test.

A quick google search pointed me to this page. Not quite what I was after, but it was a fantastic piece of code to learn just how all encompassing the python standard library is. To save you having to look at the code and trawl through it yourself, this is basically what it does.

In the python standard library is a module called moduleFinder. What it does is it takes a module, finds where it exists on disk, opens the file and reads it in. This is important, at this point it has not imported the code – ie the code has not been executed. It has simply loaded the file and read its contents into memory. Then it takes this and compiles it into a code object using the compile builtin function.

Now the next bit is cool – it takes the code object, which contains the bytecode for the python code that was just compiled, and iterates over all the instructions looking for various commands – most importantly import commands. So its pretty robust, because its using python to reverse engineer its own code and walk through the dependencies.

Because the code isn’t being executed you can query dependencies for maya tools without having to run the script from inside maya.  So if I make a change to say my vectors module (which is a standalone python module) the dependency query will still be able to list all the maya scripts that use this module.  This is obviously important if you’re in a studio where you have a significant portion of your python codebase outside maya.

Surprisingly this is super fast too, because the bytecode is literally just a stream of bytes. So its just integer comparisons when iterating over the bytecode. For the 320 scripts in one of our branches it takes 20 seconds to scan.

Now 20 seconds is still a drag, so I wrote a simple caching mechanism. The cache basically stores a crc for each file, and that file’s immediate downstream dependencies. When the cache is loaded all entries are checked to make sure they still exist on disk, and the crc’s are matched. Those that have changed get re-scanned and the cache is updated. With the caching, even a huge change that touches many files only takes a second or two to make a query against. Which is super cool.

Now all I have to do is figure out how to associate a set of unit tests with each script and then the dependency query could be made to run the downstream scripts potentially affected to ensure the change is sound. That would be cool.

So anyway, if you’re thinking about writing tools to query dependencies, do it – its really easy, and the link above gives you a great place to start.

from maya.cmds import *
o = group( em=True )
rename( o, 'something_else' )
select( o )

This will fail because the o variable is just the name of the group when it was originally created, and the name changes before the select command is run. Now obviously the above is a trivial case and can be easily solved, but sometimes its not so easy.

For example, if you have a group with a non-unique leaf name that is nested deeply in the hierarchy, just by re-parenting one of its parents, the node will change. Tracking this changed name is non-trivial, and is the sort of problem you run into every now and then when writing generalized tools for rigging, or just general scene construction.

Anyhoo, so poking around a bit I experimented with adding a few methods to MObject, kinda like this:

from maya.OpenMaya import *
def asMObject( otherMobject=None ):
	'''
	tries to cast the given obj to an mobject - it can be string
	'''
	if otherMobject is None:
		return MObject()

	if isinstance( otherMobject, basestring ):
		sel = MSelectionList()
		sel.add( otherMobject )

		tmp = MObject()
		sel.getDependNode( 0, tmp )
		#tmp.cast()

		return tmp

def partialPathName( self ):
	'''
	returns the partial name of the node
	'''
	if self.hasFn( MFn.kDagNode ):
		dagPath = MDagPath()
		MDagPath.getAPathTo( self, dagPath )

		return dagPath.partialPathName()

	return MFnDependencyNode( self ).name()

MObject.__str__ = partialPathName
MObject.__unicode__ = partialPathName
MObject.partialPathName = partialPathName
MObject.name = partialPathName

def _hash( self ):
	return MObjectHandle( self ).hashCode()

MObject.__hash__ = _hash

def cmpNodes( a, b ):
	'''
	compares two nodes and returns whether they're equivalent or not.
	the compare is done on MObjects not strings so passing the fullname
	and a partial name to the same dag will still return True
	'''
	if not isinstance( a, MObject ):
		a = asMObject( a )

	if not isinstance( b, MObject ):
		b = asMObject( b )

	return a.name() == b.name()

Now this is hardly rocket science here, but it does go along way toward making MObjects useful in just your average script, and more to the point it solves the problem discussed above.

How? Well, first off, its easy to cast a node name to an MObject with the asMObject function. More importantly, you can still pass the variable to a normal mel command. ie this works:

from maya.cmds import *
o = asMObject( group( em=True ) )
rename( o, 'something_else' )
select( o )

Plus you can compare two nodes without having to worry about whether one is a full path to the node or a partial path.

This code can be packaged up into a simple little module that you can import at will – simply by importing the script you get the functionality added to the MObject class, so all you need to do really is add this to the top of your scripts:

from apiExtensions import asMObject

And wham – you get the rest for free.

Casting to these MObjects is still slow – there’s no way around that. Thats just maya being a slut. But you can easily target which parts of your script to add this functionality to without having to change your entire code base to use something like pymel or MRV. Plus you can also pass this MObject to the api class – again without having to wrap anything.

I’m smelling win.

Thoughts?

So be warned people! Pymel might make for more readable code, but there is a huge cost. HUGE.

from maya.OpenMaya import *

import time
import maya.cmds as cmd

def asMObject( item ):
	sel = MSelectionList()
	sel.add( item )

	tmp = MObject()
	sel.getDependNode( 0, tmp )

	return tmp

def test():
	start = time.clock()
	for obj in cmd.ls():
		asMObject( obj )

	print 'time taken %0.3f' % (time.clock()-start)

This is pretty simple stuff. Simply iterating over all nodes in a blank scene and casting them to MObjects individually is slow. It takes 0.05 seconds on my machine on an empty scene. Doing the same thing with pymel takes about 0.21 seconds which is a little more than 4 times slower than this. Quite a leap from 350x.

So it seems Autodesk is largely to blame for some bloated script bindings.

From this little bit of investigation I’m not really convinced that its possible to have a fast unified abstraction of mel/api without help from Autodesk in cleaning up and speeding up their wrappers.

What might be interesting is looking into subclassing unicode and lazily populating the instance with api data as its requested from script to minimize the time spent instantiating maya’s object types. Incidentally pymel’s PyNode class used to inherit from unicode, but I’m unaware of how aggressive it was with lazy evaluation. I believe the reason Chad moved away from this idea in pymel was because strings in python are immutable and node names in maya are not. Having an immutable object represent mutable data is kinda sucky. But hey, we have to deal with this currently anyway, so its not like we’re moving backwards. Just not as far forward as we’d like.

The sucky thing about doing the lazy evaluation thing is that it’d be tricker to leverage inheritance – you wouldn’t want to determine the most appropriate class to cast the node as on instantiation because thats where it becomes expensive. So instead you’d have to dynamically populate the instance dictionary as functionality was requested.

Anyway… Once again we’re at the mercy of some shitty corner cutting from Autodesk.

In other news – has anyone seen how WELL blender has integrated scripting? Way better than any dcc app I’ve ever seen.

ref: porting code to python 3

For starters its kinda this weird middle ground where its not mel (maya.cmds) and its not the api.  You can’t easily mix it with maya.cmds without having to throw in explicit str() casts all over your code, and to put isinstance( obj, PyNode ) checks everywhere which is messy and error prone.  You also can’t easily mix it with the api directly.

So you’re kinda left in this unusual grey zone.  PyNode objects do carry along with them some handles to API objects like their mobject and others depending on the PyNode in question, but again, you have to speckle you code with attribute references like someNode.__apiobject__ etc, if you want to call into anything inside maya.OpenMaya.

But most importantly, it is amazingly slow.  Like mind bogglingly slow when compared to mel. Exactly whats going on I haven’t spent the time to discover, but here is a very simple, albeit contrived demonstration of its tardiness.

import time
import maya.cmds as cmd
MAX = 1000
start = time.clock()
for n in xrange( MAX ):
	cmd.ls()
print 'time taken %0.3f' % (time.clock()-start)

from pymel.core import ls
start = time.clock()
for n in xrange( MAX ):
	ls()  #NOTE: this is using pymel’s wrapping of the ls command
print 'time taken %0.3f' % (time.clock()-start)

On my machine the first test which uses just mel takes 0.07 seconds on a completely empty scene. The second test, which uses pymel, takes a whopping 24 seconds.

That is a 350x speed difference. That’s HUGE!

Now, originally when I started writing this blog post I hadn’t done the speed tests. My assumption was that it was slower, but the slow down was probably merely a factor of 2 due to the way pymel has to cast return values from strings, back to MObjects. But I figured instead of writing the blog post with assumptions in it, I should at least do the work to get some actual numbers.

The question now becomes, do the benefits of pymel outweigh the negatives?  In my case I believe the answer is a resounding NO.

So after using it for as long as I have I’m kinda backpedaling. Its going to suck pulling pymel out of the tree, but clearly it has to be done. I’ve written a heap of rigging code using it, and have been wondering why it has been running so slow. My assumption was that it was my fault, and that somewhere I was writing some super redundant code. Now I know better.

This is a pretty big shame – I like what I gain from pymel, but I don’t like the constraints it puts on me, and the speed hit is unacceptable.

I do however, have some ideas on what might be a better solution to wrapping mel in a nicer way. It seems to me that extending the MObject class and making it really easy to cast strings to MObject instances would be a cool way to go. The wrapped objects would be native MObjects, so they’d be first class API citizens, and you could cast them to strings easily to pass back to mel should you need to. I’ve done some tests on the idea and so far it seems promising. I have a feeling I won’t ever have a solution as comprehensive as pymel, but at the same time I’m not sure thats what I want anyway.

Anyway, I just wanted to put my findings out there for anyone else who was shopping around for opinions on whether to use pymel or not. Consider yourself warned.

Actually, let me preface this with the statement that I’m talking as a technical artist, not a modeler. Modo is a pretty decent modeler, but as someone who has to shoehorn the thing into a production pipeline its probably one of the poorest applications I’ve ever encountered. Seriously.

Lets see, there is no documentation.  Their scripting syntax is just god awful bad.  Setting a value or performing an action via script is COMPLETELY DIFFERENT from querying data about the current state of what you’re just about to change.

An example here helps demonstrate – I want to query the name of something, so I use the command:

query scenesystem item.name <theItemId>

this will give me the name of the item “theItemId”.  To change the name of the item however, I need to use two commands like so:

select.subItem <theItemId> set mesh
item.name "holy shit modo sucks ballz!"

So not only is there absolutely no symmetry between querying and editing information in your scene, but there are these cryptic systems like sceneservice, renderservice, layerservice etc – none of which are documented, and good luck figuring out which service is responsible for what.

And holy wow how bad is authoring UI? Not only is it NOT POSSIBLE to script UI’s (so no dynamic UIs for you!), but its also a matter of hand editing xml files. And again – who the hell knows what any of the keys are for. But whats super awesome about this – if you get something “wrong” modo doesn’t give you errors, or warnings or anything helpful. It just does nothing. So you’re never quite sure what the hell is going on.

Incidentally, there is a “Form Editor” which will let you build buttons with macros in them. But thats it. Oh and there is no such thing as a checkbox widget either. Just a widget and if you give the widget a command which returns a bool then the widget magically knows to be a checkbox. And how do you define these variables you ask? Oh thats ALSO fun and ALSO involves hand editing xml files and hoping like a fancy pig that you divined the correct magics modo is expecting.

I could go on but honestly, what the hell is wrong with the people at luxology? They have clearly put a heap of thought into modo. As a modeler its quite a deep and sort of accessible tool, but what the fuck are they thinking about their scripting? Like not only is it bad, but its almost like its designed to be really bad. I find it hard to believe that someone honestly things any of the choices they’ve made are good.

Its even more baffling when you look at how RIGHT the blender guys have done it.

Whats your story luxology?

Anyhoo, so whats with the lovin this time?  Well the other day I wanted to get a clear picture of what part of my python code base was being imported.  I was trying to make sure certain parts of my tools were pulling code only from a specific part of the tree in order to better isolate things.  Anyway I was kinda dreading the task, and figured it’d be a whole lot of no fun.  I had heard of import hooks, but knew nothing of them.

So 20 minutes later my problem was solved and I had a super convenient, generalized way of spewing all imports that were happening.  Furthermore it was a simple matter of running wing, setting a breakpoint in my import hook and bam.  The problem was solved in all of an hour, plus I have a convenient way of ensuring thing don’t creep in.  The import hook automatically turns itself on for me (or anyone else who sets the appropriate env var) so when I developing code I get a pretty rude warning if I start using code outside the desired part of the tree.

Sounds kinda weird – but the main point of it is we have a bunch python code which is shared across all projects studio-wide, and used mainly for tools like maya, modo, blender etc.  But we don’t want our project specific tools to rely on these pieces of code, otherwise people who aren’t content creators are no longer able to re-compile and optimize certain classes of assets.

Anyway, once again, python rocks.

So basically what I do is I have a base class that implements some simple class methods like SyntaxCreator for the given class variable containing the syntax definition for the MPxCommand you’re writing.  This class also does things like auto hook up a “-h/-help” flag so that all commands defined in the plugin behave in the same way.

Then the initializePlugin function simply iterates over all subclasses of this base class, instantiates them and registers them as commands.  Similarly with the uninitializePlugin function.  So now to add a new command to the plugin you simply have to inherit from the base class and write your doIt method and describe the flags you want used.  The new command gets registered using the name you gave the class (although you *can* override this if you want) and everything just gets setup for you.

nice!  take that c++!

I’m sure this is possible in c++ but I’m pretty sure its going to be more than the 100 lines of code this solution requires.

here’s to hoping the pypy guys can make python mind numbingly fast.

So anyway, this last week I was writing some UI to a tool that isn’t really finalized yet.  I want to keep the UI code flexible and modular so that its easy to change it up without creating a bunch of work.  Anyway if you’ve ever programmed UI using WX or QT there is this concept of events.  Basically pieces of UI can listen to events of a certain kind and define a function that gets called when that widget “hears” such an event.  Event driven UI’s are pretty common and make for a really powerful way of expressing action and reaction without having to make widgets aware of one another.  Because you’re not defining the relationship between widgets, doing things like radically changing up UI layouts is easier to achieve.

Anyway, so I wanted something like this in maya for my mel UIs.  So I made the simplest solution on the planet – which actually works out really well.  Basically I have a bunch of classes I wrote that wrap the maya mel UI widgets.  The base class has a sendEvent method and a process event method.  The sendEvent method basically just walks up the UI hierarchy and runs processEvent with the given event args.  And thats it.  Super simple, but it means I can write modular UI classes, and glue them together easily, or break off a piece of UI into a separate window etc.

Previously I’ve had to have child UI hold a handle to parent UI to call update functions or vice versa which makes this sort of modularization annoying at best, impossible at worst.  So anyway, super low tech simple solution – works a charm.  Anyone got a better idea?

How?

Well, we have a compilation step between export and visualization in the game engine.  This isn’t necessary, but it provides a convenient way of doing rigid error checking, and expensive optimization up front – and as of late we’ve been using it as a place to do additional assembly on the exported data.

When data gets exported out of the authoring app we try to preserve as much as the scene as possible – which is useful for a variety of reasons which I won’t go into here.  But for runtime efficiency, you generally want to do the opposite – rigorously remove anything that isn’t essential.  Some studios do this in their exporter, some studios do this at load time in the engine – we do it as a post export step before loading it in engine, which as I mentioned, provides a convenient place to do additional assembly on data that comes from multiple sources.

Getting back to the original point of the post – skinning geometry in modo.  Well, technically the skinning happens outside of modo, but all the data is authored inside modo, so it IS only a technicality.

First up – the skinning tool in maya is a point cloud loading and saving tool.  So basically you give it some skinned geometry, and the tool writes out position vectors with a list of joint names and joint weights – and thats it.  So if we can get that information authored in modo, then we can derive skinning data.

In modo what an artist would author is a hierarchy of transforms (I’m not sure if they’re called that in modo – modo isn’t that strong on clear terminology from what I’ve seen of it), and then parent a bunch of primitive geometry to those transforms.  The empty transforms get named in a special way (like bone_pelvis, or joint_arm_L etc) so the tool that derives the skinning data knows what to interpret as the skeleton, and then any geometry parented under that transform is assumed to be rigidly skinned to that joint.

So this is enough data to generate a point cloud that can be used to generate skinning information.  The skin weight tool then looks through the point cloud data, and does a radial search based on a couple of user settings for each vertex in the actual geometry to be skinned.  Generally what the search does is expand a starting radius until its found 2 or more verts.  Then it finds the closest verts *(see below for details on what this means), averages their weighting contribution and applies the skinning data.

So its kinda like sculpting volumes – and in fact, its a really fast and easy way of generating skinning information.

* The tool, to find the “closest verts” works kinda like this:  Given a vert on the actual geometry, it starts off with a radius of x.  The radius is grown each iteration until multiple verts are found.  From these verts, the closest is found.  The distance to this closest vert is stored, and the distances to all the other verts is then compared to a ratio.  Any vert that falls within the <closest distance>*<ratio> range is included in the weight sum (weighted by proximity).  By doing it this way scale isn’t important, and the user is presented with two fairly intuitive values to control the weighting.

some numbers for you.  for a 3000 vert character its roughly 21 seconds using maya.cmds.  if you tune the numbers you can get that down to 12 seconds, but lets assume worst case scenarios here which I’ll describe in a bit more detail soon.  so using the api to do vertex iteration and skin weight assignment takes that down to 8 seconds.  thats a speed up of 2.4 times – which is not huge, but nothing to be scoffed at either.  lets looks at some details.

first up, the searching is being done entirely in python.  so given a vertex, i need to search through a cloud of 3000 points to find the closest matches in python.  the best case scenario above (12 seconds) uses a tiny search radius, which is useful for restoring weighting with minimal mesh changes.  the worst case scenario is for restoring weighting when the mesh has changed drastically – which happens, especially early on.  so the worst case scenario the search radius grows until it finds some matches, and then it averages the weighting found for the found verts and applies the weighting.  so it is this worst case scenario which is the most interesting.

so how does the searching work?  well basically it uses a binary search algorithm on the point cloud.  what does this mean?  i didn’t really know what a binary search was either until recently when a programmer friend of mine told me.  its pretty simple: basically given a sorted list of values, you look at the middle value and figure out whether the value you want to match is greater than or less than that value and throw away the other half of the values.  because its sorted you know the best match cannot be in that half.  so with each iteration of doing this, you cut the number of values you need to search in half.  do this a few times and you’ve narrowed the number of values you need to do more expensive comparisons on to a mere handful.

so using a simple binary search algorithm you can do searching pretty quickly.  ideally you’d write some sort of spatial partitioning that considers all 3 values instead of just one value, but that is more complex and I got really good results using a simple binary search.

so anyway, the search uses the same code for the maya.cmds and api method (this code sharing is one of the many awesome things about python.  in fact I also use the same search code for tools that don’t live in maya at all).  the main difference between them is how the skin weights are actually set.  using maya.cmds.skinPercent is really slow when you’re doing it many thousands of times.  but swapping this out for the api (which isn’t quite as easy as you’d think – you basically need to restructure the entire loop to use the MIt classes for iteration) gives you the speed improvements above.  so now i just need to figure out how to speed up the search algorithm.

i could write it all in c++, but then I have to worry about things like writing data to and from disk when storing and loading weighting data.  plus its harder to share code.  the way i’ve done it now, the searching algorithms are actually used by non maya tools, so improvements there are felt across tools instead of just within maya.  so yeah, c++ sucks for all of the above.

mel (and thus default maya python) is pretty straight forward – in theory.  but in practice there are all these stupid little gotchas, and most of those gotchas made their way across to the python binding of maya’s scripting interface.  awesome things like “hey I want to add an attribute.  do I use the dt or at flag?”.  or other little things like “hey I want to set a string attribute to something – don’t forget to use the -type string flag for whatever reason”, or “hey I want to query something about an attribute, which command do I use?”, or “hey, are these two objects equal?  you’ll need 10 lines of code to be sure!”.

also mel has no data structures that make sense for a 3d app.  hello?  its a 3d app, how about vector, matrix, euler and quaternion data types?  its weird that they never added these – oh and don’t tell me about the “vector” data type in mel.  its essentially useless, and seems largely unsupported.  sure the python bindings allow you to roll your own data types, but you still need to cast return values from mel commands to their appropriate type.

there are a lot of weird commands in mel, and there is a lot of mental friction involved in trying to think whether querying data about a reference is done with the file command, or the referenceQuery command.

why does pymel help?  well, in some ways it just changes the problem, but in many ways alot of things are simplified.  there is generally less typing – which again goes to the lower friction point above.  commands that return vector data actually return vector data – which means you can add and subtract them, ask for their magnitudes etc…  there are nice methods for things like querying hierarchy.  someNode.getParent() or someNode.getChildren( type=’joint’ ) for example.

of course, if you’ve already got a heap of python scripts written you may find it annoying to integrate pymel into your code.  pymel fixes a bunch of issues, and many of those fixes mean small changes which mean you can’t just drop in pymel.  and because pymel data types aren’t strings you can’t pass a PyNode to a non pymel command.  so there are a bunch of issues doing anything but a wholesale integration of pymel, and if you have a lot of code already, a wholesale integration can mean a huge amount of work.

I’ve gone the path of a partial integration.  It was originally kinda painful, but I think I’ve found most of the parts of the tangled web that is our code base that pass data across boundaries, and its working really well.  but it was initially a pain in the ass – so be warned.  I believe this problem may get worse going forward I’m not sure.

anyway, thats my experience thus far.  if you’re doing reasonably isolated tool work you should definitely be using pymel.  if you’re doing work on more integrated code then its probably not worth doing until you have a better handle on where the problems will occur.  I stupidly decided to use it on some new rigging tools which has been kinda painful tracking down all the points of failure.  and while painful so far its been worth it.

oh and I’m using 0.9.2 – the pymel guys are already way ahead with their alpha 1.0 release.

does anyone use this resource anymore?

See you all in the new year!  2010.  Crazy!