Sorry if this question has already been covered, I couldn’t find anything about it when searchin this forum.
I’m trying to script a “smart” network deployment so we can get various vray versions running, ie: stable, test and nightly builds. Using a quiet command line install seem appropriated but I’m still facing two difficulties :
system : OSX SL
app : maya 2012 / vray 2.x
- locally modified / installed files :
Some files are directly copied / modified in maya : shared libraries (libvray.dylib etc.) and common mel scripts … is there a reliable way to “programmatically” identify these files ? I would like to be able to relocate things since we build DYLD_LIBRARY_PATH and MAYA_XXX_PATH based on custom environment variables.
- uninstallation
When installing a new version, the vray installer will try to uninstall the “old one”, it is really annoying since I don’t want to break previous deployments. What is the process used to detect this ? Is there a way to avoid the uninstall step, or just cheat to “hide” things so the installer won’t touch anything ?
we use a central install, where the vray installs are on the server and loading a different version of vray is as simple as changing maya.env and restarting maya.
We have folder that is unversioned, and this is were we put the current ‘standard’ version, then there are nightly builds in their own folders. We have a maya launcher which loads the maya.env you need for the current project. As for the render farm, we use Rush render que, which allows us to tell the render node what environment variables to use, and basically push the same values as the maya.env to Rush.
The result is we can change the version everyone is using as simply as changing the contents of the unversioned vray folder. Users can either default to the unversioned folder, or specify a nightly build. Really easy to manage, and really easy to update.
We do have a similar system, based on environment variables that will define the various paths for our applications. When launching a specific maya version, an appropriated shell profile is sourced to build these variables, and an “environment key” is sent on the farm to identify this profile when rendering, so it should behave just like your Maya.env approach.
My issue here is that I want to install additional vray versions, and keep the previous ones, and I can’t find a clean way to do this since the vray installer will uninstall any “detected” vray, and some resources are not meant to be duplicated (vray dylibs, renderer desc etc.). For the moment we have to also duplicate Maya entirely, and keep one maya intallation for each vray version we want to deploy.
To take a quick example, deploying Shave&Haircut is pretty easy in comparison since it is a simple osx package, and I’m able to list and extract the content myself, when and where I want.
I hope I’m understandable, my english is disastrous, please accept my apologies.
To take a quick example, deploying Shave&Haircut is pretty easy in comparison since it is a simple osx package, and I’m able to list and extract the content myself, when and where I want.Emphasis on “simple” The V-Ray installation has many more components and is quite a bit more complicated. Also, we are trying to stay clear of OS-specific installs (not worth the effort required to support them, especially for Mac OS X).
What you would normally do is run the V-Ray installation (maybe with custom paths), copy the resulting files to whatever folder structure is convenient for you, and uninstall it.
I agree that a VRay installation is (not that much) complex, but putting “simple” and “shave” in the same sentence was way too tempting
I’m trying a brutal approach (if brute force don’t work, try harder …) : unmount network drives to avoid uninstallation, perform the new install on some “dummy” folders, identify what was created in the fake maya root, and then move relevant files where I want. In fact there’s only a couple of files created / pached in the maya tree so it’s quite easy to relocate.
That thread is for Windows; for Linux, if you run the installer from the command line, it will automatically create a config file and at the end will tell you what option to use.
At the end of the installation, there should be something like this:```
Saving your install configuration to installcfg.txt…
You may now install the product on another machine by issuing
Ok, it’s working now, just as a reminder :
- the option for *nix systems is “-fromFile”
- it won’t accept a human readable xml so it is necessary to go through a first manual attempt to generate the required “installcfg.txt”
I also had to create fake mel scripts (scripts/others/createMayaSoftwareCommonGlobalsTab.mel, unifiedRenderGlobalsWindow.mel and shouldAppearInNodeCreateUI.mel)
I don’t know if I am allowed to divulge the secret, but there’s a lone file to move/delete to avoid the uninstall step, “locate chaos” is my friend now
The V-Ray installation has many more components and is quite a bit more complicated. Also, we are trying to stay clear of OS-specific installs (not worth the effort required to support them, especially for Mac OS X).