Hi, sorry for not posting for a long time. But this one is really interesting! Earlier this year we had a job to recreate a character that we used in Eset commercial. It would have been an easy thing, because we had the asset, but the arnold renderer, and shaders are changed a lot since last summer. And the config wasn't backed up properly with the project. This gave the idea that we should re-think our current application-environment-management system (what an expresssion:)
Until that point, for maya we had a lot of scripts, icons, shelves on the fileserver, that accessible for every maya; and with plugins/modules on the local machine (if it would be also on fileserver, the plugins we develop can't be updated if someone is using maya loaded that plugin.) For starting maya, artists were using a custom batchfile that copies needed plugins to local, sets some environment variables, and launches. But almost everything was hard-coded to maya.env and the batchfile.
It worked to point, but wasn't effective nor elegant. So we came up with the idea of Applauncher.
Here I give a little insight about this software, maybe useful for some of you thinking about similar solution.
It is a gui for starting maya, and nuke with the proper environment. In short: in the gui the artist chooses the project (show) and the context (lighting, dynamics, animation etc.) he/she wants to work. Then applauncher copies the needed scripts, plugins, modules etc., sets the environments and launches the application.
What is needed for the given context is stored on the network in an xml file, that is easy to edit and read. It's created by sup. before the show starts, but of course can be modified later. In the xml we define what addontype (scipts, modules etc), what addon with what version is in that environment config.
So when user chose context, and clicked on launch, the needed content (plugins, scripts etc) are copied to local disk, or if that content is already there, the copy process can be skipped. After copy, depending on addontypes the proper environment variables are set.
For maya we use following addontypes: modules, scripts, shelves, icons, additional envvars. All plugins are stored in modules: that is the most flexible type of addon.
For nuke we use much more type of addons, that are differently set for the software: gizmos, scripts, plugins, icons, luts, modules, ofx, prefs etc.
Important that on the server-side the addons are versioned, but on local they are not. Always the actual version of the addon (defined in xml) is copied.
We don't make separate addon for each gizmo, or script, it would be hard to version and manage them. Rather we chose to group them along some common attribute. For example my script package for maya is 1 addon. The other developer's scripts are another addon.
Example structure in xml, for maya:
addonGroup: modules
addon:commonscriptpack
version: 1.0
addon: userscriptpack1
version: 1.1
addon: userscriptpack2
version: 1.5
addon: yeti
version: 1.0
addonGroup: shelves
addon: lighting
version: 1.3
...
Now every artist at us uses this little gui without problems. The advantages: 1. we can restore any working environment at any time 2. much faster app. loads. 3. easier distribution of tools. I even integrated it with deadline, it was a must to run renders with same environment as the artists.
I hope this writing was understandable, and useful. If needed, I can continue telling more about this, because I think it has really nice logic, and features, that now is proven to be very useful.
Further reading on this theme in these topics: 1 2 3
No comments:
Post a Comment