This is a free, crowd-funded point & click adventure with a spooky theme and a reduced visual style. The first three chapters are free, but to continue beyond you need to be a supporter. 5 parts have been programmed so far.
I’ve finished the first 2 chapters and I guess I’ll donate because “The Last Door” has a gripping story. It relies heavily on the eerie atmosphere created by its sound track and the makers of this game suggest headphones and a dark environment.
Give it a try! (free account necessary)
But don’t watch the trailer on their website. It contains spoilers.
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)