Merge branch 'develop' into feature/1235-hiero-unify-otio-workflow-from-resolve
63
.github/workflows/documentation.yml
vendored
Normal file
|
|
@ -0,0 +1,63 @@
|
|||
name: documentation
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
branches: [develop]
|
||||
types: [review_requested, ready_for_review]
|
||||
paths:
|
||||
- 'website/**'
|
||||
push:
|
||||
branches: [main]
|
||||
paths:
|
||||
- 'website/**'
|
||||
|
||||
jobs:
|
||||
check-build:
|
||||
if: github.event_name != 'push'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v1
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- name: Test Build
|
||||
run: |
|
||||
cd website
|
||||
if [ -e yarn.lock ]; then
|
||||
yarn install --frozen-lockfile
|
||||
elif [ -e package-lock.json ]; then
|
||||
npm ci
|
||||
else
|
||||
npm i
|
||||
fi
|
||||
npm run build
|
||||
deploy-website:
|
||||
if: github.event_name != 'pull_request'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: 🚚 Get latest code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
|
||||
- name: 🔨 Build
|
||||
run: |
|
||||
cd website
|
||||
if [ -e yarn.lock ]; then
|
||||
yarn install --frozen-lockfile
|
||||
elif [ -e package-lock.json ]; then
|
||||
npm ci
|
||||
else
|
||||
npm i
|
||||
fi
|
||||
npm run build
|
||||
|
||||
- name: 📂 Sync files
|
||||
uses: SamKirkland/FTP-Deploy-Action@4.0.0
|
||||
with:
|
||||
server: ftp.openpype.io
|
||||
username: ${{ secrets.ftp_user }}
|
||||
password: ${{ secrets.ftp_password }}
|
||||
local-dir: ./website/build/
|
||||
88
.github/workflows/test_build.yml
vendored
Normal file
|
|
@ -0,0 +1,88 @@
|
|||
# This workflow will upload a Python Package using Twine when a release is created
|
||||
# For more information see: https://help.github.com/en/actions/language-and-framework-guides/using-python-with-github-actions#publishing-to-package-registries
|
||||
|
||||
name: Test Build
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
branches: [develop]
|
||||
types: [review_requested, ready_for_review]
|
||||
paths-ignore:
|
||||
- 'docs/**',
|
||||
- 'website/**'
|
||||
- 'vendor/**'
|
||||
|
||||
jobs:
|
||||
Windows-latest:
|
||||
|
||||
runs-on: windows-latest
|
||||
strategy:
|
||||
matrix:
|
||||
python-version: [3.7]
|
||||
|
||||
steps:
|
||||
- name: 🚛 Checkout Code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
- name: Set up Python
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: ${{ matrix.python-version }}
|
||||
|
||||
- name: 🧵 Install Requirements
|
||||
shell: pwsh
|
||||
run: |
|
||||
./tools/create_env.ps1
|
||||
|
||||
- name: 🔨 Build
|
||||
shell: pwsh
|
||||
run: |
|
||||
./tools/build.ps1
|
||||
|
||||
Ubuntu-latest:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
python-version: [3.7]
|
||||
|
||||
steps:
|
||||
- name: 🚛 Checkout Code
|
||||
uses: actions/checkout@v2
|
||||
|
||||
- name: Set up Python
|
||||
uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: ${{ matrix.python-version }}
|
||||
|
||||
- name: 🧵 Install Requirements
|
||||
run: |
|
||||
./tools/create_env.sh
|
||||
|
||||
- name: 🔨 Build
|
||||
run: |
|
||||
./tools/build.sh
|
||||
|
||||
# MacOS-latest:
|
||||
|
||||
# runs-on: macos-latest
|
||||
# strategy:
|
||||
# matrix:
|
||||
# python-version: [3.7]
|
||||
|
||||
# steps:
|
||||
# - name: 🚛 Checkout Code
|
||||
# uses: actions/checkout@v2
|
||||
|
||||
# - name: Set up Python
|
||||
# uses: actions/setup-python@v2
|
||||
# with:
|
||||
# python-version: ${{ matrix.python-version }}
|
||||
|
||||
# - name: 🧵 Install Requirements
|
||||
# run: |
|
||||
# ./tools/create_env.sh
|
||||
|
||||
# - name: 🔨 Build
|
||||
# run: |
|
||||
# ./tools/build.sh
|
||||
13
.gitignore
vendored
|
|
@ -66,7 +66,7 @@ coverage.xml
|
|||
|
||||
# Node JS packages
|
||||
##################
|
||||
node_modules/
|
||||
node_modules
|
||||
package-lock.json
|
||||
|
||||
openpype/premiere/ppro/js/debug.log
|
||||
|
|
@ -81,3 +81,14 @@ openpype/premiere/ppro/js/debug.log
|
|||
.env
|
||||
dump.sql
|
||||
test_localsystem.txt
|
||||
|
||||
# website
|
||||
##########
|
||||
website/translated_docs
|
||||
website/build/
|
||||
website/node_modules
|
||||
website/i18n/*
|
||||
|
||||
website/debug.log
|
||||
|
||||
website/.docusaurus
|
||||
|
|
@ -1,15 +1,11 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
"""Open install dialog."""
|
||||
|
||||
import os
|
||||
import sys
|
||||
|
||||
import os
|
||||
os.chdir(os.path.dirname(__file__)) # for override sys.path in Deadline
|
||||
|
||||
from Qt import QtWidgets # noqa
|
||||
from Qt.QtCore import Signal # noqa
|
||||
|
||||
from .install_dialog import InstallDialog
|
||||
from .bootstrap_repos import BootstrapRepos
|
||||
from .version import __version__ as version
|
||||
|
||||
|
|
@ -25,16 +21,21 @@ def get_result(res: int):
|
|||
|
||||
def open_dialog():
|
||||
"""Show Igniter dialog."""
|
||||
from Qt import QtWidgets
|
||||
from .install_dialog import InstallDialog
|
||||
|
||||
app = QtWidgets.QApplication(sys.argv)
|
||||
|
||||
d = InstallDialog()
|
||||
d.finished.connect(get_result)
|
||||
d.open()
|
||||
|
||||
app.exec()
|
||||
|
||||
return RESULT
|
||||
|
||||
|
||||
__all__ = [
|
||||
"InstallDialog",
|
||||
"BootstrapRepos",
|
||||
"open_dialog",
|
||||
"version"
|
||||
|
|
|
|||
|
|
@ -57,25 +57,10 @@ def _prepare_publish_environments():
|
|||
project_name = os.getenv("AVALON_PROJECT")
|
||||
asset_name = os.getenv("AVALON_ASSET")
|
||||
|
||||
io.install()
|
||||
project_doc = io.find_one({
|
||||
"type": "project"
|
||||
})
|
||||
av_asset = io.find_one({
|
||||
"type": "asset",
|
||||
"name": asset_name
|
||||
})
|
||||
parents = av_asset["data"]["parents"]
|
||||
hierarchy = ""
|
||||
if parents:
|
||||
hierarchy = "/".join(parents)
|
||||
|
||||
env["AVALON_PROJECT"] = project_name
|
||||
env["AVALON_ASSET"] = asset_name
|
||||
env["AVALON_TASK"] = os.getenv("AVALON_TASK")
|
||||
env["AVALON_WORKDIR"] = os.getenv("AVALON_WORKDIR")
|
||||
env["AVALON_HIERARCHY"] = hierarchy
|
||||
env["AVALON_PROJECTCODE"] = project_doc["data"].get("code", "")
|
||||
env["AVALON_APP"] = f"hosts.{publish_host}"
|
||||
env["AVALON_APP_NAME"] = "celaction_local"
|
||||
|
||||
|
|
|
|||
|
|
@ -1,18 +1,12 @@
|
|||
import os
|
||||
import sys
|
||||
import nuke
|
||||
|
||||
from avalon import api as avalon
|
||||
from openpype.tools import workfiles
|
||||
from pyblish import api as pyblish
|
||||
from openpype.api import Logger
|
||||
import openpype.hosts.nuke
|
||||
import avalon.api
|
||||
import pyblish.api
|
||||
import openpype
|
||||
from . import lib, menu
|
||||
|
||||
|
||||
self = sys.modules[__name__]
|
||||
self.workfiles_launched = False
|
||||
log = Logger().get_logger(__name__)
|
||||
log = openpype.api.Logger().get_logger(__name__)
|
||||
|
||||
AVALON_CONFIG = os.getenv("AVALON_CONFIG", "pype")
|
||||
HOST_DIR = os.path.dirname(os.path.abspath(openpype.hosts.nuke.__file__))
|
||||
|
|
@ -25,7 +19,7 @@ INVENTORY_PATH = os.path.join(PLUGINS_DIR, "inventory")
|
|||
|
||||
# registering pyblish gui regarding settings in presets
|
||||
if os.getenv("PYBLISH_GUI", None):
|
||||
pyblish.register_gui(os.getenv("PYBLISH_GUI", None))
|
||||
pyblish.api.register_gui(os.getenv("PYBLISH_GUI", None))
|
||||
|
||||
|
||||
def reload_config():
|
||||
|
|
@ -61,15 +55,16 @@ def install():
|
|||
'''
|
||||
|
||||
log.info("Registering Nuke plug-ins..")
|
||||
pyblish.register_plugin_path(PUBLISH_PATH)
|
||||
avalon.register_plugin_path(avalon.Loader, LOAD_PATH)
|
||||
avalon.register_plugin_path(avalon.Creator, CREATE_PATH)
|
||||
avalon.register_plugin_path(avalon.InventoryAction, INVENTORY_PATH)
|
||||
pyblish.api.register_plugin_path(PUBLISH_PATH)
|
||||
avalon.api.register_plugin_path(avalon.api.Loader, LOAD_PATH)
|
||||
avalon.api.register_plugin_path(avalon.api.Creator, CREATE_PATH)
|
||||
avalon.api.register_plugin_path(avalon.api.InventoryAction, INVENTORY_PATH)
|
||||
|
||||
# Register Avalon event for workfiles loading.
|
||||
avalon.on("workio.open_file", lib.check_inventory_versions)
|
||||
avalon.api.on("workio.open_file", lib.check_inventory_versions)
|
||||
|
||||
pyblish.register_callback("instanceToggled", on_pyblish_instance_toggled)
|
||||
pyblish.api.register_callback(
|
||||
"instanceToggled", on_pyblish_instance_toggled)
|
||||
workfile_settings = lib.WorkfileSettings()
|
||||
# Disable all families except for the ones we explicitly want to see
|
||||
family_states = [
|
||||
|
|
@ -79,39 +74,27 @@ def install():
|
|||
"gizmo"
|
||||
]
|
||||
|
||||
avalon.data["familiesStateDefault"] = False
|
||||
avalon.data["familiesStateToggled"] = family_states
|
||||
|
||||
# Workfiles.
|
||||
launch_workfiles = os.environ.get("WORKFILES_STARTUP")
|
||||
|
||||
if launch_workfiles:
|
||||
nuke.addOnCreate(launch_workfiles_app, nodeClass="Root")
|
||||
avalon.api.data["familiesStateDefault"] = False
|
||||
avalon.api.data["familiesStateToggled"] = family_states
|
||||
|
||||
# Set context settings.
|
||||
nuke.addOnCreate(workfile_settings.set_context_settings, nodeClass="Root")
|
||||
# nuke.addOnCreate(workfile_settings.set_favorites, nodeClass="Root")
|
||||
|
||||
nuke.addOnCreate(workfile_settings.set_favorites, nodeClass="Root")
|
||||
nuke.addOnCreate(lib.open_last_workfile, nodeClass="Root")
|
||||
nuke.addOnCreate(lib.launch_workfiles_app, nodeClass="Root")
|
||||
menu.install()
|
||||
|
||||
|
||||
def launch_workfiles_app():
|
||||
'''Function letting start workfiles after start of host
|
||||
'''
|
||||
if not self.workfiles_launched:
|
||||
self.workfiles_launched = True
|
||||
workfiles.show(os.environ["AVALON_WORKDIR"])
|
||||
|
||||
|
||||
def uninstall():
|
||||
'''Uninstalling host's integration
|
||||
'''
|
||||
log.info("Deregistering Nuke plug-ins..")
|
||||
pyblish.deregister_plugin_path(PUBLISH_PATH)
|
||||
avalon.deregister_plugin_path(avalon.Loader, LOAD_PATH)
|
||||
avalon.deregister_plugin_path(avalon.Creator, CREATE_PATH)
|
||||
pyblish.api.deregister_plugin_path(PUBLISH_PATH)
|
||||
avalon.api.deregister_plugin_path(avalon.api.Loader, LOAD_PATH)
|
||||
avalon.api.deregister_plugin_path(avalon.api.Creator, CREATE_PATH)
|
||||
|
||||
pyblish.deregister_callback("instanceToggled", on_pyblish_instance_toggled)
|
||||
pyblish.api.deregister_callback(
|
||||
"instanceToggled", on_pyblish_instance_toggled)
|
||||
|
||||
reload_config()
|
||||
menu.uninstall()
|
||||
|
|
@ -123,7 +106,7 @@ def on_pyblish_instance_toggled(instance, old_value, new_value):
|
|||
log.info("instance toggle: {}, old_value: {}, new_value:{} ".format(
|
||||
instance, old_value, new_value))
|
||||
|
||||
from avalon.nuke import (
|
||||
from avalon.api.nuke import (
|
||||
viewer_update_and_undo_stop,
|
||||
add_publish_knob
|
||||
)
|
||||
|
|
|
|||
|
|
@ -3,9 +3,14 @@ import re
|
|||
import sys
|
||||
from collections import OrderedDict
|
||||
|
||||
|
||||
from avalon import api, io, lib
|
||||
from avalon.tools import workfiles
|
||||
import avalon.nuke
|
||||
from avalon.nuke import lib as anlib
|
||||
from avalon.nuke import (
|
||||
save_file, open_file
|
||||
)
|
||||
from openpype.api import (
|
||||
Logger,
|
||||
Anatomy,
|
||||
|
|
@ -13,6 +18,7 @@ from openpype.api import (
|
|||
get_anatomy_settings,
|
||||
get_hierarchy,
|
||||
get_asset,
|
||||
get_current_project_settings,
|
||||
config,
|
||||
ApplicationManager
|
||||
)
|
||||
|
|
@ -25,8 +31,10 @@ log = Logger().get_logger(__name__)
|
|||
|
||||
self = sys.modules[__name__]
|
||||
self._project = None
|
||||
self.workfiles_launched = False
|
||||
self._node_tab_name = "{}".format(os.getenv("AVALON_LABEL") or "Avalon")
|
||||
|
||||
|
||||
def get_node_imageio_setting(**kwarg):
|
||||
''' Get preset data for dataflow (fileType, compression, bitDepth)
|
||||
'''
|
||||
|
|
@ -1616,3 +1624,41 @@ def find_free_space_to_paste_nodes(
|
|||
xpos = min(group_xpos)
|
||||
ypos = max(group_ypos) + abs(offset)
|
||||
return xpos, ypos
|
||||
|
||||
|
||||
def launch_workfiles_app():
|
||||
'''Function letting start workfiles after start of host
|
||||
'''
|
||||
# get state from settings
|
||||
open_at_start = get_current_project_settings()["nuke"].get(
|
||||
"general", {}).get("open_workfile_at_start")
|
||||
|
||||
# return if none is defined
|
||||
if not open_at_start:
|
||||
return
|
||||
|
||||
if not self.workfiles_launched:
|
||||
self.workfiles_launched = True
|
||||
workfiles.show(os.environ["AVALON_WORKDIR"])
|
||||
|
||||
|
||||
def open_last_workfile():
|
||||
# get state from settings
|
||||
open_last_version = get_current_project_settings()["nuke"].get(
|
||||
"general", {}).get("create_initial_workfile")
|
||||
|
||||
log.info("Opening last workfile...")
|
||||
last_workfile_path = os.environ.get("AVALON_LAST_WORKFILE")
|
||||
|
||||
if not os.path.exists(last_workfile_path):
|
||||
# return if none is defined
|
||||
if not open_last_version:
|
||||
return
|
||||
|
||||
save_file(last_workfile_path)
|
||||
else:
|
||||
# to avoid looping of the callback, remove it!
|
||||
nuke.removeOnCreate(open_last_workfile, nodeClass="Root")
|
||||
|
||||
# open workfile
|
||||
open_file(last_workfile_path)
|
||||
|
|
|
|||
|
|
@ -252,7 +252,7 @@ class HarmonySubmitDeadline(
|
|||
def get_job_info(self):
|
||||
job_info = DeadlineJobInfo("Harmony")
|
||||
job_info.Name = self._instance.data["name"]
|
||||
job_info.Plugin = "HarmonyPype"
|
||||
job_info.Plugin = "HarmonyOpenPype"
|
||||
job_info.Frames = "{}-{}".format(
|
||||
self._instance.data["frameStartHandle"],
|
||||
self._instance.data["frameEndHandle"]
|
||||
|
|
@ -42,7 +42,7 @@ class FtrackModule(
|
|||
ftrack_settings = settings[self.name]
|
||||
|
||||
self.enabled = ftrack_settings["enabled"]
|
||||
self.ftrack_url = ftrack_settings["ftrack_server"]
|
||||
self.ftrack_url = ftrack_settings["ftrack_server"].strip("/ ")
|
||||
|
||||
current_dir = os.path.dirname(os.path.abspath(__file__))
|
||||
server_event_handlers_paths = [
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
"priority": 50,
|
||||
"primary_pool": "",
|
||||
"secondary_pool": "",
|
||||
"chunk_size": 0
|
||||
"chunk_size": 1000000
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -6,7 +6,9 @@
|
|||
"load": "ctrl+alt+l",
|
||||
"manage": "ctrl+alt+m",
|
||||
"build_workfile": "ctrl+alt+b"
|
||||
}
|
||||
},
|
||||
"open_workfile_at_start": false,
|
||||
"create_initial_workfile": true
|
||||
},
|
||||
"create": {
|
||||
"CreateWriteRender": {
|
||||
|
|
|
|||
|
|
@ -43,6 +43,16 @@
|
|||
"label": "Build Workfile"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "boolean",
|
||||
"key": "open_workfile_at_start",
|
||||
"label": "Open Workfile window at start of a Nuke session"
|
||||
},
|
||||
{
|
||||
"type": "boolean",
|
||||
"key": "create_initial_workfile",
|
||||
"label": "Create initial workfile version if none available"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
@ -87,7 +97,7 @@
|
|||
"name": "schema_nuke_publish",
|
||||
"template_data": []
|
||||
},
|
||||
{
|
||||
{
|
||||
"type": "schema",
|
||||
"name": "schema_nuke_load",
|
||||
"template_data": []
|
||||
|
|
@ -101,4 +111,4 @@
|
|||
"name": "schema_publish_gui_filter"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
|
@ -160,32 +160,11 @@ def set_context(project, asset, task):
|
|||
os.environ["AVALON_TASK"] = task
|
||||
io.Session["AVALON_TASK"] = task
|
||||
|
||||
io.install()
|
||||
|
||||
av_project = io.find_one({'type': 'project'})
|
||||
av_asset = io.find_one({
|
||||
"type": 'asset',
|
||||
"name": asset
|
||||
})
|
||||
|
||||
parents = av_asset['data']['parents']
|
||||
hierarchy = ''
|
||||
if parents and len(parents) > 0:
|
||||
hierarchy = os.path.sep.join(parents)
|
||||
|
||||
os.environ["AVALON_HIERARCHY"] = hierarchy
|
||||
io.Session["AVALON_HIERARCHY"] = hierarchy
|
||||
|
||||
os.environ["AVALON_PROJECTCODE"] = av_project['data'].get('code', '')
|
||||
io.Session["AVALON_PROJECTCODE"] = av_project['data'].get('code', '')
|
||||
|
||||
io.Session["current_dir"] = os.path.normpath(os.getcwd())
|
||||
|
||||
os.environ["AVALON_APP"] = HOST_NAME
|
||||
io.Session["AVALON_APP"] = HOST_NAME
|
||||
|
||||
io.uninstall()
|
||||
|
||||
|
||||
def cli_publish(data, publish_paths, gui=True):
|
||||
PUBLISH_SCRIPT_PATH = os.path.join(
|
||||
|
|
|
|||
|
|
@ -6,7 +6,8 @@ exclude =
|
|||
.git,
|
||||
__pycache__,
|
||||
docs,
|
||||
*/vendor
|
||||
*/vendor,
|
||||
website
|
||||
|
||||
max-complexity = 30
|
||||
|
||||
|
|
|
|||
|
|
@ -157,11 +157,12 @@ Write-Host "Reading Poetry ... " -NoNewline
|
|||
if (-not (Test-Path -PathType Container -Path "$($env:USERPROFILE)\.poetry\bin")) {
|
||||
Write-Host "NOT FOUND" -ForegroundColor Yellow
|
||||
Install-Poetry
|
||||
|
||||
Write-Host "INSTALLED" -ForegroundColor Cyan
|
||||
} else {
|
||||
Write-Host "OK" -ForegroundColor Green
|
||||
}
|
||||
|
||||
$env:PATH = "$($env:PATH);$($env:USERPROFILE)\.poetry\bin"
|
||||
|
||||
Write-Host ">>> " -NoNewline -ForegroundColor green
|
||||
Write-Host "Cleaning cache files ... " -NoNewline
|
||||
|
|
@ -172,6 +173,7 @@ Write-Host "OK" -ForegroundColor green
|
|||
|
||||
Write-Host ">>> " -NoNewline -ForegroundColor green
|
||||
Write-Host "Building OpenPype ..."
|
||||
|
||||
$out = & poetry run python setup.py build 2>&1
|
||||
if ($LASTEXITCODE -ne 0)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -172,6 +172,7 @@ main () {
|
|||
poetry run python -m pip install --upgrade pip
|
||||
poetry run pip install --force-reinstall setuptools
|
||||
poetry run pip install --force-reinstall wheel
|
||||
poetry run python -m pip install --force-reinstall pip
|
||||
}
|
||||
|
||||
main -3
|
||||
|
|
|
|||
50
website/docs/admin_distribute.md
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
---
|
||||
id: admin_distribute
|
||||
title: Distribute
|
||||
sidebar_label: Distribute
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
To let your artists to use OpenPype, you'll need to distribute the frozen executables to them.
|
||||
|
||||
Distribution consists of two parts
|
||||
|
||||
### 1. OpenPype Igniter
|
||||
|
||||
This is the base application that will be installed locally on each workstation.
|
||||
It is self contained (frozen) software that also includes all of the OpenPype codebase with the version
|
||||
from the time of the build.
|
||||
|
||||
Igniter package is around 500MB and preparing an updated version requires you to re-build pype. That would be
|
||||
inconvenient for regular and quick distribution of production updates and fixes. So you can distribute those
|
||||
independently, without requiring you artists to re-install every time.
|
||||
|
||||
### 2. OpenPype Codebase
|
||||
|
||||
When you upgrade your studio pype deployment to a new version or make any local code changes, you can distribute
|
||||
these changes to your artists, without the need of re-building OpenPype, by using `create_zip` tool provided.
|
||||
The resulting zip needs to be made available to the artists and it will override their local OpenPype install
|
||||
with the updated version.
|
||||
|
||||
You have two ways of making this happen
|
||||
|
||||
#### Automatic Updates
|
||||
|
||||
Everytime and Artist launches OpenPype on their workstation, it will look to a pre-defined
|
||||
[openPype update location](#self) for any versions that are newer than the
|
||||
latest, locally installed version. If such version is found, it will be downloaded,
|
||||
automatically extracted to the correct place and launched. This will become the default
|
||||
version to run for the artist, until a higher version is detected in the update location again.
|
||||
|
||||
#### Manual Updates
|
||||
|
||||
If for some reason you don't want to use the automatic updates, you can distribute your
|
||||
zips manually. Your artist will then have to unpack them to the correct place on their disk.
|
||||
|
||||
The default locations are:
|
||||
|
||||
- Windows: `C:\Users\%USERNAME%\AppData\Local\pypeclub\openpype`
|
||||
- Linux: ` `
|
||||
- Mac: ` `
|
||||
119
website/docs/admin_docsexamples.md
Normal file
|
|
@ -0,0 +1,119 @@
|
|||
---
|
||||
id: admin_docsexamples
|
||||
title: Examples of using notes
|
||||
sidebar_label: docsexamples
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<Tabs
|
||||
groupId="platforms"
|
||||
defaultValue="win"
|
||||
values={[
|
||||
{label: 'Windows', value: 'win'},
|
||||
{label: 'Linux', value: 'linux'},
|
||||
{label: 'Mac', value: 'mac'},
|
||||
]}>
|
||||
|
||||
<TabItem value="win">
|
||||
|
||||
This is your mac stuff
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="linux">
|
||||
|
||||
This is your linux stuff
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="mac">
|
||||
|
||||
This is your mac stuff
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
:::note Name of the category
|
||||
|
||||
<Tabs
|
||||
groupId="platforms"
|
||||
defaultValue="win"
|
||||
values={[
|
||||
{label: 'Windows', value: 'win'},
|
||||
{label: 'Linux', value: 'linux'},
|
||||
{label: 'Mac', value: 'mac'},
|
||||
]}>
|
||||
|
||||
<TabItem value="win">
|
||||
|
||||
This is your mac stuff
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="linux">
|
||||
|
||||
This is your linux stuff
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="mac">
|
||||
|
||||
This is your mac stuff
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
:::
|
||||
|
||||
|
||||
=========================
|
||||
|
||||
:::important
|
||||
|
||||
- This is my note
|
||||
- another list
|
||||
- super list
|
||||
|
||||
```python
|
||||
import os
|
||||
print(os.environ)
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
This is my note
|
||||
:::
|
||||
|
||||
:::note
|
||||
This is my note
|
||||
:::
|
||||
|
||||
:::warning
|
||||
This is my note
|
||||
:::
|
||||
|
||||
:::caution
|
||||
This is my note
|
||||
:::
|
||||
|
||||
export const Highlight = ({children, color}) => (
|
||||
<span
|
||||
style={{
|
||||
backgroundColor: color,
|
||||
borderRadius: '2px',
|
||||
color: '#fff',
|
||||
padding: '0.2rem',
|
||||
}}>
|
||||
{children}
|
||||
</span>
|
||||
);
|
||||
|
||||
<Highlight color="#25c2a0">Docusaurus green</Highlight> and <Highlight color="#1877F2">Facebook blue</Highlight> are my favorite colors.
|
||||
|
||||
I can write **Markdown** alongside my _JSX_!
|
||||
140
website/docs/admin_openpype_commands.md
Normal file
|
|
@ -0,0 +1,140 @@
|
|||
---
|
||||
id: admin_openpype_commands
|
||||
title: OpenPype Commands Reference
|
||||
sidebar_label: OpenPype Commands
|
||||
---
|
||||
|
||||
|
||||
## `tray`
|
||||
|
||||
To launch Tray:
|
||||
```sh
|
||||
pype tray
|
||||
```
|
||||
|
||||
### `--debug`
|
||||
|
||||
To launch Tray with debugging information:
|
||||
```sh
|
||||
pype tray --debug
|
||||
```
|
||||
|
||||
--------------------
|
||||
|
||||
|
||||
## `eventserver`
|
||||
|
||||
This command launches ftrack event server.
|
||||
|
||||
This should be ideally used by system service (such us systemd or upstart
|
||||
on linux and window service).
|
||||
|
||||
You have to set either proper environment variables to provide URL and
|
||||
credentials or use option to specify them. If you use `--store_credentials`
|
||||
provided credentials will be stored for later use.
|
||||
|
||||
To run ftrack event server:
|
||||
```sh
|
||||
pype eventserver --ftrack-url=<url> --ftrack-user=<user> --ftrack-api-key=<key> --ftrack-events-path=<path> --no-stored-credentials --store-credentials
|
||||
```
|
||||
|
||||
|
||||
### `--debug`
|
||||
- print debug info
|
||||
|
||||
### `--ftrack-url`
|
||||
- URL to ftrack server
|
||||
|
||||
### `--ftrack-user`
|
||||
- user name to log in to ftrack
|
||||
|
||||
### `--ftrack-api-key`
|
||||
- ftrack api key
|
||||
|
||||
### `--ftrack-events-path`
|
||||
- path to event server plugins
|
||||
|
||||
### `--no-stored-credentials`
|
||||
- will use credential specified with options above
|
||||
|
||||
### `--store-credentials`
|
||||
- will store credentials to file for later use
|
||||
|
||||
--------------------
|
||||
|
||||
## `launch`
|
||||
|
||||
Launch application in Pype environment.
|
||||
|
||||
### `--app`
|
||||
|
||||
Application name - this should be the same as it's [defining toml](admin_hosts#launchers) file (without .toml)
|
||||
|
||||
### `--project`
|
||||
Project name
|
||||
|
||||
### `--asset`
|
||||
Asset name
|
||||
|
||||
### `--task`
|
||||
Task name
|
||||
|
||||
### `--tools`
|
||||
*Optional: Additional tools environment files to add*
|
||||
|
||||
### `--user`
|
||||
*Optional: User on behalf to run*
|
||||
|
||||
### `--ftrack-server` / `-fs`
|
||||
*Optional: Ftrack server URL*
|
||||
|
||||
### `--ftrack-user` / `-fu`
|
||||
*Optional: Ftrack user*
|
||||
|
||||
### `--ftrack-key` / `-fk`
|
||||
*Optional: Ftrack API key*
|
||||
|
||||
For example to run Python interactive console in Pype context:
|
||||
```sh
|
||||
pype launch --app python --project my_project --asset my_asset --task my_task
|
||||
```
|
||||
|
||||
--------------------
|
||||
|
||||
|
||||
## `publish`
|
||||
|
||||
Pype takes JSON from provided path and use it to publish data in it.
|
||||
```sh
|
||||
pype publish <PATH_TO_JSON>
|
||||
```
|
||||
|
||||
### `--debug`
|
||||
- print more verbose infomation
|
||||
|
||||
--------------------
|
||||
|
||||
## `extractenvironments`
|
||||
|
||||
Extract environment variables for entered context to a json file.
|
||||
|
||||
Entered output filepath will be created if does not exists.
|
||||
|
||||
All context options must be passed otherwise only openpype's global environments will be extracted.
|
||||
|
||||
Context options are "project", "asset", "task", "app"
|
||||
|
||||
### `output_json_path`
|
||||
- Absolute path to the exported json file
|
||||
|
||||
### `--project`
|
||||
- Project name
|
||||
|
||||
### `--asset`
|
||||
- Asset name
|
||||
|
||||
### `--task`
|
||||
- Task name
|
||||
|
||||
### `--app`
|
||||
- Application name
|
||||
86
website/docs/admin_settings.md
Normal file
|
|
@ -0,0 +1,86 @@
|
|||
---
|
||||
id: admin_settings
|
||||
title: Working with settings
|
||||
sidebar_label: Working with settings
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
OpenPype stores all of it's settings and configuration in the mongo database. To make the configuration as easy as possible we provide a robust GUI where you can access and change everything that is configurable
|
||||
|
||||
**Settings** GUI can be started from the tray menu.
|
||||
|
||||
Please keep in mind that these settings are set-up for the full studio and not per-individual. If you're looking for individual artist settings, you can head to
|
||||
[Local Settings](#local-settings) section in the artist documentation.
|
||||
|
||||
|
||||
## Categories
|
||||
|
||||
We use simple colour coding to show you any changes to the settings:
|
||||
- **Grey**: [OpenPype default](#openpype-defaults)
|
||||
- **Green**: [Studio default](#openpype-defaults)
|
||||
- **Orange**: [Project Override](#project-overrides)
|
||||
- **Blue**: Changed and unsaved value
|
||||
|
||||
You'll find that settings are split into categories:
|
||||
|
||||
### [System](admin_settings_system)
|
||||
|
||||
System sections contains all settings that can be configured on a studio level, but cannot
|
||||
be changed on a per-project basis. These include mostly high level options like path to
|
||||
mongo database, toggling major modules on and off and configuring studio wide application
|
||||
availability.
|
||||
|
||||
### [Project](admin_settings_project)
|
||||
|
||||
Project tab contains most of OpenPype settings and all of them can be configured and overriden on a per-project basis if need be. This includes most of the workflow behaviors
|
||||
like what formats to export, naming conventions, publishing validations, automatic assets loaders and a lot more.
|
||||
|
||||
We recommend to try to keep as many configurations as possible on a studio level and only override selectively, because micromanaging all of the project settings might become cumbersome down the line. Most of the settings can be safely adjusted and locked on a project
|
||||
after the production started.
|
||||
|
||||
## Understanding Overrides
|
||||
|
||||
Most of the individual settings can be set and overriden on multiple levels.
|
||||
|
||||
### OpenPype defaults
|
||||
When you first open settings all of the values and categories will be marked with a
|
||||
light **grey labels** or a **grey vertical bar** on the left edge of the expandable category.
|
||||
|
||||
That means, the value has been left at OpenPype Default. If the default changes in future
|
||||
OpenPype versions, these values will be reflect the change after you deploy the new version.
|
||||
|
||||
### Studio defaults
|
||||
|
||||
Any values that you change and then press save in the bottom right corner, will be saved
|
||||
as studio defaults. This means they will stay at those values even if you update your pype.
|
||||
To make it clear which settings are set by you specifically, they are marked with a **green
|
||||
edge** and **green labels**, once set.
|
||||
|
||||
To set studio default, just change the value in the system tab and press save. If you want
|
||||
to keep the value but add the option to your studio default to protect it from potential
|
||||
future updates, you ran `right click` and choose `add to studio default`, then press save.
|
||||
|
||||
In the Project settings tab, you need to select the **( Default )** project on the left, to set your studio defaults for projects. The rest works the same as in the System tab.
|
||||
|
||||

|
||||
|
||||
You can also reset any settings to OpenPype default by doing `right click` and `remove from studio default`
|
||||
|
||||

|
||||
|
||||
### Project Overrides
|
||||
|
||||
Many settings are usefull to be adjusted on a per-project basis. To identify project
|
||||
overrides, they are marked with **orange edge** and **orange labels** in the settings GUI.
|
||||
|
||||
To set project overrides proceed the same way as with the Studio defaults, but first select
|
||||
a particular project you want to be configuring on the left hand side of the Project Settings tab.
|
||||
|
||||
Here you can see all three overrides at the same time. Deadline has not studio changes at all, Maya has some studio defaults configures and Nuke also contains project specific overrides.
|
||||

|
||||
|
||||
Override colours work as breadcrumbs to allow quick identification of what was changed and where. As you can see on this image, Orange colour is propagated up the hierarchy even though only a single value (sync render version with workfile toggle), was changed.
|
||||
|
||||

|
||||
11
website/docs/admin_settings_project.md
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
id: admin_settings_project
|
||||
title: Project Settings
|
||||
sidebar_label: Project Settings
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
|
||||
PROJECT Settings
|
||||
106
website/docs/admin_settings_project_anatomy.md
Normal file
|
|
@ -0,0 +1,106 @@
|
|||
---
|
||||
id: admin_settings_project_anatomy
|
||||
title: Project Anatomy
|
||||
sidebar_label: Project Anatomy
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
|
||||
Project Anatomy is the most important configuration piece for each project you work on with openPype.
|
||||
|
||||
It defines:
|
||||
- Project Root folders
|
||||
- File naming conventions
|
||||
- Folder structure templates
|
||||
- Default project attributes
|
||||
- Task Types
|
||||
- Applications and Tool versions
|
||||
- Colour Management
|
||||
- File Formats
|
||||
|
||||
Anatomy is the only configuration that is always saved as project override. This is to make sure, that any updates to OpenPype or Studio default values, don't affect currently running productions.
|
||||
|
||||

|
||||
|
||||
## Roots
|
||||
|
||||
Roots define where files are stored with path to shared folder. It is required to set root path for each platform you are using in studio. All paths must point to same folder!
|
||||
|
||||

|
||||
|
||||
It is possible to set multiple roots when necessary. That may be handy when you need to store specific type of data on another disk.
|
||||

|
||||
|
||||
|
||||
Note how multiple roots are used here, to push different types of files to different shared storage.
|
||||

|
||||
|
||||
|
||||
## Templates
|
||||
|
||||
Templates define project's folder structure and filenames.
|
||||
|
||||
We have a few required anatomy templates for OpenPype to work properly, however we keep adding more when needed.
|
||||
|
||||
### Available template keys
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--5 markdown">
|
||||
|
||||
|
||||
| Context key | Description |
|
||||
| --- | --- |
|
||||
| `root[name]` | Path to root folder |
|
||||
| `project[name]` | Project's full name |
|
||||
| `project[code]` | Project's code |
|
||||
| `hierarchy` | All hierarchical parents as subfolders |
|
||||
| `asset` | Name of asset or shot |
|
||||
| `task` | Name of task |
|
||||
| `version` | Version number |
|
||||
| `subset` | Subset name |
|
||||
| `family` | Main family name |
|
||||
| `ext` | File extention |
|
||||
| `representation` | Representation name |
|
||||
| `frame` | Frame number for sequence files. |
|
||||
| `output` | |
|
||||
| `comment` | |
|
||||
|
||||
</div>
|
||||
<div class="col col--7 markdown">
|
||||
|
||||
| Date-Time key | Example result | Description |
|
||||
| --- | --- | --- |
|
||||
| `d` | 1, 30 | Short day of month |
|
||||
| `dd` | 01, 30 | Day of month with 2 digits. |
|
||||
| `ddd` | Mon | Shortened week day name. |
|
||||
| `dddd` | Monday | Full week day name. |
|
||||
| `m` | 1, 12 | Short month number. |
|
||||
| `mm` | 01, 12 | Month number with 2 digits. |
|
||||
| `mmm` | Jan | Shortened month name. |
|
||||
| `mmmm` | January | Full month name. |
|
||||
| `yy` | 20 | Shortened year. |
|
||||
| `yyyy` | 2020 | Full year. |
|
||||
| `H` | 4, 17 | Shortened 24-hour number. |
|
||||
| `HH` | 04, 17 | 24-hour number with 2 digits. |
|
||||
| `h` | 5 | Shortened 12-hour number. |
|
||||
| `hh` | 05 | 12-hour number with 2 digits. |
|
||||
| `ht` | AM, PM | Midday part. |
|
||||
| `M` | 0 | Shortened minutes number. |
|
||||
| `MM` | 00 | Minutes number with 2 digits. |
|
||||
| `S` | 0 | Shortened seconds number. |
|
||||
| `SS` | 00 | Seconds number with 2 digits. |
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
## Attributes
|
||||
|
||||
|
||||
|
||||
## Task Types
|
||||
|
||||
|
||||
## Colour Management and Formats
|
||||
132
website/docs/admin_settings_system.md
Normal file
|
|
@ -0,0 +1,132 @@
|
|||
---
|
||||
id: admin_settings_system
|
||||
title: System Settings
|
||||
sidebar_label: System settings
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
## Global
|
||||
|
||||
Settings applicable to the full studio.
|
||||
|
||||
`Studio Name`
|
||||
|
||||
`Studio Code`
|
||||
|
||||
`Environment`
|
||||
|
||||
## Modules
|
||||
|
||||
Configuration of OpenPype modules. Some can only be turned on and off, others have
|
||||
their own attributes that need to be set, before they become fully functional.
|
||||
|
||||
### Avalon
|
||||
|
||||
`Avalon Mongo Timeout` - You might need to change this if your mongo connection is a bit slow. Making the
|
||||
timeout longer will give Avalon better chance to connect.
|
||||
|
||||
`Thumbnail Storage Location` - simple disk storage path, where all thumbnails will be stored.
|
||||
|
||||
### Ftrack
|
||||
|
||||
`Server` - URL of your ftrack server.
|
||||
|
||||
Additional Action paths
|
||||
|
||||
`Action paths` - Directories containing your custom ftrack actions.
|
||||
|
||||
`Event paths` - Directories containing your custom ftrack event plugins.
|
||||
|
||||
`Intent` - Special ftrack attribute that mark the intention of individual publishes. This setting will be reflected
|
||||
in publisher as well as ftrack custom attributes
|
||||
|
||||
`Custom Attributes` - Write and Read permissions for all OpenPype required ftrack custom attributes. The values should be
|
||||
ftrack roles names.
|
||||
|
||||
### Sync Server
|
||||
|
||||
Disable/Enable OpenPype site sync feature
|
||||
|
||||
### Standalone Publisher
|
||||
|
||||
Disable/Enable Standalone Publisher option
|
||||
|
||||
### Deadline
|
||||
|
||||
`Deadline Rest URL` - URL to deadline webservice that. This URL must be reachable from every
|
||||
workstation that should be submitting render jobs to deadline via OpenPype.
|
||||
|
||||
### Muster
|
||||
|
||||
`Muster Rest URL` - URL to Muster webservice that. This URL must be reachable from every
|
||||
workstation that should be submitting render jobs to muster via OpenPype.
|
||||
|
||||
`templates mapping` - you can customize Muster templates to match your existing setup here.
|
||||
|
||||
### Clockify
|
||||
|
||||
`Workspace Name` - name of the clockify workspace where you would like to be sending all the timelogs.
|
||||
|
||||
### Timers Manager
|
||||
|
||||
`Max Idle Time` - Duration (minutes) of inactivity, after which currently running timer will be stopped.
|
||||
|
||||
`Dialog popup time` - Time in minutes, before the end of Max Idle ti, when a notification will alert
|
||||
the user that their timer is about to be stopped.
|
||||
|
||||
### Idle Manager
|
||||
|
||||
Service monitoring the activity, which triggers the Timers Manager timeouts.
|
||||
|
||||
### Logging
|
||||
|
||||
Module that allows storing all logging into the database for easier retrieval and support.
|
||||
|
||||
## Applications
|
||||
|
||||
In this section you can manage what Applications are available to your studio, locations of their
|
||||
executables and their additional environments.
|
||||
|
||||
Each DCC is made of two levels.
|
||||
1. **Application group** - This is the main name of the application and you can define extra environments
|
||||
that are applicable to all version of the give application. For example any extra Maya scripts that are not
|
||||
version dependant, can be added to `Maya` environment here.
|
||||
2. **Application versions** - Here you can define executables (per platform) for each supported version of
|
||||
the DCC and any default arguments (`--nukex` for instance). You can also further extend it's environment.
|
||||
|
||||

|
||||
|
||||
Please keep in mind that the environments are not additive by default, so if you are extending variables like
|
||||
`PYTHONPATH`, or `PATH` make sure that you add themselves to the end of the list.
|
||||
|
||||
For instance:
|
||||
|
||||
```json
|
||||
{
|
||||
"PYTHONPATH": [
|
||||
"my/path/to/python/scripts",
|
||||
"{PYTHONPATH}"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## Tools
|
||||
|
||||
A tool in openPype is anything that needs to be selectively added to your DCC applications. Most often these are plugins, modules, extensions or similar depending on what your package happens to call it.
|
||||
|
||||
OpenPype comes with some major CG renderers pre-configured as an example, but these and any others will need to be changed to match your particular environment.
|
||||
|
||||
Their environment settings are split to two levels just like applications to allow more flexibility when setting them up.
|
||||
|
||||
In the image before you can see that we set most of the environment variables in the general MTOA level, and only specify the version variable in the individual versions below. Because all environments within pype setting will resolve any cross references, this is enough to get a fully dynamic plugin loading as far as your folder structure where you store the plugins is nicely organized.
|
||||
|
||||
|
||||
In this example MTOA will automatically will the `MAYA_VERSION`(which is set by Maya Application environment) and `MTOA_VERSION` into the `MTOA` variable. We then use the `MTOA` to set all the other variables needed for it to function within Maya.
|
||||

|
||||
|
||||
All of the tools defined in here can then be assigned to projects. You can also change the tools versions on any project level all the way down to individual asset or shot overrides. So if you just need to upgrade you render plugin for a single shot, while not risking the incompatibilities on the rest of the project, it is possible.
|
||||
37
website/docs/admin_use.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
---
|
||||
id: admin_use
|
||||
title: Install and Run
|
||||
sidebar_label: Install & Run
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
|
||||
## Install
|
||||
|
||||
You can install OpenPype on individual workstations the same way as any other software.
|
||||
When you create you build, you will end up with an installation package for the platform
|
||||
that was used for the build.
|
||||
|
||||
- Windows: `OpenPype-3.0.0.msi`
|
||||
- Linux: `OpenPype-3.0.0.zip`
|
||||
- Mac: `OpenPype-3.0.0.dmg`
|
||||
|
||||
After OpenPype is installed, it will ask the user for further installation if it detects a
|
||||
newer version in the studio update location.
|
||||
|
||||
## Run OpenPype
|
||||
|
||||
To use OpenPype on a workstation simply run the executable that was installed.
|
||||
On the first run the user will be prompted to for OpenPype Mongo URL.
|
||||
This piece of information needs to be provided to the artist by the admin setting
|
||||
up OpenPype in the studio.
|
||||
|
||||
Once artist enters the Mongo URL address, OpenPype will remember the connection for the
|
||||
next launch, so it is a one time process.From that moment OpenPype will do it's best to
|
||||
always keep up to date with the latest studio updates.
|
||||
|
||||
If the launch was successfull, the artist should see a green OpenPype logo in their
|
||||
tray menu. Keep in mind that on Windows this icon might be hidden by default, in which case,
|
||||
the artist can simply drag the icon down to the tray.
|
||||
7
website/docs/api.md
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
id: api
|
||||
title: Pype API
|
||||
sidebar_label: API
|
||||
---
|
||||
|
||||
Work in progress
|
||||
53
website/docs/artist_concepts.md
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
---
|
||||
id: artist_concepts
|
||||
title: Key concepts
|
||||
sidebar_label: Key Concepts
|
||||
---
|
||||
|
||||
## Glossary
|
||||
|
||||
### Asset
|
||||
|
||||
In our pipeline all the main entities the project is made from are internally considered *'Assets'*. Episode, sequence, shot, character, prop, etc. All of these behave identically in the pipeline. Asset names need to be absolutely unique within the project because they are their key identifier.
|
||||
|
||||
### Subset
|
||||
|
||||
Usually, an asset needs to be created in multiple *'flavours'*. A character might have multiple different looks, model needs to be published in different resolutions, a standard animation rig might not be useable in a crowd system and so on. 'Subsets' are here to accommodate all this variety that might be needed within a single asset. A model might have subset: *'main'*, *'proxy'*, *'sculpt'*, while data of *'look'* family could have subsets *'main'*, *'dirty'*, *'damaged'*. Subsets have some recommendations for their names, but ultimately it's up to the artist to use them for separation of publishes when needed.
|
||||
|
||||
### Version
|
||||
|
||||
A numbered iteration of a given subset. Each version contains at least one [representation][daa74ebf].
|
||||
|
||||
[daa74ebf]: #representation "representation"
|
||||
|
||||
### Representation
|
||||
|
||||
Each published variant can come out of the software in multiple representations. All of them hold exactly the same data, but in different formats. A model, for example, might be saved as `.OBJ`, Alembic, Maya geometry or as all of them, to be ready for pickup in any other applications supporting these formats.
|
||||
|
||||
### Family
|
||||
|
||||
Each published [subset][3b89d8e0] can have exactly one family assigned to it. Family determines the type of data that the subset holds. Family doesn't dictate the file type, but can enforce certain technical specifications. For example OpenPype default configuration expects `model` family to only contain geometry without any shaders or joins when it is published.
|
||||
|
||||
|
||||
[3b89d8e0]: #subset "subset"
|
||||
|
||||
|
||||
|
||||
### Host
|
||||
|
||||
General term for Software or Application supported by OpenPype and Avalon. These are usually DCC applications like Maya, Houdini or Nuke, but can also be a web based service like Ftrack or Clockify.
|
||||
|
||||
|
||||
### Tool
|
||||
|
||||
Small piece of software usually dedicated to a particular purpose. Most of OpenPype and Avalon tools have GUI, but some are command line only
|
||||
|
||||
|
||||
### Publish
|
||||
|
||||
Process of exporting data from your work scene to versioned, immutable file that can be used by other artists in the studio.
|
||||
|
||||
### Load
|
||||
|
||||
Process of importing previously published subsets into your current scene, using any of the OpenPype tools.
|
||||
Loading asset using proper tools will ensure that all your scene content stays version controlled and updatable at a later point
|
||||
82
website/docs/artist_ftrack.md
Normal file
|
|
@ -0,0 +1,82 @@
|
|||
---
|
||||
id: artist_ftrack
|
||||
title: Ftrack
|
||||
sidebar_label: Artist
|
||||
---
|
||||
|
||||
# How to use Ftrack in OpenPype
|
||||
|
||||
## Login to Ftrack module in OpenPype tray (best case scenario)
|
||||
1. Launch OpenPype tray if not launched yet
|
||||
2. *Ftrack login* window pop up on start
|
||||
- or press **login** in **Ftrack menu** to pop up *Ftrack login* window
|
||||
|
||||

|
||||
|
||||
3. Press `Ftrack` button
|
||||

|
||||
4. Web browser opens
|
||||
5. Sign in Ftrack if you're requested
|
||||
|
||||

|
||||
6. Message is shown
|
||||
|
||||

|
||||
7. Close message and you're ready to use actions - continue with [Application launch](#application-launch-best-case-scenario)
|
||||
|
||||
---
|
||||
## Application launch (best case scenario)
|
||||
1. Make sure OpenPype is running and you passed [Login to Ftrack](#login-to-ftrack-module-in-pype-tray-best-case-scenario) guide
|
||||
2. Open web browser and go to your studio Ftrack web page *(e.g. https://mystudio.ftrackapp.com/)*
|
||||
3. Locate the task on which you want to run the application
|
||||
4. Display actions for the task
|
||||

|
||||
5. Select application you want to launch
|
||||
- application versions may be grouped to one action in that case press the action to reveal versions to choose *(like Maya in the picture)*
|
||||

|
||||
6. Work
|
||||
|
||||
---
|
||||
## Change Ftrack user
|
||||
1. Log out the previous user from Ftrack Web app *(skip if new is already logged)*
|
||||
|
||||

|
||||
2. Log out the previous user from Ftrack module in tray
|
||||
|
||||

|
||||
3. Follow [Login to Ftrack](#login-to-ftrack-module-in-pype-tray-best-case-scenario) guide
|
||||
|
||||
---
|
||||
## What if...
|
||||
|
||||
### Ftrack login window didn't pop up and Ftrack menu is not in tray
|
||||
**1. possibility - OpenPype tray didn't load properly**
|
||||
- try to restart OpenPype
|
||||
|
||||
**2. possibility - Ftrack is not set in OpenPype**
|
||||
- inform your administrator
|
||||
|
||||
|
||||
### Web browser did not open
|
||||
**1. possibility - button was not pressed**
|
||||
- Try to press again the `Ftrack` button in *Ftrack login* window
|
||||
|
||||
**2. possibility - Ftrack URL is not set or is not right**
|
||||
- Check **Ftrack URL** value in *Ftrack login* window
|
||||
- Inform your administrator if URL is incorrect and launch tray again when administrator fix it
|
||||
|
||||
**3. possibility - Ftrack Web app can't be reached the way OpenPype use it**
|
||||
- Enter your **Username** and [API key](#where-to-find-api-key) in *Ftrack login* window and press **Login** button
|
||||
|
||||
### Ftrack action menu is empty
|
||||
**1. possibility - OpenPype is not running**
|
||||
- launch OpenPype
|
||||
|
||||
**2. possibility - You didn't go through Login to Ftrack guide**
|
||||
- please go through [Login to Ftrack](#login-to-ftrack-module-in-pype-tray-best-case-scenario) guide
|
||||
|
||||
**3. possibility - User logged to Ftrack Web is not the same as user logged to Ftrack module in tray**
|
||||
- Follow [Change user](#change-user) guide
|
||||
|
||||
**4. possibility - Project don't have set applications**
|
||||
- ask your Project Manager to check if he set applications for the project
|
||||
84
website/docs/artist_getting_started.md
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
---
|
||||
title: Getting started with OpenPype
|
||||
sidebar_label: Getting started
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
|
||||
## Working in the studio
|
||||
|
||||
In studio environment you should have OpenPype already installed and deployed, so you can start using it without much setup. Your admin has probably put OpenPype icon on your desktop or even had your computer set up so OpenPype will start automatically.
|
||||
|
||||
If this is not the case, please contact your administrator to consult on how to launch OpenPype in your studio
|
||||
|
||||
## Working from home
|
||||
|
||||
If you are working from home though, you'll need to install it yourself. You should, however, receive the OpenPype installer files from your studio
|
||||
admin, supervisor or production, because OpenPype versions and executables might not be compatible between studios.
|
||||
|
||||
To install OpenPype you just need to unzip it anywhere on the disk
|
||||
|
||||
To use it, you have two options
|
||||
|
||||
**openpype_gui.exe** is the most common for artists. It runs OpenPype GUI in system tray. From there you can run all the available tools. To use any of the features, OpenPype must be running in the tray.
|
||||
|
||||
**openpype_console.exe** in usefull for debugging and error reporting. It opens console window where all the necessary information will appear during user's work.
|
||||
|
||||
|
||||
<Tabs
|
||||
groupId="platforms"
|
||||
defaultValue="win"
|
||||
values={[
|
||||
{label: 'Windows', value: 'win'},
|
||||
{label: 'Linux', value: 'linux'},
|
||||
{label: 'Mac', value: 'mac'},
|
||||
]}>
|
||||
|
||||
<TabItem value="win">
|
||||
|
||||
WIP - Windows instructions once installers are finished
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="linux">
|
||||
|
||||
WIP - Linux instructions once installers are finished
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="mac">
|
||||
|
||||
WIP - Mac instructions once installers are finished
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## First Launch
|
||||
|
||||
|
||||
When you first start OpenPype, you will be asked to give it some basic information.
|
||||
### MongoDB
|
||||
|
||||
In most cases that will only be your studio MongoDB Address.
|
||||
|
||||
It is a URL that you should receive from you studio and most often will look like this `mongodb://username:passwword@mongo.mystudiodomain.com:12345` or `mongodb://192.168.100.15:27071`, it really depends on your studio setup. When OpenPype Igniter
|
||||
asks for it, just put it in the corresponding text field and press `install` button.
|
||||
|
||||
### OpenPype Version Repository
|
||||
|
||||
Sometimes your studio might also ask you to fill in the path to it's version
|
||||
repository. This is a location where OpenPype will be looking for when checking
|
||||
if it's up to date and where updates are installed from automatically.
|
||||
|
||||
This pat is usually taken from the database directly, so you shouldn't need it.
|
||||
|
||||
|
||||
## Updates
|
||||
|
||||
If you're connected to your studio, OpenPype will check for, and install updates automatically everytime you run it. That's why during the first start, it will go through a quick update installation process, even though you might have just installed it.
|
||||
|
||||
|
||||
## Advanced use
|
||||
|
||||
For more advanced use of OpenPype commands please visit [Admin section](admin_openpype_commands).
|
||||
17
website/docs/artist_hosts.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
id: artist_hosts
|
||||
title: Hosts
|
||||
sidebar_label: Hosts
|
||||
---
|
||||
|
||||
## Maya
|
||||
|
||||
## Houdini
|
||||
|
||||
## Nuke
|
||||
|
||||
## Fusion
|
||||
|
||||
## Unreal
|
||||
|
||||
## System
|
||||
107
website/docs/artist_hosts_aftereffects.md
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
---
|
||||
id: artist_hosts_aftereffects
|
||||
title: AfterEffects
|
||||
sidebar_label: AfterEffects
|
||||
---
|
||||
<!-- based on PS implementation, same principle and menu -->
|
||||
## Available Tools
|
||||
|
||||
- [Work Files](artist_tools.md#workfiles)
|
||||
- [Create](artist_tools.md#creator)
|
||||
- [Load](artist_tools.md#loader)
|
||||
- [Publish](artist_tools.md#publisher)
|
||||
- [Manage](artist_tools.md#inventory)
|
||||
- [Subset Manager](artist_tools.md#subset-manager)
|
||||
|
||||
## Setup
|
||||
|
||||
To install the extension, download, install [Anastasyi's Extention Manager](https://install.anastasiy.com/). Open Anastasyi's Extension Manager and select AfterEffects in menu. Then go to `{path to pype}/repos/avalon-core/avalon/aftereffects/extension.zxp`.
|
||||
|
||||
Drag extension.zxp and drop it to Anastasyi's Extension Manager. The extension will install itself.
|
||||
|
||||
## Implemented functionality
|
||||
|
||||
AfterEffects implementation currently allows you to import and add various media to composition (image plates, renders, audio files, video files etc.)
|
||||
and send prepared composition for rendering to Deadline.
|
||||
|
||||
## Usage
|
||||
|
||||
When you launch AfterEffects you will be met with the Workfiles app. If don't
|
||||
have any previous workfiles, you can just close this window.
|
||||
|
||||
Workfiles tools takes care of saving your .AEP files in the correct location and under
|
||||
a correct name. You should use it instead of standard file saving dialog.
|
||||
|
||||
In AfterEffects you'll find the tools in the `OpenPype` extension:
|
||||
|
||||
 <!-- same menu as in PS -->
|
||||
|
||||
You can show the extension panel by going to `Window` > `Extensions` > `OpenPype`.
|
||||
|
||||
### Create
|
||||
|
||||
When you have created an composition you want to publish, you will need to tag existing composition. To do this open the `Creator` through the extensions `Create` button.
|
||||
|
||||

|
||||
|
||||
Because of current rendering limitations, it is expected that only single composition will be marked for publishing!
|
||||
|
||||
After Creator is successfully triggered on selected composition, it will be marked with an icon and its color
|
||||
will be changed.
|
||||
|
||||

|
||||
|
||||
### Publish
|
||||
|
||||
When you are ready to share your work, you will need to publish it. This is done by opening the `Publish` by clicking the corresponding button in the OpenPype Panel.
|
||||
|
||||

|
||||
|
||||
This tool will run through checks to make sure the contents you are publishing is correct. Hit the "Play" button to start publishing.
|
||||
|
||||
You may encounter issues with publishing which will be indicated with red squares. If these issues are within the validation section, then you can fix the issue. If there are issues outside of validation section, please let the OpenPype team know. For More details have a look at the general [Publish](artist_tools.md#publisher) documentation.
|
||||
|
||||
### Load
|
||||
|
||||
When you want to load existing published work, you can use the `Loader` tool. You can reach it in the extension's panel.
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
The supported families for loading into AfterEffects are:
|
||||
|
||||
- `image`
|
||||
- `plate`
|
||||
- `render`
|
||||
- `prerender`
|
||||
- `review`
|
||||
- `audio`
|
||||
- `background` `(set of images sorted in predefined order)`
|
||||
|
||||
To load an item, right-click on the subset you want and choose a representation you want to load:
|
||||
|
||||

|
||||
|
||||
### Manage
|
||||
|
||||
Now that we have some content loaded, you can manage which version is loaded. This is done through the `Scene Manager`. You can reach it through the extension's `Manage` button.
|
||||
|
||||
:::note
|
||||
Loaded images have to stay as smart layers in order to be updated. If you rasterize the layer, you can no longer update it to a different version using OpenPype tools.
|
||||
:::
|
||||
|
||||

|
||||
|
||||
You can switch to a previous version of the image or update to the latest.
|
||||
|
||||

|
||||

|
||||
|
||||
### Subset Manager
|
||||
|
||||

|
||||
|
||||
All created compositions will be shown in a simple list. If user decides, that this composition shouldn't be
|
||||
published after all, right click on that item in the list and select 'Remove instance'
|
||||
|
||||
Removing composition direclty in the AE would result to worfile contain phantom metadata which could result in
|
||||
errors during publishing!
|
||||
128
website/docs/artist_hosts_harmony.md
Normal file
|
|
@ -0,0 +1,128 @@
|
|||
---
|
||||
id: artist_hosts_harmony
|
||||
title: Harmony
|
||||
sidebar_label: Harmony
|
||||
---
|
||||
|
||||
## Available Tools
|
||||
|
||||
- [Work Files](artist_tools.md#workfiles)
|
||||
- [Create](artist_tools.md#creator)
|
||||
- [Load](artist_tools.md#loader)
|
||||
- [Publish](artist_tools.md#publisher)
|
||||
- [Manage](artist_tools.md#inventory)
|
||||
|
||||
:::note
|
||||
Only one tool can be open at a time. If you open a tool while another tool is open, it will wait in queue for the existing tool to be closed. Once the existing tool is closed, the new tool will open.
|
||||
:::
|
||||
|
||||
## Usage
|
||||
|
||||
The integration creates an `OpenPype` menu entry where all related tools are located.
|
||||
|
||||
:::note
|
||||
Menu creation can be temperamental. Its best to start Harmony and do nothing else until the application is fully launched.
|
||||
If you dont see the `OpenPype` menu, then follow this to create it:
|
||||
- Go to the `Script Editor`
|
||||
- Find the script called `TB_sceneOpened.js` and run it.
|
||||
- Choose the `start` method to run.
|
||||
:::
|
||||
|
||||
### Workfiles
|
||||
|
||||
`OpenPype > Workfiles`
|
||||
|
||||
Work files are temporarily stored locally, in `[user]/.avalon/harmony`, to reduce network bandwidth. When saving the Harmony scene, a background process ensures the network files are updated.
|
||||
|
||||
:::important
|
||||
Because the saving to the network location happens in the background, be careful when quickly saving and closing Harmony (and the terminal window) since an interrupted saving to the network location can corrupt the workfile. To be sure the workfile is saved to the network location look in the terminal for a line similar to this:
|
||||
|
||||
`DEBUG:avalon.harmony.lib:Saved "[Local Scene Directory]" to "[Network Scene Directory]\[Name Of Workfile].zip"`
|
||||
:::
|
||||
|
||||
### Create
|
||||
|
||||
`OpenPype > Create`
|
||||
|
||||

|
||||
|
||||
These are the families supported in Harmony:
|
||||
|
||||
- `Render`
|
||||
- This instance is for generating a render and review. This is a normal write node, but only PNGs are supported at the moment.
|
||||
- `Template`
|
||||
- This instance is for generating a templates. This is a normal composite node, which you can connect any number of nodes to.
|
||||
- Any connected nodes will be published along with their dependencies and any back drops.
|
||||
- `Palette`
|
||||
- Palettes are indirectly supported in Harmony. This means you just have to have palettes in your scene to publish them.
|
||||
|
||||
When you `Use selection` on creation, the last selected node will be connected to the created node.
|
||||
|
||||
### Publish
|
||||
|
||||
`OpenPype > Publish`
|
||||
|
||||
 <!-- picture has to be changed (Harmony needed) -->
|
||||
|
||||
This tool will run through checks to make sure the contents you are publishing is correct. Hit the "Play" button to start publishing.
|
||||
|
||||
You may encounter issues with publishing which will be indicated with red squares. If these issues are within the validation section, then you can fix the issue. If there are issues outside of validation section, please let the OpenPype team know.
|
||||
|
||||
#### Repair Validation Issues
|
||||
|
||||
All validators will give some description about what the issue is. You can inspect this by going into the validator through the arrow:
|
||||
|
||||
 <!-- picture has to be changed (Harmony needed) -->
|
||||
|
||||
You can expand the errors by clicking on them for more details:
|
||||
|
||||
 <!-- picture has to be changed (Harmony needed) -->
|
||||
|
||||
Some validator have repair actions, which will fix the issue. If you can identify validators with actions by the circle icon with an "A":
|
||||
|
||||
 <!-- picture has to be changed (Harmony needed) -->
|
||||
|
||||
To access the actions, you right click on the validator. If an action runs successfully, the actions icon will turn green. Once all issues are fixed, you can just hit the "Refresh" button and try to publish again.
|
||||
|
||||
 <!-- gif has to be changed (Harmony needed) -->
|
||||
|
||||
### Load
|
||||
|
||||
`OpenPype > Load`
|
||||
|
||||
 <!-- picture has to be changed (Harmony needed) -->
|
||||
|
||||
The supported families for Harmony are:
|
||||
|
||||
- `image`
|
||||
- `harmony.template`
|
||||
- Only import is current supported for templates.
|
||||
- `harmony.palette`
|
||||
- Loaded palettes are moved to the top of the colour stack, so they will acts as overrides. Imported palettes are left in the scene.
|
||||
- `workfile`
|
||||
- Only of type `zip`.
|
||||
|
||||
To load, right-click on the subset you want and choose a representation:
|
||||
|
||||
 <!-- gif has to be changed (Harmony needed) -->
|
||||
|
||||
:::note
|
||||
Loading templates or workfiles will import the contents into scene. Referencing is not supported at the moment, so you will have to load newer versions into the scene.
|
||||
:::
|
||||
|
||||
### Manage
|
||||
|
||||
`OpenPype > Manage`
|
||||
|
||||
 <!-- picture has to be changed (Harmony needed) -->
|
||||
|
||||
You can switch to a previous version of the image or update to the latest.
|
||||
|
||||
 <!-- gif has to be changed (Harmony needed) -->
|
||||
 <!-- gif has to be changed (Harmony needed) -->
|
||||
|
||||
:::note
|
||||
Images and image sequences will be loaded into the scene as read nodes can coloured green. On startup the pipeline checks for any outdated read nodes and colours them red.
|
||||
- <span style={{color:'green'}}>Green</span> = Up to date version in scene.
|
||||
- <span style={{color:'red'}}>Red</span> = Outdated version in scene.
|
||||
:::
|
||||
693
website/docs/artist_hosts_maya.md
Normal file
|
|
@ -0,0 +1,693 @@
|
|||
---
|
||||
id: artist_hosts_maya
|
||||
title: Maya
|
||||
sidebar_label: Maya
|
||||
---
|
||||
|
||||
## OpenPype global tools
|
||||
|
||||
- [Set Context](artist_tools.md#set-context)
|
||||
- [Work Files](artist_tools.md#workfiles)
|
||||
- [Create](artist_tools.md#creator)
|
||||
- [Load](artist_tools.md#loader)
|
||||
- [Manage (Inventory)](artist_tools.md#inventory)
|
||||
- [Publish](artist_tools.md#publisher)
|
||||
- [Library Loader](artist_tools.md#library-loader)
|
||||
|
||||
## Working with OpenPype in Maya
|
||||
|
||||
OpenPype is here to ease you the burden of working on project with lots of
|
||||
collaborators, worrying about naming, setting stuff, browsing through endless
|
||||
directories, loading and exporting and so on. To achieve that, OpenPype is using
|
||||
concept of being _"data driven"_. This means that what happens when publishing
|
||||
is influenced by data in scene. This can by slightly confusing so let's get to
|
||||
it with few examples.
|
||||
|
||||
## Publishing models
|
||||
|
||||
### Intro
|
||||
|
||||
Publishing models in Maya is pretty straightforward. Create your model as you
|
||||
need. You need to adhere to specifications of your studio that can be different
|
||||
between studios and projects but by default your geometry has to be named properly.
|
||||
For example `sphere_GEO` or `cube1_GEO`. Geometry needs to have freezed transformations
|
||||
and must reside under one group, for example `model_GRP`.
|
||||
|
||||

|
||||
|
||||
Note that `sphere_GEO` has frozen transformations.
|
||||
|
||||
### Creating instance
|
||||
|
||||
Now create **Model instance** from it to let OpenPype know what in the scene you want to
|
||||
publish. Go **OpenPype → Create... → Model**
|
||||
|
||||

|
||||
|
||||
`Asset` field is a name of asset you are working on - it should be already filled
|
||||
with correct name as you've started Maya or switched context to specific asset. You
|
||||
can edit that field to change it to different asset (but that one must already exists).
|
||||
|
||||
`Subset` field is a name you can decide on. It should describe what kind of data you
|
||||
have in the model. For example, you can name it `Proxy` to indicate that this is
|
||||
low resolution stuff. See [Subset](artist_concepts#subset).
|
||||
|
||||
:::note LOD support
|
||||
By changing subset name you can take advantage of _LOD support_ in OpenPype. Your
|
||||
asset can contain various resolution defined by different subsets. You can then
|
||||
switch between them very easy using [Inventory (Manage)](artist_tools#inventory).
|
||||
There LODs are conveniently grouped so they don't clutter Inventory view.
|
||||
|
||||
Name your subset like `main_LOD1`. Important part is that `_LOD1`. You can have as many LODs as you need.
|
||||
:::
|
||||
|
||||
Read-only field just under it show final subset name, adding subset field to
|
||||
name of the group you have selected.
|
||||
|
||||
`Use selection` checkbox will use whatever you have selected in Outliner to be
|
||||
wrapped in Model instance. This is usually what you want. Click on **Create** button.
|
||||
|
||||
You'll notice then after you've created new Model instance, there is new set
|
||||
in Outliner called after your subset, in our case it is `modelMain`.
|
||||
|
||||
And that's it, you have your first model ready to publish.
|
||||
|
||||
Now save your scene (if you didn't do it already). You will notice that path
|
||||
in Save dialog is already set to place where scenes related to modeling task on
|
||||
your asset should reside. As in our case we are working on asset called
|
||||
**Ben** and on task **modeling**, path relative to your project directory will be
|
||||
`project_XY/assets/ben/work/modeling`. Let's save our scene as `model_test_v01`.
|
||||
|
||||
### Publishing models
|
||||
|
||||
Now let's publish it. Go **OpenPype → Publish...**. You will be presented with following window:
|
||||
|
||||

|
||||
|
||||
Note that content of this window can differs by your pipeline configuration.
|
||||
For more detail see [Publisher](artist_tools#publisher).
|
||||
|
||||
Items in left column are instances you will be publishing. You can disable them
|
||||
by clicking on square next to them. Green square indicate they are ready for
|
||||
publishing, red means something went wrong either during collection phase
|
||||
or publishing phase. Empty one with gray text is disabled.
|
||||
|
||||
See that in this case we are publishing from scene file `model_test_v01.mb` in
|
||||
Maya model named `modelMain (ben)` (next item). Publishing of workfile is
|
||||
currenly disabled (last item).
|
||||
|
||||
Right column lists all tasks that are run during collection, validation,
|
||||
extraction and integration phase. White items are optional and you can disable
|
||||
them by clicking on them.
|
||||
|
||||
Lets do dry-run on publishing to see if we pass all validators. Click on flask
|
||||
icon at the bottom. Validators are run. Ideally you will end up with everything
|
||||
green in validator section.
|
||||
|
||||
### Fixing problems
|
||||
|
||||
To make things interesting, I intentionally forgot to freeze transformations
|
||||
on `sphere_GEO` as I know it will trigger validator designed to check just this.
|
||||
|
||||

|
||||
|
||||
You can see our model is now marked red in left column and in right we have
|
||||
red box next to `Transform Zero (Freeze)` validator.
|
||||
|
||||
You can click on arrow next to it to see more details:
|
||||
|
||||

|
||||
|
||||
From there you can see in **Records** entry that there is problem with `sphere_GEO`.
|
||||
Some validators have option to fix problem for you or just select objects that
|
||||
cause trouble. This is the case with our failed validator.
|
||||
|
||||
In main overview you can notice little up arrow in a circle next to validator
|
||||
name. Right click on it and you can see menu item `select invalid`. This
|
||||
will select offending object in Maya.
|
||||
|
||||
Fix is easy. Without closing Publisher window we just freeze transformations.
|
||||
Then we need to reset it to make it notice changes we've made. Click on arrow
|
||||
circle button at the bottom and it will reset Publisher to initial state. Run
|
||||
validators again (flask icon) to see if everything is ok.
|
||||
|
||||
It should be now. Write some comment if you want and click play icon button
|
||||
when ready.
|
||||
|
||||
Publish process will now take its course. Depending on data you are publishing
|
||||
it can take a while. You should end up with everything green and message
|
||||
**Finished successfully ...** You can now close publisher window.
|
||||
|
||||
To check for yourself that model is published, open
|
||||
[Asset Loader](artist_tools#loader) - **OpenPype → Load...**.
|
||||
There you should see your model, named `modelMain`.
|
||||
|
||||
## Look development
|
||||
|
||||
Look development in OpenPype is easy. It helps you with versioning different
|
||||
kinds of shaders and easy switching between them.
|
||||
|
||||
Let se how it works.
|
||||
|
||||
### Loading model
|
||||
|
||||
In this example I have already published model of Buddha. To see how to publish
|
||||
model with OpenPype see [Publishing Model](artist_hosts_maya#publishing-models).
|
||||
|
||||
First of lets start with empty scene. Now go **OpenPype → Load...**
|
||||
|
||||

|
||||
|
||||
Here I am loading `modelBuddha`, its version 1 for asset **foo**. Just right-click
|
||||
on it and select **Reference (abc)**. This will load model into scene as alembic.
|
||||
Now you can close Loader window.
|
||||
|
||||
### Creating look
|
||||
|
||||
Now you can create whatever look you want. Assign shaders, textures, etc. to model.
|
||||
In my case, I assigned simple Arnolds _aiSurfaceShader_ and changed its color to red.
|
||||
|
||||

|
||||
|
||||
I am quite happy with it so I want to publish it as my first look.
|
||||
|
||||
### Publishing look
|
||||
|
||||
Select your model in outliner and ho **OpenPype → Create...**. From there
|
||||
select **Look**. Make sure `use selection` checkbox is checked.
|
||||
Mine subset name is `Main`. This will create _Look instance_ with a name **lookMain**.
|
||||
|
||||
Close _Creator_ window.
|
||||
|
||||
Now save your scene, give it some sensible name. Next, go **OpenPype → Publish**.
|
||||
This process is almost identical as publishing models, only different _Validators_
|
||||
and other plugins will be used.
|
||||
|
||||
This should be painless and cause no trouble so go ahead, click play icon button at
|
||||
the bottom and it will publish your look.
|
||||
|
||||
:::note publishing multiple looks
|
||||
You can reference same model into scene multiple times, change materials on every
|
||||
instance with what you need. Then on every model create _Look instance_. When
|
||||
publishing all those _Look instances_ will be published at same time.
|
||||
:::
|
||||
|
||||
### Loading looks into models
|
||||
|
||||
Now lets see how look are applied. Start new empty scene, load your published
|
||||
model there as before (using _Reference (abc)_). If you didn't notice until now,
|
||||
there are few yellow icons in left shelf:
|
||||
|
||||

|
||||
|
||||
Those are shortcuts for **Look Manager**, [Work Files](artist_tools.md#workfiles),
|
||||
[Load](artist_tools.md#loader), and [Manage (Inventory)](artist_tools.md#inventory).
|
||||
|
||||
Those can be found even in top menu, but that depends on your studio setup.
|
||||
|
||||
You are interested now in **Look Manager** - first item with brush icon. Select
|
||||
your Buddha model and open **Look Manager**.
|
||||
|
||||

|
||||
|
||||
This is **Look Manager** window. Yours would be empty until you click **Get All Assets**
|
||||
or **Get Assets From Selection**. You can use later to quick assign looks if you have
|
||||
multiple assets loaded in scene. Click on one of those button now.
|
||||
|
||||
You should now see all assets and their subsets loaded in scene, and on right side
|
||||
all applicable published looks.
|
||||
|
||||
Select you asset and on the right side right click on `Main` look. Apply it.
|
||||
|
||||
You notice that Buddha model is now red, materials you've published are now applied
|
||||
to it.
|
||||
|
||||
That way you can create looks as you want and version them using OpenPype.
|
||||
|
||||
## Setting scene data
|
||||
|
||||
Maya settings concerning framerate, resolution and frame range are handled by
|
||||
OpenPype. If set correctly in Ftrack, Maya will validate you have correct fps on
|
||||
scene save and publishing offering way to fix it for you.
|
||||
|
||||
For resolution and frame range, use **OpenPype → Reset Frame Range** and
|
||||
**OpenPype → Reset Resolution**
|
||||
|
||||
|
||||
## Creating rigs with OpenPype
|
||||
|
||||
Creating and publishing rigs with OpenPype follows similar workflow as with
|
||||
other data types. Create your rig and mark parts of your hierarchy in sets to
|
||||
help OpenPype validators and extractors to check it and publish it.
|
||||
|
||||
### Preparing rig for publish
|
||||
|
||||
When creating rigs, it is recommended (and it is in fact enforced by validators)
|
||||
to separate bones or driving objects, their controllers and geometry so they are
|
||||
easily managed. Currently OpenPype doesn't allow to publish model at the same time as
|
||||
its rig so for demonstration purposes, I'll first create simple model for robotic
|
||||
arm, just made out of simple boxes and I'll publish it.
|
||||
|
||||

|
||||
|
||||
For more information about publishing models, see [Publishing models](artist_hosts_maya#publishing-models).
|
||||
|
||||
Now lets start with empty scene. Load your model - **OpenPype → Load...**, right
|
||||
click on it and select **Reference (abc)**.
|
||||
|
||||
I've created few bones and their controllers in two separate
|
||||
groups - `rig_GRP` and `controls_GRP`. Naming is not important - just adhere to
|
||||
your naming conventions.
|
||||
|
||||
Then I've put everything into `arm_rig` group.
|
||||
|
||||
When you've prepared your hierarchy, it's time to create *Rig instance* in OpenPype.
|
||||
Select your whole rig hierarchy and go **OpenPype → Create...**. Select **Rig**.
|
||||
Set is created in your scene to mark rig parts for export. Notice that it has
|
||||
two subsets - `controls_SET` and `out_SET`. Put your controls into `controls_SET`
|
||||
and geometry to `out_SET`. You should end up with something like this:
|
||||
|
||||

|
||||
|
||||
### Publishing rigs
|
||||
|
||||
Publishing rig is done in same way as publishing everything else. Save your scene
|
||||
and go **OpenPype → Publish**. When you run validation you'll mostly run at first into
|
||||
few issues. Although number of them will seem to be intimidating at first, you'll
|
||||
find out they are mostly minor things easily fixed.
|
||||
|
||||
* **Non Duplicate Instance Members (ID)** - This will most likely fail because when
|
||||
creating rigs, we usually duplicate few parts of it to reuse them. But duplication
|
||||
will duplicate also ID of original object and OpenPype needs every object to have
|
||||
unique ID. This is easily fixed by **Repair** action next to validator name. click
|
||||
on little up arrow on right side of validator name and select **Repair** form menu.
|
||||
|
||||
* **Joints Hidden** - This is enforcing joints (bones) to be hidden for user as
|
||||
animator usually doesn't need to see them and they clutter his viewports. So
|
||||
well behaving rig should have them hidden. **Repair** action will help here also.
|
||||
|
||||
* **Rig Controllers** will check if there are no transforms on unlocked attributes
|
||||
of controllers. This is needed because animator should have ease way to reset rig
|
||||
to it's default position. It also check that those attributes doesn't have any
|
||||
incoming connections from other parts of scene to ensure that published rig doesn't
|
||||
have any missing dependencies.
|
||||
|
||||
### Loading rigs
|
||||
|
||||
You can load rig with [Loader](artist_tools.md#loader). Go **OpenPype → Load...**,
|
||||
select your rig, right click on it and **Reference** it.
|
||||
|
||||
## Point caches
|
||||
OpenPype is using Alembic format for point caches. Workflow is very similar as
|
||||
other data types.
|
||||
|
||||
### Creating Point Caches
|
||||
|
||||
To create point cache just create whatever hierarchy you want and animate it.
|
||||
Select its root and Go **OpenPype → Create...** and select **Point Cache**.
|
||||
|
||||
After that, publishing will create corresponding **abc** files.
|
||||
|
||||
Example setup:
|
||||
|
||||

|
||||
|
||||
### Loading Point Caches
|
||||
|
||||
Loading point cache means creating reference to **abc** file with Go **OpenPype → Load...**.
|
||||
|
||||
Example result:
|
||||
|
||||

|
||||
|
||||
## Set dressing in Maya
|
||||
|
||||
Set dressing is term for easily populate complex scenes with individual parts.
|
||||
OpenPype allows to version and manage those sets.
|
||||
|
||||
### Publishing Set dress / Layout
|
||||
|
||||
Working with Set dresses is very easy. Just load your assets into scene with
|
||||
[Loader](artist_tools.md#loader) (**OpenPype → Load...**). Populate your scene as
|
||||
you wish, translate each piece to fit your need. When ready, select all imported
|
||||
stuff and go **OpenPype → Create...** and select **Set Dress** or **Layout**.
|
||||
This will create set containing your selection and marking it for publishing.
|
||||
|
||||
:::note set dress vs layout
|
||||
Currently *set dress* and *layout* are functionally identical
|
||||
:::
|
||||
|
||||
Now you can publish is with **OpenPype → Publish**.
|
||||
|
||||
### Loading Set dress / Layout
|
||||
|
||||
You can load Set dress / Layout using [Loader](artist_tools.md#loader)
|
||||
(**OpenPype → Load...**). Select you layout or set dress, right click on it and
|
||||
select **Reference Maya Ascii (ma)**. This will populate your scene with all those
|
||||
models you've put into layout.
|
||||
|
||||
## Rendering with OpenPype
|
||||
|
||||
OpenPype in Maya can be used for submitting renders to render farm and for their
|
||||
subsequent publishing. Right now OpenPype support [AWS Thinkbox Deadline](https://www.awsthinkbox.com/deadline)
|
||||
and [Virtual Vertex Muster](https://www.vvertex.com/overview/).
|
||||
|
||||
* For setting up Muster support see [admin section](admin_config#muster)
|
||||
* For setting up Deadline support see [here](admin_config#aws-thinkbox-deadline)
|
||||
|
||||
:::note Muster login
|
||||
Muster is now configured so every user must log in to get authentication support. If OpenPype founds out this token is missing or expired, it will ask again for credentials.
|
||||
:::
|
||||
|
||||
### Creating basic render setup
|
||||
|
||||
If you want to submit your render to farm, just follow these simple steps.
|
||||
|
||||
#### Preparing scene
|
||||
|
||||
Lets start with empty scene. First I'll pull in my favorite Buddha model.
|
||||
**OpenPype → Load...**, select model and right+click to pop up context menu. From
|
||||
there just click on **Reference (abc)**.
|
||||
|
||||
Next, I want to be sure that I have same frame range as is set on shot I am working
|
||||
on. To do this just **OpenPype → Reset Frame Range**. This should set Maya timeline to same
|
||||
values as they are set on shot in *Ftrack* for example.
|
||||
|
||||
I have my time set, so lets create some animation. We'll turn Buddha model around for
|
||||
50 frames (this is length of my timeline).
|
||||
|
||||
Select model, go to first frame, key Y axis rotation, go to last frame, enter 360 to
|
||||
**Channel Editor** Y rotation, key it and its done. If you are not sure how to do it,
|
||||
you are probably reading wrong documentation.
|
||||
|
||||
Now let set up lights, ground and camera. I am lazy so I create Arnolds Skydome light:
|
||||
**Arnold → Lights → Skydome Light**. As ground simple Plane will suffice and I'll set
|
||||
my perspective view as I like and create new camera from it (`CTRL+SHIFT+C`) and rename
|
||||
it from `persp1` to `mainCamera`.
|
||||
|
||||
One last thing, I'll assign basic *aiSurfaceShader* to my Buddha and do some little
|
||||
tweaks on it.
|
||||
|
||||
#### Prepare scene for submission
|
||||
|
||||
As we have working simple scene we can start preparing it for rendering. OpenPype is fully utilizing
|
||||
Render Setup layers for this. First of all, we need to create *Render instance* to tell OpenPype what
|
||||
to do with renders. You can easily render locally or on render farm without it, but *Render instance*
|
||||
is here to mark render layers you want to publish.
|
||||
|
||||
Lets create it. Go **OpenPype → Create...**. There select **Render** from list. If you keep
|
||||
checked **Use selection** it will use your current Render Layers (if you have them). Otherwise,
|
||||
if no render layers is present in scene, it will create one for you named **Main** and under it
|
||||
default collection with `*` selector.
|
||||
|
||||
No matter if you use *Deadline* or *Muster*, OpenPype will try to connect to render farm and
|
||||
fetch machine pool list.
|
||||
|
||||
:::note Muster login
|
||||
This might fail on *Muster* in the event that you have expired authentication token. In that case, you'll be presented with login window. Nothing will be created in the scene until you log in again and do create **Render** again.
|
||||
:::
|
||||
|
||||
So now my scene now looks like this:
|
||||
|
||||

|
||||
|
||||
You can see that it created `renderingMain` set and under it `LAYER_Main`. This set corresponds to
|
||||
**Main** render layer in Render Setup. This was automatically created because I had not created any
|
||||
render layers in scene before. If you already have layers and you use **Use selection**, they will
|
||||
appear here, prefixed with `LAYER_`. Those layer set are created whenever you create new layer in
|
||||
Render Setup and are deleted if you delete layer in Render Setup. However if you delete `LAYER_` set,
|
||||
layer in Render Setup isn't deleted. It just means it won't be published.
|
||||
|
||||
Creating *Render instance* will also set image prefix in render settings to OpenPype defaults based on
|
||||
renderer you use - for example if you render with Arnold, it is `maya/<Scene>/<RenderLayer>/<RenderLayer>_<RenderPass>`.
|
||||
|
||||
There are few setting on *Render instance* `renderingMain` in **Attributes Editor**:
|
||||
|
||||

|
||||
|
||||
Few options that needs explaining:
|
||||
|
||||
* `Primary Pool` - here is list of pool fetched from server you can select from.
|
||||
* `Suspend publish Job` - job sent to farm will not start render automatically
|
||||
but is in *waiting* state.
|
||||
* `Extend Frames` - if checked it will add new frames to previous render, so you can
|
||||
extend previous image sequence.
|
||||
* `Override Existing Frame` - will overwrite file in destination if they exists
|
||||
* `Priority` is priority of job on farm
|
||||
* `Frames Per Task` is number of sequence division between individual tasks (chunks)
|
||||
making one job on farm.
|
||||
|
||||
Now if you run publish, you notice there is in right column new item called
|
||||
`Render Layers` and in it there is our new layer `Main (999_abc_0010) [1-10]`. First part is
|
||||
layer name, second `(999_abc_0010)` is asset name and rest is frame range.
|
||||
|
||||

|
||||
|
||||
You see I already tried to run publish but was stopped by few errors. Lets go
|
||||
through them one by one just to see what we need to set up further in scene for
|
||||
successful publish.
|
||||
|
||||
**No Default Cameras Renderable** is telling me:
|
||||
|
||||
```fix
|
||||
Renderable default cameras found: [u'|persp|perspShape']
|
||||
```
|
||||
|
||||
and so can be resolved by simple change in *Main* layer render settings.
|
||||
All I have to do is just remove the `persp` camera from render settings and add there correct camera.
|
||||
|
||||
This leaves me only with **Render Settings** error. If I click on it to see
|
||||
details, I see it has problem with animation not being enabled:
|
||||
|
||||
```fix
|
||||
Animation needs to be enabled. Use the same frame for start and end to render single frame
|
||||
```
|
||||
|
||||
Go to **Render Settings**, select your render layer and in **Common** tab change
|
||||
in **File Output** `Frame/Animation ext` to whatever you want, just not _Single Frame_.
|
||||
Set **Frame Range** `Start frame` and `End frame` according your needs.
|
||||
|
||||
If you run into problems with *image file prefix* - this should be set correctly when
|
||||
creating *Render instance*, but you can tweak it. It needs to begin with `maya/<Scene>` token
|
||||
to avoid render conflicts between DCCs. It needs to have `<RenderLayer>` or `<Layer>` (vray) and
|
||||
`<RenderPass>` or `<Aov>` (vray). If you have more then one renderable cameras, add `<Camera>` token.
|
||||
|
||||
Sane default for arnold, redshift or renderman is:
|
||||
|
||||
```fix
|
||||
maya/<RenderLayer>/<RenderLayer>_<RenderPass>
|
||||
```
|
||||
|
||||
and for vray:
|
||||
|
||||
```fix
|
||||
maya/<Layer>/<Layer>
|
||||
```
|
||||
|
||||
Doing **OpenPype → Reset Resolution** will set correct resolution on camera.
|
||||
|
||||
Scene is now ready for submission and should publish without errors.
|
||||
|
||||
:::tip what happens when I publish my render scene
|
||||
When publishing is finished, job is created on farm. This job has one more dependent job connected to itself.
|
||||
When render is finished, this other job triggers in and run publish again, but this time it is publishing rendered image sequence and creating quicktime movie for preview from it. Only those rendered sequences that have **beauty** AOV get preview as it doesn't make sense to make it for example from cryptomatte.
|
||||
:::
|
||||
|
||||
### Attaching render to subset
|
||||
|
||||
You can create render that will be attached to another subset you are publishing, rather than being published on its own. Let's assume, you want to render a model turnaround.
|
||||
In the scene from where you want to publish your model create *Render subset*. Prepare your render layer as needed and then drag
|
||||
model subset (Maya set node) under corresponding `LAYER_` set under *Render instance*. During publish, it will submit this render to farm and
|
||||
after it is rendered, it will be attached to your model subset.
|
||||
|
||||
## Render Setups
|
||||
|
||||
### Publishing Render Setups
|
||||
|
||||
OpenPype can publish whole **Render Settings** setup. You can then version in and load it to
|
||||
any Maya scene. This helps TDs to distribute per asset/shots render settings for Maya.
|
||||
|
||||
To publish render settings, go **OpenPype → Create...** and select **Render Setup Preset**.
|
||||
|
||||
In your scene will appear set `rendersetup<subset>`. This one has no settings, only its presence
|
||||
in scene will trigger publishing of render settings.
|
||||
|
||||
When you publish scene, current settings in **Render Settings** will be serialized to json file.
|
||||
|
||||
### Loading Render Setups
|
||||
|
||||
In any scene, you can load published render settings with **OpenPype → Load...**. Select your published
|
||||
render setup settings, right+click on it and select **Load RenderSetup template**.
|
||||
|
||||
This will load and parse json file and apply all setting there to your Render Setting.
|
||||
|
||||
:::warning
|
||||
This will overwrite all setting you already have.
|
||||
:::
|
||||
|
||||
## Reviews
|
||||
|
||||
OpenPype supports creating review video for almost any type of data you want to publish.
|
||||
What we call review video is actually _playblast_ or _capture_ (depending on terminology
|
||||
you are familiar with) made from pre-defined camera in scene. This is very useful
|
||||
in cases where you want to add turntable preview of your model for example. But it can
|
||||
be used to generate preview for animation, simulations, and so on.
|
||||
|
||||
### Setting scene for review extraction
|
||||
|
||||
Lets see how review publishing works on simple scene. We will publish model with
|
||||
turntable preview video.
|
||||
|
||||
I'll be using Stanford University dragon model. Start with empty scene.
|
||||
Create your model, import it or load from OpenPype. I'll just import model as OBJ
|
||||
file.
|
||||
|
||||
After we have our model in, we need to set everything to be able to publish it
|
||||
as model - for detail see [Publishing models](artist_hosts_maya#publishing-models).
|
||||
|
||||
To recap - freeze transforms, rename it to `dragon_GEO` and put it into group
|
||||
`dragon_GRP`. Then select this group and **OpenPype → Create...** and choose **Model**.
|
||||
|
||||
Now, lets create camera we need to generate turntable video. I prefer to animate
|
||||
camera itself and not model because all animation keys will be associated with camera
|
||||
and not model we want to publish.
|
||||
|
||||
I've created camera, named it `reviewCamera` and parent it under `reviewRotation_LOC`
|
||||
locator. I set my timeline to 50 frames, key `reviewRotation_LOC` Y axis on frame
|
||||
1 to 0 and on frame 50 to 360. I've also set animation curve between those two keys
|
||||
to linear.
|
||||
|
||||
To mark camera to be used for review, select camera `reviewCamera` and go **OpenPype → Create...**
|
||||
and choose **Review**.
|
||||
|
||||
This will create set `review<subset>` including selected camera. You can set few options
|
||||
on this set to control review video generation:
|
||||
|
||||
* `Active` - control on/off state
|
||||
* `Frame Start` - starting frame for review
|
||||
* `Frame End` - end frame for review
|
||||
* `Handles` - number of handle frame before and after
|
||||
* `Step` - number of steps
|
||||
* `Fps` - framerate
|
||||
|
||||
This is my scene:
|
||||
|
||||

|
||||
|
||||
_* note that I had to fix UVs and normals on Stanford dragon model as it wouldn't pass
|
||||
model validators_
|
||||
|
||||
### Publishing model with review
|
||||
|
||||
You can now publish your model and generate review video. Go **OpenPype → Publish...**,
|
||||
validate if you will, and publish it. During publishing, Maya will create _playblast_
|
||||
for whole frame range you've specified, then it will pass those frames to _ffmpeg_.
|
||||
That will create video file, pass it to another extractor creating burnins in it
|
||||
and finally uploading this video to ftrack with your model (or other type) published
|
||||
version. All parts of this process - like what burnins, what type of video file,
|
||||
settings for Maya playblast - can be customized by your TDs. For more information
|
||||
about customizing review process refer to [admin section](admin_presets_plugins).
|
||||
|
||||
|
||||
## Working with Yeti in OpenPype
|
||||
|
||||
OpenPype can work with [Yeti](https://peregrinelabs.com/yeti/) in two data modes.
|
||||
It can handle Yeti caches and Yeti rigs.
|
||||
|
||||
### Creating and publishing Yeti caches
|
||||
|
||||
Let start by creating simple Yeti setup, just one object and Yeti node. Open new
|
||||
empty scene in Maya and create sphere. Then select sphere and go **Yeti → Create Yeti Node on Mesh**
|
||||
Open Yeti node graph **Yeti → Open Graph Editor** and create setup like this:
|
||||
|
||||

|
||||
|
||||
It doesn't matter what setting you use now, just select proper shape in first
|
||||
*Import* node. Select your Yeti node and create *Yeti Cache instance* - **OpenPype → Create...**
|
||||
and select **Yeti Cache**. Leave `Use selection` checked. You should end up with this setup:
|
||||
|
||||

|
||||
|
||||
You can see there is `yeticacheDefault` set. Instead of *Default* it could be named with
|
||||
whatever name you've entered in `subset` field during instance creation.
|
||||
|
||||
We are almost ready for publishing cache. You can check basic settings by selecting
|
||||
Yeti cache set and opening *Extra attributes* in Maya **Attribute Editor**.
|
||||
|
||||

|
||||
|
||||
Those attributes there are self-explanatory, but:
|
||||
|
||||
- `Preroll` is number of frames simulation will run before cache frames are stored.
|
||||
This is usefull to "steady" simulation for example.
|
||||
- `Frame Start` from what frame we start to store cache files
|
||||
- `Frame End` to what frame we are storing cache files
|
||||
- `Fps` of cache
|
||||
- `Samples` how many time samples we take during caching
|
||||
|
||||
You can now publish Yeti cache as any other types. **OpenPype → Publish**. It will
|
||||
create sequence of `.fur` files and `.fursettings` metadata file with Yeti node
|
||||
setting.
|
||||
|
||||
### Loading Yeti caches
|
||||
|
||||
You can load Yeti cache by **OpenPype → Load ...**. Select your cache, right+click on
|
||||
it and select **Load Yeti cache**. This will create Yeti node in scene and set its
|
||||
cache path to point to your published cache files. Note that this Yeti node will
|
||||
be named with same name as the one you've used to publish cache. Also notice that
|
||||
when you open graph on this Yeti node, all nodes are as they were in publishing node.
|
||||
|
||||
### Creating and publishing Yeti Rig
|
||||
|
||||
Yeti Rigs are working in similar way as caches, but are more complex and they deal with
|
||||
other data used by Yeti, like geometry and textures.
|
||||
|
||||
Let's start by [loading](artist_hosts_maya#loading-model) into new scene some model.
|
||||
I've loaded my Buddha model.
|
||||
|
||||
Create select model mesh, create Yeti node - **Yeti → Create Yeti Node on Mesh** and
|
||||
setup similar Yeti graph as in cache example above.
|
||||
|
||||
Then select this Yeti node (mine is called with default name `pgYetiMaya1`) and
|
||||
create *Yeti Rig instance* - **OpenPype → Create...** and select **Yeti Cache**.
|
||||
Leave `Use selection` checked.
|
||||
|
||||
Last step is to add our model geometry to rig instance, so middle+drag its
|
||||
geometry to `input_SET` under `yetiRigDefault` set representing rig instance.
|
||||
Note that its name can differ and is based on your subset name.
|
||||
|
||||

|
||||
|
||||
Save your scene and ready for publishing our new simple Yeti Rig!
|
||||
|
||||
Go to publish **OpenPype → Publish** and run. This will publish rig with its geometry
|
||||
as `.ma` scene, save Yeti node settings and export one frame of Yeti cache from
|
||||
the beginning of your timeline. It will also collect all textures used in Yeti
|
||||
node, copy them to publish folder `resource` directory and set *Image search path*
|
||||
of published node to this location.
|
||||
|
||||
:::note Collect Yeti Cache failure
|
||||
If you encounter **Collect Yeti Cache** failure during collecting phase, and the error is like
|
||||
```fix
|
||||
No object matches name: pgYetiMaya1Shape.cbId
|
||||
```
|
||||
then it is probably caused by scene not being saved before publishing.
|
||||
:::
|
||||
|
||||
### Loading Yeti Rig
|
||||
|
||||
You can load published Yeti Rigs as any other thing in OpenPype - **OpenPype → Load ...**,
|
||||
select you Yeti rig and right+click on it. In context menu you should see
|
||||
**Load Yeti Cache** and **Load Yeti Rig** items (among others). First one will
|
||||
load that one frame cache. The other one will load whole rig.
|
||||
|
||||
Notice that although we put only geometry into `input_SET`, whole hierarchy was
|
||||
pulled inside also. This allows you to store complex scene element along Yeti
|
||||
node.
|
||||
|
||||
:::tip auto-connecting rig mesh to existing one
|
||||
If you select some objects before loading rig it will try to find shapes
|
||||
under selected hierarchies and match them with shapes loaded with rig (published
|
||||
under `input_SET`). This mechanism uses *cbId* attribute on those shapes.
|
||||
If match is found shapes are connected using their `outMesh` and `outMesh`. Thus you can easily connect existing animation to loaded rig.
|
||||
:::
|
||||
145
website/docs/artist_hosts_nuke.md
Normal file
|
|
@ -0,0 +1,145 @@
|
|||
---
|
||||
id: artist_hosts_nuke
|
||||
title: Nuke
|
||||
sidebar_label: Nuke
|
||||
---
|
||||
|
||||
:::important
|
||||
After Nuke starts it will automatically **Apply All Settings** for you. If you are sure the settings are wrong just contact your supervisor and he will set them correctly for you in project database.
|
||||
:::
|
||||
|
||||
:::note
|
||||
The workflows are identical for both. We are supporting versions **`11.0`** and above.
|
||||
:::
|
||||
|
||||
## OpenPype global tools
|
||||
|
||||
- [Set Context](artist_tools.md#set-context)
|
||||
- [Work Files](artist_tools.md#workfiles)
|
||||
- [Create](artist_tools.md#creator)
|
||||
- [Load](artist_tools.md#loader)
|
||||
- [Manage (Inventory)](artist_tools.md#inventory)
|
||||
- [Publish](artist_tools.md#publisher)
|
||||
- [Library Loader](artist_tools.md#library-loader)
|
||||
|
||||
## Nuke specific tools
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
### Set Frame Ranges
|
||||
|
||||
Use this feature in case you are not sure the frame range is correct.
|
||||
|
||||
##### Result
|
||||
|
||||
- setting Frame Range in script settings
|
||||
- setting Frame Range in viewers (timeline)
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
<figure>
|
||||
|
||||

|
||||
|
||||
<figcaption>
|
||||
|
||||
1. limiting to Frame Range without handles
|
||||
2. **Input** handle on start
|
||||
3. **Output** handle on end
|
||||
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
### Set Resolution
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
|
||||
This menu item will set correct resolution format for you defined by your production.
|
||||
|
||||
##### Result
|
||||
|
||||
- creates new item in formats with project name
|
||||
- sets the new format as used
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
### Set Colorspace
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
This menu item will set correct Colorspace definitions for you. All has to be configured by your production (Project coordinator).
|
||||
|
||||
##### Result
|
||||
|
||||
- set Colorspace in your script settings
|
||||
- set preview LUT to your viewers
|
||||
- set correct colorspace to all discovered Read nodes (following expression set in settings)
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
### Apply All Settings
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
It is usually enough if you once per while use this option just to make yourself sure the workfile is having set correct properties.
|
||||
|
||||
##### Result
|
||||
|
||||
- set Frame Ranges
|
||||
- set Colorspace
|
||||
- set Resolution
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
### Build Workfile
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
This tool will append all available subsets into an actual node graph. It will look into database and get all last [versions](artist_concepts.md#version) of available [subsets](artist_concepts.md#subset).
|
||||
|
||||
|
||||
##### Result
|
||||
|
||||
- adds all last versions of subsets (rendered image sequences) as read nodes
|
||||
- adds publishable write node as `renderMain` subset
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
284
website/docs/artist_hosts_nukestudio.md
Normal file
|
|
@ -0,0 +1,284 @@
|
|||
---
|
||||
id: artist_hosts_nukestudio
|
||||
title: Hiero
|
||||
sidebar_label: Hiero / Nuke Studio
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
:::note
|
||||
All the information also applies to **_Nuke Studio_**, but for simplicity we only refer to Hiero. The workflows are identical for both. We are supporting versions **`11.0`** and above.
|
||||
:::
|
||||
|
||||
|
||||
## Hiero specific tools
|
||||
|
||||
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
### Create Default Tags
|
||||
|
||||
This tool will recreate all necessary OpenPype tags needed for successful publishing. It is automatically ran at start of the Hiero. Use this tool to manually re-create all the tags if you accidentaly delete them, or you want to reset them to default values.
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
#### Result
|
||||
|
||||
- Will create tags in Tags bin in case there were none
|
||||
- Will set all tags to default values if they have been altered
|
||||
|
||||
## Publishing Shots
|
||||
|
||||
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
With OpenPype, you can use Hiero as a starting point for creating project hierarchy in avalon and ftrack database (episodes, sequences, shots, folders etc.), publishing plates, reference quicktimes, audio and various soft effects that will be evailable later on for compositors and 3D artist to use.
|
||||
|
||||
There are two ways to `Publish` data and create shots in database from Hiero. Use either context menu on right clicking selected clips or go to top `menu > OpenPype > Publish`.
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Keep in mind that the publishing currently works on selected shots
|
||||
|
||||
Shot names for all the related plates that you want to publish (subsets) has to be the same to be correctly paired together (as it is shown in image).
|
||||
Note the layer **review** which contains `plateMainReview`.
|
||||
This media is just h264, 1920x1080 video for that will be used as preview of the actual `plateMain` subset and will be uploaded to Ftrack. We explain how to work with review tag in [**Reviewing**](#reviewing).
|
||||
|
||||
|
||||
:::important
|
||||
To to successfuly publish a shot from Hiero:
|
||||
1. At least one clip of your shot must be tagged with `Hierarchy`, `subset` and `handleStart/End`.
|
||||
2. Your source media must be pre-cut to correct length (including handles)
|
||||
:::
|
||||
|
||||
### Tagging
|
||||
|
||||
|
||||
OpenPype's custom tags are used for defining shot parameters and to define which clips and how they are going to be published.
|
||||
|
||||
If you want to add any properties to your clips you'll need to adjust values on the given tag and then drag it onto the clip.
|
||||
|
||||
|
||||
<figure>
|
||||
|
||||

|
||||
|
||||
<figcaption>
|
||||
|
||||
1. double click on preferable tag and drag&drop it to selected clip(s)
|
||||
2. Basic set of tags on clip (usually subset: plateMain)
|
||||
3. Additionally select clip and edit its parameters
|
||||
4. Edit parameters here but do not touch `family`
|
||||
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
:::important
|
||||
Only clips with `subset` will be directly processed for publishing.
|
||||
:::
|
||||
|
||||
### Custom Tags Details
|
||||
|
||||
#### Asset related
|
||||
| Icon | Description | Editable | Options |
|
||||
| ------------------- | ---------------------------------------------------------------------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------- |
|
||||
| ![Hierarchy][hi] | Define parent hierarchy of the shot. Usually combined with one of subset tags. | root, folder, sequence, episode, shot | example: {sequence} = name of Hiero sequence or overwrite by any text without `-` or `_` |
|
||||
| ![Frame Start][fst] | Set start frame of the shot. Using `"source"` will keep original frame numbers. | number | int `number` or `"source"` |
|
||||
|
||||
|
||||
#### Subsets
|
||||
|
||||
| Icon | Description | Editable | Options |
|
||||
| ------------------ | ------------------------------------------------------------------------------ | -------- | --------------------------------- |
|
||||
| ![Review][rew] | Choose which track holds review quicktime for the given shot. | track | `"review"` or other track name |
|
||||
| ![Plate Main][pmn] | Main plate subset identifier | subset | `"main"` or other |
|
||||
| ![Plate FG][pfg] | Foreground plate subset identifier (comped over the main plate) | subset | `"Fg##"` or other |
|
||||
| ![Plate BG][pbg] | Background plate subset identifier (comped under the main plate) | subset | `"Bg##"` or other |
|
||||
| ![Plate Ref][ref] | Reference plate subset identifier | subset | `"Ref"` or other |
|
||||
|
||||
#### Subset's attributes
|
||||
|
||||
| Icon | Description | Editable | Options |
|
||||
| ------------------ | --------------------------------------------------------------------------------- | ------------------- | ----------------------------- |
|
||||
| ![Resolution][rsl] | Use source resolution instead of sequence settings. | none | |
|
||||
| ![Retiming][rtm] | Publish retime metadata to shot if retime or time-warp found on clip | marginIn, marginOut | int `number` frame cushioning |
|
||||
| ![Lens][lns] | Specify lens focal length metadata (work in progress) | focalLengthMm | int `number` |
|
||||
|
||||
#### Handles
|
||||
|
||||
| Icon | Description | Editable | Options |
|
||||
| --------------------- | ---------------------------------------------------------------------------- | -------- | -------------------------- |
|
||||
| ![Handles Start][ahs] | Handles at the start of the clip/shot | value | change to any int `number` |
|
||||
| ![Handles End][ahe] | Handles at the end of a clip/shot | value | change to any int `number` |
|
||||
|
||||
[hi]: assets/nks_icons/hierarchy.png
|
||||
|
||||
[ahs]: assets/nks_icons/3_add_handles_start.png
|
||||
|
||||
[ahe]: assets/nks_icons/1_add_handles_end.png
|
||||
|
||||
[rsl]: assets/nks_icons/resolution.png
|
||||
|
||||
[rtm]: assets/nks_icons/retiming.png
|
||||
|
||||
[rew]: assets/nks_icons/review.png
|
||||
|
||||
[pmn]: assets/nks_icons/z_layer_main.png
|
||||
|
||||
[pfg]: assets/nks_icons/z_layer_fg.png
|
||||
|
||||
[pbg]: assets/nks_icons/z_layer_bg.png
|
||||
|
||||
[lns]: assets/nks_icons/lense1.png
|
||||
|
||||
[fst]: assets/nks_icons/frame_start.png
|
||||
|
||||
[ref]: assets/nks_icons/reference.png
|
||||
|
||||
### Handles
|
||||
|
||||
OpenPype requires handle information in shot metadata even if they are set to 0.
|
||||
For this you need to add handles tags to the main clip (Should be the one with Hierarchy tag).
|
||||
This way we are defining a shot property. In case you wish to have different
|
||||
handles on other subsets (e.g. when plateBG is longer than plateFG) you can add handle tags with different value to this longer plate.
|
||||
|
||||
If you wish to have different handles length (say 100) than one of the default tags, simply drag `start: add 10 frames` to your clip
|
||||
and then go to clips tags, find the tag, then replace 10 for 100 in name and also change value to 100.
|
||||
This is also explained following tutorial [`Extending premade handles tags`](#extending-premade-handles-tags)
|
||||
|
||||
:::caution
|
||||
Even if you don't need any handles you have to add `start: add 0 frames` and `end: add 0 frames` tags to the clip with Hierarchy tag.
|
||||
:::
|
||||
|
||||
### Retiming
|
||||
|
||||
OpenPype is also able to publish retiming parameters into the database.
|
||||
Any clip with **editorial**/**retime** or **TimeWarp** soft effect has to be tagged with `Retiming` tag, if you want this information preserved during publishing.
|
||||
|
||||
Any animation on **TimeWarp** is also preserved and reapplied in _Nuke_.
|
||||
|
||||
You can only combine **retime** and with a single **Timewarp**.
|
||||
|
||||
### Reviewing
|
||||
|
||||
There are two ways to publish reviewable **h264 mov** into OpenPype (and Ftrack).
|
||||
|
||||
<Tabs
|
||||
defaultValue="reviewtag"
|
||||
values={[
|
||||
{label: 'Review Tag', value: 'reviewtag'},
|
||||
{label: 'Sidecar File', value: 'sidecar'},
|
||||
]}>
|
||||
|
||||
<TabItem value="reviewtag">
|
||||
|
||||
|
||||
|
||||
The first one uses the Review Tag pointing to the track that holds the reviewable quicktimes for plates.
|
||||
|
||||
This tag metadata has `track` key inside that points to `review` track by default. If you drop this tag onto any publishable clip on the timeline you're telling OpenPype "you will find quicktime version of this plate on `review` track (clips must have the same name)"
|
||||
|
||||
In the image on the right we dropped it to **plateMain** clip. Then we renamed the layer tha hold reviewable quicktime called `plateMainReview`. You can see that the clip names are the same.
|
||||
|
||||
|
||||
|
||||
<figure>
|
||||
|
||||

|
||||
|
||||
<figcaption>
|
||||
|
||||
1. `-review` suffix is added to publishing item label if any reviewable file is found
|
||||
2. `plateMain` clip is holding the Review tag
|
||||
3. layer name is `review` as it is used as default in _Review_ Tag in _track_
|
||||
4. name of clip is the same across all subsets
|
||||
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="sidecar">
|
||||
|
||||
Second way would be to add the **h264 mov 1920x1080** into the same folder
|
||||
as image sequence. The name of the file has to be the same as image sequence.
|
||||
Publisher will pick this file up and add it to the files list during collecting.
|
||||
This will also add `"- review"` to instance label in **Publish**.
|
||||
|
||||
Example:
|
||||
|
||||
- img seq: `image_sequence_name.0001.exr`
|
||||
- mov: `image_sequence_name.mov`
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
--------------
|
||||
|
||||
|
||||
### LUT Workflow
|
||||
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
It is possible to publish Hiero soft effects for compositors to use later on. You can add the effect to a particular clip or to whole layer as shows on the picture. All clips
|
||||
below the `Video 6` layer (green arrow) will be published with the **LUT** subset which combines all the colour corrections from he soft effects. Any clips above the `Video 6` layer will have no **LUT** published with them.
|
||||
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Any external Lut files used in the soft effects will be copied over to `resources` of the published subset folder `lutPlateMain` (in our example).
|
||||
|
||||
:::note
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
You cannot currently publish soft effects on their own because at the moment we only support soft effects as a part of other subset publishing. Image is demonstrating successful publishing.
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
:::
|
||||
|
||||
## Tutorials
|
||||
|
||||
|
||||
### Basic publishing with soft effects
|
||||
|
||||
<iframe src="https://drive.google.com/file/d/1-BN6ia9ic9om69mq3T4jiwZnbrBGdyNi/preview"></iframe>
|
||||
|
||||
|
||||
### Extending premade handles tags
|
||||
|
||||
<iframe src="https://drive.google.com/file/d/1-BexenWWmSURA-QFgxkoZtyxMEhZHOLr/preview"></iframe>
|
||||
107
website/docs/artist_hosts_photoshop.md
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
---
|
||||
id: artist_hosts_photoshop
|
||||
title: Photoshop
|
||||
sidebar_label: Photoshop
|
||||
---
|
||||
|
||||
## Available Tools
|
||||
|
||||
- [Work Files](artist_tools.md#workfiles)
|
||||
- [Create](artist_tools.md#creator)
|
||||
- [Load](artist_tools.md#loader)
|
||||
- [Publish](artist_tools.md#publisher)
|
||||
- [Manage](artist_tools.md#inventory)
|
||||
|
||||
## Setup
|
||||
|
||||
To install the extension, download, install [Anastasyi's Extention Manager](https://install.anastasiy.com/). Open Anastasyi's Extension Manager and select Photoshop in menu. Then go to `{path to pype}/repos/avalon-core/avalon/photoshop/extension.zxp`. Drag extension.zxp and drop it to Anastasyi's Extension Manager. The extension will install itself.
|
||||
|
||||
## Usage
|
||||
|
||||
When you launch Photoshop you will be met with the Workfiles app. If dont have any previous workfiles, you can just close this window.
|
||||
|
||||
In Photoshop you can find the tools in the `OpenPype` extension:
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
You can show the extension panel by going to `Window` > `Extensions` > `OpenPype`.
|
||||
|
||||
### Create
|
||||
|
||||
When you have created an image you want to publish, you will need to create special groups or tag existing groups. To do this open the `Creator` through the extensions `Create` button.
|
||||
|
||||

|
||||
|
||||
With the `Creator` you have a variety of options to create:
|
||||
|
||||
- Check `Use selection` (A dialog will ask whether you want to create one image per selected layer).
|
||||
- Yes.
|
||||
- No selection.
|
||||
- This will create a single group named after the `Subset` in the `Creator`.
|
||||
- Single selected layer.
|
||||
- The selected layer will be grouped under a single group named after the selected layer.
|
||||
- Single selected group.
|
||||
- The selected group will be tagged for publishing.
|
||||
- Multiple selected items.
|
||||
- Each selected group will be tagged for publishing and each layer will be grouped individually.
|
||||
- No.
|
||||
- All selected layers will be grouped under a single group named after the `Subset` in the `Creator`.
|
||||
- Uncheck `Use selection`.
|
||||
- This will create a single group named after the `Subset` in the `Creator`.
|
||||
|
||||
### Publish
|
||||
|
||||
When you are ready to share some work, you will need to publish. This is done by opening the `Pyblish` through the extensions `Publish` button.
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
This tool will run through checks to make sure the contents you are publishing is correct. Hit the "Play" button to start publishing.
|
||||
|
||||
You may encounter issues with publishing which will be indicated with red squares. If these issues are within the validation section, then you can fix the issue. If there are issues outside of validation section, please let the OpenPype team know.
|
||||
|
||||
#### Repair Validation Issues
|
||||
|
||||
All validators will give some description about what the issue is. You can inspect this by going into the validator through the arrow:
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
You can expand the errors by clicking on them for more details:
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
Some validator have repair actions, which will fix the issue. If you can identify validators with actions by the circle icon with an "A":
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
To access the actions, you right click on the validator. If an action runs successfully, the actions icon will turn green. Once all issues are fixed, you can just hit the "Refresh" button and try to publish again.
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
### Load
|
||||
|
||||
When you want to load existing published work, you can load in smart layers through the `Loader`. You can reach the `Loader` through the extension's `Load` button.
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
The supported families for Photoshop are:
|
||||
|
||||
- `image`
|
||||
|
||||
To load an image, right-click on the subset you want and choose a representation:
|
||||
|
||||

|
||||
|
||||
### Manage
|
||||
|
||||
Now that we have some images loaded, we can manage which version is loaded. This is done through the `Scene Inventory`. You can reach it through the extension's `Manage` button.
|
||||
|
||||
:::note
|
||||
Loaded images has to stay as smart layers in order to be updated. If you rasterize the layer, you cannot update it to a different version.
|
||||
:::
|
||||
|
||||

|
||||
|
||||
You can switch to a previous version of the image or update to the latest.
|
||||
|
||||

|
||||

|
||||
40
website/docs/artist_hosts_unreal.md
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
id: artist_hosts_unreal
|
||||
title: Unreal
|
||||
sidebar_label: Unreal
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
OpenPype supports Unreal in similar ways as in other DCCs Yet there are few specific you need to be aware of.
|
||||
|
||||
### Project naming
|
||||
|
||||
Unreal doesn't support project names starting with non-alphabetic character. So names like `123_myProject` are
|
||||
invalid. If OpenPype detects such name it automatically prepends letter **P** to make it valid name, so `123_myProject` will become `P123_myProject`. There is also soft-limit on project name length to be shorter then 20 characters. Longer names will issue warning in Unreal Editor that there might be possible side effects.
|
||||
|
||||
## OpenPype global tools
|
||||
|
||||
OpenPype global tools can be found in *Window* main menu:
|
||||
|
||||

|
||||
|
||||
- [Create](artist_tools.md#creator)
|
||||
- [Load](artist_tools.md#loader)
|
||||
- [Manage (Inventory)](artist_tools.md#inventory)
|
||||
- [Publish](artist_tools.md#publisher)
|
||||
- [Library Loader](artist_tools.md#library-loader)
|
||||
|
||||
## Static Mesh
|
||||
|
||||
### Loading
|
||||
|
||||
To import Static Mesh model, just choose **OpenPype → Load ...** and select your mesh. Static meshes are transfered as FBX files as specified in [Unreal Engine 4 Static Mesh Pipeline](https://docs.unrealengine.com/en-US/Engine/Content/Importing/FBX/StaticMeshes/index.html). This action will create new folder with subset name (`unrealStaticMeshMain_CON` for example) and put all data into it. Inside, you can find:
|
||||
|
||||

|
||||
|
||||
In this case there is **lambert1**, material pulled from Maya when this static mesh was published, **unrealStaticMeshCube** is the geometry itself, **unrealStaticMeshCube_CON** is a *AssetContainer* type and is there to mark this directory as Avalon Container (to track changes) and to hold OpenPype metadata.
|
||||
|
||||
### Publishing
|
||||
|
||||
Publishing of Static Mesh works in similar ways. Select your mesh in *Content Browser* and **OpenPype → Create ...**. This will create folder named by subset you've choosen - for example **unrealStaticMeshDefault_INS**. It this folder is that mesh and *Avalon Publish Instance* asset marking this folder as publishable instance and holding important metadata on it. If you want to publish this instance, go **OpenPype → Publish ...**
|
||||
184
website/docs/artist_publish.md
Normal file
|
|
@ -0,0 +1,184 @@
|
|||
---
|
||||
id: artist_publish
|
||||
title: Publishing
|
||||
sidebar_label: 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 don’t 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 don’t 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](#model) | Cleaned geo without materials | main, proxy, broken |
|
||||
| [Look](#look) | Package of shaders, assignments and textures | main, wet, dirty |
|
||||
| [Rig](#rig) | Characters or props with animation controls | main, deform, sim |
|
||||
| [Assembly](#assembly) | A complex model made from multiple other models. | main, deform, sim |
|
||||
| [Layout](#layout) | Simple representation of the environment | main, |
|
||||
| [Setdress](#setdress) | Environment containing only referenced assets | main, |
|
||||
| [Camera](#camera) | May contain trackers or proxy geo | main, tracked, anim |
|
||||
| [Animation](#animation) | Animation exported from a rig. | characterA, vehicleB |
|
||||
| [Cache](#cache) | Arbitrary animated geometry or fx cache | rest, ROM , pose01 |
|
||||
| MayaAscii | Maya publishes that don't fit other categories | |
|
||||
| [Render](#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 | main |
|
||||
| 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.pallette | | |
|
||||
|
||||
|
||||
|
||||
### 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
|
||||
414
website/docs/artist_tools.md
Normal file
|
|
@ -0,0 +1,414 @@
|
|||
---
|
||||
id: artist_tools
|
||||
title: Tools
|
||||
sidebar_label: Tools
|
||||
---
|
||||
|
||||
## Set Context
|
||||
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
Any time your host app is open in defined context it can be changed to different hierarchy, asset or task within a project. This will allow you to change your opened session to any other asset, shot and tasks within the same project. This is useful particularly in cases where your host takes long time to start.
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
:::note
|
||||
|
||||
Notice that the window doesn't close after hitting `Accept` and confirming the change of context. This behaviour let's you keep the window open and change the context multiple times in a row.
|
||||
:::
|
||||
|
||||
## Creator
|
||||
|
||||
### Details
|
||||
|
||||
Despite the name, Creator isn't for making new content in your scene, but rather taking what's already in it and creating all the metadata your content needs to be published.
|
||||
|
||||
In Maya this means creating a set with everything you want to publish and assigning custom attributes to it so it get's picked up during publishing stage.
|
||||
|
||||
In Nuke it's either converting an existing write node to a publishable one, or simply creating a write node with all the correct settings and outputs already set.
|
||||
|
||||
### Usage
|
||||
|
||||
1. select what you want to publish from your scenes
|
||||
2. Open *Creator* from OpenPype menu
|
||||
3. Choose what family (data type) you need to export
|
||||
4. Type the name for you export. This name is how others are going to be able to refer to this particular subset when loading it into their scenes. Every assets should have a Main subset, but can have any number of other variants.
|
||||
5. Click on *Create*
|
||||
|
||||
* * *
|
||||
|
||||
## Loader
|
||||
Loader loads published subsets into your current scene or script.
|
||||
|
||||
### Usage
|
||||
1. open *Loader* from OpenPype menu
|
||||
2. select the asset where the subset you want to load is published
|
||||
3. from subset list select the subset you want
|
||||
4. right-click the subset
|
||||
5. from action menu select what you want to do *(load, reference, ...)*
|
||||
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
### Refresh data
|
||||
Data are not auto-refreshed to avoid database issues. To refresh assets or subsets press refresh button.
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
### Load another version
|
||||
Loader by default load last version, but you can of course load another versions. Double-click on the subset in the version column to expose the drop down, choose version you want to load and continue from point 4 of the [Usage](#usage-1).
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
### Filtering
|
||||
|
||||
#### Filter Assets and Subsets by name
|
||||
To filter assets/subsets by name just type name or part of name to filter text input. Only assets/subsets containing the entered string remain.
|
||||
|
||||
- **Assets filtering example** *(it works the same for subsets)*:
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
#### Filter Subsets by Family
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
To filter [subsets](artist_concepts#subset) by their [families](artist_publish#families) you can use families list where you can check families you want to see or uncheck families you are not interested in.
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
### Subset groups
|
||||
Subsets may be grouped which can help to make the subset list more transparent. You can toggle visibility of groups with `Enable Grouping` checkbox.
|
||||
|
||||

|
||||
|
||||
|
||||
#### Add to group or change current group
|
||||
You can set group of selected subsets with shortcut `Ctrl + G`.
|
||||
|
||||

|
||||
|
||||
|
||||
:::warning
|
||||
You'll set the group in Avalon database so your changes will take effect for all users.
|
||||
:::
|
||||
|
||||
Work in progress...
|
||||
|
||||
## Library Loader
|
||||
|
||||
Library loader is extended [loader](#loader) which allows to load published subsets from Library projects. Controls are same but library loader has extra Combo Box which allows you to choose project you want to load from.
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
* * *
|
||||
|
||||
## Publisher
|
||||
|
||||
> Use publish to share your work with others. It collects, validates and exports the data in standardized way.
|
||||
|
||||
### Details
|
||||
|
||||
When you run pyblish, the UI is made of 2 main parts. On the left, you see all the items pyblish will be working with (called instances), and on the right a list of actions that are going to process these items.
|
||||
Even though every task type has some pre-defined settings of what should be collected from the scene and what items will be published by default. You can technically publish any output type from any task type.
|
||||
Each item is passed through multiple plugins, each doing a small piece of work. These are organized into 4 areas and run in sequence.
|
||||
|
||||
### Using Pyblish
|
||||
|
||||
In the best case scenario, you open pyblish from the Avalon menu, press play, wait for it to finish, and you’re done.
|
||||
These are the steps in detail, for cases, where the default settings don’t work for you or you know that the task you’re working on, requires a different treatment.
|
||||
|
||||
#### Collect
|
||||
|
||||
Finds all the important data in the scene and makes it ready for publishing
|
||||
|
||||
#### Validate
|
||||
|
||||
Each validator makes sure your output complies to one particular condition. This could be anything from naming conventions, scene setting, to plugin usage. An item can only be published if all validators pass.
|
||||
|
||||
#### Extract
|
||||
|
||||
Extractor takes the item and saves it to the disk. Usually to temporary location. Each extractor represents one file format and there can be multiple file formats exported for each item.
|
||||
|
||||
#### Integrate
|
||||
|
||||
Integrator takes the extracted files, categorizes and moves them to a correct location on the disk or on the server.
|
||||
|
||||
* * *
|
||||
|
||||
## Inventory
|
||||
|
||||
With Scene Inventory, you can browse, update and change subsets loaded with [Loader](#loader) into your scene or script.
|
||||
|
||||
:::note
|
||||
You should first understand [Key concepts](artist_concepts#) to understand how you can use this tool.
|
||||
:::
|
||||
|
||||
### Details
|
||||
<!-- This part may be in Maya description? -->
|
||||
|
||||
Once a subset is loaded, it turns into a container within a scene. This containerization allows us to have a good overview of everything in the scene, but also makes it possible to change versions, notify user if something is outdated, replace one asset for another, etc.
|
||||
<!-- END HERE -->
|
||||
|
||||
The scene manager has a simple GUI focused on efficiency. You can see everything that has been previously loaded into the scene, how many time it's been loaded, what version and a lot of other information. Loaded assets are grouped by their asset name, subset name and representation. This grouping gives ability to apply changes for all instances of the loaded asset *(e.g. when __tree__ is loaded 20 times you can easily update version for all of them)*.
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
To interact with any container, you need to right click it and you'll see a drop down with possible actions. The key actions for production are already implemented, but more will be added over time.
|
||||
|
||||

|
||||
|
||||
### Usage
|
||||
|
||||
#### Change version
|
||||
You can change versions of loaded subsets with scene inventory tool. Version of loaded assets is colored to red when newer version is available.
|
||||
|
||||
|
||||

|
||||
|
||||
##### Update to the latest version
|
||||
Select containers or subsets you want to update, right-click selection and press `Update to latest`.
|
||||
|
||||
##### Change to specific version
|
||||
Select containers or subsets you want to change, right-click selection, press `Set version`, select from dropdown version you want change to and press `OK` button to confirm.
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
#### Switch Asset
|
||||
It's tool in Scene inventory tool that gives ability to switch asset, subset and representation of loaded assets.
|
||||
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
|
||||
Because loaded asset is in fact representation of version published in asset's subset it is possible to switch each of this part *(representation, version, subset and asset)*, but with limitations. Limitations are obvious as you can imagine when you have loaded `.ma` representation of `modelMain` subset from `car` asset it is not possible to switch subset to `modelHD` and keep same representation if `modelHD` does not have published `.ma` representation. It is possible to switch multiple loaded assets at once that makes this tool very powerful helper if all published assets contain same subsets and representations.
|
||||
|
||||
Switch tool won't let you cross the border of limitations and inform you when you have to specify more if impossible combination occurs *(It is also possible that there will be no possible combination for selected assets)*. Border is colored to red and confirm button is not enabled when specification is required.
|
||||
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
|
||||
|
||||
Possible switches:
|
||||
- switch **representation** (`.ma` to `.abc`, `.exr` to `.dpx`, etc.)
|
||||
- switch **subset** (`modelMain` to `modelHD`, etc.)
|
||||
- `AND` keep same **representation** *(with limitations)*
|
||||
- `AND` switch **representation** *(with limitations)*
|
||||
- switch **asset** (`oak` to `elm`, etc.)
|
||||
- `AND` keep same **subset** and **representation** *(with limitations)*
|
||||
- `AND` keep same **subset** and switch **representation** *(with limitations)*
|
||||
- `AND` switch **subset** and keep same **representation** *(with limitations)*
|
||||
- `AND` switch **subset** and **representation** *(with limitations)*
|
||||
|
||||
We added one more switch layer above subset for LOD (Level Of Depth). That requires to have published subsets with name ending with **"_LOD{number}"** where number represents level (e.g. modelMain_LOD1). Has the same limitations as mentioned above. This is handy when you want to change only subset but keep same LOD or keep same subset but change LOD for multiple assets. This option is hidden if you didn't select subset that have published subset with LODs.
|
||||
|
||||
 <!-- picture needs to be changed -->
|
||||
### Filtering
|
||||
|
||||
#### Filter by name
|
||||
|
||||
There is a search bar on the top for cases when you have a complex scene with many assets and need to find a specific one.
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
#### Filter with Cherry-pick selection
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
To keep only selected subsets right-click selection and press `Cherry-Pick (Hierarchy)` *(Border of subset list change to **orange** color when Cherry-pick filtering is set so you know filter is applied).*
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
To return to original state right-click anywhere in subsets list and press `Back to Full-View`.
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
:::tip
|
||||
You can Cherry-pick from Cherry-picked subsets.
|
||||
:::
|
||||
|
||||
* * *
|
||||
|
||||
## Workfiles
|
||||
|
||||
Save new working scenes or scripts, or open the ones you previously worked on.
|
||||
|
||||
### Details
|
||||
|
||||
Instead of digging through your software native file browser, you can simply open the workfiles app and see all the files for the asset or shot you're currently working with. The app takes care of all the naming and the location of your work files.
|
||||
|
||||
When saving a scene you can also add a comment. It is completely up to you how you use this, however we recommend using it for subversion within your current working version.
|
||||
|
||||
Let's say that the last version of the comp you published was v003 and now you're working on the file prj_sh010_compositing_v004.nk if you want to keep snapshots of your work, but not iterate on the main version because the supervisor is expecting next publish to be v004, you can use the comment to do this, so you can save the file under the name prj_sh010_compositing_v004_001 , prj_sh010_compositing_v004_002. the main version is automatically iterated every time you publish something.
|
||||
|
||||
### Usage
|
||||
|
||||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
#### To open existing file:
|
||||
|
||||
1. Open Workfiles tool from OpenPype menu
|
||||
2. Select file from list - the latest version is the highest *(descendent ordering)*
|
||||
3. Press `Open` button
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
#### To save new workfile
|
||||
1. Open Workfiles tool from OpenPype menu
|
||||
2. Press `Save As` button
|
||||
3. You can add optional comment to the filename, that will be appended at the end
|
||||
4. Press `OK`
|
||||
|
||||
:::note
|
||||
You can manually override the workfile version by unticking next available version and using the version menu to choose your own.
|
||||
:::
|
||||
|
||||
## Look Assigner
|
||||
|
||||
> The Look Manager takes care of assigning published looks to the correct model in the scene.
|
||||
|
||||
### Details
|
||||
|
||||
When a look is published it also stores the information about what shading networks need to be assigned to which models, but it also stores all the render attributes on the mesh necessary for a successful render.
|
||||
|
||||
### Usage
|
||||
|
||||
Look Assigner has GUI is made of two parts. On the left you will see the list of all the available models in the scene and on the right side, all the looks that can be associate with them. To assign a look to a model you just need to:
|
||||
|
||||
1. Click on "load all subsets"
|
||||
2. Choose a subset from the menu on the left
|
||||
3. Right click on a look from the list on the right
|
||||
4. Choose "Assign"
|
||||
|
||||
At this point you should have a model with all it's shaders applied correctly. The tool automatically loads the latest look available.
|
||||
|
||||
|
||||
## Subset Manager
|
||||
|
||||
> Subset Manager lists all items which are meant for publishig and will be published if Publish is triggered
|
||||
|
||||
### Details
|
||||
|
||||
One or more items (instances) could be published any time Publish process is started. Each this publishable
|
||||
item must be created by Creator tool previously. Subset Manager provides easy way how to check which items,
|
||||
and how many, will be published.
|
||||
|
||||
It also provides clean and preferrable way how to remove unwanted item from publishing.
|
||||
|
||||
### Usage
|
||||
|
||||
Subset Manager has GUI is made of two parts. On the left you will see the list of all the available publishable items in the scene and on the right side, details about these items.
|
||||
|
||||
<div class="col col--6 markdown">
|
||||
|
||||

|
||||
</div>
|
||||
|
||||
Any time new item is Created, it will show up here.
|
||||
|
||||
Currently there is only single action, 'Remove instance' which cleans workfile file from publishable item metadata.
|
||||
This might not remove underlying host item, it depends on host and implementation!
|
||||
|
||||
It might also happen that user deletes underlying host item(for example layer in Photoshop) directly in the host, but metadata will stay.
|
||||
This could result in phantom issues during publishing. Use Subset Manager to purge workfile from abandoned items.
|
||||
|
||||
Please check behaviour in host of your choice.
|
||||
23
website/docs/artist_work.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
id: artist_work
|
||||
title: Working on tasks
|
||||
sidebar_label: Working
|
||||
---
|
||||
|
||||
Check the [documentation](https://docusaurus.io) for how to use Docusaurus.
|
||||
|
||||
## Lorem
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus elementum massa eget nulla aliquet sagittis. Proin odio tortor, vulputate ut odio in, ultrices ultricies augue. Cras ornare ultrices lorem malesuada iaculis. Etiam sit amet libero tempor, pulvinar mauris sed, sollicitudin sapien.
|
||||
|
||||
## Mauris In Code
|
||||
|
||||
Mauris vestibulum ullamcorper nibh, ut semper purus pulvinar ut. Donec volutpat orci sit amet mauris malesuada, non pulvinar augue aliquam. Vestibulum ultricies at urna ut suscipit. Morbi iaculis, erat at imperdiet semper, ipsum nulla sodales erat, eget tincidunt justo dui quis justo. Pellentesque dictum bibendum diam at aliquet. Sed pulvinar, dolor quis finibus ornare, eros odio facilisis erat, eu rhoncus nunc dui sed ex. Nunc gravida dui massa, sed ornare arcu tincidunt sit amet. Maecenas efficitur sapien neque, a laoreet libero feugiat ut.
|
||||
|
||||
## Nulla
|
||||
|
||||
Nulla facilisi. Maecenas sodales nec purus eget posuere. Sed sapien quam, pretium a risus in, porttitor dapibus erat. Sed sit amet fringilla ipsum, eget iaculis augue. Integer sollicitudin tortor quis ultricies aliquam. Suspendisse fringilla nunc in tellus cursus, at placerat tellus scelerisque. Sed tempus elit a sollicitudin rhoncus. Nulla facilisi. Morbi nec dolor dolor. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Cras et aliquet lectus. Pellentesque sit amet eros nisi. Quisque ac sapien in sapien congue accumsan. Nullam in posuere ante. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Proin lacinia leo a nibh fringilla pharetra.
|
||||
|
||||
## Orci
|
||||
|
||||
Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Proin venenatis lectus dui, vel ultrices ante bibendum hendrerit. Aenean egestas feugiat dui id hendrerit. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Curabitur in tellus laoreet, eleifend nunc id, viverra leo. Proin vulputate non dolor vel vulputate. Curabitur pretium lobortis felis, sit amet finibus lorem suscipit ut. Sed non mollis risus. Duis sagittis, mi in euismod tincidunt, nunc mauris vestibulum urna, at euismod est elit quis erat. Phasellus accumsan vitae neque eu placerat. In elementum arcu nec tellus imperdiet, eget maximus nulla sodales. Curabitur eu sapien eget nisl sodales fermentum.
|
||||
BIN
website/docs/assets/aftereffects_creator.png
Normal file
|
After Width: | Height: | Size: 15 KiB |
BIN
website/docs/assets/aftereffects_creator_after.png
Normal file
|
After Width: | Height: | Size: 13 KiB |
BIN
website/docs/assets/aftereffects_loader.png
Normal file
|
After Width: | Height: | Size: 68 KiB |
BIN
website/docs/assets/aftereffects_publish.png
Normal file
|
After Width: | Height: | Size: 28 KiB |
BIN
website/docs/assets/ftrack/ftrack-component_open-icon.png
Normal file
|
After Width: | Height: | Size: 4.6 KiB |
BIN
website/docs/assets/ftrack/ftrack-component_open_1-small.png
Normal file
|
After Width: | Height: | Size: 67 KiB |
BIN
website/docs/assets/ftrack/ftrack-component_open_1.png
Normal file
|
After Width: | Height: | Size: 981 KiB |
BIN
website/docs/assets/ftrack/ftrack-create_folders-icon.png
Normal file
|
After Width: | Height: | Size: 5.1 KiB |
|
After Width: | Height: | Size: 5.9 KiB |
BIN
website/docs/assets/ftrack/ftrack-custom_attrib_apps.jpg
Normal file
|
After Width: | Height: | Size: 40 KiB |
BIN
website/docs/assets/ftrack/ftrack-delete_asset-icon.png
Normal file
|
After Width: | Height: | Size: 5 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_1.png
Normal file
|
After Width: | Height: | Size: 6.5 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_2.png
Normal file
|
After Width: | Height: | Size: 11 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_3.png
Normal file
|
After Width: | Height: | Size: 20 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_50.png
Normal file
|
After Width: | Height: | Size: 7.8 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_60.png
Normal file
|
After Width: | Height: | Size: 323 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_71-small.png
Normal file
|
After Width: | Height: | Size: 232 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_71.png
Normal file
|
After Width: | Height: | Size: 966 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_80-small.png
Normal file
|
After Width: | Height: | Size: 38 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_80.png
Normal file
|
After Width: | Height: | Size: 586 KiB |
BIN
website/docs/assets/ftrack/ftrack-login_81.png
Normal file
|
After Width: | Height: | Size: 60 KiB |
BIN
website/docs/assets/ftrack/ftrack-multiple_notes-icon.png
Normal file
|
After Width: | Height: | Size: 5.1 KiB |
BIN
website/docs/assets/ftrack/ftrack-multiple_notes_1-small.png
Normal file
|
After Width: | Height: | Size: 19 KiB |
BIN
website/docs/assets/ftrack/ftrack-multiple_notes_1.png
Normal file
|
After Width: | Height: | Size: 984 KiB |
BIN
website/docs/assets/ftrack/ftrack-prepare_project-icon.png
Normal file
|
After Width: | Height: | Size: 5.7 KiB |
BIN
website/docs/assets/ftrack/ftrack-prepare_project_1-small.png
Normal file
|
After Width: | Height: | Size: 28 KiB |
BIN
website/docs/assets/ftrack/ftrack-prepare_project_1.png
Normal file
|
After Width: | Height: | Size: 984 KiB |
BIN
website/docs/assets/ftrack/ftrack-pype_admin-icon.png
Normal file
|
After Width: | Height: | Size: 6 KiB |
BIN
website/docs/assets/ftrack/ftrack-pype_doctor-icon.png
Normal file
|
After Width: | Height: | Size: 6.2 KiB |
BIN
website/docs/assets/ftrack/ftrack-thumbnail-icon.png
Normal file
|
After Width: | Height: | Size: 6.2 KiB |
BIN
website/docs/assets/harmony_creator.PNG
Normal file
|
After Width: | Height: | Size: 8.2 KiB |
BIN
website/docs/assets/maya-look_dev-look_manager.jpg
Normal file
|
After Width: | Height: | Size: 29 KiB |
BIN
website/docs/assets/maya-look_dev-red_buddha.jpg
Normal file
|
After Width: | Height: | Size: 44 KiB |
BIN
website/docs/assets/maya-model_create_instance.jpg
Normal file
|
After Width: | Height: | Size: 23 KiB |
BIN
website/docs/assets/maya-model_freeze_error_details.jpg
Normal file
|
After Width: | Height: | Size: 36 KiB |
BIN
website/docs/assets/maya-model_hierarchy_example.jpg
Normal file
|
After Width: | Height: | Size: 39 KiB |
BIN
website/docs/assets/maya-model_loading.jpg
Normal file
|
After Width: | Height: | Size: 65 KiB |
BIN
website/docs/assets/maya-model_pre_publish.jpg
Normal file
|
After Width: | Height: | Size: 54 KiB |
BIN
website/docs/assets/maya-model_publish_error.jpg
Normal file
|
After Width: | Height: | Size: 42 KiB |
BIN
website/docs/assets/maya-model_review_setup.jpg
Normal file
|
After Width: | Height: | Size: 65 KiB |
BIN
website/docs/assets/maya-pointcache_loaded.png
Normal file
|
After Width: | Height: | Size: 38 KiB |
BIN
website/docs/assets/maya-pointcache_setup.png
Normal file
|
After Width: | Height: | Size: 49 KiB |
BIN
website/docs/assets/maya-render_publish_detail1.jpg
Normal file
|
After Width: | Height: | Size: 55 KiB |
BIN
website/docs/assets/maya-render_setup.jpg
Normal file
|
After Width: | Height: | Size: 88 KiB |
BIN
website/docs/assets/maya-render_setup_window.jpg
Normal file
|
After Width: | Height: | Size: 8 KiB |
BIN
website/docs/assets/maya-renderglobals.jpg
Normal file
|
After Width: | Height: | Size: 22 KiB |
BIN
website/docs/assets/maya-rig_hierarchy_example.jpg
Normal file
|
After Width: | Height: | Size: 77 KiB |
BIN
website/docs/assets/maya-rig_model_setup.jpg
Normal file
|
After Width: | Height: | Size: 31 KiB |
BIN
website/docs/assets/maya-shortcut_buttons.jpg
Normal file
|
After Width: | Height: | Size: 37 KiB |
BIN
website/docs/assets/maya-yeti_basic_setup.jpg
Normal file
|
After Width: | Height: | Size: 56 KiB |
BIN
website/docs/assets/maya-yeti_basic_setup_outline.jpg
Normal file
|
After Width: | Height: | Size: 50 KiB |
BIN
website/docs/assets/maya-yeti_cache_attributes.jpg
Normal file
|
After Width: | Height: | Size: 15 KiB |
BIN
website/docs/assets/maya-yeti_rig.jpg
Normal file
|
After Width: | Height: | Size: 58 KiB |
BIN
website/docs/assets/nks_icons/1_add_handles_end.png
Normal file
|
After Width: | Height: | Size: 5.9 KiB |
BIN
website/docs/assets/nks_icons/2_add_handles.png
Normal file
|
After Width: | Height: | Size: 6.1 KiB |
BIN
website/docs/assets/nks_icons/3_add_handles_start.png
Normal file
|
After Width: | Height: | Size: 5.7 KiB |
BIN
website/docs/assets/nks_icons/frame_start.png
Normal file
|
After Width: | Height: | Size: 2.1 KiB |
BIN
website/docs/assets/nks_icons/hierarchy.png
Normal file
|
After Width: | Height: | Size: 5.6 KiB |
BIN
website/docs/assets/nks_icons/lense.png
Normal file
|
After Width: | Height: | Size: 12 KiB |
BIN
website/docs/assets/nks_icons/lense1.png
Normal file
|
After Width: | Height: | Size: 13 KiB |
BIN
website/docs/assets/nks_icons/reference.png
Normal file
|
After Width: | Height: | Size: 4.8 KiB |