Tag: pipeline

Tokyo Ghoul – 5 Years After

faulknermanoLeave a comment

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.

 

Iteration

faulknermanoLeave a comment

Iteration is the creative process of improving the work in incremental steps. I don’t know if it’s truly a buzzword, but from where I’m standing, it’s always buzzing around. But I think that iteration means something different depending on where you’re standing.

In an advertising agency, for example, the creative team goes through their own rounds of iteration, brainstorming ideas, solidifying them visually through thumbs for internal meetings, then a concept board (if it’s a TVC) to be cleared with client, then upon feedback, work the process up to a storyboard. The creative process is completely internal in that they have full control over their workflow with the client giving feedback. Ask the creative director what iteration means for her workflow, and she’ll tell you “it’s working up the Idea in small steps, making sure, all the while, the client is kept in the loop and making appropriate feedback, which we then apply, and advance the Idea into a final storyboard to be produced.” So far, so good.

In the post-production shop, the process is pretty much the same, only a bit more complex, naturally; we deal with lots of technical elements. So while an agency might have a single pipeline we have at last four going almost concurrently, and those pipelines intermingle with each other. We have models to be made, rigging to be applied to models, animation to be applied to the rig, models to be shaded, shaded models to be lit, whole scenes to render, renders to be comped, effects to be designed and comped, etc. And that’s a standard bread-and-butter job. Let’s not get into things like simulations, matchmoving, rotoscoping, and the like.

Now imagine the same creative director is working with a post-production shop to produce the TVC. Ask the same question, “What is iteration?” She’ll answer, non-verbatim, with this expectation: “I want to see the final product very soon, and iterate that until it becomes better.”

Because the post-production process is unknown to her, she doesn’t realise that we have many final ‘products’ to iterate over: models have their own iteration-cycle, distinct from the animation iteration-cycle; so is look development, so is effects development; and these come together as a ‘master’ development pipeline with a separate iteration-cycle as well. She doesn’t automatically think to apply her own iterative workflow principle to the post-production side because they are uninformed. But because they prefer not to know, they remain at arm’s length from the post-production group, as distanced as they themselves, as creative teams, are to their clients, who are equally indifferent of their process. The indifference is passed down from client to agency, from agency to post-production, generally speaking.

Now, all this time, I’ve been using the agency’s creative director as my example. This is not a fair emphasis, by the way, though it surely makes the point clear, and many agencies relate this way to post-production houses. But you will also find directors, be it art directors, TVC directors, or anyone calling the ‘creative shots’ are just as guilty of this indifference. But the worse of all, it should be noted, is that the indifference occurs within a post-production group, as some of the upper crust only pay lip-service to the very technical nature of their own operation. Though I began with the ignorance of an agency creative director, she is the least guilty of them all.

The post-production upper crust might have done well to learn the internal creative process of the agency. But I think they condescended to think they could be anything but the client, and thus distancing themselves from their own post-production group. Perhaps by assuming the superior client role, they thought can eke something creative out of the ‘headphone-hooded geeks’.

The agency enjoys a creative process that they themselves have built and enforce in order to serve their own purposes because doing so will yield a better product for the client and for themselves. Yet, the post-production group gets served up onto a plate of uninformed demands by uninformed folks, left undefended by the upper crust who are just as uninformed; and it would have yielded poor results if not for talent and lots unnecessary personal sacrifices. But even sacrifices have their limits.

Anyone who demands, “I want you to go hard out so you can get me the final product tomorrow, so I can iterate/nitpick/pixel-fuck that until it becomes better” does not know what iteration means and lacks the discipline of imagination necessary to mix the creative aesthetic with the highly technical processes, which is what this industry is about.

 

Sandline

faulknermanoLeave a comment

As a CG supervisor in a small CG group, I find it part of my job to think of new ways to improve the workflow beyond the scope of the job. Yes, I technically supervise a job, but who technically supervises the group? Indeed, to introduce small improvements after every job is one of the main ideas of what it means to be supervising.

