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!

Nuke-RV integration!

Whoaa, the sneak peek video was out yesterday, and the tools are now downloadable (for free of course)! The developers of RV are really great guys, thank you!
Now you can preview readnodes directly in rv, render to rv, set up checkpoints of your work, create multiple version quickly to review with the sup etc. Check the video here.
Now I really need a second monitor for work :)

New commercial!

Our latest finished work at Digitalapes, the Vilmos commercial is on air now, so you can check it out here.
There is a makingof video too. Hope you like it.

Extending camera projected image in nuke - quick tip

Imagine this situation: you have a tracked scene, got the camera, using it (on 1 frame) for projecting a mattepaint to a proxy geometry. Then you go on compositing, huge node-tree builds on this  projection. And then suddenly you notice (or worse, the sup notices) that on a few frames the matte not covering enough area, needs to be extended. Everything else should remain as is, but you have to paint a good 50pixels more, outside the current mattepaint's format. The problem is: if you scale/translate the matte and paint the needed area, the current projection will crawl away. If you paint using the current format, but outside the image, making the bounding box larger, that will be cropped off by projection, as it is ignoring the bounding box.
The solution is simple: use a reformat before projection, using scale parameter, and link that value to the focal length of the projector camera, using the expression (assuming the original focal length of projection camera was say 25mm):
1/Reformat1.scale*25
Reformat1 is the name of the reformat node before the projection. So when changing the scale value of that node, the proj. camera will change it's fov accordingly. Scale to 1.2, and everything will stay as it was, but extended part will appear, or at least will be in the bounding box. Important: the reformat's resize type knob should be none!
This way the new painted area can be revealed easily. If the camera still cropping the image, try to adjust the overscan parameter in the scanline renderer, as this can crop the image too.
I'm going to make a few images later to illustrate this process.

First timelapse

My first timelapse video, I'm really into this kind of photography, so be prepared, more to come...

Cloudy timelapse from Gabor Toth on Vimeo.

Xmarks to shutdown...

Oh, no! Xmarks (best bookmark, tab sync extension for firefox, chrome) announced to shutdown in a few weeks, unless enough people willing to pay a small amount (10$, annually) for this great app.

The whole story is here.

You can make pledge to offer money here.

And here are the alternatives to xmarks (not as good as far as I know).

I think I'm gonne pay for this great service, that served millions of people for 4 years, without charging them. I need this.

Preseter for nuke 1.0beta1

Hi,

here is s quick solution for having a few different variations of node setups in nuke, without saving different versions. So on a review session with the director sup etc., you don't need to always open/save scripts for considering different versions of color grading etc. You select the nodes need to change, press getNodes button. Then you can store all the knob values for these nodes, maximum in 4 different versions, when pressing set1-4, and these can be restored - what a surprise - with the restore1-4 buttons. Note that this version currently stores these in memory, so these aren't saved with the script. Next version will do that :) And because of this you may not want to have more than 1 preseter node in the script, they can be confused... :)
You can donwload it here

As usual, comments, feedback are welcome!
Gabor

Deadline - nuke post job script

We wanted to have an automatic process with deadline, to convert all the 3d renders to exrs with proper compression and autocrop (datawindow) option enabled. Currently I implemented this on linux, and I had to make a little hack to run nuke from shell. I think it's much easier on windows (no permission problems etc.) Usage:
So the main file is a pythonfile, a deadline post job script, the path of this has to be placed in deadline monitor, in the job properties panel. The machine that rendered the last task will "render" this extra task. The file gets data from deadline, like output path, frame range etc. Then it's executing a nuke render, from command line, but the renderable file is not a nuke script, but another python file. It could be a nuke scene, with a read and write node, but I think it's nicer to generate the nodes on the fly, and this way no problem with script paths etc.
So we have 2 python files at this point: a "JobNuke2exr.py" which should be placed in deadline, and "glt_deadlinepostjob.py" which should be reachable by nuke and deadline (that's why I inserted a line with sys.path.append in the first python file, it should be edited). To make it more complex, I had to make an .sh file, (like a .bat on windows) that launches nuke from terminal, with arguments, because the specific deadline command (SpawnProcess) couldn't make this. Of course this .sh file needs also be edited, because it contains the path to nuke executable.
So the first .py calls this .sh, that fires nuke, that renders the other .py! Easy, no? :)
A little thing with the process that has to be solved: currently nuke rendering checkerboards, and not skipping missing frames.
Here you can download the files
I'm sure this whole postprocess can be achieved much easier, but at this point this is working here. Comments, tips are welcome.
Gabor

