Nuke scnenemanager and other tools

Hi,

I will present a quick description of our most important inhouse tool for nuke, that I developed :). Maybe some of you will get inspiration to develop something like this. :) It is a gui programmed in python, using pyqt and pyqt designer.
It has two parts, the first part we call "scenemanager", which is a helper gui for quick opening and saving nuke scenes (yes, we call it scenes, instead of scripts, to avoid confusion with python and tcl scripts. I know nuke scene itself actually a tcl script, but anyway :)
In this gui you can quickly select the different parts of the path to the scene, like project, shotgroup (sequence), shot, task, and scene. Basicly with 5-6 clicks you can open any scene from any project.

Very, very handy to avoid spending minutes for browsing the paths in the default nuke scriptopen browser. 

Nuke scenamanager interface

It also has a number features, like: commenting scenes and displaying scene details, these are stored in an sqlite database. Storing used renderlayers for comparing later. Also featuring an elements checker, which is storing all the exr renders from fx or lighting, and comparing that to the versions used in the current comp, and displaying if there is new updated render for a shot. It is a brute-force method, it searches for exr sequences the selected project/shotgroup on disk. We could have used some automated method for storing render information from our deadline rendermanager, but we found that renders could come from outside, like outer renderfarm, or other vendors. So the most reliable method of knowing all the renders that we have, if we search for exrs in our file system.

Element checker

The other part of this scenemanager we call "nuke butcher" :)  (instead of nuke batcher), which is a standalone batch processor for nuke. It was developed in the need of more compers. With it you can chain different actions together, and do that on many comps at once. For example, the most basic use is to make a general herocomp for the first renders of one shot manually, and with this tool I can distribute that to all the other shots, and it will set the names, frameranges, and the newest arnold render versions automatically per shot, and submit all these comps to deadline to render. But it can do knob modifications on nodes, or any custom python code. Last time I wrote a custom code for that and with that I could export manually animated dof nodes from all the shots, then do a new hero comp render for all the shots (which means dof nodes are all the same in all shots), and then import the already exported dof nodes and place them back in comp. So it can save a loooooot of manual labor time. 

Nuke butcher interface

Of course it was a big challange to develop it, and it still needs some update, like saving action presets, but it is still very functional, and working nicely, and it is the software that I'm the most proud of! At least until this point :)

Hope this was interesting for some of you and I would be very grateful if you could share also some tools or tips what you are using at your place. 

Of course the software itself is not shareable, and not for sale, it is and inhouse development, used in Puppetworks. 

Applauncher - setting environment for apps

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

simple converter gui

I finally had the time to finish the first version of a program, that converts image sequences from one format to another. This is the first program I did with pyqt and designer, and it's still very very beta. The best thing in this is that I think I started to get the grasp of the designer-qt-python code-exe pipeline. If you want to try, you need to have nuke installed, because this program calls nuke for conversion, in command line mode. You have to set a path to a directory that contains the sequences to convert. It processes the sequences, but not the subdirectories recursively, it will be in the next release :) And you have to set the path to nuke and to the "glt_batchconvertFromCmdline2.py" file in the gui. As usual I can't guarantee anything. You can download it from here

Maya + pyqt + mel

I recently discovered a way to use my melscripting knowledge, and do some experiment with pyqt designer. I know I promised a gui programming with python and designer and that will come soon too. Until that: it is possible to create a gui in designer, and do the core scripting in mel. It creates an .ui file, and in maya 2011 you can load it with the loadUI command. If you name the layouts, buttons etc. properly in designer, you can freely modify them from mel, create, attach, parent or trigger action with them. Here you can find a good tutorial for start, and here is a table, showing gui element types in designer and the corresponding type in mel. I discovered some strange things about the layout handling, and I don't know if it's a bug or not. But if you don't want to learn python quickly, but want to quickly slap a gui, it's worth a try.

PyQT for nuke - 64bit

Hi, here is a post about compiling pyqt 4 for python 2.5 - 64bit, that is required for current version of nuke (6.1). The next version, 6.2 will come with  python 2.6, but until then if you want to use pyqt with 64bit nuke, you have to compile from source, or download from this place as I did. Thanks to Ozgur!