Frame13/ayon-core
1
0
Fork 1
mirror of https://github.com/ynput/ayon-core.git synced 2025-12-24 21:04:40 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #4039 from rjq/documentation-updates

Browse source
This commit is contained in:
Milan Kolar 2022-10-28 08:53:29 +02:00 • committed by GitHub
commit dbf5052e2c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 45 additions and 44 deletions
Download patch file Download diff file Expand all files Collapse all files

31
website/docs/admin_settings.md
View file

@ -9,9 +9,9 @@ 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 Admin -> Studio Settings.
**Settings** GUI can be started from the tray menu *Admin -> Studio Settings*.
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
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](admin_settings_local.md) section in the artist documentation.
## Categories
@ -31,32 +31,32 @@ You'll find that settings are split into categories:
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.
availability.
### Project
Project tab contains most of OpenPype settings and all of them can be configured and overridden 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.
Project tab contains most of OpenPype settings and all of them can be configured and overridden 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 overridden on multiple levels.
Most of the individual settings can be set and overridden 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.
When you first open settings, all of the values and categories will be marked with either
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
The grey colouring signifies 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
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
@ -76,10 +76,13 @@ You can also reset any settings to OpenPype default by doing `right click` and `
Many settings are useful 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.
The process of settting project overrides is similar to setting the Studio defaults. The key difference is to select a particular project you want to be configure. Those projects can be found on the left hand side of the Project Settings tab.
In the image below you can see all three overrides at the same time.
1. Deadline has **no changes to the OpenPype defaults** at all — **grey** colour of left bar.
2. Maya has **studio-wide defaults configured**, which are inherited in the particular project - **green** colour of left bar.
3. Nuke contains **project specific overrides** - **orange** colour of left bar.
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.
![colours_01](assets/settings/colours_02.png)
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.

58
website/docs/admin_settings_system.md
View file

@ -19,15 +19,16 @@ Settings applicable to the full studio.
**`Admin Password`** - After setting admin password, normal user won't have access to OpenPype settings
and Project Manager GUI. Please keep in mind that this is a studio wide password and it is meant purely
as a naive barier to prevent artists from accidental setting changes.
as a simple barrier to prevent artists from accidental setting changes.
**`Environment`** - Globally applied environment variables that will be appended to any OpenPype process in the studio.
**`Disk mapping`** - Platform dependent configuration for mapping of virtual disk(s) on an artist's OpenPype machines before OP starts up.
**`Disk mapping`** - Platform dependent configuration for mapping of virtual disk(s) on an artist's OpenPype machines before OP starts up.
Uses `subst` command, if configured volume character in `Destination` field already exists, no re-mapping is done for that character(volume).
### FFmpeg and OpenImageIO tools
We bundle FFmpeg tools for all platforms and OpenImageIO tools for Windows and Linux. By default are used bundled tools but it is possible to set environment variables `OPENPYPE_FFMPEG_PATHS` and `OPENPYPE_OIIO_PATHS` in system settings environments to look for them in different directory e.g. for different linux distributions or to add oiio support for MacOs. Values of both environment variables should lead to directory where tool executables are located (multiple paths are supported).
We bundle FFmpeg tools for all platforms and OpenImageIO tools for Windows and Linux. By default, bundled tools are used, but it is possible to set environment variables `OPENPYPE_FFMPEG_PATHS` and `OPENPYPE_OIIO_PATHS` in system settings environments to look for them in different directory.
For example—when using different Linux distributions in a facility that do not have a consistent install location or to add OIIO support for MacOS. Values of both environment variables should lead to directory where tool executables are located instead of an explicit path to the binary executable. Using multiple paths are supported, separated by colons, is supported—e.g. */usr/local/bin:$HOME/.local/bin*
### OpenPype deployment control
**`Versions Repository`** - Location where automatic update mechanism searches for zip files with
@ -41,11 +42,11 @@ For more information about Production and Staging go to [Distribute](admin_distr
**Production version** and **Staging version** fields will define which version will be used in studio. Filling explicit version will force new OpenPype processes to use it. That gives more control over studio deployment especially when some workstations don't have access to version repository (e.g. remote users). It can be also used to downgrade studio version when newer version have production breaking bug.
When fields are not filled the latest version in versions repository is used as studio version. That makes updating easier as it is not needed to modify settings but workstations without access to versions repository can't find out which OpenPype version should be used.
When fields are not filled, the latest version in the versions repository is used as studio version. That makes updating easier as it is not needed to modify settings, though workstations without access to versions repository can't find out which OpenPype version should be used.
If version repository is not set or is not accessible for workstation the latest available version on workstation is used or version inside build.
If **`Version Repository`** is not set or is not accessible for workstation, the latest available version on workstation is used or the version inside build.
**`Version check interval`** - OpenPype tray application check if currently used OpenPype version is up to date with production/staging version. It is possible to modify how often the validation is triggered in minutes. It is possible to set the interval to `0`. That will turn off version validations but it is not recommend.
**`Version check interval`** - The OpenPype tray application has the ability to check if its version currently in use is up to date with the Studio's production/staging version. It is possible to modify how often the validation is triggered in minutes. The interval can also be set to `0`, which will turn off version validations, but it is not recommend.
A dialog asking for restart is shown when OpenPype tray application detect that different version should be used.
![general_settings](assets/settings/settings_system_version_update.png)
@ -53,15 +54,13 @@ A dialog asking for restart is shown when OpenPype tray application detect that
## 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.
Configuration of OpenPype's various modules. Some can only be toggled on or off, while 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.
**`Avalon Mongo Timeout`** - This might need to be changed 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.
**`Thumbnail Storage Location`** - simple disk storage path where all thumbnails will be stored.
### Ftrack
@ -76,8 +75,7 @@ Additional Action paths
**`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.
**`Custom Attributes`** - Write and Read permissions for all OpenPype required ftrack custom attributes. Each values needs to be name of an ftrack role.
### Sync Server
@ -89,15 +87,15 @@ Disable/Enable Standalone Publisher option
### Deadline
**`Deadline Rest URL`** - URL to deadline webservice that. This URL must be reachable from every
**`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
**`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.
**`templates mapping`** - you can customize Muster templates to match your existing setup here.
### Clockify
@ -107,36 +105,36 @@ workstation that should be submitting render jobs to muster via OpenPype.
**`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
**`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
### 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. In OpenPype context each application that is integrated is
In this section you can manage what Applications are available to your studio, locations of their
executables, and their additional environments. In OpenPype context, each application that is integrated is
also called a `Host` and these two terms might be used interchangeably in the documentation.
Each Host is made of two levels.
Each Host 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 versions of the given application. For example any extra Maya scripts that are not
version dependent, 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.
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.
![settings_applications](assets/settings/applications_01.png)
### Environments
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.
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:
@ -151,7 +149,7 @@ For instance:
### Adding versions
It is possible to add new version for any supported application. There are two ways of doing it.
It is possible to add new version for any supported application. There are two ways of doing it.
1. **Add new executable** to an existing application version. This is a good way if you have multiple fully compatible versions of your DCC across the studio. Nuke is a typical example where multiple artists might have different `v#` releases of the same minor Nuke release. For example `12.2v3` and `12.3v6`. When you add both to `12.2` Nuke executables they will be treated the same in OpenPype and the system will automatically pick the first that it finds on an artist machine when launching. Their order is also the order of their priority when choosing which version to run if multiple are present.
![settings_applications](assets/settings/settings_addapplication.gif)
@ -161,16 +159,16 @@ It is possible to add new version for any supported application. There are two w
## 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.
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.
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 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.
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.
![tools](assets/settings/tools_01.png)
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.