Getting MFn type from string type name

[ben_hawkyardJPBMR]

Hi folks! I'm writing some code to traverse the scene, which should let users filter for specific node types. Ideally, I want the users calling my code to provide the string type name of the nodes they're after, e.g. "transform", or "aiStandardSurface" etc.

I'm using MItDependencyGraph under the hood. This can take a MFn.Type as a filter, to let us get specific types of node.

My trouble at the moment is I can't find a good way to map string node type names to MFn.Type values. One option I have is to not filter nodes at all and just query their MFnDependencyNode.typeName, but this is quite a bit slower in testing than filtering directly with MItDepdencyGraph.

So far, the one way I can see of doing is, is to take the string type name, then create a node of this type, then get the MFnDependencyNode.typeName of my created node, then delete the node. Obviously this is not ideal! Another approach would be to maintain a very large hardcoded dict mapping string type names to MFn.Types. I'd rather not do this though if possible as it's likely to need to change as we add/remove plugins from our pipeline.

Does anyone have a better solution?

[brentmc]

Hi,

There is a static method on MFnBase that will return the name for a given type.

const char* MFnBase::typeString(MFn::Type)

So, you could build a reverse lookup dictionary by looping from MFn::kInvalid to MFn::kLast and inserting the result of MFnBase::typeString into the dictionary if the returned pointer returned is not null. You would only have to do this the first time and cache the dictionary.

[ben_hawkyardJPBMR]

Hey Brent, thanks for getting back to me so fast!

Sorry, I should've clarified that I'm working in Maya 2026/python here; I've had some luck using MFnBase.typeString but only in OpenMaya 1 . If do 

from maya.api import OpenMaya
OpenMaya.MFnBase.typeString

I get an "AttributeError: type object 'OpenMaya.MFnBase' has no attribute 'typeString'". I don't suppose there's plans to have this work with OpenMaya 2? I only ask as that's what I'm using in the rest of my code.

I've also had issues building up this mapping; as I understand it lots of different type names can map to the same underlying MFnType, e.g. an arnold "aiStandardSurface" node is a kPluginDependNode, but MFnBase.typeString(MFnType.kPluginDependNode) doesn't give us any way to get back to aiStandardSurface; do you know if there's any way I could account for this sort of thing?

[brentmc]

Hi,

What about using something like MNodeClass which can be constructed from a type string and then give you typeid and other info?
Like your original idea of using createNode but without creating the actual node. 😉

https://help.autodesk.com/view/MAYADEV/2026/ENU/?guid=MAYA_API_REF_cpp_ref_class_m_node_class_html

[ben_hawkyardJPBMR]

Anything to avoid actually creating nodes!

I've had a go at using MNodeClass but I'm not sure this quite works for me either, e.g.

>>> from maya.api import OpenMaya
>>> cls = OpenMaya.MNodeClass("transform")
>>> cls.typeId.id()
<<< 1481003597
>>> OpenMaya.MFn.kTransform
<<< 110

Here the type id I get out of "transform" doesn't line up with the value of MFn.Type.kTransform. I'm not sure I really understand how type ids relate to MFn.Types but as far as I can see they're pretty distinct?

I'm having a bit of a look at MDGModifier/MDagModifier to "create" the node (not calling doIt) and then seeing if I can inspect that MObject a bit at runtime.

[brentmc]

MFn.Type is not really a distinct type in that sense. It's primary purpose is to represent function sets which is more like an interface that can be applied to an MObject. (where the typeId is meant to be unique to each node type)

The original idea behind function sets is you could have a camera interface and maybe cameras and spot lights both support that interface so you could in theory do camera-like things to a spot light. However, I don't think Maya ever leaned heavily into that concept and instead function sets so closely follow the object type. (but not exactly and that is where you are running into issues)

So, maybe your safest bet is to create temporary objects that you can interogate or a combination of this and hard coding some common node types as I'm out of ideas at this point.