Multiple autosave in nuke

So we had a little dataloss yesterday, some of our nuke files went 0B in size. Checked the autosaves... none existing! What happened (other than file system corrruption or what)? We are working on linux, and the NUKE_TEMP_DIR environment variable was properly set in init.py. But, nuke was started as a simple user, and that dir can be written only by root. At least this is my idea. That's about it, but I started to think where and how to place autosaves properly. We now having them in /home/user/Nuke/autosaves folder. Another question is how to preserve the autosave files? Because nuke deletes them as soon as the scene is saved, but we need them to stay, for these occasional dataloss events.
I found a tip in the mailing list, to include the current date, time in the autosaved filename:

/autosaves/[date %y]-[date %m]-[date %d]_[date %H]-[date %M]_[file tail [value root.name]]
But this is too long, and can get infinite number of autosaves.

So another tip: include only the current minute, so it starts again in the next hour, maximum of 60 file (for 1 scenefile, if you save a new version there can be another 60!)
[file rootname [value root.name]]-[date %M].nk.autosave
it gives path like (when for example the current time in minute is 15):
w:/Projects/Test/AutosaveTest/AutosaveTest_v001-15.nk
But that is still to much files.

How can it be reduced? I could include a modulo (%) operator to limit the number of minutes, like %6 gives only 0-5. It's great, but think. When minute is 01, it writes in the fileneme 01. When 02, 02 and so on, and when 06, it starts from the beginning. It would be better to have 1 autosave filename in the first 5 minutes (continuously overwritten), then another in the next 5 minutes, and so on. So in half an hour you still would have the first file, and that gives a good chance to go back if something went wrong. This can be achieved, by an expression like this:

[file rootname [value root.name]]-[expr int ([expr [date %M]%30]/5)].nk.autosave

Let's look at this from closer! The first part (before the "-") is simply gives back the file path, but without extension, so we can put anything after this. The second part can be understood from inside the date part: [date %M] is the minute of current time (That's going 0-59). Outside there is an expr(ession) command for the modulo (%30) operation, that gives the remaining of current minute and 30, with this we modified the range to 0-29. Then comes "/5", notice the brackets, so range is 0-5.8. Then the "expr int" takes only the integer of this. The final range is 0-5 integer only. This is pasted after the filename.
Now this expression makes a "filename-0" file when current minute is between 0-4, then "filename-1" when minutes 5-9... and at 30 it starts from the beginning, overwriting the "filename-0". There can be maximum of 6 files, for 1 version. But remember if you save the script (ctrl-s) the last autosave will be deleted!
I hope this will be useful for someone. Modify as you need.

Interesting page

Effectscorner

Heavy nuke scenes 2

In quite a complex scene, that I mentioned in previous post, where environment is fully built from mattepaints, in around 60-70 layer, and a number of these is 6000*8000 or higher in resolution, memory handling is quite crucial. And the more effect, correction, masking is made on these big mattepaints, the memory quickly can go up high. So what I did is after getting good feedback (from sup) on these big layers, I always saved them with all color corrections, and masking to a new exr file (with autocrop if which is a nice thing). But left the replaced branch of nodes in the script, if later have to change it. Of course you can't save animated nodes to a single exr, but that's life.

Heavy nuke scenes 1

Few words about heavy scene management.
Working on Going Postal I had the opportunity to work with very large scenes, especially the opening sequence.
The main experience: if possible, break up shots/scenes into smaller pieces! In this movie I wanted to see in some aspects the boundaries of 3d in nuke, so I decided to handle my quite complicated shot in one nuke scene. It involved a three matchmoved greenscreen shot, and a matte painted multiple projected full city establisher, connected with a quick moving cameras (and those motion's blended seamlessly) above a large scale terrain, with constantly changing lighting condition, from daylight to sunset, in a multiple piece 3d projected environment.
Ok, it sounds bad, and it was bad. The result... not so bad, but could have been better :) But it was a really great experience with nuke. Of course, it could have been done in 3d, but the 3d department was full of work, so I did it completely in nuke (not counting of course the mattepaints, and matchmoves)
I don't want to write a whole essay about it, so I just write my thought as quick tips, or guidelines.

