pyblish / pyblish-advance Goto Github PK

Goal

Ease the transition from not validating to validating assets.

Motivation

Benefits aside, forcefully validating assets can be too large of a change in an environment where previously no validation took place.

Forceful validation can introduce tension and frustration without immediate payoff, resulting in artists looking for ways around validation and ultimately defeat the purpose of validating in the first place.

About benefits, validated data enables both artist and developer to make assumptions on it.

An asset library may, for example assume that a "topologyModel" contains a 3d thumbnail for instant preview, whereas an auto-rigging utility may assume it is build put of quads and that the artist who built it have taken topology into account (as opposed to, say, raw scan data).

But the act of outputting valid data may not always be feasible when under pressure. Especially not when the benefits are not instant to the artist suffering through the extra hoops required to jump through.

Therefore, the artist require an outlet for outputting data under pressure that does not necessarily live up to pristine standards, but still enables other artists and developers the benefit of valid - "certified" - data.

Implementation

Enable publishing of assets that did not pass validation.

The non-certified asset appear like any other, usable like any other.

If, and only if, the asset was published while passing validation, it is assigned a "certificate". An a data point of any kind highlighting that the asset did indeed pass validation during publish. The certificate implies that the asset passed validation relative its family.

A certified asset guarantees that the particular asset complies with associated requirements.

For example, a certified character rig is guaranteed to have all of its cachable geometry in an objectSet called "output_SEL".

An non-certified asset does not.

Future

Tools may then be built with this consideration in mind.

Tools can take advantage and offer a more intelligent interface of the asset based on this knowledge, such as whether or not to try and display a thumbnail in a library-type application.

Knowing that an asset did not pass validation, it can take extra steps to ensure that they are still usable, without offering some of the more advanced and specific options towards it.

A method in which to "tag" certain data amongst large amount of data as being "approved".

Goal

Better organise large quantities of versions.

Motivation

During production, some assets build a greater hierarchy of dependencies than others. For example, one asset may have been passed through strict review by directors, supervisors and others stakeholders and are continued to be built upon further down the pipeline.

These assets can be marked "approved" or otherwise "accepted" to signal to others that it is in a good state for continued effort.

Implementation

Highlight assets of particular importance or status.

A version of an asset is tagged with an additional attribute - approved=True. The attribute may be used in applications that require it, such as asset libraries, review and production tracking software.

Goal

Enable integration testing across multiple departments.

Usecases

• As a [stakeholder] I would like to [what] in order to [profit]
• As an artist, I would like to automatically setup my workspace with relevant assets so as to get started quickly
• As an artist, I would like to preview my work in relation to surrounding work such that I can ensure it works together
• As a supervisor, I would like to automatically produce a render of a shot in its current state

Motivation

Assuming each shot consists of many parts and that monitoring when one of these parts change, it can be important to test whether the change works together with surrounding parts. But assembling these disparate parts can be both daunting and repetitive.

For example, picture an animator having produced a new version of a background character, partially obscured by a foreground character, environment and prop. His expertise lies in character animation, yet for him to visualise his work in relation to surrounding work, he must find and load the relevant versions of environment, foreground character and prop and put these together in an appropriate manner, which may differ across project and/or shot, before ultimately knowing what his work looks like in the greater whole.

Another common issue lies in knowing what you are passing down the pipeline.

In some cases, you can be presented with one thing, such as an animation, but have something different being passed on. Maybe publishing the asset discarded critical information due to some difficult-to-debug problem.

This can be solved by reviewing things that have already passed through the publishing phase, but for this to happen it cannot be tedious.