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. I think with Scene Assemblies, if we need to have a custom shader setup on the assets then we should do it on the Assembly Definition and this way it is going to make things cleaner and consistent. Also, there are AOVs that we still can use to render custom passes etc. 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. E.Ozgur Yilmaz eoyilmaz.blogspot.com On Wed, May 7, 2014 at 2:56 PM, Marcus Ottosson <[email protected]>wrote: > 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. > > > On 7 May 2014 12:15, Erkan Özgür Yılmaz <[email protected]> wrote: > >> 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. >> >> 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. >> >> >> E.Ozgur Yilmaz >> eoyilmaz.blogspot.com >> >> >> On Tue, May 6, 2014 at 6:02 PM, Erkan Özgür Yılmaz <[email protected]>wrote: >> >>> 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. >>> >>> >>> E.Ozgur Yilmaz >>> eoyilmaz.blogspot.com >>> >>> >>> On Mon, May 5, 2014 at 4:27 PM, Marcus Ottosson >>> <[email protected]>wrote: >>> >>>> 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. :) >>>> >>>> >>>> On 5 May 2014 14:19, Erkan Özgür Yılmaz <[email protected]> wrote: >>>> >>>>> Ohh, I see that it is also not possible to change what definition an >>>>> asset reference is referencing to in the main scene, so it is useless for >>>>> my purpose... >>>>> >>>>> E.Ozgur Yilmaz >>>>> eoyilmaz.blogspot.com >>>>> >>>>> >>>>> On Mon, May 5, 2014 at 4:02 PM, Erkan Özgür Yılmaz <[email protected] >>>>> > wrote: >>>>> >>>>>> 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, >>>>>> >>>>>> >>>>>> E.Ozgur Yilmaz >>>>>> eoyilmaz.blogspot.com >>>>>> >>>>>> >>>>>> On Mon, May 5, 2014 at 1:07 PM, Marcus Ottosson < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> On 5 May 2014 10:53, Erkan Özgür Yılmaz <[email protected]> wrote: >>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> On the other hand working with flat hierarchies is not an >>>>>>>> alternative for us for now. >>>>>>>> >>>>>>>> >>>>>>>> E.Ozgur Yilmaz >>>>>>>> eoyilmaz.blogspot.com >>>>>>>> >>>>>>>> >>>>>>>> On Mon, May 5, 2014 at 12:39 PM, Marcus Ottosson < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5 May 2014 09:52, Erkan Özgür Yılmaz <[email protected]>wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Is there a way to persistently replace sub-reference paths. >>>>>>>>>> >>>>>>>>>> In my current setup, whenever I replace a sub-reference path, the >>>>>>>>>> edit (changing the file reference path) is not saved with the file. >>>>>>>>>> So >>>>>>>>>> reopening the scene will not reflect the changes made in the >>>>>>>>>> reference file >>>>>>>>>> paths. >>>>>>>>>> >>>>>>>>>> E.Ozgur Yilmaz >>>>>>>>>> eoyilmaz.blogspot.com >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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/CAGNmyx5rnrXaapK_yxsaeRhXwHXURh7sa1bbor%3DHFs-VDS6yVA%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx5rnrXaapK_yxsaeRhXwHXURh7sa1bbor%3DHFs-VDS6yVA%40mail.gmail.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/CAFRtmOBDnLWatPp9QXWpgEL5ZWAtq1mRC6Z9G3st6%3DAwOCRFzA%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBDnLWatPp9QXWpgEL5ZWAtq1mRC6Z9G3st6%3DAwOCRFzA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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/CAGNmyx5k01TZx05xZ1ivE5FXFAn9X-1_Da3-98ByZqiByW5jwQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx5k01TZx05xZ1ivE5FXFAn9X-1_Da3-98ByZqiByW5jwQ%40mail.gmail.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/CAFRtmOCMPNSpi%3DjwOdMgmrRepr%3DGk7bH8Xnyzd7QeE98rhG4SA%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCMPNSpi%3DjwOdMgmrRepr%3DGk7bH8Xnyzd7QeE98rhG4SA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>> 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/CAGNmyx7vWkwfWZ8LhOKYQj9O_QB5jqu9jeeXfJ3g%2BSPToZL7Gw%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx7vWkwfWZ8LhOKYQj9O_QB5jqu9jeeXfJ3g%2BSPToZL7Gw%40mail.gmail.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/CAFRtmOD6S2RbZZ%3DoTC5JsjN4fSpfVhdFPXnugWzj3HRKDUoRyQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD6S2RbZZ%3DoTC5JsjN4fSpfVhdFPXnugWzj3HRKDUoRyQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- >> 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/CAGNmyx427vOw53es3%2BkEf9jx2PkMaf%2Bsa9zZcjrT-0OX0tek8w%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx427vOw53es3%2BkEf9jx2PkMaf%2Bsa9zZcjrT-0OX0tek8w%40mail.gmail.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/CAFRtmOC_vB3Ou6t2vKXL7PXmEvSaUny90CNGeRE-ExLjRdYFzg%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC_vB3Ou6t2vKXL7PXmEvSaUny90CNGeRE-ExLjRdYFzg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAGNmyx7_U0xkkaLqL42nBkRfjTLhu-JdurKpkDvVFFZForV7XA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
