I’ve written a number of scripts and macros for Fusion, but I’ve never dealt with its theme/skin engine. Since Fusion 7 is about to be released and totally looks like Fusion 6 I’ve drawn a custom skin (or theme) to freshen up the GUI a bit.
Fusion’s skin engine is quite flexible but not everything can be fully themed and customized. I’ve documented the skin file format while building my skin in case other people are interested in delving into this.
So, without further ado, here’s the skin:
Download Fresh14.fuskin and place it into your Fusion\Skins directory. Then go to Preferences → Global → Appearance and move “Fresh14″ from the left list to the right one (below the Fusion 6.1 entry that is already there).
Credits for the icons: http://www.icons8.com
The skin contains:
- new tool controls that change the glossy look with one that is consistent and much flatter but still uses bevels and highlights to indicate widgets that you can push or drag.
- a color scheme that is as desaturated as possible to not be distracting but doesn’t look dull or monochrome.
- consistent icon style, including new ones for the tracker, the file dialog and the main tool bar. Moreover, many icons in Fusion’s default skin had the wrong size and were being scaled down to fit onto buttons. Not anymore.
- wider input fields so decimals don’t get cut off all the time.
- wider margins between certain controls to make the GUI look less cramped.
Scott Squires has a good article about how the VFX business model is getting distorted by film subsidies.
Companies and workers will continue to be forced to move to the place on earth that offers the largest (tax-payer funded) film subsidies.
As far as I know, here in Germany, the Stuttgart area (or the state it’s the capital of) has recently increased subsidies. Companies like Pixomondo or Mackevision (think “Game of Thrones”) surely benefit in the sense that they can get some shots from overseas shows.
Oh look! LookFX, which had opened an office in Stuttgart, maybe unrelated to said subsidies but maybe just because of them (I have no idea) has gone tits up.
In Munich I’ve immediately heard people ask for further tax breaks for post-production work. But would that really benefit local vendors or just big film studios? And wouldn’t it be a bubble that’s gonna burst when another state takes the lead in a “race towards the bottom”?
You could certainly design subsidies that can’t simply be exploited by overseas studios as a way to reduce their costs while not actually increasing profits of local vendors. Attach limits or thresholds, coupled to the amount of money that’s spent on local actors or other crafts. Whatever. But will those subsidies be effective in attracting shows when the producers of said shows wouldn’t profit as much as from Vancover’s or New York’s taxpayers?
Another blog that’s constantly covering the issue of film subsidies is VFX Soldier.
Nuke has some powerful ways to define how nodes are labeled in the DAG. And they make for some fun ways to augment your gizmos. By default, Nuke ships with a script called autolabel.py which takes care of labeling all the nodes in various ways:
- the node’s name (obviously)
- a channel combo like “green blue” in case the node doesn’t simply process RGBA.
- the value of a node’s “output” knob, if such a knob exists (try adding one as a user knob to see this magic label)
- the current file name of a read node
- the merge mode of a merge node (sic!)
- the text of a node’s label knob
- and probably much more…
You can, however, write your own autolabel function for either a specific node or a whole class of nodes. The downside is that you lose all of the default autolabels if you don’t reimplement them yourself.
Every tool has a hidden knob called autolabel that can hold a Python expression. Its return value is used to label the node. So let’s see how this works. Create a node (mine’s called “Blur3″ from now on) and open the scripting console panel. Type:
autoLabel = "abc" nuke.toNode("Blur3")['autolabel'].setValue(autoLabel)
Of course this fails. But you see clearly that Nuke tries to execute your autolabel string as a Python expression. So let’s start with a basic example:
autoLabel = "nuke.thisNode().name()" nuke.toNode("Blur3")['autolabel'].setValue(autoLabel)
This works. Note how the command nuke.thisNode() is used to refer to the node whose label is currently being processed. Just using the node’s name as a label is the most basic thing to do. As the presence of an autolabel string will override Nuke’s default behavior, you won’t get anything else that a blur node might usually have (channel info and custom label value). Also note how this label is only applied to “Blur3″. Any other blur nodes will continue to use Nuke’s default autolabel.py behavior. But these autolabel expressions can get more useful, complex and powerful:
Here I’m changing the label based on the value of another knob. Python doesn’t have the C-like syntax “expression ? yes : no” which would be really handy in this case. But it has something similar which I wasn’t aware of before a fellow TD showed this to me:
("some string" if expression else "another string")
This will help us build even more powerful autolabel expressions. Note how all of this is still one single string so I’m using single quotes inside it and I need to escape all newline characters as \\n. A single backslash would cause a line break in the code itself instead of the string. What’s still missing is the label knob which Nuke adds to all nodes by default. We need to implement this ourselves and it’s a bit tricky because you need to add a line break for this only if there actually is a label.
autoLabel = "nuke.thisNode().name() + (' big!' if nuke.thisNode()['size'].value()>100 else ' small') + ('\\n'+nuke.thisNode()\['label'].value() if nuke.thisNode()['label'].value() else '')" nuke.toNode("Blur3")['autolabel'].setValue(autoLabel)
The further you go the more complex all of this gets. So why would you use the autolabel knob when Nuke has autolabel event handlers as well?
- the knob affects a single tool, not a whole class of nodes
- that string will get copy&pasted around with the node, autolabel event handlers remain separate from your nuke scripts (the latter has its advantages of course when it comes to maintainability and preventing your pipeline’s code from leaving your company)
- the knob can be used with groups and node presets. All groups share the same class so it’s not possible to single one of them out.
autolabel event handlers:
To finish this tutorial, here’s the autolabel event handler that corresponds to the knob monstrosity above. It needs to be placed into your menu.py (or any python modules that are imported). You can have multiple autolabel handlers so you don’t need to cover all node classes in one function. Nuke calls all of them in a row and uses the first one that doesn’t return None.
def BlurLabel(): n = nuke.thisNode() if n.Class() == "Blur": autoLabel = n.name() + (' big!' if n['size'].value()>100 else ' small') if n['label'].value(): autoLabel = autoLabel + '\n' + n['label'].value() return autoLabel nuke.addAutolabel(BlurLabel)
Fusion 7 is close to a release. It will go beyond Nuke in some aspects (great stereo tools bundled for free and an impressive-looking scripting console/debugger), finally catch up in other parts (a modular GUI and UV unwrapping in 3D space) and contain lots of fixes and overdue improvements.
Fusion? You know, the compositing software next to Nuke?
Fusion has always beaten Nuke in terms of speed and versatility in a broadcast / commercials area. But eyeon software‘s weird and cryptic marketing, dated website, their unwillingness to communicate a roadmap combined with the fact that Fusion hasn’t been updated for close to two years has pissed off their user base and made most of the industry switch to the software that initially only high end VFX shops were using. There they can profit from a large freelancer base, lots of talented R&D people, 3rd party training and a company that is upfront about future developments and schedules.
And if you’re doing high end VFX you’re just served well with Nuke, no matter how much faster Fusion would be. The motion graphics crowd on the other hand is still served well by AfterEffects. By now, Fusion’s at the bottom of a downward spiral of “less users – less interest of 3rd parties – less tutorials and plugins – less users” that I think is hard to recover from. Eyeon’s latest efforts to tap into the Avid community seem to bear fruits though but the GUI and feature needs of those folks clearly clash with regular compositing artists.
But here’s eyeon software, back from the dead so to speak, with at least a changelog and some videos about what we can expect in Fusion 7. I’ll talk more about the release once I’ve put it to the test myself.
For now, the “What’s new” PDF instills the feeling that eyeon’s marketing is still bonkers. They start up with the tiniest change. The cool stuff is at the end of the PDF. And it actually touts the standard multi-document (MDI) style of Windows applications as a new feature. Seriously folks, Fusion has had that interface for years and nobody loves it because a crash on one comp pulls down the whole application and nobody has the screen space to lay out two comps side-by-side anyways. This reeks of “grasping at straws” to inflate the feature list which wouldn’t be necessary at all. Fusion 7 promises new 3D tools, UV unwrapping, (screen space) Ambient Occlusion and many GUI improvements and it will include Dimension by default – eyeon’s stereoscopic and optical flow toolset that gives Occula a run for its money. It also seems as if I can update some of my Fuses and macros with new API features.
Stay tuned for a thorough review of different aspects of the Fusion update.