The Tool and the Toy

When I first started in this vfx/CG industry over a decade ago, the progress of software innovations were not as numerous as today. But in relative terms, the innovation has continued, and in my opinion, is not necessarily superior; it has accomplished its goals at a certain level sophistication that is just expected given the fact that we develop on top of another’s innovation. We couldn’t get where we were unless we do all that research and development from scratch. The software back then were fewer, but those that existed were used in production, and they gave rise to production techniques around which today’s new software base their design.

But the main difference between yesterday and today is the relative power of a software to do its job versus creative expectations. I’ll use renderers as  my example. Not only was yesterday’s creative expectations lower, that a renderer capable of generating shiny raytraced reflections, coloured shadows, and post-effect lens flares amazed audiences, it was also more difficult to achieve with clunky interfaces and technical limitations. Today’s landscape is different: renderers are not only fast, but they provide photorealistic results — the predominant requirement — for anyone smart enough install the software and have a sketchy understanding of xyz.

I exaggerate. Still, it is not hard to argue how easy you can achieve good-looking renders with a few clicks. For me, it started when global illumination — physically-based rendering — was introduced, and from then unbiased rendering for the masses. It continued to real-time (GPU-accelerated) rendering, which is continuing to develop and make a mark — its overall contribution still unknown, yet very promising.

But this isn’t a history lesson as much as it is an observation of the present. In the same the idea of blogs gave rise to the idea that written vomit is publishable, the development of better and better photorealistic renderers is giving some people the notion that it should be immediately plugged in for production.

If this suggestion was given with professional caveats, or qualified proposals, I would be very eager to listen in. But in my world, the opposite often happens: software is being pushed in the pipe without regard of how it is to be implemented as a tool. This software is great — it’s a cool new toy. But it would be a great proposition if the software was used in seclusion. It would be bettered if the proposition was partnered with a real plan of implementation, but I would be satisfied with a sober feedback of how the tool performed in a small project. Implementing it into a pipeline requires more consideration than “hey, this is cool!” It’s nice to have new toys, but not all new toys are tools. They have the potential to be tools, but they continue to be toys until you clearly understand their limitation, until you see in what way they contribute to the workflow, until they are technically implemented in the pipe in consideration with the creative workflow.

I sometimes wonder why these things never occur to people who keep banging their head on the wall? Maybe they’re not banging their head: maybe it’s someone else’s head their banging and they don’t get hurt: poor decisions are of no consequence because it’s the lower rung that bears it; so I suppose it doesn’t matter to them. But it matters to me: because it’s the lack of thinking things thoroughly, the lack of planning, the lack of learning from past mistakes that frustrates; it takes me nowhere: I end up where I started from.

I’ve worked enough the industry to know what production means. It isn’t just a word thrown about, as some would like to do, to make it appear you have worked on a paying job and thus granted production experience. A dumb-ass could work in a production, but he’s still a dumb-ass with production experience. The problem I encounter is that for some people, professionalism in production is just for show — for the benefit of the boss who doesn’t know better,  for the benefit of a client who doesn’t understand. Look under the hood and you see a teetering structure of unintelligible hacks; you see cowboys shooting from the hip, wormtongues conjuring up smoke-and-mirrors consisting of embarrassingly inappropriate jargon. Professionalism in production is not about just about producing something professional-looking, it’s about being professional with how you do production: it’s acknowledging and learning from mistakes, it’s learning how to use your brain before you move your first vertex.

And that’s the difference between a professional working with tools, and a child playing with toys.

 

Disable “Taskbar Always On Top” in Windows 7

Just thought of sharing the worldwide protest of Windows 7’s stupid and intended omission of allowing other windows to go over the taskbar.

There have been numerous efforts to do this, but few of them I particular liked. So I decided to script my own AHK, and this method, so far, mimics Windows XP the closest.


~LButton::
WinGetActiveTitle, curWindow
WinSet, AlwaysOnTop, on ,%curWindow%
WinSet, bottom, , ahk_class Shell_TrayWnd
WinSet, AlwaysOnTop, off ,%curWindow%
return

 

EDIT: after working with it a bit more, I found that the script stole the focus from some menu items, causing the inability to select a menu item unless the mouse button was held down whilst choosing, and then releasing it to choose the entry. I modified the script — and glad it worked — so that instead of using the AlwaysOnTop parameter, Top replaces it, making the script less attention-getting.

 

~LButton::
WinGetActiveTitle, curWindow
WinSet, Top, ,%curWindow%
WinSet, bottom, , ahk_class Shell_TrayWnd
WinSet, Top, ,%curWindow%
return