Tokyo Ghoul – 5 Years After

I had started out as a freelance in my previous company, and then a year later, I became a permanent staff as a CG supervisor. A CG supervisor’s responsibilities may encompass many things. Or, inversely, may encompass only a narrow field. This depends on the company’s expectations from the role and the person. As such, some write certain things on paper, but are not carried out in reality, and vice-versa.

As a technical person in a supervisory role, I naturally supervised everything I had competent skills in. This meant everything in CG post-production, whether it would be as high-level as a pipeline development, or low-level as switching out a heat sinks from defective computers. This is just my nature. I like fixing, and designing things as well. There were some things that I initially didn’t always look forward to, like production shoots, but it was my job. And in the end, I learned to like it as much as a computer geek possibly can.

Through the intervening 5 years, the role remained as broad as I was. There was no need to do less work. In Sporty Drive, I had taken more responsibilities than before, but no more than a CG supervisor of my expectations would have. This would be the only project in 5 years that I can confidently assert that gave me a sufficient level of satisfaction after its completion. But from then on, as if on the downward phase of a sine wave, it became a challenge of enduring the tedium of the advertising world.

Tokyo Ghoul was the last major project I worked on in that studio. And I mention this because it serves as an end reference point for my role as CG supervisor just before I left. We hired a new great TD, originally from Weta, and both worked — in tandem with the main studio in Japan — on some shots for Ghoul. Our major task was rigging, though we also did some animation, too. Although I had been usually the one to work on rigging in the past, the studio execs and producer wanted to leverage our new TD’s expertise and occupational history to impress our Japanese counterparts, so all of the rigging work was assigned to him.

I was left to become a visual effects producer of sorts. I helped write the final visual effects breakdown; since our work was technical in nature, I wrote documentation and emails explaining the technical concepts to a non-technical Japanese translator: what problems we were having, the details of what we need, what the rigs are meant to do, etc. I created video tutorials for workflow suggestions (that sometimes had nothing to do with rigging, but simply a knowledge exchange between CG artists), and for explaining the rigs we were delivering. It echoed my Lifeway CG teaching days.

(I also did some animation: when we couldn’t afford to get animators in, I took over and animated a few shots in the end.)

You can say that my role was largely educational and social. It was challenging and it was important as well. I’m aware of that, and I’m fine with it. But this isn’t the sort of thing that I’d been wishing for. In fact, this was certainly a step in the wrong way, and a step that I had been forced to make gradually over the years.

The execs do not have any sense (tactically or strategically) for technicalities of CG production, so they habitually nod their heads in feigned consonance whenever I relate anything related to technology or software. Thus it becomes a difficult proposition to build anything of substance in an environment where pipeline is only just a word bandied about creative directors who want to sound cool among production people. It’s not real enough for execs; it’s not as real as clients’ whims, it’s not as real as the debates of the philosophy of creativity that I used to hear in our open-space office, it’s not even as real as promised money.

I am not exaggerating when I say that though I had been coding the studio’s pipeline for 5 years, the execs have assumed that I don’t actually code, and perhaps they think I just download plugins and scripts. Anyone who truly knows my development work will probably laugh at that bit of irony. And I’m laughing a bit, too. (Of course, never mind the 10 odd years prior of doing code; to some that’s ancient history.)

Perhaps they lacked confidence in my professional pedigree, or they didn’t know enough to understand any other aspiration apart from theirs. Perhaps, perhaps. Either way, I saw the trajectory of where I’d end up, and if I wouldn’t be out of a job due to redundancy, I would have been out of my mind in boredom.

So, in the end, when an opportunity presented itself to do a bit of original coding related to Iray, Janus, and LightWave, I took on a contract, despite its short term.

I think there’s a point when many factors for quitting converge. But some seem so charged with emphatic resonance that you’d think that was the primary reason for changing your job (or your life). People might say they hated working with so-and-so, or got paid peanuts, or felt no respect from others, or the workplace was stressful. But all of them helped to make it worse, until at one point, not any one of those factors is going to be enough to make it better. When the bad stuff accumulates, it hardens after a time. Then, even if they worked on getting new tables, lamps, decors, heaters, hardware, software, or whatever to make it seem that they’re addressing issues, everything wrong has accumulated to the point none of it matters. Because none of them, by themselves, matter anyway. As one the execs — an example of irony if I ever saw one — used to pontificate: the whole is greater than the sum of its parts. And so truly, it is: when the parts are faulty, the whole is more faulty than the parts.

Never forget.

 

Commercial: Jalna

jalna_thumb_1
(Click to watch video)

The cg aspect to this — falling blueberries on yoghurt in a pot — was another solo job for me. The final comp was a Flame job, though I always try to get 3d renders as close to the actual colours as possible.

There was no pre-production for me as this was just given to me all of a sudden; I would have liked to have gotten lighting information in the set and reference plates. Basically, what we had — not a whole lot — was all that I could work on. Thankfully, there was a close-up shot of the pot as part of the edit, which I used as projected texture back to my cg pot model. This allowed me to get graded colours directly onto the 3d render.

The viscous yoghurt fluid sim was done in Realflow, and rendered in V-Ray because the sub-surface shading there was very easy to get. But the rest of the elements were rendered in LightWave where I could get the most control over how colours were being rendered. This was important because I had also taken a piece of reference footage which showed how the pot looked like under a lighting condition similar to that of the cut. LightWave’s nodal shading system made it easier for me to control the shading of local areas.

 

Commercial: Mother Earth “Snacks”

I rarely get solo projects, and when I do, it’s often some retail job that either involve the simplest form of motion graphics that a 10-year old could do, or some CG-ish product shot that covers the same old ground that I’ve been treading on for 13 years now.

Well, although, this ad is of the second form (CG-ish product), the fact that it is a solo project is something that always fills me with delight, as I feel freest when I work alone as I move into the pace that suits me best.

For a product ad, for what it is, I think the ad is visually ok. Obviously, it breaks no barriers, but I had fun doing it. I learned a bit more about LightWave’s instancing, added some features and fixed bugs in Janus; it was relaxing to do something on my own, based on my own tastes.

Commercial: Vector Solar Green House

Remember that this work thread is about the fact that cg projects are rarely straightforward; one artist might look he’s not doing anything, when, in fact, he’s doing everything, and vice-versa.

My contribution to this commercial is intermingled with the fact that it had been animated, and its look set up by someone else to be rendered in Octane, a GPU-based, unbiased renderer, presumably to make rendering faster and more beautiful. However, it wasn’t faster, and it wasn’t that much more beautiful, as the look was mainly AO-like. Time was running out. We have a renderfarm that can render mental ray, V-Ray, LightWave, and After Effects; but not Octane. So, it was passed on to me so I can render and comp it in time. Not surprisingly, it wasn’t just about hitting the render button in LightWave.

I took the original assets, replaced everything with LightWave shaders, tweaked the shadows and diffuse shading so that they matched, as close as possible, to the original test Octane renders, and had to fix many of the errors present in the scene, as well a number of broken models. I strategised on how much needs rendering based on the animatics; I used Janus, the ultimate LW ass-saver, to breakout lots of the necessary animated elements and mattes, and rendered them; Richard and I did the motion graphics, and I comped everything for the final product in After Effects.

This hot-potato workflow, in which a project is tossed completely to another person to be rescued, is out of my control; I simply have to do it. The main problem I have with it is that few recognises it as that: a pawning-off of accountability and yet accepting the full credit for it (as such, I’m not credited). And, again, this is why this work thread is being written: a project like this would not have seen the light of day if someone hadn’t objectively dealt with the details that were required to actually finish the job to the client’s standards. What you see isn’t what went on.

There are hard facts in professional workflows, which some are in denial of. Workflows that fly against simple reason will not get them where they want, no matter how much they cuss or growl at the monitor. There is a lesson to be learnt here, but are those who need to learn it actually get it?

Commercial: 5 Seeds

This was another sub-contract from Australian vfx vendor. My contribution here was the extension of the trees at the beginning of the ad, which featured apples (real apples either weren’t on season at the time, or that they were apple trees to begin with). We bought some stock trees, I populated them with apples, shaded, lit, rendered in LightWave, and integrated them into the foreground and background areas of the matchmoved footage.

The trickiest bit, actually, was the Australian vfx company. They operated in Nuke, and required lensing data to be piped back to our renders. But while they knew their own process — which involved UV remapping, I hadn’t done it to other vendor’s specs before during post-production, but it turned out all right in the end, as it usually does.

