... of our current job production. It's quite a big one, (in size, and prestige) and of course I can't tell anything in detail until it comes out. What I can tell is that it will be one of the hardest deadline, and definitely the best quality in 3d we ever did. I wish I could show some pictures... but I can't :(
What's good news, I think I can share 2 new tools I developed during this production. Come back in 2 weeks!
Apr 22, 2011
Apr 1, 2011
Quick tip - Nuke metadata (e.g.: jpeg exif ) in label
I had an experiment that involved taking a lot of photos with different aperture, focal etc. settings. I got tired of looking up camera settings in xnview, so I did a little trick. Jpeg exif information exists in nuke as metadata, and quite easy to get that. I just created a noop node, and pasted a little tcl/python expression in it's label, or directly in the read node's label.
For example to get the focal length:
Focal: [lindex [split [python {nuke.thisNode().metadata()['input/focal_length']}] / ] 0]
A little explanation:
[python {nuke.thisNode().metadata()['input/focal_length']}] - this gets the actual value for the input/focal length key. Metadata stored as key-value pairs, you want to pass the key ('input/focal_length'), and get the value (70/1, for example). The outer part of the expression, (split and lindex) just separates the 70/1 by splitting with "/" and taking the first part only, that is the needed value 70. I don't really know what is "/1", but it's not needed. If you want other parameters, best to view exact key string of the needed metadata with a "viewmetadata" node, and putting that into the expression on the noop/read or other node, and modify if needed. For example if you want to shutter speed value, no reason to cut the second part after "/", beacause it's stored like 1/50.
One last hint: if you have a noop with expression like this, and connect to other read node, it doesn't updates automatically! On other nodes I used to just press disable/enable, and label get's updated, but noops don't have disable. It's easier to put the whole thing directly to read node's label.
For example to get the focal length:
Focal: [lindex [split [python {nuke.thisNode().metadata()['input/focal_length']}] / ] 0]
A little explanation:
[python {nuke.thisNode().metadata()['input/focal_length']}] - this gets the actual value for the input/focal length key. Metadata stored as key-value pairs, you want to pass the key ('input/focal_length'), and get the value (70/1, for example). The outer part of the expression, (split and lindex) just separates the 70/1 by splitting with "/" and taking the first part only, that is the needed value 70. I don't really know what is "/1", but it's not needed. If you want other parameters, best to view exact key string of the needed metadata with a "viewmetadata" node, and putting that into the expression on the noop/read or other node, and modify if needed. For example if you want to shutter speed value, no reason to cut the second part after "/", beacause it's stored like 1/50.
One last hint: if you have a noop with expression like this, and connect to other read node, it doesn't updates automatically! On other nodes I used to just press disable/enable, and label get's updated, but noops don't have disable. It's easier to put the whole thing directly to read node's label.
Mar 16, 2011
Quick tip - Nuke gizmo input connection name
When creating a gizmo with multiple input connections, it's useful give names to the connections, so the artist will know what to connect. Here's a screenshot of a gizmo I'm creating:
Here I have two connections named "seq" and "cam". This can be achieved by renaming the input nodes in the gizmo/group from "Input1", "Input2" etc. to "Inputseq", "Inputcam". The string after the word "Input", in the node name, will be the name of the connection.
Here I have two connections named "seq" and "cam". This can be achieved by renaming the input nodes in the gizmo/group from "Input1", "Input2" etc. to "Inputseq", "Inputcam". The string after the word "Input", in the node name, will be the name of the connection.
Mar 9, 2011
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.
Mar 4, 2011
New nuke gizmo - rotator
Do you need to rotate a wheel in nuke? Do you have the translation for it but it needs to rotate accordingly? Here's the solution: rotator gizmo! Premiere here, now. Put the gizmo in your menu.py. Assume you have a wheel plate in the starting position, matted with alpha. Put down the gizmo from menu, connect after the wheel. Holding down ctrl, move the center sign to the center of the wheel (the translate knob should remain 0). Then drag the dot named "outside" to anywhere on the wheel circumference. You can test the rotation now by dragging the center sign without pressing control (changing the translate knob). Currently it does proper rotation only from this starting point, but in any direction. Then put the translation animation in the translate knob and you are done. Turn on motionblur if you need.
Comments, feedbacks are welcome!
I will put this on nukepedia/creativecrash, as the others, but after a little while. So if you want to get the new gizmos/scripts I make as soon as possible, come back, here you can find them!
Comments, feedbacks are welcome!
I will put this on nukepedia/creativecrash, as the others, but after a little while. So if you want to get the new gizmos/scripts I make as soon as possible, come back, here you can find them!
Feb 5, 2011
Nuke 6.2, maya, scenemanagers
So now after finshing a project, using Nuke 6.1 for a long time (months), now we can try 6.2 version of nuke. It has really exciting new features, finally they built python 2.6! (You can think that okay that's not the feature I'd mentioned in the first place! :) It's good, because python 2.6 has official win64 build, and maya2011 is also using 2.6, so the so called scenemanager gui I'm started to develop for nuke, with alteration of course, but without conceptual changes, can be used later on for maya (or houdini). Actually I already coded a scenemanager for maya, but it was scripted in mel. We are using it for opening, saving, referencing scenes, assets, according to our inhouse name convention. Now I'm developing a similar gui for nuke, but this time with pyqt, now python 2.6, and it will be fetching all data from our project database. This will be later adapted for maya (if we had time).
If there's interest, maybe I can share screenshots, concepts, or code snippets/tips as I'm going with the development of the nuke scenemanager. Please comment if you would be interested in that! Thanks,
Gabor
If there's interest, maybe I can share screenshots, concepts, or code snippets/tips as I'm going with the development of the nuke scenemanager. Please comment if you would be interested in that! Thanks,
Gabor
Jan 30, 2011
Nuke commandline render and python
Happy new year nukers, and non-nukers! First post this year, hopefully many more will follow it.
For the beginning, a little about commandline rendering with nuke, using pythonscript (got the idea from a mailing list post of mine). I mean with nuke you can't only execute a nuke file, but a pythonscript too. Like this:
nuke6.1.exe -x -F 1-30 myscript.py
One can think, that this is useful for creating nodes on the fly, like a read node, a write node, and execute that for converting sequences to another format. That is an option, but you also can open existing scripts and modify them. For this you can use the scriptOpen command. For example, if you have a nuke script called test_v001,nk, make a file called test.py, and write in it:
nuke.scriptOpen("e:\\Projects\\test_v001.nk")
(Replace the path with the path to your nuke file) After this in the .py file you can do modifications on your nukefile. Knob changes etc. And that's it. You can execute with the above mentioned cmdline command:
nuke6.1.exe -x -F 1-30 test.py
There is another option to do that. Slight change, but important, and you can do much more with it than rendering. You can not only execute, but literally open nuke files in command line (terminal) mode, hold it in memory, do changes (blindly) to that. For example I use that for my archiving script, open many nukefiles one by one, collect the used readnodes, and put those in a list etc. So I'm not executing the nukefile, just open it. But if I want I can render it too. I put a line more in the previous test.py file, so it will look like this:
nuke.scriptOpen("e:\\Projects\\test_v001.nk")
#do some modification on knobs if you need
nuke.execute('Write1', 1, 30, 1)
Here I called an execute command at the end of my pythonscript (I must know the name of my writenode)
I will use this script in my commandline command, that is almost the same as before:
nuke6.1.exe -t -F 1-30 test.py
But notice the -t flag! That means the test.py is not executed as a render, but treated as normal a pythonscript, just like if I put that in script editor in nuke. It will render the nukefile anyway, because the execute command in the test.py But as I said the great thing is to have an option to execute python scripts in terminal mode with the nuke interpreter.
For the beginning, a little about commandline rendering with nuke, using pythonscript (got the idea from a mailing list post of mine). I mean with nuke you can't only execute a nuke file, but a pythonscript too. Like this:
nuke6.1.exe -x -F 1-30 myscript.py
One can think, that this is useful for creating nodes on the fly, like a read node, a write node, and execute that for converting sequences to another format. That is an option, but you also can open existing scripts and modify them. For this you can use the scriptOpen command. For example, if you have a nuke script called test_v001,nk, make a file called test.py, and write in it:
nuke.scriptOpen("e:\\Projects\\test_v001.nk")
(Replace the path with the path to your nuke file) After this in the .py file you can do modifications on your nukefile. Knob changes etc. And that's it. You can execute with the above mentioned cmdline command:
nuke6.1.exe -x -F 1-30 test.py
There is another option to do that. Slight change, but important, and you can do much more with it than rendering. You can not only execute, but literally open nuke files in command line (terminal) mode, hold it in memory, do changes (blindly) to that. For example I use that for my archiving script, open many nukefiles one by one, collect the used readnodes, and put those in a list etc. So I'm not executing the nukefile, just open it. But if I want I can render it too. I put a line more in the previous test.py file, so it will look like this:
nuke.scriptOpen("e:\\Projects\\test_v001.nk")
#do some modification on knobs if you need
nuke.execute('Write1', 1, 30, 1)
Here I called an execute command at the end of my pythonscript (I must know the name of my writenode)
I will use this script in my commandline command, that is almost the same as before:
nuke6.1.exe -t -F 1-30 test.py
But notice the -t flag! That means the test.py is not executed as a render, but treated as normal a pythonscript, just like if I put that in script editor in nuke. It will render the nukefile anyway, because the execute command in the test.py But as I said the great thing is to have an option to execute python scripts in terminal mode with the nuke interpreter.
Subscribe to:
Posts (Atom)