Replacing Sub Reference Path
433 views
Skip to first unread message
Erkan Özgür Yılmaz
May 5, 2014, 4:52:26 AM5/5/14
to python_inside_maya
Hi all,
Is there a way to persistently replace sub-reference paths.
Marcus Ottosson
May 5, 2014, 5:39:19 AM5/5/14
to python_in...@googlegroups.com
Spontaneously, I would think that those path's aren't stored within your current scene, but in the reference. I suppose the most sustainable method of altering those paths would be in the scene with the immediate reference, and not in a parent scene, as you would be relying on the order at which your history is applied. E.g. if the nested reference has it's path altered before its parent reference.
Generally, I'd consider whether or not there was a way to work with flat hierarchies of references, as opposed to nested, as these scenarios can understandably get quite complex.
--
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 python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx5rnrXaapK_yxsaeRhXwHXURh7sa1bbor%3DHFs-VDS6yVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Erkan Özgür Yılmaz
May 5, 2014, 5:53:17 AM5/5/14
to python_inside_maya
We were doing the complex thing previously with what we called "Deep Reference Updates".
It was updating all the intermediate files and creating new versions. It was a quite complex script though. Then we wanted to switch something we call "Shallow Reference Update" and I've coded it.
It is much much simpler than the previous one, and it is working very nice, but again when you reopen your scene everything you just did is gone.
Now what I plan to do is to create a scriptJob, and store all the reference paths in a side file (pickled dictionary) and restore all the paths on scene open. I don't like it and will never like this kind of hacks. But what we were able to do with this "Shallow Reference Updates" is to have a kind of Katana Style asset loads and I want to keep it.It was updating all the intermediate files and creating new versions. It was a quite complex script though. Then we wanted to switch something we call "Shallow Reference Update" and I've coded it.
It is much much simpler than the previous one, and it is working very nice, but again when you reopen your scene everything you just did is gone.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBDnLWatPp9QXWpgEL5ZWAtq1mRC6Z9G3st6%3DAwOCRFzA%40mail.gmail.com.
Marcus Ottosson
May 5, 2014, 6:07:30 AM5/5/14
to python_in...@googlegroups.com
I think the general approach to nested references is to flatten the hierarchy prior to publishing your asset.
That way, the TD still has access to each reference while working while the artists won't be bogged down by the issues of working with a nested reference. Recursively updating references (if I understood you correctly) sure sounds dangerous.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx5k01TZx05xZ1ivE5FXFAn9X-1_Da3-98ByZqiByW5jwQ%40mail.gmail.com.
Erkan Özgür Yılmaz
May 5, 2014, 9:02:35 AM5/5/14
to python_inside_maya
I'm thinking about using "Scene Assemblies" instead of FileReferencing. Do you guys have any bad experience with scene assemblies, or did you switch to them and ever missed file referencing?
We are kind of in asset creation phase and I think I can handle a migration from file referencing to scene assemblies if at the end it will worth it. So it is very important for me to know if any of you guys had a bad experience with Scene Assemblies.
thanks in advance,
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCMPNSpi%3DjwOdMgmrRepr%3DGk7bH8Xnyzd7QeE98rhG4SA%40mail.gmail.com.
Marcus Ottosson
May 5, 2014, 9:27:06 AM5/5/14
to python_in...@googlegroups.com
I believe the intent of Scene Assembly is to replace the general Referencing workflow. I have little experience with it however, but it would seem to favour a more manual (read "stable") approach and thus becoming more reliant on an automatic/coded approach. I would imagine that it solves many of the mysteries surrounding nested references however and wouldn't give up on it so quickly. :)
If you're in the phase where you need a complex set-up of references, and are in a position to try scene assembly, then I'd be very interested to hear about your conclusions. :)
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx7vWkwfWZ8LhOKYQj9O_QB5jqu9jeeXfJ3g%2BSPToZL7Gw%40mail.gmail.com.
Erkan Özgür Yılmaz
May 6, 2014, 11:02:43 AM5/6/14
to python_inside_maya
Hey Marcus,
It seems that I was wrong about Scene Assemblies, it is much much better and favorable compared to FileReferences. My first impression was wrong. I was looking from somewhat an old perspective.I've watched a couple of videos in Area. What I understood is that Scene Assemblies are somewhat parallel when compared to the serial workflow of FileReferences. And what I've envy about Katana was being able to load the upstream/downstream assets on render time (I know that Katana is more than that) and with scene assemblies you are kind of able to do that, also it supports simple regular expressions for custom selections of which versions you want to see in which event, also it is open source and has a python api (though I didn't check it yet).
Now I need to figure out a workflow on top of it and write migration scripts for the environment assets that we've already created.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD6S2RbZZ%3DoTC5JsjN4fSpfVhdFPXnugWzj3HRKDUoRyQ%40mail.gmail.com.
Erkan Özgür Yılmaz
May 7, 2014, 7:15:56 AM5/7/14
to python_inside_maya
some new findings, first I loved being able to have all the different representations (locator, bouding box, lowres, hires, ASS/MRProxy/DRA etc. anything you want/name) of an asset in one place all together and then switch between them.
But there is a couple of deal breakers: you can not change the material assignment once you've referenced the assembly definition, also it doesn't support render layers, making connections from nodes in different levels of assembly definitions are not always possible etc.
But there is a couple of deal breakers: you can not change the material assignment once you've referenced the assembly definition, also it doesn't support render layers, making connections from nodes in different levels of assembly definitions are not always possible etc.
So with all its quirks I still can see a workflow adapting Scene Assemblies, but I think we are not going to be able use it for our current project, it is not mature yet.
Marcus Ottosson
May 7, 2014, 7:56:53 AM5/7/14
to python_in...@googlegroups.com
Ah, thanks for the update, that's very good to know.
Generally, I'd avoid mixing shader assignments and references altogether. In fact, I wouldn't mix anything but meshes and caches into a shader-assignment setup. But, if your current project already assumes such a workflow, then it makes sense not to try and jam this into scene assembly.
In the future, would you consider seggregating shaders from references? It would possibly involve storing shaders and their assignments separately; potentially resulting in more code on your end; but the benefits might outweigh the cost when you're looking at many projects with similar requirements.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx427vOw53es3%2BkEf9jx2PkMaf%2Bsa9zZcjrT-0OX0tek8w%40mail.gmail.com.
Erkan Özgür Yılmaz
May 7, 2014, 9:44:40 AM5/7/14
to python_inside_maya
After thinking about the pros/cons of Scene Assemblies and because of the fact that we have switched to Arnold for this project and then I presume that we are not going to use that much render layers anymore, we've decided to give Scene Assemblies a shot in one of our complex sequences where we really need to render everything as ASS files.
The only thing that we are avoiding was doing per face shader assignments, but we were happy with being able to assign shaders to our referenced assets in lighting scenes.Also, I had this very old shader assigment system of mine. I was using it when Maya was f*cking the shader assignments on referenced assets a lot, then I've written this custom system which was restoring the shaders at render time (with pre-render layer mel scripts). I may develop it further to handle shader assignments on Scene Assemblies, don't know.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC_vB3Ou6t2vKXL7PXmEvSaUny90CNGeRE-ExLjRdYFzg%40mail.gmail.com.
Marcus Ottosson
May 7, 2014, 10:23:20 AM5/7/14
to python_in...@googlegroups.com
> I was using it when Maya was f*cking the shader assignments on referenced assets a lot
This has been my experience as well (small though it may be, I don't do shading) and one of the reason I suggest keeping it separate. But not the only reason. Splitting up the process of setting up assets and assigning shaders have other benefits in overall production management. Benefits involving automation; such as shot-building, in which case a scene isn't dependent on references at all, and may be assembled differently based on your requirements. E.g. lighting artists would build with only assets and dependencies fit for lighting, and the animator, may build it with live rigs, so she could animate them.
The concept exists in parallel industries too. Here, have a good book on the topic:
In particular, the part of about "Intelligent content", 1.2
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx7_U0xkkaLqL42nBkRfjTLhu-JdurKpkDvVFFZForV7XA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages