Workflow

Some minor notes on Workflow with colorbleed-config. Will move to extended documentation at some point.

Modeling

At Colorbleed we mostly model in Maya and for generating a model publish we have a relatively strict colorbleed.model family that performs a lot of checks on your geometry, e.g. UVs, naming conventions, freeze transforms, invalid polygons, etc. This is to ensure output models have a consistency of being relatively clean and you can have thorough expectations of the output.

Note: For output content that is less strict and/or animated you can use the colorbleed.pointcache family that is less strict and outputs only an Alembic .abc pointcache. However, we do recommend the workflow with models as it ensures clean propagation of input models for rigging and other stages of production.

Rigging

The colorbleed.rig family generates a mayaAscii file that contains a rig with controls. Upon loading a rig it will automatically create a publish instance for that character, so that when the animator is done you can directly consistently publish the output.

The requirements for publishing a rig is that the publish instance's out_SET and controls_SET must at least be populated with some content.

• controls_SET: This should house the control transforms (not parent groups) and will be validated on having no keys on unlocked keyable attributes, have default values for all transform controls (zero translate, zero rotate, one scale) and ensure the Visibility attribute is locked (so one doesn't accidentally key it)
• out_SET: This is the out publishable content that the rig will output after animation. Usually this is the parent group that contains all output geometry in the rig. This will end up generating an Alembic pointcache from the animation scene.

Lookdev

The Look Development is the process of generating textures and shaders to apply to a model. Our look development process is built-around Maya and is published as the colorbleed.look family.

The look development process is renderer-agnostic and should support basically all render engines that apply shaders as shadingEngines to the geometry. This is how Maya by default assigns shaders internally.

The colorbleed.look family output results in:

• A mayaAscii (.ma) file that contains the Maya shaders.
• A JSON shader relationhips (.json) file that holds which shader should be applied to which mesh by .cbId.
• A resources/ folder that contains any textures (incl. sequences or UDIM) used by the shaders (from Maya file nodes)

Look variations (subsets) per Renderlayer

It is possible to publish different look subsets from a single file, e.g. a blue and a red variation for the same asset. To support this the creation of the look through Avalon > Create.. > Look imprints the currently active renderlayer into the instance. This is visible in the Attribute Editor for the instance* as the renderLayer attribute.

For example one can use the masterLayer for the blue subset and a separate redLayer renderlayer for the red subset. To do this:

1. Go to masterLayer.
2. Create look lookBlue.
3. Go to redLayer.
4. Create look lookRed.

When publishing now the active shaders will be collected and published from their respective renderlayers, as can be seen in the instance's attribute editor.

*Note: due to a bug in Maya 2018/2019 custom attributes on objectSets are visible under the "Arnold Attributes" tab whenever Arnold is loaded.

Lighting (rendering)

The Colorbleed-config supports rendering in Maya and is relatively renderer-agnostic so should work with most renderers. It has been tested and used with V-Ray (vrayformaya), Redshift and Arnold (mtoa). We usually refer to this task as lighting.

Submitting renders to Deadline

To submit your renders the first thing you'll need to do is create a "renderglobalsDefault" instance. This is what the pipeline uses to recognize it needs to process the renderlayers for submission at publish time.

You can create it through:

• Colorbleed > Rendering > DL Submission Settings UI (recommended, as this allows to customize how your scene gets submitted)
• OR Avalon > Create.. > Render Globals

With the render globals created you can do Avalon > Publish.. to start submitting your scene.

Rendering multiple cameras per layer

With the support for multiple cameras per renderlayer it is now possible to submit a single layer with multiple cameras. To do this:

1. Ensure multiple cameras are set as renderable in the layer.
2. Update the "filename" prefix to support multiple cameras. The easiest trick is to run "Publish" and validate, likely it will fail on "Filename Prefix", right click it and press repair.
3. Submit your render.

It's important to understand that the resulting published subset will be prefixed with the camera name. As such, it's good to ensure your camera name/hierarchy is as you expect them on the first submission and keep them the same over time.