ayon-core/website/docs/artist_publish.md
Petr Kalis a66edaf1d0
Maya: implement matchmove publishing (#5445)
* OP-6360 - allow export of multiple cameras as alembic

* OP-6360 - make validation of camera count optional

* OP-6360 - make ValidatorCameraContents optional

This validator checks number of cameras, without optionality publish wouldn't be possible.

* OP-6360 - allow extraction of multiple cameras to .ma

* OP-6360 - update defaults for Ayon

Changes to Ayon settings should also bump up version of addon.

* OP-6360 - new matchmove creator

This family should be for more complex sets (eg. multiple cameras, with geometry, planes etc.

* OP-6360 - updated camera extractors

Added matchmove family to extract multiple cameras.
Single camera is protected by required validator.

* OP-6360 - added matchmove to reference loader

* Revert "OP-6360 - make ValidatorCameraContents optional"

This reverts commit 4096e81f785b1299b54b1e485eb672403fb89a66.

* Revert "OP-6360 - update defaults for Ayon"

This reverts commit 4391b25cfc93fbb783146a726c6097477146c467.

* OP-6360 - performance update

Number of cameras might be quite large, set operations will be faster than loop.

* Revert "OP-6360 - make validation of camera count optional"

This reverts commit ee3d91a4cbec607b0f8cc9d47382684eba88d6d0.

* OP-6360 - explicitly cast to list for Maya functions

cmds.ls doesn't like sets in some older versions of Maya apparently. Sets are used here for performance reason, so explicitly cast them to list to make Maya happy.

* OP-6360 - added documentation about matchmove family

* OP-6360 - copy input planes

* OP-6360 - expose Settings to keep Image planes

Previous implementation didn't export Image planes in Maya file, to keep behavior backward compatible new Setting was added and set to False.

* OP-6360 - make both camera extractors optional

In Settings Alembic extractor was visible as optional even if code didn't follow that.

* OP-6360 - used long name

* OP-6360 - fix wrong variable

* Update openpype/hosts/maya/plugins/publish/extract_camera_mayaScene.py

Co-authored-by: Roy Nieterau <roy_nieterau@hotmail.com>

* OP-6360 - removed shortening of varible

* OP-6360 - Hound

* OP-6360 - fix wrong key

* Update openpype/hosts/maya/plugins/publish/extract_camera_mayaScene.py

Co-authored-by: Toke Jepsen <tokejepsen@gmail.com>

* Update openpype/hosts/maya/api/lib.py

Co-authored-by: Toke Jepsen <tokejepsen@gmail.com>

* Update openpype/hosts/maya/plugins/publish/extract_camera_alembic.py

Co-authored-by: Toke Jepsen <tokejepsen@gmail.com>

* OP-6360 - fix wrong variable

* OP-6360 - added reattaching method

Image planes were attached wrong, added method to reattach them properly.

* Revert "Update openpype/hosts/maya/api/lib.py"

This reverts commit 4f40ad613946903e8c51b2720ac52756e701f8b8.

* OP-6360 - exported baked camera should be deleted

Forgotten commenting just for development.

* OP-6360 - updated docstring

* OP-6360 - remove scale keys

Currently parentConstraint from old camera to new one doesn't work for keyed scale attributes. To key scale attributes doesn't make much sense so as a workaround, keys for scale attributes are checked AND if they are diferent from defaults (1.0) publish fails (as artist might want to actually key scale). If all scale keys are defaults, they are temporarily removed, cameras are parent constrained, exported and old camera returned to original state.

* OP-6360 - cleaned up resetting of scale keys

Batch calls used instead of one by one.
Cleaned up a return type as key value is no necessary as we are not setting it, just key.

* OP-6360 - removed unnecessary logging

* OP-6360 - reattach image plane to original camera

Image plane must be reattached before baked camera(s) are deleted.

* OP-6360 - added context manager to keep image planes attached to original camera

Without this image planes would disappear after removal of baked cameras.

* OP-6360 - refactored contextmanager

* OP-6360 - renamed flag

Input connections are not copied anymore as they might be dangerous. It is possible to epxlicitly attach only image planes instead.

* OP-6360 - removed copyInputConnections

Copying input connections might be dangerous (rig etc.), it is possible to explicitly attach only image planes.

* OP-6360 - updated plugin labels

* Update openpype/hosts/maya/plugins/create/create_matchmove.py

Co-authored-by: Roy Nieterau <roy_nieterau@hotmail.com>

* OP-6360 - fixed formatting

---------

Co-authored-by: Roy Nieterau <roy_nieterau@hotmail.com>
Co-authored-by: Toke Jepsen <tokejepsen@gmail.com>
2023-09-29 17:33:28 +02:00

11 KiB
Raw Blame History

id title sidebar_label
artist_publish Publishing Publishing

What is publishing?

A process of exporting particular data from your work scene to be shared with others.

Think of publishing as a checkpoint between two people, making sure that we catch mistakes as soon as possible and dont let them pass through pipeline step that would eventually need to be repeated if these mistakes are not caught.

Every time you want to share a piece of work with others (be it camera, model, textures, animation or whatever), you need to publish this data. The main reason is to save time down the line and make it very clear what can and cannot be used in production. This process should mostly be handled by publishing scripts but in certain cases might have to be done manually.

Published assets should comply to these rules:

  • Clearly named, based on internal naming conventions.
  • Versioned (with master version created for certain types of assets).
  • Immediately usable, without any dependencies to unpublished assets or work files.
  • Immutable

All of these go into the publish folder for the given entity (shot, asset, sequence)

:::note Keep in mind that while publishing the data might take you some extra time, it will save much more time in the long run when your colleagues dont need to dig through your work files trying to understand them and find that model you saved by hand. :::

Families:

The Instances are categorized into families based on what type of data they contain. Some instances might have multiple families if needed. A shot camera will for example have families 'camera' and 'review' to indicate that it's going to be used for review quicktime, but also exported into a file on disk.

Following family definitions and requirements are OpenPype defaults and what we consider good industry practice, but most of the requirements can be easily altered to suit the studio or project needs. Here's a list of supported families

Family Comment Example Subsets
Model Cleaned geo without materials main, proxy, broken
Look Package of shaders, assignments and textures main, wet, dirty
Rig Characters or props with animation controls main, deform, sim
Assembly A complex model made from multiple other models. main, deform, sim
Layout Simple representation of the environment main,
Setdress Environment containing only referenced assets main,
Camera May contain trackers or proxy geo, only single camera main, tracked, anim
expected.
Animation Animation exported from a rig. characterA, vehicleB
Cache Arbitrary animated geometry or fx cache rest, ROM , pose01
MayaAscii Maya publishes that don't fit other categories
Render Rendered frames from CG or Comp
RenderSetup Scene render settings, AOVs and layers
Plate Ingested, transcode, conformed footage raw, graded, imageplane
Write Nuke write nodes for rendering
Image Any non-plate image to be used by artists Reference, ConceptArt
LayeredImage Software agnostic layered image with metadata Reference, ConceptArt
Review Reviewable video or image.
Matchmove Matchmoved camera, potentially with geometry, allows main
multiple cameras even with planes.
Workfile Backup of the workfile with all its content uses the task name
Nukenodes Any collection of nuke nodes maskSetup, usefulBackdrop
Yeticache Cached out yeti fur setup
YetiRig Yeti groom ready to be applied to geometry cache main, destroyed
VrayProxy Vray proxy geometry for rendering
VrayScene Vray full scene export
ArnodldStandin All arnold .ass archives for rendering main, wet, dirty
LUT
Nukenodes
Gizmo
Nukenodes
Harmony.template
Harmony.palette

Model

Clean geometry without any material assignments. Published model can be as small as a single mesh, or as complex as a full building. That is purely up to the artist or the supervisor. Models can contain hierarchy defined by groups or nulls for better organisation.

Apart from model subsets, we also support LODs as extra level on top of subset. To publish LODs, you just need to prepare subsets for publishing names modelMySubsetName_LOD##, if OpenPype finds _LOD## (hashes replaced with LOD level), it will automatically be considered a LOD of the given subset.

Example Subsets: modelMain, modelProxy, modelSculpt, modelBroken, modelMain_LOD01, modelMain_LOD02

Example representations: .ABC, .MA, .MB, .BLEND, .OBJ, .FBX

Look

A package of materials, shaders, assignments, textures and attributes that collectively define a look of a model for rendering or preview purposes. This can usually be applied only to the model is was authored for, or its corresponding cache, however, material sharing across multiple models is also possible. A look should be fully self-contained and ready for rendering.

Example Subsets: lookMain, lookProxy, lookWet, lookDirty, lookBlue, lookRed

Example Representations: .MA + .JSON, .MTLX (yet unsupported), .BLEND

Please note that a look is almost never a single representation, but a combination of multiple. For example in Maya a look consists of .ma file with the shaders, .json file which contains the attributes and assignments and /resources folder with all the required textures.

Rig

Characters or props with animation controls or other parameters, ready to be referenced into a scene and animated. Animation Rigs tend to be very software specific, but in general they tend to consist of Geometry, Bones or Joints, Controllers and Deformers. OpenPype in maya supports both, self-contained rigs, that include everything in one file, but also rigs that use nested references to bring in geometry, or even skeleton. By default we bake rigs into a single file during publishing, but that behaviour can be turned off to keep the nested references live in the animation scenes.

Example Subsets: rigMain, rigMocap, rigSim, rigCamera, rigMuscle

Example Representations: .MA, .MB, .BLEND, .HDA

Assembly

A subset created by combining two or more smaller subsets into a composed bigger asset. A good example would be a restaurant table asset with the cutlery and chairs included, that will eventually be loaded into a restaurant Set. Instead of loading each individual fork and knife for each table in the restaurant, we can first prepare assemblyRestaurantTable subset which will contain the table itself, with cutlery, flowers, plates and chairs nicely arranged.

This table can then be loaded multiple times into the restaurant for easier scene management and updates.

Extracted assembly doesn't contain any geometry directly, but rather information about all the individual subsets that are inside the assembly, their version and transformations. On top of that and alembic is exported which only holds any extra transforms and groups that are needed to fully re-create the original assembled scene.

Assembly ca also be used as a sort of collection of elements that are often used together in the shots. For example if we're set dressing lot's of forest shots, it would make sense to make and assembly of all the forest elements for scattering so we don't have to load them individually into each shot.

Example Subsets: assemblyTable, assemblyForestElements, assemblyRoof

Example Representations: .ABC + .JSON

Setdress

Fully prepared environment scene assembled from other previously published assets. Setdress should be ready for rendering as is, including any instancing, material assignments and other complex setups the environment requires. Due to this complexity, setdress is currently only publishable in the native file format of the host where it was created. In maya that would be .ma or .mb file.

Camera

Clean virtual camera without any proprietary rigging, or host specific information. Considering how widely across the hosts published cameras are used in production, published camera should ideally be as simple and clean as possible to ensure consistency when loaded into various hosts.

Example Representations: .MA, .ABC

Cache

Geometry or effect with baked animation. Cache is usually exported as alembic, but can be potentially any other representation that makes sense in the given scenario. Cache is defined by the artist directly in the fx or animation scene.

Example Subsets: assemblyTable, assemblyForestElements, assemblyRoof

Example Representations: .ABC, .VDB, .BGEO

Animation

Published result of an animation created with a rig. Animation can be extracted as animation curves, cached out geometry or even fully animated rig with all the controllers. Animation cache is usually defined by a rigger in the rig file of a character or by FX TD in the effects rig, to ensure consistency of outputs.

Example Subsets: animationBob_01, animationJack_02, animationVehicleA

Example Representations: .MA, .ABC, .JSON

Yeti Cache

Cached out yeti fur simulation that originates from a yeti rig applied in the shot context.

Yeti Rig

Yeti groom setup ready to be applied to a cached out character in the shot context.

Render