I’m not using OpenPype or Ayon yet but I’m browsing through the documentation in preparation for an eventual test drive. I noticed that the DCCs must be launched through the Ayon app that must be downloaded and installed locally on the desktop machines. This concept is not compatible with our current solution (Rez) and would complicate things considerably for us.
I’m starting this topic in order to start a discussion around the possibility of adding support for Rez, to talk about how we are using it and hoping others can chime in with their own experience.
We are a university with over 250 machines running Windows (not my decision). At the beginning of the school year, the IT department ask all the teachers which software they need for their classes, they install them all on one computer, ask the teachers to test and then image that computer to all the others. Then we are stuck with that config for the rest of the year. Teachers don’t have admin rights on the machines so they cannot install new versions themselves if they wanted. They do have admin rights on their own computer only, in their office.
I didn’t like that. I like to update DCCs and plugins with point releases during the year for all the students. That’s why I installed Rez myself. I put it on the network in a place I have write access, I created a bunch of packages and I even installed Maya, Nuke, Houdini and Mari to that location on the network (installed locally on my machine, copied the folder to the network and created a rez package for them). I did the same with the Arnold plugins for Maya and Houdini and the maya-usd plugin.
This way, I can update those applications and plugins whenever I want (which is usually within a week of a new release). Also, when you launch an application through Rez, it launches from the network but while you are working, it can copy the folder locally to the machine so the next time you (or anyone else) launch the same app, it will use the local copy.
Of course, Rez also manages the versions intelligently. When you request the latest version of Houdini and the latest version of htoa, it uses the latest two versions that are compatible together. That is the main reason for using Rez in the first place.
Rez packages can define environment variables, several different packages can add to one single environment variable (PATH, PYTHONPATH, etc.). They can define aliases to define commands to execute in the terminal (the houdini package defines the
houdini alias, the
mplay, etc.) so once you are inside a rez environment, you can simply type the name of the alias to launch the tool you want.
I have created a set of Windows shortcuts in a folder accessible to all. Each shortcut contains a
rez-env command and a list of packages to load. For example, the houdini shortcut has this command:
rez-env houdini-19.5 htoa-6 ocio_config_aces castors -- houdini
Specifying houdini-19.5 makes sure that this shortcut never launches Houdini 19.0 or Houdini 20.0 when it’s available. The same goes for htoa, it specifies version 6 so it can pick any version as long as it starts with 6. The
ocio_config_aces packages is one I made that provides the config and sets the
OCIO environment variable accordingly. And the
castors package is for a project we were working on this winter. It adds a few custom HDAs to the houdini session and sets a few settings.
When a new version of Houdini or htoa becomes available, I can simply install it on the network, update the package for it and release it. The next time someone uses the shortcut, the rez-env command will resolve to the new version and launch it. I don’t even have to update the shortcut, or to tell the students about it. If I release a new version of Houdini but don’t release the version of Arnold that goes with it, the shortcut will not launch that new version. It only uses versions that are compatible together.
During the last semester, we needed to test a beta version of Arnold for Houdini. I created a new shortcut specifying the beta version and bypassing the filter (we have a rez filter that ignores beta versions by default). So when using this shortcut, students would fire up a houdini session with the beta version of Arnold and they were able to test it on any machine, and even in the render farm.
To me, it looks like Rez could do a lot of what that Ayon app does already, but in a more flexible way. There could be an ayon package that defines the environment variables it needs to send to the DCC. It could also define the aliases for the commands it has.
This way, studios could choose how they launch applications the way they want with Windows shortcuts, their custom rez launcher, or any other method. Or the Ayon app could use a list of package requests and the name of an alias to launch an app instead of a hard coded path, and inject its own package to the list.
For us, it greatly simplified the way we manage applications and plugins. I even showed it to the IT guys and they were excited how much it improved the system we had in place. I also simplifies the way I can release my own plugins to the students. So I think it would be a blocker for us if we can not launch applications through Rez.
Next year, I will create a shortcut for each application, for each project team. They can decide which version they want to use and if they want to use Arnold with Houdini or Maya, or RenderMan, and decide the version of the renderer they use. This way, each team will have a tailored made application for their needs and we will still be able to update them very easily.