Are you in 2011? I've just spend the last few weeks in deep discussions with
Autodesk over a number of bugs in the way reference edits and specifically
namespaces are handled. In 2010 the namespaces were all based on root space
':' and there were some issues with editing namespaces which left the edits
incorrect and therefore broke the files.
In 2011 they added the 'relative' flag and things are way more stable. What
it doesn't say in the docs (or not that I can find) is that the namespaces
are relative to the namespace of the refNode itself. We've always renamed
the refNode when switching characters so that things are consistent, I could
never understand why, when switching the referenced Namespace there wasn't
some name handling performed on the refNode itself so that when you looked
in the referenceEditor, things actually made sense.
Anyway, with the relative flag all the namespace handling is solid, at
last..... you just have to remember that it's all 'relative' (or at least it
is if you want to take advantage of it)
If it's of any use to anybody here's our rename snippet... Like i say, this
is after a lot of snag catching between us and Autodesk:
namespace=fileRef.namespace
parentNS=pCore.Namespace(cmds.file(path, q=True, pns=True )[0])
if checkNSClashes:
# Resolve ns clashes prior to renaming
NewNameSpace=NameSpaceUtils.ResolveNameSpaceClash(NewNameSpace,DebugPrint=True)
print '\nparentSpace : %s \npath : %s \nnewNS : %s' %
(parentNS,path,NewNameSpace)
try:
if parentNS:
pCore.lockNode(refNode,lock=False)
pCore.rename(refNode, '%s:%sRN' %
(str(parentNS),str(NewNameSpace)))
pCore.lockNode(refNode,lock=True)
pCore.namespace(set=parentNS) # move to the child's parent
space
cmds.namespace(rel=True)
else:
pCore.lockNode(refNode,lock=False)
pCore.rename(refNode, '%sRN' % (str(NewNameSpace)))
pCore.lockNode(refNode,lock=True)
# rename the namespace using the relative namespace code form
2011
cmds.file(path,e=True,ns=NewNameSpace)
cmds.namespace(rel=False)
cmds.namespace(set=':')
Not sure if that's of any help to anybody
cheers
Mark
On 9 July 2010 12:08, Erkan Özgür Yılmaz <[email protected]> wrote:
> Hi Paul,
>
> What I wanted to achieve was to replace a referenced file with another,
> where the first reference (the replaced one) is actually a reference inside
> the newly replaced file.
>
> May be it is somehow a wrong pipeline design I did. In our current
> pipeline, we reference the rig assets to shading assets and do the shading
> in this scene. There is no problem if the rig asset doesn't have any
> references ( ex. the model asset is not referenced to the rig asset but
> imported ). So referencing the rig asset to shading asset, and replacing all
> the references in animations with the shading asset and using the
> changeEditTarget doesn't cause any problem.
>
> The problem is, when you have a rig asset that has some references to (
> lets say ) model assets, then in animation scene when I replace the rig
> asset with shading asset I loose all the edits, even I don't have a single
> edit that I can change the target on. In any case I should be able to get
> all the edits done in top level reference node as failed edits, but I
> can't...
>
> So as a work around, I query all the edit commands, replace the assets and
> apply the edits by changing the namespace in the MEL commands. With this
> workaround I got errors in "parent" commands because the long name of the
> objects are changing, and the other edits becomes invalid.
>
> So that's all I think :)
>
> and thank you for your interest...
>
> Cheers...
>
>
> E.Ozgur Yilmaz
> Lead Technical Director
> eoyilmaz.blogspot.com
> www.ozgurfx.com
>
>
> On Fri, Jul 9, 2010 at 8:25 AM, Paul Molodowitch <[email protected]>wrote:
>
>> Mark, your fix is in my latest pymel, as well as a test for it.
>>
>> Been taking a look at the way getReferenceEdits works (as well as how
>> cmds.referenceQuery(es=1) works), and I think we're gonna need to
>> change it's behavior. Right now, what it returns just isn't very
>> useful.
>>
>> To explain - there's basically two ways you can group refEdits in
>> relation to reference nodes - by what ref node they're stored on, and
>> by which objects they affect (and which ref node those objects are
>> 'introduced' in). (These can be different reference nodes when
>> reference nodes are nested...) So, if you're querying a reference
>> node for it's ref edits, I can think of three possible results it
>> could return which you might consider 'useful':
>>
>> 1) All the refEdits which affects nodes introduced by it
>> 2) All the refEdits stored on it
>> 3) All the refEdits which affect nodes introduced by it, but stored on
>> the 'topReference' node
>>
>> The first two are potentially useful for partioning; ie, if you
>> iterated over all the reference nodes in the scene, using either
>> methods 1 or 2, you'd end up with all the ref edits, grouped in some
>> sort of sane manner. The third is useful for getting the reference
>> edits which "make sense" in the context of a given scene (see the docs
>> on referenceQuery for only the edits on the topReference are the ones
>> you'll usually care about in a given scene).
>>
>> Unfortunately, currently getReferenceEdits returns none of these -
>> instead, it returns the ref edits which affect the it's nodes, and are
>> stored on it. While this might seem appealing from a symmetry
>> standpoint, it's actually not very useful when the node is not it's
>> own 'topReference'. I really can't think of any situation in which
>> you'd be interested in that particular set of edits.
>>
>> So, I think I'll probably alter the behavior of getReferenceEdits to
>> instead return #3.... at least by default - the ideal would be to have
>> flags to alter which set of edits is returned...
>>
>> This would break backward compatibility for this command, but since I
>> can't imagine many people actually wanting the current behavior (as
>> Erkan's case illustrates), I don't think that will be a big issue.
>>
>> Also - Erkan, haven't had a chance yet to look at your
>> changeEditTarget issue... if you could supply some sample code
>> illustrating a case where it's broken, it would help, though...
>>
>> - Paul
>>
>> 2010/6/29 Erkan Özgür Yılmaz <[email protected]>:
>> > I was wrong about getting the right reference edits. The method,
>> > FileReference.getReferenceEdits, returns the list of the edits done in
>> the
>> > reference node of that FileReference instance (FileReference.refNode).
>> To
>> > get the edits on a differenct reference node, which is what I want, I
>> should
>> > always give a reference node to onReferenceNode flag. The behaviour of
>> maya
>> > and pymel is correct... I was wrong about that in previous posts... Also
>> > changeEditTarget is not working in my case, but its behaviour is
>> somewhat
>> > correct (where I don't expect that to happen).
>> >
>> > E.Ozgur Yilmaz
>> > Lead Technical Director
>> > eoyilmaz.blogspot.com
>> > www.ozgurfx.com
>> >
>> >
>> > On Mon, Jun 28, 2010 at 3:19 PM, Erkan Özgür Yılmaz <[email protected]
>> >
>> > wrote:
>> >>
>> >> I have a similiar problem with references:
>> >>
>> >> - trying to get referenceEdits for a referenced node inside another
>> >> referenced node gives nothing until I specify that I want to get the
>> edits
>> >> those has been done in a specific reference node by using
>> onReferenceNode
>> >> flag whereas both maya and pymel documentation says not using
>> >> onReferenceNode causes you to get all the edits.
>> >>
>> >> - trying to change edit targets with referenceEdit.changeEditTarget is
>> not
>> >> working in above case with or without onReferenceNode flag
>> >>
>> >> I'm not saying that these are bugs, may be they are not very well
>> >> documented or I don't understand the correct usage... But I must say
>> that in
>> >> other cases I use these commands successfully to change referenced
>> files
>> >> with new ones. I only have problem when the referenced file also has
>> some
>> >> references to other files...
>> >>
>> >> E.Ozgur Yilmaz
>> >> Lead Technical Director
>> >> eoyilmaz.blogspot.com
>> >> www.ozgurfx.com
>> >>
>> >>
>> >> On Fri, Jun 18, 2010 at 1:30 PM, MarkJ <[email protected]> wrote:
>> >>>
>> >>> I've been deep in referencing hell for the last few weeks, trying to
>> >>> debug some issues with the way Maya handles namespaces and references
>> >>> in our pipeline. Part of this is to do a fast checker that will give
>> >>> the guys a heads up as to the health status of the ref scenes they're
>> >>> working on. I'm basically trying to get a printout of all failed
>> >>> referenceEdits for all loaded referenceNodes.
>> >>>
>> >>> It looks like I've come across a possible bug in the way Pymel hadles
>> >>> this. Code below is a simple test wrapper, in the scene I've got 3
>> >>> references all pointing to the same file. I know that all 3 have
>> >>> failed edits on them and if I run the below code using the
>> >>> cmds.refQuery I get all 3 as fails + the count. But using either of
>> >>> the Pymel blocks I only get the fails caught for the first ref, not
>> >>> the other 3.
>> >>>
>> >>> refNodes=[ref for ref in pCore.listReferences() if ref.isLoaded()]
>> >>> for ref in refNodes:
>> >>> print ref,
>> >>>
>> >>>
>> len(pm.referenceQuery(ref.refNode,successfulEdits=False,failedEdits=True,es=True))
>> >>> print ref,
>> >>>
>> >>>
>> len(cmds.referenceQuery(str(ref.refNode),successfulEdits=False,failedEdits=True,es=True))
>> >>> print ref, len(ref.getReferenceEdits(failedEdits=True))
>> >>>
>> >>> anybody else come across issues with this?
>> >>>
>> >>> thanks
>> >>>
>> >>> Mark
>> >>>
>> >>> --
>> >>> http://groups.google.com/group/python_inside_maya
>> >
>> > --
>> > http://groups.google.com/group/python_inside_maya
>>
>> --
>> http://groups.google.com/group/python_inside_maya
>>
>
> --
> http://groups.google.com/group/python_inside_maya
>
--
http://groups.google.com/group/python_inside_maya
