Sounds right. I've never used much of the Maya API myself, but it sounds like it lets you keep an absolute reference to the nodes you create which seems like a good way to go if all of your node creation happens within the same script.
The issue is what happens once your script finishes, when the absolute reference also vanishes into oblivion along with the absolute path. But, as you said, you can exploit the fact that nodes can stay connected to other nodes which would give them a common starting point from which to start looking for names. However I'm curious as to why you choose to create this Meta node (is that a custom node-type?) or rely on the message slot of nodes (if I understood you correctly), which is already used by other nodes (although sporadically) when Maya already makes use of objectSet<http://download.autodesk.com/global/docs/maya2013/en_us/Nodes/objectSet.html>, aka "set", for this purpose. Maybe I'm not in the loop on exactly it is what you're trying to do though; is this still a question on finding objects in a scene? By name? On 23 March 2014 02:49, Joe Weidenbach <[email protected]> wrote: > Just for clarification on a few of these areas, I'd like to break this > down a bit, and who knows, this great info on the backend might be useful > to someone, so here goes: > > > > > On 3/22/2014 4:05 AM, Marcus Ottosson wrote: > > I think the Python API 2.0 is already in effect (since Maya > 2013<http://docs.autodesk.com/MAYAUL/2013/ENU/Maya-API-Documentation/index.html?url=files/GUID-AC9B3C66-90FE-493F-A7B2-44ABBA77CED2.htm,topicNumber=d30e29422>or > so) but only applies to the API. maya.cmds on the other hand is a > wrapper around MEL independent of the underlying API and so wasn't affected > by that change, PyMEL is then a another wrapper on-top of that wrapper, but > I think PyMEL uses some of the Python API for some of its more esoteric > features; possibly to distinguish between nodes, I'm not sure. > > > As I already mentioned in a previous response to this email, Maya's Python > API 2.0 is available (and has been since 2013), but is incomplete. I'm not > deep enough into programming the Maya API to know exactly how much is not > done yet, but at the very least it is missing Iterators, which takes away > the majority of the useful mesh information/editing functions. You can > still use the 1.0 API for those within the same script, but you can't mix > the two--you can't retrieve an object with the 2.0 API and then pass it to > a 1.0 function for processing (or vice versa). > > You have correctly stated that maya.cmds is a wrapper around the MEL > functionality, and is again incomplete (although much less so). You have > to go pretty deep to find the areas where maya.cmds just won't work, and it > is mostly in the UI and callback functionality, along with some of the > animation commands. For these, you must wrap a MEL command to be called. > Also, maya.cmds, like MEL, is completely string based, so you have to do a > lot of work keeping track of any changes to names. This is where PyMEL > comes in. > > PyMEL is a wrapper around the overall Python functionality--not just > maya.cmds. Specifically, it uses the API to reach in and give us direct > access to the node-level information and functions, and keeps direct > references to objects instead of names. It's really nice functionality for > keeping your code simple (I find that coding in PyMel produces nice clean > code that tends to take up 1/2 to 2/3 of the lines of code to achieve the > same tasks versus maya.cmds and the API. The problem with PyMel is > twofold--first, it's slower (it's another layer of wrappers, after all), > and two, it causes compatibility issues. I've run into situations where a > bug in PyMEL effectively broke my maya installations, and anything which > even used it would drop Maya into an infinite plugin-loading loop. Because > of this, I try to stay away from PyMel unless I know it's going to be fully > available and tested for installs I'm working on. > > If you truly needed a sustainable, persistent "absolute path" to the > nodes you create, you could do what I suspect Maya does internally; which > is to assign a unique identifier (UUID, GUID or similar) to an attribute > within your node. You could then use this attribute to distinguish nodes > from each other, even though they may have the same name. > > > # Psuedo-code, bear with me. > > # Step 1. Create node with unique identifier > group = cmds.createNode('transform') # Will produce a unique name > cmds.addAttr(group, 'uid', 'my_unique_identifier', dt='string') > cmds.rename(group, 'myCommonName') # Absolute path is lost into oblivion.. > > # Step 2. Find node by unique identifier > exact_result = None > multiple_results = cmds.ls('myCommonName', long=True) # May return > multiple nodes > for result in multiple_results: > uid = cmds.getAttr(result + ".uid") > if uid == my_special_id: > exact_result = result > > This is actually a really useful pattern to setup, and I might > implement it in future projects. However, Maya does give us functionality > that would allow us to keep direct references to objects using the > graph--Message Nodes. This also avoids the need for loops to search for a > given GUID. What it does add is the need to maintain a node to keep these > references on, which is incidentally the exact use case this question > belonged to for me :). I'm actually creating a "Meta" node that attaches > itself to my relevant structures in the scene, and it always has the same > name--which led to challenges when I was creating a new node. So, that's > where the question came from :). I think Justin's solution is actually the > one I want to work with on this, just because I much prefer to deal with > the actual object instead of trying to keep track of the name. As I said, > I really like PyMel's way of handling things, I've just run into enough > issues that I don't want to deal with PyMel directly :). > > With that said, this is a really good explanation of why you should create > a node and rename it rather than specifying the name directly. > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/532E4BD0.3000501%40gmail.com<https://groups.google.com/d/msgid/python_inside_maya/532E4BD0.3000501%40gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *Marcus Ottosson* [email protected] -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD052w%2B9dhAuvcsh_zgPFo_tMfPHnfErSfERuC8PMs9wA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
