When I reference in a character it always give me a namespace along with it. Is there a way to negate this effect? If not, I have a character gui that won’t work because of the namespace. If there a way to make it work with a namespace? Or any other suggestions for it?
For the namespace, I don’t want any namespace to be used. I have to put one in the namespace textfield, or else it will use the file name. Any other suggestions?
I found this. Could someone help me out with this?
[QUOTE=btribble;9869]You’re not going to like my suggestion: Rewrite the code to support namespaces. We all suffered through it, why shouldn’t you? [/QUOTE]
Because I’m trying to fine a better solution to help everyone out! :D:
Think I’ve probably said this before somewhere, but if you’re dealing with references
DO NOT IGNORE NAMESPACES, or do so at your peril.
There role for references is to effectievly partition the scene such that data from reference fileA doesn’t get screwed up with that from fileB, even more crucial if the 2 references point to the same character rig etc. You have to understand that Maya is basically a flat graph under the hood and namespaces are the only way it deals with this kind of data. All reference edits are NAME based so if you start to try and remove these you’re in a whole world of hurt.
I’ll second the re-writing the code. it might not be your fastest solution, but it is your better solution.
my thoughts are you can either support the namespaces using maya.cmds, or use pyMel, which deals with the actual api objects (so you don’t have to worry about naming conventions [or openMaya? my understanding is that it works with the same stuff, someone who knows more weigh in here].
in my limited experience, the farther away from the end user you can get naming convention enforcement, the better. a good solid tool won’t break for any names that the DCC app will allow the user to assign to objects.
Yep, definitely agree with the guys who are saying you should update your code - when I read this post yesterday, my first thought was “why doesn’t the script support namespaces?” … it’s pretty vital for a character rig UI, I’d have thought - what if you have more than one character in the scene?
Surely you’d want a nice easy way of setting which character the UI is controlling, and namespaces are perfect for that.
Its the same kind of good code practice as always expecting long dag paths and dealing with them in code. Unless of course you’re running Pymel in which case you’re in a nice warm place on that front
you can use the file command with the flag defaultNamespace (dns)
file -r -dns
you will obtain a referenced file without namespace, take care of the names clashing, because there is no system to handle it like with the classical way of referencing a scene
[QUOTE=MoP;9897]Yep, definitely agree with the guys who are saying you should update your code - when I read this post yesterday, my first thought was “why doesn’t the script support namespaces?” … it’s pretty vital for a character rig UI, I’d have thought - what if you have more than one character in the scene?
Surely you’d want a nice easy way of setting which character the UI is controlling, and namespaces are perfect for that.[/QUOTE]
That depends on how much of an update you are able to/willing to do, and on the code itself.
If you absolutely need to get it done quick and move on, it may be as quick as allowing for node names that are split by a :, but there’s probably an opportunity to significantly update and improve the code at this point
Namespaces are indeed a pain to work with in mel scripting, so why hasn’t someone come up with a plugin to handle rigging issues where namespaces come into conflict? It should be easy for anyone who knows what they’re doing to make some sort of node/command in python for space-switching and/or dynamic parenting.
For now however I discovered a mel tip fromthis blog which might help you on your namespace troubles, although the final solution is still not as solid as a plugin and still is tedious to come up with:
Tip #8: ls can be used to search for custom attributes
Following on from tip #7, “ls” also works with attributes. So, if you added a custom attribute to the root node of all your character rigs (called “keCharacterRig” for example), then you could then search for all rigs in the scene like this:
string $allRigs = ls "*.keCharacterRig";
Which is pretty awesome - it gives you a great way to “tag” certain objects and quickly look for them later. Imagine working on a crowd scene, or a scene with a large number of props. Suddenly, writing a script to find and update all character rigs in the scene becomes a piece of cake Jason Schleifer mentions on one of his DVDs that Weta used a technique like this in their pipeline to manage their assets in their Maya scenes for Lord Of The Rings.
The best way of handling namespaces for a rig to be honest is to not use anything based on naming. We’ve used attribute tags on all controllers for years now, the marker data in the tagAttr is used by our define code to build up a global array so that we always know that whatever rig we have, $ControlArray[0] will always be the main RigNode, $ControlArray[1] = LWrist etc. We also have arrays build by the define code for things like mirror arrays and joint arrays etc.
That said we recently started to move over to using MetaData for our internal rigs, similar to the GDC talk that was done last year I think. So the rig is hooked to a blank Maya node of our own type, which in turn is wired to other metaNodes via message links, that then discribe the rigging systems. Basically a seperate sceneGraph under the hood which we can walk very easily.
Whatever you do, removing name dependacies is a good thing for your systems.