Yes, that is the module that you need to override. By setting RV_SUPPORT_PATH to a location of your choosing, and copying the same structure that the rvPackages file structure has, with an overriden source_setup.mu, you can change all behaviours. I think that even setting that file as empty will get rid of all colorspace assumptions.
On Fri, Oct 7, 2011 at 9:35 AM, Jonathan Egstad <[email protected]>wrote: > Yeah, we use RV to and I've already implemented the LUTs pulldown. > Although I can't figure out how to force "No Conversion" when RV opens. The > Alexa's auto default to DPX/Cineon. > > > You have to override the default colorspace handling code which is > triggered on a new-source event - I believe it's in the source_setup.mu' > file. > > -jonathan > > Thoughts?! > > Yeah, I'm feeling the same as you on FC too Nathan, although having that as > a secondary is nice and it pisses me off to no end to not be able to figure > this out or find a workaround. > > Thanks everyone!!!!! > > > > On Thu, Oct 6, 2011 at 7:09 PM, Nathan Rusch <[email protected]>wrote: > >> Well, to be fair, FrameCycler is probably the black sheep in this >> conversation... from what I can tell they just sort of do their own thing >> and expect everyone to deal with it. Never once have I heard of them beta >> testing a product or feature or asking for user feedback or input. Thus, my >> stance on Framecycler has always been to steer away from it when things >> start to get serious as far as maintaining any kind of a consistent, unified >> pipeline. >> >> Offhand, RV can actually do centralized configuration stuff even with >> local installations (we use it that way). You can set up a default >> preferences file in a central location and point all users to it to start >> off with, and whichever config file is newer (between the central and the >> user’s) will take precedence in cases where a preference is defined in both. >> And obviously being able to roll your own extensions is a huge benefit for >> review tools, LUT repositories, etc. >> >> -Nathan >> >> >> *From:* Dan Walker <[email protected]> >> *Sent:* Thursday, October 06, 2011 10:52 AM >> *To:* Nuke user discussion <[email protected]> >> *Subject:* Re: [Nuke-users] LUT global location, variable(s)??? >> >> *Not too sure what else you were looking for really. * >> >> >> Being able to control configuration settings on a piece of software (eg. >> FrameCycler) without having to copy something to the software's native >> location (per machine). >> >> Nuke and RV can do it. RV is installed on our server and there are env's >> you can set for custom lut locations. You can also modify the >> User_settings.xml file that FC generates to hard code a path, but again, >> that file is local to the machine FC is being ran on. >> >> <LUTPath1>" >> \\xxx\xxx_xxx\release\nuke\config\project\XXX\versions\v001\nuke_LUT\ >> "</LUTPath1> >> >> After doing quiet a lot of research, I'm still stumped with FrameCycler. >> Yes there are variables to control where framecycler puts it's temp files >> (which is where the FrameCycler User_settings.xml also resides) but it's >> ridiculous to assume, when defining a LUT setting for everyone, that you'll >> need to do it on a per machine basis. >> >> Yeah, it's great that there are software deployment systems that can >> control the push of a config and all the other features that comes with it, >> but come on! This isnt' the 90's for cry'in out loud. One would think >> software has been developed to "assume" that a facility would maybe want to >> have the feature of setting a "global" config and not assume all facilities >> are interconnected when it comes to Pipeline and IT departments. What about >> facilities that are global (meaning all around the world) that reference a >> "cloud" server? Should I have to push a config to all the users in London, >> Hong Kong, etc.... >> >> My .02 >> >> >> >> On Tue, Oct 4, 2011 at 3:28 PM, Dave Goodbourn <[email protected] >> > wrote: >> >>> Now that all depends on your definition of quick! Once you have a >>> software distribution system setup, making any change to 100+ workstations >>> and render nodes can only take a matter of minutes! >>> >>> You can always do it with scripting to copy config files and setup >>> variables on each machine. Not too sure what else you were looking for >>> really. >>> >>> >>> >>> On 4 Oct 2011, at 23:07, Dan Walker <[email protected]> wrote: >>> >>> Wow, no quick solutions? That just sucks now don't it! :-) >>> On Oct 4, 2011 10:27 AM, "Dave Goodbourn" <[email protected]> >>> wrote: >>> > Have you looked at software deployment software like WPKG < >>> http://wpkg.org/> at >>> > all? You can very easily deploy all the settings and environmental >>> variables >>> > to all your machines from the comfort of your own seat! Works well for >>> us. >>> > It's only Windows based but there's plenty of *nix solutions like >>> > Puppet<http://puppetlabs.com/> >>> > . >>> > >>> > D. >>> > >>> > On Tue, Oct 4, 2011 at 6:12 PM, Dan Walker <[email protected]> >>> wrote: >>> > >>> >> Hi Torax, >>> >> >>> >> unfortunately software cannot be installed on a server. even if it was >>> you >>> >> would still have to setup each individual artist with the manually >>> defined >>> >> environment variables or paths to the luts location. I'm specifically >>> >> talking about frame cycler when manually defining paths. all nuke >>> software >>> >> is installed locally on each machine and I'm looking for a way to >>> point >>> >> frame cycler and rv at luts installed globally. I'm wanting all of >>> this done >>> >> without having to go to each artist machine and perform a manual >>> setup. Nuke >>> >> already has a viewer lut setup, utilizing the alexa 3D lut through a >>> vector >>> >> field node. >>> >> On Oct 4, 2011 1:00 AM, "Torax Unga" <[email protected]> wrote: >>> >> > There are many different approaches: >>> >> > Here is one: >>> >> > - you will probably want to have you software installed in a central >>> >> location in the networks, so you only modify the settings once >>> >> > >>> >> > - put the luts in a location all software can see. (ie: >>> ../luts/nuke/ >>> >> ../framecycler ../rv) >>> >> > - generate the flavors of the lut for the software (I recomend .csp >>> for >>> >> Nuke and RV and .cube for Framecycler) >>> >> > - you can assign environment variables to those ( ie >>> $NUKE_ALEXA_LUT) >>> >> > >>> >> > - for Nuke create a viewer lut that point to the luts using the >>> >> Vectorfiled node. >>> >> > - for RV you can download and install the "Custom Luts Menu" package >>> >> available on their web site and modify the scripts to point to the lut >>> >> location', and to assign a hot key to it. you can also modify the " >>> >> sources.mu" file so the lut get applied automatically based on some >>> >> conditionals. >>> >> > - in framecycler you can modify the lut search folder in the >>> settings to >>> >> point to your lut folder. >>> >> > >>> >> > there definitely more advance setups, but this one should work. >>> >> > >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > From: Dan Walker <[email protected]> >>> >> > To: Nuke user discussion <[email protected]> >>> >> > Sent: Monday, October 3, 2011 6:56 PM >>> >> > Subject: [Nuke-users] LUT global location, variable(s)??? >>> >> > >>> >> > >>> >> > Hey, >>> >> > >>> >> > Anyone have a quick setup for accessing LUT's in a global location >>> that >>> >> RV, FrameCycler and Nuke can access, upon execution of whatever >>> Flipbook app >>> >> you're using. >>> >> > >>> >> > Example: >>> >> > >>> >> > I'm in Nuke - Nuke is using a custom Alexa LUT as the viewer LUT >>> >> (referencing the nuke 3D LUT at a global facility wide location) >>> >> > >>> >> > I launch FrameCycler - I want to access a custom Alexa LUT >>> (referencing >>> >> the IRIDAS 3D LUT at a global facility wide location) >>> >> > >>> >> > I launch RV - I want to access a custom Alexa LUT (referencing a 3D >>> LUT >>> >> at a global facility wide location) >>> >> > >>> >> > I want all of this setup globally instead of having to load the >>> LUT's for >>> >> each flipbook app on an individual basis. >>> >> > >>> >> > Thanks much in advance! >>> >> > >>> >> > -Dan >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > Nuke-users mailing list >>> >> > [email protected], >>> http://forums.thefoundry.co.uk/ >>> >> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >>> >> _______________________________________________ >>> >> Nuke-users mailing list >>> >> [email protected], http://forums.thefoundry.co.uk/ >>> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >>> > >>> > >>> > >>> > -- >>> > >>> > *Dave Goodbourn*** >>> > >>> > IT Manager >>> > >>> > ** >>> > >>> > * >>> > * >>> > >>> > *uFX **(a division** of uMedia)* >>> > >>> > *UK: *2nd & 3rd Floors, 32 Rathbone Place, London, W1T 1JJ >>> > >>> > *BE: *Avenue Louise 235, 1050 Brussels, Belgium >>> > >>> > *GENERAL *+44 20 7268 0068 <%2B44%2020%207268%200068> >>> > >>> > *FAX* +44 20 7268 0069 <%2B44%2020%207268%200069> >>> > [email protected] >>> > >>> > www.u-fx.co.uk >>> > >>> > >>> > >>> > Confidentiality notice< >>> http://www.umedia.eu/medias/CONFIDENTIALITY20NOTICE.pdf> >>> > >>> > Company legal information< >>> http://www.umedia.eu/medias/Company_legal_information.pdf> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> >> ------------------------------ >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > -- Jose Fernandez de Castro
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