Firefox crashes

Hi, just a quick note. I'm using firefox 3.5.9, on xp sp2, 32bit. I encountered occasional crashes, that was really annoying. So I tracked down which extension could do this. So first type of crashes was on google searches, this was caused by xmarks, especially the siteinfo feature. If this was turned off, it didn't crash. Second type of crash was with particular sites, like linkedin.com, this was caused by AVG safe search. I hope this helps for someone.

Loop with offset in nuke

Hi, I just needed to do a loop with offset, on an animation curve. That means that the cycle is continuously increasing or decreasing, depending the value of the first and last key of the loop. In maya, it is called cycle with offset. Unfortunately in nuke there is no option to do that from the menu. I solved this with a custom expression. For this I used 2 custom integer knobs on the node, called "LoopStart", "LoopEnd" (case sensitive!), marking the start and end key of the cycle. Later I will make an option built in the menu, but until that, here is the expression:

curve((((frame-LoopStart)%(LoopEnd-LoopStart))+LoopStart) ) + (floor(((frame-LoopStart)/(LoopEnd-LoopStart))) * (curve(LoopEnd)-(curve(LoopStart))))

How to apply that:
make animation you want to loop. With right click on the node/manage user knobs, make 2 integer knobs called LoopStart and LoopEnd. Set these to the frame of the first and last key of the loop. And then add this expression to the animated knob and that's it.
I made an additional option, because I needed to offset these animations in time many times, so making an extra knob called "TimeOffset", the expressions look like this:
curve((((frame-LoopStart- TimeOffset)%(LoopEnd-LoopStart))+LoopStart) ) + (floor(((frame-LoopStart-TimeOffset)/(LoopEnd-LoopStart))) * (curve(LoopEnd)-(curve(LoopStart))))

This is useful when the readnode is timeoffseted (with a separate node), so link the TimeOffset KNOB, to the timoffset NODE, so you have to adjust it only in 1 place.
With this, I did a lot of medusas floating upwards, each animating differently, but from only one readnode, many timeoffset nodes, and transformgeo nodes.
Hope this will be useful for somebody :)

reloadrange

Ok, long time no post, so here it is: I haven't posted this python script, that is already on creativecrash: glt_reloadrange. Basicly it checks the frame range of the selected readnode, and if it is different that was set in the node, updates it. It useful for example when you start using a 3d rendered sequence, before it is fully rendered. After the 3d render has finished, just select that readnode, and use this script.
Available here:

about me and nuke

In a nutshell a bit about me, and the tools I use. I work for Digitalapes, a vfx company in Hungary, as a 2d TD/compositor. As you may have guessed, we use Nuke for compositing. We were using Fusion back in 2005, and later Shake (in Cubeeffects Inc.) In my opinion, generally Nuke is far superior than these other two (but to be honest, each has its strength). After using Fusion, I found Shake very stable, and in the same time very basic. This is an advantage to learn and understand compositing, but i was also missing a lot of tools. Now Nuke has the speed, is multi-platformed, and well-designed from its basics, and has almost all the tools we need. Only thing that I miss, is Shake's previews and warps, and Fusion's particle system.

Lee Stranahan: Open Letter To James Cameron: Fairness For Visual Effects Artists

Lee Stranahan: Open Letter To James Cameron: Fairness For Visual Effects Artists

Heathaze gizmo

I always wanted to have a decent heathaze plugin for nuke. My problem with heathaze plugins in other composite softwares was they look so uniformly distort the image. For this reason I have put together one, that is not so uniform. So I'm releasing here my heathaze gizmo for nuke, you can download it from creativecrash.
Note that this gizmo is not a usual heathaze, as it doesn't distort the image, it just creates a red-green noisy image, that can be used with an idistort node as distortion channels. More explanation can be found in the tooltip of the node.

Welcome...

Hi All! So, I started this blog, because... I had a lot in my mind, that I would like to share - and I hope it's worth to share - with you. The posts will regard mainly my profession, that is vfx - mostly tips/tricks with softwares I use (Nuke, Maya etc.), scripts I've written. I hope it will be useful for some of you, and if it is, drop me an email or comment it.
One more thing: because I'm not a very advanced programmer, I take no responsibility if you use scripts/code/tips I've written, use on your own risk. But of course I'll upload such things only if I tested those through.
Best:
Gabor L. Toth

Blog created