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

Submit nuke render job with specific views for deadline

Hi, I posted this on deadline forums, I thought it would be on a good place here too.
In this post I describe what files to edit in the deadline repository, if you want to submit not all, but specific view(s) from a multiview (stereo) nuke scene to deadline. The modification include the nuke submitter dialog, where user can check which views to render, and the nuke plugin file. Hope it helps someone. By the way it is for deadline 5.0, the exact solution for other versions may be different.


Submission/SubmitNukeToDeadline.py, gui declaration in __init__ somewhere append this:

1:   self.viewToRenderLabel = nuke.Text_Knob( "separator31", "Views to render:" )   
2:   self.addKnob( self.viewToRenderLabel)   
3:   self.views = nuke.views()   
4:   self.viewToRenderKnobs = []   
5:   for x, v in enumerate(self.views):   
6:    bknob = nuke.Boolean_Knob(('viewToRender_%d' % x), v)   
7:    bknob.setFlag(0x1000)   
8:    self.viewToRenderKnobs.append((bknob, v))   
9:    self.addKnob(bknob)   
10:   bknob.setValue(True)   

Still SubmitNukeToDeadline.py, in SubmitJob function, where writing into plugin info file, for example after: "fileHandle.write( "NukeX=%s\n" % dialog.useNukeX.value() )"

1:  viewsToRender = getSelectedViews()  
2:  viewsToRender_str = ','.join(viewsToRender)  
3:  print 'Views to render in plugin info file: %s' % viewsToRender_str  
4:  fileHandle.write( "viewsToRender=%s\n" % viewsToRender_str )  

Still SubmitNukeToDeadline.py, at the end, a new function to get list of views from submitter dialog (that the user selected) write this:

1:  def getSelectedViews():  
2:   global dialog  
3:   x = 0  
4:   viewsToRender = []  
5:   for vk in dialog.viewToRenderKnobs:  
6:    if vk[0].value():  
7:     viewsToRender.append(vk[1])     
8:   x+=1  
9:   print '\nViews to render: %s\n\n\n ' % viewsToRender  
10:  return viewsToRender  

-------
In plugins/ nuke.py file in RenderArgument function, just before return append this:

1:  viewsToRender = GetPluginInfoEntryWithDefault( "viewsToRender", "" )  
2:  if viewsToRender != '':  
3:   LogInfo( "==VIEWS==\nUsing " + viewsToRender + " view(s) for rendering\n" )  
4:   renderarguments += " -view \"" + viewsToRender + "\""   

And that's it. It's even logging the views to be rendered.
Cheers,
Gabor

Licensing

Hi,
I've been a big fan of the Foundry nuke user mailing list for years now. I strongly suggest reading that for everyone using nuke, there are interesting topics every day, the best resource to find solution to a problem.
But this is not an advertising here. A few weeks ago I read a topic in this list, where a guy, posted a pythonscript as a solution for something. This script was written by me before, even my commented lines were there. Every character is the same with a script that I posted here before. And in that mail at the mailing list there wasn't any indication that it was not written by him, but someone else. True he didn't say he wrote it, either.
I don't expect much first because these that I share here are not the best top-notch scripts/gizmos man has ever created, but I try to do my best. And I didn't put any legal notice into my scripts, until this point. But even with these things, I expected a little mentioning if someone is using my creations to help others, even if these are tiny scripts. Something like, "okay, this is from a blog" Not even have to point to this blog, but something...
Ok, no more crying :)
So from now on, I put a copyright text on the blog, at links menu. Of course nothing else will change, I will post my tools as I can.
Hope this post doesn't bothers you, I just had to do.
Cheers,
Gabor

Copyright

Copyright for all the scripts, source codes, and other kind of software extensions in this blog are under New BSD license, unless otherwise noted:


Copyright (c) 2010 till present, Gabor L. Toth (thoughtvfx.blogspot.com)
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the thoughtvfx nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL COPYRIGHT HOLDER BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

10k

Okay, so we reached 10000 pageviews! (Of course not in a month or week, but all-time ) I know it's not a big thing, but for me it is. Thanks for everybody, I hope this blog could have been (and will be) useful for you! Come back more often, as I try to post even more often and on even more interesting topics. And if you find useful stuff here, and you can refer to this blog (on your own blog, anywhere), please do!

Thanks,
Gabor

Nuke multiple views in read nodes

Hi,

I had a little problem not long ago, with setting stereo sequences in readnodes. No problem when the filepaths of views differ only in the view names, like BH_010_left.%04d.dpx and BH_010_right.%04d.dpx. Then you can use "%V" as wildcard for view name. But unfortunately our 3d guys was giving me renders where the 2 view are different in version number, like BH_010_v005_layer1.beauty.%04d.exr and BH_010_v006_layer1.beauty.%04d.exr.
(We have redesigned our cg output system to handle this since then, but I share this experience anyway ) The problem is that the file knob in the readnode is capable of splitting for views (split a knob = make different values for different views in the same knob), but the automatic path manipulator tools, like version up-down script, search and replace, that are needed to change so many passes in readnodes at once, are not working with splitted filenames, only working on the view that is not splitted off. For example if you split off left, these will work only on right view.
So the workflow to handle readnodes's paths with splitted views: choose 1 view that will be split off, so you won't be able to manipulate (only one by one). Assume this is the "right" view. Put all the readnodes down, set them to desired version for "right" view. Check that you are on the "right" view (in the viewer top line). Then (while all read selected) run this script:

sn=nuke.selectedNodes('Read')
for n in sn:
n['file'].splitView()


This will split off right view in all readnodes. Now change to left view in the viewer, and then change the version (alt+shift up/down), or do search and replace, those will be effecting the left view only (the "unsplitted" view).
If you have to change both view again, (for example new versions rendered for both view) then unsplit the previously splitted view ("right" in this example), with standing on "right" view, and running this little script:

sn=nuke.selectedNodes('Read')
for n in sn:
n['file'].unsplitView()


It will make readnodes normal again, and you can start the process over again :)
Sounds complicated? It's not, just tedious. Of course I could have used separate readnodes for each view (for each pass), but hey, that would be so simple right? (And too many readnodes)

Deadline - nuke post job script Update

Hi,
recently I had to improve our postjobscript system: I did some code rewrite, now much more elegant. Here I post an example script, that converts the current job's output to half sized exr, and a mov.
These are the changes since the old script that is referred in my old post:
- No more batch file! Running nuke directly.
- Automatically finding the installed nuke from deadline list
- Handling multiple views (currently left-right as viewnames are hardcoded, I need to change that)
- Handling multiple job output sequences

But as usual there can be bugs, so if you find one, please report.
The process to use:
- Put the 2 scripts in a folder somewhere in the deadline repository (for example I use this: DeadlineRepository\scripts\PrePostTaskJobScripts\JobNukeConvert\)
- Edit the JobNukeConvert.py: change the path in line (65) that starts with:
arg= (" -x -F " + framesList + ... to point to the current location of the other python script
- Set the JobNukeConvert.py as a postjobscript from deadline monitor (job properties)
- That's it. It should spit out a half-res. converted exr sequence, and a mov for each job output sequence (will put beside the rendered sequence)
- Of course you need to modify the glt_deadlinepostjobscript_convert.py according to your needs (what kind of formats to convert to etc.), but if you have some knowledge of nuke-python, that can't be that hard. Or maybe I can help...

Let me know if doesn't work for some reason. Or if it does work :) You can donwnload it from here.
I hope someone finds it useful,

Gabor