or, rather, MPxNode, not MPxDependencyNode -- yay for consistency ;) On Sat, Dec 4, 2010 at 5:14 PM, Adam Mechtley <[email protected]>wrote:
> Well, I'll qualify this by saying you're doing stuff I haven't had to do, > so I can't really say what categorically is and is not possible, but only > what (little) I do know. > > The only *specific* and *universal* mapping you can get is between > typeName and typeId (which you can do with a DN function set; again, not > especially important because I was suggesting creating the map by spitting > the output into your source file, whether it's C++ or Python, just using > Python to populate it). Since there's not a way to filter an iterator using > a typeId, you could look up the type niceName in the mapping and then just > test typeId on each item in the iterator when needed. You at least gain * > something* from getting the typeId before entering the iterator and then > comparing typeId rather than a string when you need to more closely inspect > a plugin node (which I would most likely do rather than exclusively > examining typeId, so I can still filter at higher levels of abstraction if > needed). > > I don't think there are really any other exceptions. The apiTypes are only > special in that they can be interpreted in a way where class hierarchy is > known, so that any particular object can be represented by a multitude of > apiTypes. To the extent that kPluginDependNode is a child of other classes > represented by apiTypes, you can know more about it, but your custom node > classes must all inherit from MPxDependencyNode, right? Anything beyond that > they API can't really dynamically "learn" about in order to create a new > apiType. > > On Sat, Dec 4, 2010 at 12:27 PM, Chad Dombrova <[email protected]> wrote: > >> >> On Dec 3, 2010, at 4:57 PM, Adam Mechtley wrote: >> >> > I think part of the problem here is that the "types" recognized in the >> command engine (e.g. listConnections) are somewhat arbitrary. I mean those >> are just sort of "nice names" for some API type, right? >> >> yes and no. maybe for animCurve and kAnimCurve, but these API types don't >> even exist for custom nodes. and still, is there really no lookup between >> these anywhere in the maya API? seems like a useful thing, but maybe it's >> just me. >> >> > One possibility would be to write a script that just creates a node of >> each type and uses the nodeType command to populate a "static" dictionary in >> some module with niceName:apiType pairs, assuming you want the same types >> represented by nice names in the command engine. >> >> well, luckily pymel has exactly this in interal.factories, but what if i >> was working in c++ and didn't have pymel available. >> >> > In the case of custom node types (e.g., apiType = kPluginDependNode), I >> think you'd just need to rely on the MTypeID to distinguish one from >> another. >> >> would certainly be nice if the iterators could just filter on MTypeID. >> are there other exceptions that i will have to test manually other than >> kPluginDependNode subtypes? >> >> -- >> http://groups.google.com/group/python_inside_maya >> > > -- http://groups.google.com/group/python_inside_maya