Commercial: Hyundai ix35

This was a sub-contract from an Australian vfx vendor. Terry, with an assistant intern (which was more trouble than help), built rickety structures on the bridge and gave it an gloomy look. My main contribution to this was the front-on car shot on the bridge; I tracked the shot in PFTrack, though it couldn’t completely solve it; I had to hand-track to start of the shot. I modelled and shaded broken old wood that the car was driving on, lit and rendered layers in LightWave using Janus, and test-comped it before sending it to OZ.

I admit that it’s nice to have been involved with an ad that simply looks nice, even though I had absolutely no control or even input on how the other scenes — and the ad as a whole — was going to look like. Implicitly taking credit for being associated with the ad’s look is as easy as simply letting others naturally assume it. Let that not be the case here.

Janus Macros – Problem of Permutations

Long live Janus. ;-)

 

I’ve been doing some custom development for an architectural visualisation company in Australia called 3DVIZ recently. During Janus’s commercial phase,  3DVIZ bought a licence. It is usually the case that I don’t know what Janus user actually do with Janus technically-speaking. Few users ask for feature requests, and even fewer ones explain their workflow and how to better improve it through Janus. That’s mainly why Janus developed the way it was: my own personal production needs, and my curiosity in proceduralism.

It is the proceduralism that seemed to draw 3DVIZ into Janus. When I wrote the FOR loop constructs in Janus, it was mostly out of admiration of Houdini and the curiosity of what proceduralism could look like in Janus. No had asked for it, I only had an inkling that I may, just possibly, need it if ever the chance I get into a large-scale project in LightWave. But, if I’m honest, I’ve never actually used FOR loops for any of my commercial projects; none of them were ever big enough to warrant to advantages of using the feature.

When 3DVIZ contacted me for support, I realised that they were using it in a far more advanced way than I personally used it as a TD in commercial work. It was gratifying to see that someone actually had some need to proceduralise their scene management and rendering to that level, and that Janus’s FOR loops actually made all the difference.

3DVIZ approached me again with a permutation problem. From the little I know about it so far, their asset hierarchy is well-organised (ie rigid). And this is the case because they need to be able to render more variants upon variants; from a house, they render parts of the house in varying configurations, each with their own types of materials, and so on so forth.

Part of 3DVIZ’s own request, since they know their problem more than I do, is to enable them to automate scene loading and Janus operations from a more ‘global’ script; as FOR loops handle the breakouts for any given scene, now they want to expand that capability across scenes. The concept is similar to LightWave’s own Render-Q script, where a script resides ‘persistently’ and orders LightWave to do tasks.

The most obvious idea to automate Janus is to allow it to accept macro commands. A ‘controller’ script handles the scene loading, then writes a macro to a file, which contains commands to breakout so-and-so render pass; then signals Janus to receive the macro; when Janus completes the macro, the ‘controller’ loads up another scene in its queue, then writes another macro, and repeats the procedure.

Thanks to the years put into Janus, the implementation of macros was clean, and with some limited testing, the concept works as well as imagined.

However, my main obstacle would be their expansive asset hierarchy. The real challenge is to make sense of it in my head, and design a ‘controller’ script that creates sensible macros that solve 3DVIZ’s particular problem of permutations.

 

Retirement and Retrospect: Janus EOL

After some thought last year, weighing in what I want to do for the future, I  decided that I should ‘clean my closet’ first. And one of the things that stood out in that closet was Janus development. There have been no new sales for Janus for quite a long time now, unsurprisingly, because I never really made any respectable effort in its marketing. Besides a few clients, its userbase has equally been quiet. And so I’ve decided to retire Janus from commercial development, and the main reason is that I can’t see myself guaranteeing the same kind of support that Janus users have enjoyed through the years for free.

It feels like a nominal thing to say that Janus is no longer being developed because Janus dev hasn’t been as active, and I’m pretty sure only a very few are concerned with its development anyway. If anything, announcing the fact will simply get me off that spectral hook of ‘developer obligation’ for EOL products. At least that’s what I hope.

I’ve always said in the past that Janus was never meant to be a mainstream tool. But over the course of the years, I learned one major reason why: many LWers didn’t try it. Part of me comprehends the rationale that the Janus video tutorials described a workflow that they didn’t like, or was confusing. But this is what I couldn’t understand: despite the complaints of the lack of a render layer system in LW, why people wouldn’t even attempt a free try in the hopes that they make something out of it.

Then there was the price point of 200 bucks (later 100 bucks) which might have made it totally incompatible with their idea of a layering system, no matter how well (or badly) designed. I kept hearing their demands to NT to put a layering system in there as part of their LW upgrade path, avoiding the need to invest in a 100-200 dollar plugin. Apparently, they’ve been waiting for a long time: at least 7 years.

What strikes me ironically, in retrospect, is that if they had invested in Janus from the beginning, it would have been a free Janus upgrade path from then on. Of course, I can’t say that I would have guaranteed it, though it seems likely since it was the case despite the minimal community support behind it. It would have been a very small price to pay to have such a tool that early on in LW9.5 — LW 2015 still does not have a functional equivalent of Janus or a render layer system. I say that in retrospect; a few Janus users have been saying it for years.

Most LWers have lived without a proper layering system, because the need is not truly pressing for most of them; I think despite their complaints, they can wait 7 more years if they have to.

Whether or not I would have stopped development regardless of its popularity is something I will never know myself. To me, Janus, as a commercial product, has run its course. I think it does a lot more than what was advertised, which is a good thing for me as a developer; I’m proud of what I’ve accomplished, but more grateful for the things I’ve learned developing this tool. Janus is still available to be bought, but no support will be given (unless I can actually afford to), and I will try my darnedest to ignore bug fix requests: it’s easy to get obsessed with them, and they eat up lots of my time.

This is not to say that I’m through with Janus: I use it daily, and I will continue to code it to solve problems that I encounter myself. I may yet support Janus in the context of a company as a technical consultant, which is a better use of my time, and I can be actually recompensed for my work. I may fork it, or create a derivative for other progs like Maya — who knows, really? The future unknown, and I’d rather not try to plan or predict. I’ve focused on tools for the most part of my vfx career, and left creative pursuits largely untravelled. And that’s where I’m headed next.

User functions FTW

Here I am, few days later talking about user functions in Janus again. Why not? It’s been giving me results and it’s fun to play with — as a TD, I mean.

Back at work I wanted to output an RGB matte for multiple instanced object. LW doesn’t have a way to do a scene-based surface override on an object (perhaps shaderMeister?– though I don’t know if it the Spot Instance node will work with it). Basically, I wanted an easy way of assigning RGB colours to items in a particular group.

Before, Janus’s item processing was strictly group-oriented, where group settings were simply propagated to the items. There was no way to individually and programmatically affect certain items within the group. So in the latest rev, I changed that. But the important bit was that I tied it (again) to user functions, and I embedded a new context — the group item context — through populating two constant variables relating to the group item’s index and name. In this way, the user function can be created that references the group item’s index, and based on that value, the command parameters can be changed on that particular item as it is being processed. It’s basically a ‘last minute’ change in the render pass settings just before the group item is applied its parent group settings.

Since user functions are basically string replacements from within the cmd line, there’s a lot of flexibility (but can also end up a heaping mess if the Janus user doesn’t watch it), so that I can dynamically various bits of settings; I’m not limited to adding one parameter, for example, because I can just concatenate the new subcommands in the return string; so as along as the final resulting cmd line is syntactically valid, Janus will grok it.

Janus for Mac

It’s a bit too early to shout out, so I’m whispering here in my little blog about Janus for Mac. I’ve restarted development for the Mac. It basically just took a weekend to hunker down and sort what was going with it.

The biggest issue that I came up with was the use of LScript’s store() and recall() functions, where in Windows it uses the registry to store the information. In the Mac, I’m not sure where it ends up, but apparently, calling it those functions multiple times seemed to put LW in a state where it could no longer stream more files into memory. It was as if the i/o was full.

I avoided this by redirecting the functions; this was already facilitated by the fact that they were already housed in custom functions, and all I had to do was make it everything cohesive. I also cleaned up the code so that the array that Janus uses to store settings were more consistent, and that the PC version should remain unaffected by the change.

At this point the Mac seems to be very workable, and I’m probably going to do a few iterations of tests in the coming weeks. And who knows? — it may come out officially soon after that.