This requires some chin-rubbing. The company I work for retains only a very small core group — less than the fingers of your either hand — so it has been used to hiring freelances for any conceivable job. Part of the problem of freelances is that when the job is finished, you don’t keep the experience they’ve gained from working on the project. Another problem is that no one can guarantee that any freelance will be hired for the next job. These make it difficult to implement an efficient pipeline when, most of the time, most of the crew needs to be indoctrinated to it at the start of the project.

Freelance artists have various ways of working, and they can be required to adhere to certain procedures, but depending on whether or not you’ve worked with an artist before, this is a time-consuming task, characterised with many user errors and frustration that persist throughout the entire project, culminating in freelances finally concluding their contracts — and leaving — just when they have finally gotten to grips with the method. And when a new job begins, you may have to do it all over again.

It is easy enough to suggest scripting tools to user-proof known issues. But to cover a multitude of different possible variances coming from unknown future artists is hard to improve upon when the next job comes along: the same ‘mistake’ is not always done the same way. Fighting fires is part of the work of a TD, but when looking for a workable pipeline, you don’t want to depend on it.

Simplicity was my goal: the more generic the structure, the easier it is to understand. Perhaps the structure, methods, and protocols mimick already-established conventions. Perhaps it becomes incorporated into the host app GUI so it feels more natural to get into.

The shot workflow we now use was first developed through a collaboration between me and Louis Desrochers, who was, appropriately enough, a freelance who had at the time been working with us on a commercial. Later, my colleague Terry Nghe and I would extend this workflow.

I called this workflow and the tools that support it Sandline.

 

SHOT

There are several facets, but one of them is the simple concept of the shot:

  • A shot is represented by a folder, and contains all things unique to that shot; the folder’s name is the shot name
  • A shot contains ‘scene’ folders such as ‘anim’, ‘layout’, ‘render’, and others — it is open-ended
  • A shot contains a special cache folder to store vertex-cache data, point clouds, meshes, etc.
  • A shot contains a special image plane folder
  • A shot can be considered a ‘sub-shot’ if the shot folder is nested in the directory structure
  • A shot has a definition file which define its frame range, renderer, resolution, render client min/max frame setting, and a description of the scene
  • A shot’s definition sits on top of a global project definition

One of the reasons the shot folder came into being is due to our experience in cloud-rendering. We had used the default Maya workspace behaviour in which cache files were written to the project root’s cache data directory. When it was time to upload the data to the cloud service, we would sometimes forget to upload some of the cache files or the scene files because they were being dragged from their two different and respective places.

So why not move all cache files into the same folder since they are only relevant for that shot?

While that solution was an answer a very specific workflow problem — we no longer use FTP-based cloud services when we can help it — the logic behind it was sound: we would have convenient access to all data related to a specific shots.

 

CACHING

The original Sandline development centered around automating vertex-caching. It does it this way:

  • Meshes to be cached are tagged by grouping them in a specially-named node, or by applying custom attributes to nodes
  • Namespaces in meshes are treated like directory structures
  • Vertex caches are versioned according to the animation scene’s own version
  • Any version of the vertex cache be be applied to a scene sans cache nodes, and does this based on name-matching and tagging — the same way it saved the cache

 

MODELS

An adjunct to caching is models which refer to a scene file that is contains plain geometry and its shading. The idea behind models is to have a geometry with the same point-order as the rig. When the cache is saved off the rig, it is applied to the shaded models version. In this way, it is possible to totally separate the pipeline between animators, riggers, modellers, and shaders.

The models folder is a global folder, which means it can be used by any shot. It also has a ‘versions’ folder where working versioned scenes are worked on. When the models are published, they are promoted to the models directory — and appropriately renamed and stripped off their version number — to be used directly by any scene.

 

RIGS

Rigs are very much attached to the same idea as models in that that resulting geometry that is used can come from either one, but they must contain the same geometry if the project involves vertex caching (not all projects do). If a rig has been built around a production mesh, and the mesh was modified, the model must be imported back in. Likewise, if, by technical requirements of the rig, the model needed to be modified, those changes must be exported out to a models file to be sorted out by the modeller and shader to conform with the rig file.

Like models, rigs are publish-able: they have a separate ‘versions’ folder where version of rigs are stored. When published, the version number is stripped and promoted to the rigs folder.

 

MAYA INTEGRATION

I took some pains to integrate, as much as I can, the functions directly into the interface of Maya.

2015-05-16 21_26_19-Autodesk Maya 2013 x64_ untitled_The ANIM, LAYOUT, RENDER menus are references to the subfolder of each shot. But instead of listing each shot on the menu, they appear underneath  scene folders:

2015-05-16 21_29_21-Autodesk Maya 2013 x64_ untitled_

ROLE-CENTRIC

This might appear odd to most people because you’d normally expect to traverse to your desired scene in the same way you traverse a directory structure. But what’s happening here is that I tried to arrange it from the point of view of what is interesting for the artist in a specific capacity. Indeed, the roles of the freelance is general, but it is always specific for particular time. If you were an animator, you would typically be only concerned with the ANIM folder. If you were responsible for scene assembly or layout, you will cast your attention on the LAYOUT menu. If you were setting the scene up for render, the RENDER menu (and some others). In other words, the menus are arranged according to use, according to role.

And the most important thing about Sandline is that the project leads makes up the roles on a per-project basis: sometimes the LAYOUT role is not relevant, or the LAYOUT role is used as an FX scene. The name of the folder is only a general term, and it is by no means restricted to those roles that has been named as default.

 

FLEXIBILITY

I work in commercials, which means that almost every project is going to be different from the last one. This means that our workflow — and not least of all our mindset — must be pliable enough to adapt to practical requirements.

For instance, when is it a good time to use the cache system? When there is major mesh deformation happening on high poly counts, or if the scene’s combined complexity — say, multiple characters — complicates render scenes, then a cache system will surely be considered. But when a shot only involves transformations, or if visibility settings are animating (eg attributes that do not propagate in cache data), how much practical benefits would you really get using caches? Or perhaps we’re animating high poly count meshes using transforms (eg mechanical objects); caching those verts to represent transformations instead of using the transformations themselves is a waste of storage and a waste of time.

Also, not all freelances are going to adhere to procedure. More often than not, regardless of how skilled a freelance is, they will do things their way before they do anything else. And there comes a point when they have progressed too far ahead in the scene to repair a dubious workflow, such as forgetting or refusing to reference scenes in certain situations. It has happened too many times. What happens here?

Well, the answer is not in the tool, per se. Of course, I can tell you now that I can come up with several ideas for tools that fixes certain issues, and if time allowed, I would have written those tools. Sure: but the main point of Sandline is the ability to accept those inconsistencies and ignore them; or rather, focus on the basic workflow, to encourage its use. So when a freelance forgets/refuses to reference, the tools don’t hinge on their improper use.

I’ve seen other systems which are rigid, and it was properly rigid due to the straightforwardness of their actual project: there is a strict flow of data, and protocols of usage. In a commercials environment, this doesn’t work, and no one will get away playing that sort of tyranny with freelances; you won’t get the project moving, unless it’s a 4-month long post-production schedule, which doesn’t happen any more.

 

So, this has been just an introduction to the idea behind Sandline, which is named after Sandline International, a now-defunct private military company. The play is on the idea of ‘freelance’, and this tool was created with that in mind.

That said, freelances who have had the opportunity to use the system, while saying it was ‘cool’, still fell back to their own workflow. Again, this is natural, and almost expected, and is not really that bad. However, in time, I hope to improve Sandline to the point where using it is more seamless, and the measure of its success is how quickly freelances are able to take it in and see immediately its workflow benefits even if they haven’t used the system before.