View Full Version : reference and shader problems
07 July 2010, 07:15 PM
We're having a problem with the referencing system.
Lets say we have a file called testA.ma with a sphere and a red material.
Now we reference this file in a scene called testB.ma. In testB, the modeller was a bit distracted and assigned another shader to the referenced sphere from testB.ma. He then saved the file.
So what happens now is that the sphere in testB has is original material overridden by the material from testB.
the modeller then sends the scene to the lighter which is not really happy to see the original shader ovrewritten. In this case it's an easy fix as we just can reassign the material, but with scenes containing hundreds of objects, it gets a bit more complex.
As all those files are saved as ma file, I thought there could be a way to fix this using a text editor. I can see where the material form testB gets assigned and remove that line, but then, the sphere comes in testB.ma with no shader assigned at all, which is not really a solution.
Any comments or tips from people with the same kind of experience in production would be welcome !
07 July 2010, 02:29 PM
I suppose you took out a line like:
//connectAttr "testARN.placeHolderList" "lambert2SG.dagSetMembers" -nextAvailable
but perhaps you overlooked the referenced edit list?
You'e going to have to make an edit something like this:
createNode reference -name "testARN";
setAttr ".placeHolderList" 0;
setAttr ".edits" -type "dataReferenceEdits"
//"testARN" 2 3 "|testA:pSphere1|testA:pSphereShape1.instObjGroups" "testA:lambert2SG.dagSetMembers" "-na" 5 3 "testARN" "|testA:pSphere1|testA:pSphereShape1.instObjGroups" "testARN.placeHolderList" "testA:lambert2SG.dsm";
07 July 2010, 08:03 PM
you can create selection sets for each shader and the objects it is assigned to and further down your pipe assign them back.
what we do is export our shaders to a shaders.mb file for each model/scene once we finished developing them and reference them somewhere along the way. like after the animation/rig and prior to lighting.
this way you can also always edit your shaders/change them without the need to reassign them somewhere in your setup, it will be automatic.
we do a look dev scene for the model, shaders, lights.. a test scene. once happy we create the pipe:
model(includes uvs and a lowres model for previz anim) -> rig -> animation -> shaders(this sometimes is assigned in the rig) -> master lighting -> layers(if there are different lightings per object layers) -> render passes
often we have to do cleanups, reference edit list removals/fixes just like mentioned here to fix stuff. but this is the most proper way to work, and ofcourse you lock everything you dont want others to change along each reference file..like transformations or values.
07 July 2010, 09:02 PM
Replace reference option have been working pretty well with us . When it started to give some surprises ; we had shader bin created for almost every character , Environment and animated props . Ofcourse there are times where things get tricky and one needs to edit as mentioned .
We had a system where the final scenes assets were replaced completely with the shader files . We already had seperate files set up for beauty , occlusion , vectors and mattes and replace referencing did great .
Now we can replace with a single file which have all the passes embedded ; thanks to render passes and more predictable render layers .
07 July 2010, 05:48 PM
Try using my abxRenderLayers (http://www.creativecrash.com/maya/marketplace/scripts-plugins/rendering/misc/c/abxrenderlayers--2) script on creative crash. I added some much needed functions to the render layer menus. You can list and remove multiple overrides at once on a given render layer, much in the same way that you can list and remove reference edits in the reference editor. It also has tools to export render layers to .mel files that you can then read through, edit and do a search and replace on node names, then re-import back into your scenes.
07 July 2010, 05:48 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.