Ideas for pipeline checklist

[GeneralLethal]

So our relatively small VFX company is asking each department to come up with a checklist guide to standardize the transfer of material between departments and minimize technical problems. As the newly appointed lead of the small FX team, I do have several ideas about what I expect when I get material from other departments (mainly layout and modelling) and how to make it as easy as possible down the line (lighting and comp) with the material we produce (simulated meshes, VDB'S, ASS's and renders). The respective leads of these departments also gave me their input about their expectations. Even then, I'm sure there are a lot of ideas I haven't thought of, and I would love to have your input.

Edited February 17, 2017 by GeneralLethal

[michael]

scale!!

of cameras and assets...really important to set some standards and enforce them.

[GeneralLethal]

Thanks Michael, indeed this is crucial, especially when the work involves several different software.

We do a good job up to now of keeping a standard scale except for very specific shots, but it's a very good point to add so that potential new employees know where to stand.

[LaidlawFX]

As far as materials, I would recommend Substance Designer. It is a third party program so you need to shell additional money, but with great integration into Houdini. Then all your teams can use the same shading program in all your packages. Otherwise you'll have to recompile, and build custom shaders in each program that shade them same way. Unless you are only using one render engine, like mantra. The key part is to manage a transferable list of textures, and settings like diffuse contribution. If it is a fairly simple two program switch, a python binding to read from an .xml isn't too bad to create. 

The one thing especially if you are using mantra as your default engine. I would develop a single uber shader for every type of hard surface asset, and a common one for volumes and hair, too. A shader with at least three layers. This will only be more complex in the upfront development but at run time it will render just as fast your simplest shader, since, mantra does not compile anything in a shut off if block. This will minimize the the amount of shaders you have to manage, and the different lighting models and variations that can happen from different look development setups.

After you have a series of developed looks, in one shader, it's extremely easy to build up a library of very common materials, like car paint. There are a hundred of ways to do car paint that look correct in different lighting environment, but as a studio and especially for your lighters, and whom ever has to maintain these shaders, you only want one. 

Good luck with your team!

[Matt_K]

Colour pipeline!

Having the correct colour space (luts etc) for plates, texture maps & viewers is a crucial aspect to any pipeline as it can be confusing trying to integrate different sources (Red, Alexa etc) with Cg elements and comp-library elements and keep the colour consistant.

A good linear workflow can save a lot of headaches down the line, and allow the lighters & comp dept to work confidently.

Good luck!
Matt,

 

[Skybar]

Could be good to decide what to do with bind/rest poses for characters if you are doing hair/fur in Houdini. 

[fuat]

besides the ones already mentioned, for me the most important is:
- meaningful folder structure
- naming conventions
- and the most important: backtracing files/caches.
theres no worse thing than having to change/rebuild something and not knowing from which file it was generated. or searching though tons of folders trying to find the right asset or cache or scenefiles. 

[GeneralLethal]

Thanks a lot everyone, lots of useful ideas!

@LaidlawFX: I'll sometimes use Mantra for FX only shots, but our studio is mostly Maya so most rendering ends up being Arnold. Your idea of a single shader still applies though, and it would probably make it much easier for the development team to make a tool for the lighters that would allow them to override the material's parameters in Maya if needed. Good to know Mantra doesn't compile unused parts of the materials, I wonder if Arnold does the same when creating .ass files? Lots to think about, thanks!

@Matt_K: Thanks, indeed a linear workflow is essential. Luckily, Houdini makes it very easy to implement, and my company made sure that very plate is interpreted correctly when it is imported in Houdini. Just have to make sure it's the same with artist created or downloaded images.

@Skybar: You're right. Haven't had much character work up to now, but it wouldn't hurt to have a basic workflow ready.

@fuat: Absolutely! Luckily, my company pretty much has this down already for scenes, published assets and renders, but cache folders still tend to be a bit messy and some guidelines would make them much easier to navigate.

What about importing and re-exporting Alembic files, anybody has a fail-safe way of ensuring object structure and hierarchy is always preserved through their Houdini trip? Tends to be case-by-case with me but I'd love to hear of a more standardized way that would work through merges, packing, unpacking and whatnot, if such a thing exists.

Any other ideas are much appreciated!

[LaidlawFX]

As far as Alembic if you are working with a later version of Houdini 15.5 and Maya 2016/2017, we were able to completely round trip from within Houdini as is back to Maya this past summer with a fairly complex pipeline. The authoring from Maya aside, as I did not write that part.

Depending on how you choose to structure your data as you send it to the alembic file. You may need to use a few python scripts in a python sop, to pull extra data that is not available in the alembic sop, or alembic import interface. The alembic import at the object level has all it's python code available so you can easily override the alembic sop it places down, with your own .hda wrapper of that node if you need to do something custom. But you should only need to do this if you purposely are storing the data into different places.

$HFS\bin\AbcEcho.exe will be your friend in debugging how the data appears in each alembic file.

As far as standardizing, I made my alembic import node at the sop level. That way it was easy to reference in different workflows, as opposed to always at the object level. You can handle .fbx the same way too if you have character rigs. If you are doing character rigs off the shelf i would stick with .fbx as they handle fk/ik out of the box, where as alembic you currently need to re-interpret that data.

[kiryha]

I make first steps in integration Houdini with my existing pipeline for Maya so there is not too much particular information for Houdini users, but there a lot of ideas and tools for Maya, which could be used with Houdini as well.  
I would mention:
- Unified folder structure for all project materials (2D, 3D, editing, grading, pre-production, managing etc) including scenes, caches and renders
- Naming, versioning; assets and shots structuring rules
- Tracking versions and data (assets, renders, caches etc) with Ftrack

I plan to develop same as for Maya tools, which will allow automatically creating and naming Houdini scenes, exporting and importing data etc.
Hope you can find something useful in pipeline wiki.

 

UPD. Here is my Houdini pipeline  version

Edited February 6, 2019 by kiryha