Initially, we were maintaining a customized version of rvui.mu that made any
base tweaks to the interface, settings, etc. that we needed, but this proved to
be a huge pain, since that file often changes between minor RV releases
(breaking everything).
Since then, I’ve switched to implementing our modifications and customizations
as a single facility “mode” in an RV package that sets any preferences that
can’t be saved in RV.conf (or calls explicit commands to switch them
immediately in certain cases when required – turning off Linear Filtering, for
example). Additionally, it handles things like in-line modifications to the
built-in menus (which is still a pretty clunky process).
-Nathan
From: Dan Walker
Sent: Thursday, October 06, 2011 7:25 PM
To: Nuke user discussion
Subject: Re: [Nuke-users] LUT global location, variable(s)???
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.
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 <nathan_ru...@hotmail.com> 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
Sent: Thursday, October 06, 2011 10:52 AM
To: Nuke user discussion
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 <dave.goodbo...@u-fx.co.uk>
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 <walkerd...@gmail.com> wrote:
Wow, no quick solutions? That just sucks now don't it! :-)
On Oct 4, 2011 10:27 AM, "Dave Goodbourn" <dave.goodbo...@u-fx.co.uk>
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 <walkerd...@gmail.com> 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" <tungau...@yahoo.com> 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 <walkerd...@gmail.com>
>> > To: Nuke user discussion <nuke-users@support.thefoundry.co.uk>
>> > 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
>> > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>> _______________________________________________
>> Nuke-users mailing list
>> Nuke-users@support.thefoundry.co.uk, 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
>
> *FAX* +44 20 7268 0069
> d...@u-fx.co.uk
>
> 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
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
------------------------------------------------------------------------------
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
--------------------------------------------------------------------------------
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
