mirror of
https://github.com/ynput/ayon-core.git
synced 2025-12-24 21:04:40 +01:00
Fix common typos in openpype/website
This commit is contained in:
Roy Nieterau
parent
c6eb14ab62
commit
2e2d8009ae
41 changed files with 88 additions and 88 deletions
|
|
@ -32,7 +32,7 @@ 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
|
||||
Every time 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
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ paste to any terminal of your choice
|
|||
<div class="col col--6 markdown">
|
||||
|
||||
|
||||
As it is shown in bellow picture you have to go to Fusion Tab and then in Fusion menu find Fusion Settings. Go to Fusion/Script and find Default Python Version and swith to Python 3.6
|
||||
As it is shown in below picture you have to go to Fusion Tab and then in Fusion menu find Fusion Settings. Go to Fusion/Script and find Default Python Version and switch to Python 3.6
|
||||
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ import Tabs from '@theme/Tabs';
|
|||
import TabItem from '@theme/TabItem';
|
||||
|
||||
## Subset name templates
|
||||
Definition of possibile subset name templates in TVPaint integration.
|
||||
Definition of possible subset name templates in TVPaint integration.
|
||||
|
||||
### [Render Layer](artist_hosts_tvpaint#render-layer)
|
||||
Render layer has additional keys for subset name template. It is possible to use **render_layer** and **render_pass**.
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ pype launch --app python --project my_project --asset my_asset --task my_task
|
|||
|
||||
| Argument | Description |
|
||||
| --- | --- |
|
||||
| `--debug` | print more verbose infomation |
|
||||
| `--debug` | print more verbose information |
|
||||
|
||||
```shell
|
||||
pype publish <PATH_TO_JSON>
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ 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
|
||||
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
|
||||
|
|
@ -42,7 +42,7 @@ after the production started.
|
|||
|
||||
## Understanding Overrides
|
||||
|
||||
Most of the individual settings can be set and overriden 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
|
||||
|
|
@ -72,7 +72,7 @@ You can also reset any settings to OpenPype default by doing `right click` and `
|
|||
|
||||
### Project Overrides
|
||||
|
||||
Many settings are usefull to be adjusted on a per-project basis. To identify project
|
||||
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
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ We have a few required anatomy templates for OpenPype to work properly, however
|
|||
| `version` | Version number |
|
||||
| `subset` | Subset name |
|
||||
| `family` | Main family name |
|
||||
| `ext` | File extention |
|
||||
| `ext` | File extension |
|
||||
| `representation` | Representation name |
|
||||
| `frame` | Frame number for sequence files. |
|
||||
| `output` | |
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ also called a `Host` and these two terms might be used interchangeably in the do
|
|||
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 dependant, can be added to `Maya` environment here.
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ import TabItem from '@theme/TabItem';
|
|||
Running Openpype webserver is needed as a backend part for Web publishing.
|
||||
Any OS supported by Openpype could be used as a host server.
|
||||
|
||||
Webpublishing consists of two sides, Front end (FE) and Openpype backend. This documenation is only targeted on OP side.
|
||||
Webpublishing consists of two sides, Front end (FE) and Openpype backend. This documentation is only targeted on OP side.
|
||||
|
||||
It is expected that FE and OP will live on two separate servers, FE publicly available, OP safely in customer network.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ In our pipeline all the main entities the project is made from are internally co
|
|||
|
||||
### 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.
|
||||
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 usable 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
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ 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.
|
||||
**openpype_console.exe** in useful for debugging and error reporting. It opens console window where all the necessary information will appear during user's work.
|
||||
|
||||
|
||||
<Tabs
|
||||
|
|
@ -76,7 +76,7 @@ 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.
|
||||
If you're connected to your studio, OpenPype will check for, and install updates automatically every time 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
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ sidebar_label: AfterEffects
|
|||
|
||||
## 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`.
|
||||
To install the extension, download, install [Anastasyi's Extension 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.
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ Because of current rendering limitations, it is expected that only single compos
|
|||
After Creator is successfully triggered on selected composition, it will be marked with an icon and its color
|
||||
will be changed.
|
||||
|
||||
|
||||
|
||||
|
||||
### Publish
|
||||
|
||||
|
|
@ -109,5 +109,5 @@ You can switch to a previous version of the image or update to the latest.
|
|||
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
|
||||
Removing composition directly in the AE would result to worfile contain phantom metadata which could result in
|
||||
errors during publishing!
|
||||
|
|
@ -31,7 +31,7 @@ All the information also applies to **_Nuke Studio_**(NKS), but for simplicity w
|
|||
|
||||
### Create Default Tags
|
||||
|
||||
This tool will recreate all necessary OpenPype tags needed for successful publishing. It is automatically ran at start of the Hiero/NKS. Use this tool to manually re-create all the tags if you accidentaly delete them, or you want to reset them to default values.
|
||||
This tool will recreate all necessary OpenPype tags needed for successful publishing. It is automatically ran at start of the Hiero/NKS. Use this tool to manually re-create all the tags if you accidentally delete them, or you want to reset them to default values.
|
||||
|
||||
#### Result
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ This tool will set any defined colorspace definition from OpenPype `Settings / P
|
|||
|
||||
#### Result
|
||||
|
||||
- Define corect color management settings on project
|
||||
- Define correct color management settings on project
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
|
@ -95,8 +95,8 @@ With OpenPype, you can use Hiero/NKS as a starting point for creating a project'
|
|||
<br></br><br></br>
|
||||
|
||||
### Preparing timeline for conversion to instances
|
||||
Because we don't support on-fly data conversion so in case of working with raw camera sources or some other formats which need to be converted for 2D/3D work. We suggest to convert those before and reconform the timeline. Before any clips in timeline could be converted to publishable instances we recomend following.
|
||||
1. Merge all tracks which supposed to be one and they are multipy only because of editor's style
|
||||
Because we don't support on-fly data conversion so in case of working with raw camera sources or some other formats which need to be converted for 2D/3D work. We suggest to convert those before and reconform the timeline. Before any clips in timeline could be converted to publishable instances we recommend following.
|
||||
1. Merge all tracks which supposed to be one and they are multiply only because of editor's style
|
||||
2. Rename tracks to follow basic structure > if only one layer then `main` in case of multiple layer (elements) for one shot then `main`, and other elements for example: `bg`, `greenscreen`, `fg01`, `fg02`, `display01`, etc. please avoid using [-/_.,%&*] or spaces. These names will be later used in *subset* name creation as `{family}{trackName}` so for example **plateMain** or **plateFg01**
|
||||
3. Define correct `Set Media Color Transform` at all clips as those will be also published to metadata and used for later loading with correct color transformation.
|
||||
4. Reviewable video material which you wish to be used as preview videos on any supported Projec manager platform (Ftrack) has to be added ideally to track named **review**. This can be offline edit used as reference video for 2D/3D artists. This video material can be edited to fit length of **main** timeline track or it cand be one long video clip under all clips in **main** track, because OpenPype will trim this to appropriate length with use of FFMPEG. Please be avare we only support MP4(h264) or JPG sequence at the moment.
|
||||
|
|
@ -110,7 +110,7 @@ Because we don't support on-fly data conversion so in case of working with raw c
|
|||
|
||||
### Converting timeline clips to instances
|
||||
|
||||
Every clip on timeline which is inteded to be published has to be converted to publishable instance.
|
||||
Every clip on timeline which is intended to be published has to be converted to publishable instance.
|
||||
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
|
|
@ -169,7 +169,7 @@ I case you wish to publish reviewable video as explained above then find the app
|
|||
Hover above each input field for help.
|
||||
<br></br>
|
||||
|
||||
Handles can be defined here to. In case you wish to have individual clip set differently we recomend to set here the default value and later change those in the created OpenPype tag's metadata under `handleStart` and `handleEnd` properties (look bellow for details)
|
||||
Handles can be defined here to. In case you wish to have individual clip set differently we recommend to set here the default value and later change those in the created OpenPype tag's metadata under `handleStart` and `handleEnd` properties (look below for details)
|
||||
</div>
|
||||
|
||||
<div class="col col--6 markdown">
|
||||
|
|
@ -182,7 +182,7 @@ Handles can be defined here to. In case you wish to have individual clip set dif
|
|||
After you hit **Ok** tags are added to selected clips (except clips in **review** tracks).
|
||||
<br></br>
|
||||
|
||||
If you wish to change any individual propertie of the shot then you are able to do it here. In this example we can change `handleStart` and `handleEnd` to some other values.
|
||||
If you wish to change any individual properties of the shot then you are able to do it here. In this example we can change `handleStart` and `handleEnd` to some other values.
|
||||
</div>
|
||||
|
||||
<div class="col col--6 markdown">
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ 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).
|
||||
currently 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
|
||||
|
|
@ -628,7 +628,7 @@ 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.
|
||||
This is useful 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
|
||||
|
|
@ -715,7 +715,7 @@ For actual publishing of your groom to go **OpenPype → Publish** and then pres
|
|||
|
||||
|
||||
:::tip adding more descriptions
|
||||
You can add multiple xgen desctiption into the subset you are about to publish, simply by
|
||||
You can add multiple xgen description into the subset you are about to publish, simply by
|
||||
adding them to the maya set that was created for you. Please make sure that only xgen description nodes are present inside of the set and not the scalp geometry.
|
||||
:::
|
||||
|
||||
|
|
@ -753,7 +753,7 @@ parameters to it - Redshift will then represent proxy with bounding box.
|
|||
|
||||
## Using VRay Proxies
|
||||
|
||||
OpenPype support publishing, loading and using of VRay Proxy in look management. Their underlaying format
|
||||
OpenPype support publishing, loading and using of VRay Proxy in look management. Their underlying format
|
||||
can be either vrmesh or alembic.
|
||||
|
||||
:::warning vrmesh or alembic and look management
|
||||
|
|
|
|||
|
|
@ -254,7 +254,7 @@ Gathering all the info and validating usually takes just a few seconds. Creating
|
|||
##### Pyblish Note and Intent
|
||||
|
||||
|
||||
Artist can add Note and Intent before firing the publish button. The Note and Intent is ment for easy communication between artist and supervisor. After publish, Note and Intent can be seen in Ftrack notes.
|
||||
Artist can add Note and Intent before firing the publish button. The Note and Intent is meant for easy communication between artist and supervisor. After publish, Note and Intent can be seen in Ftrack notes.
|
||||
|
||||
##### Pyblish Checkbox
|
||||
|
||||
|
|
@ -334,4 +334,4 @@ If your Pyblish dialog fails on Validate Containers, you might have an old asset
|
|||
### Fixing Validate Version
|
||||
If your Pyblish dialog fails on Validate Version, you might be trying to publish already published version. Rise your version in the OpenPype WorkFiles SaveAs.
|
||||
|
||||
Or maybe you accidentaly copied write node from different shot to your current one. Check the write publishes on the left side of the Pyblish dialog. Typically you publish only one write. Locate and delete the stray write from other shot.
|
||||
Or maybe you accidentally copied write node from different shot to your current one. Check the write publishes on the left side of the Pyblish dialog. Typically you publish only one write. Locate and delete the stray write from other shot.
|
||||
|
|
@ -14,7 +14,7 @@ sidebar_label: Photoshop
|
|||
|
||||
## 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.
|
||||
To install the extension, download, install [Anastasyi's Extension 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
|
||||
|
||||
|
|
|
|||
|
|
@ -141,7 +141,7 @@ As you can see the in `{shot}` key within *Shot Template Keywords* section, you
|
|||
<div class="row markdown">
|
||||
<div class="col col--6 markdown">
|
||||
|
||||
Notice the relationship of following sections. Keys from **Shot Template Keywords** sections will be used for formating of templates in **Shot Hierarchy And Rename Settings** section.
|
||||
Notice the relationship of following sections. Keys from **Shot Template Keywords** sections will be used for formatting of templates in **Shot Hierarchy And Rename Settings** section.
|
||||
|
||||
**Shot parent hierarchy** will be forming parents of the asset (shot) *the hidden root for this is project folder*. So for example of this template we will get resulging string `shots/sq01`
|
||||
|
||||
|
|
@ -149,7 +149,7 @@ Notice the relationship of following sections. Keys from **Shot Template Keyword
|
|||
- `{_sequence_}`: timeline name
|
||||
- `{_clip_}`: clip name
|
||||
- `{_trackIndex_}`: position of track on timeline from bottom
|
||||
- `{_clipIndex_}`: clip positon on timeline from left
|
||||
- `{_clipIndex_}`: clip position on timeline from left
|
||||
|
||||
</div>
|
||||
<div class="col col--6 markdown">
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ OpenPype global tools can be found in *Window* main menu:
|
|||
|
||||
### 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:
|
||||
To import Static Mesh model, just choose **OpenPype → Load ...** and select your mesh. Static meshes are transferred 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:
|
||||
|
||||
|
||||
|
||||
|
|
@ -37,4 +37,4 @@ In this case there is **lambert1**, material pulled from Maya when this static m
|
|||
|
||||
### 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 ...**
|
||||
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 chosen - 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 ...**
|
||||
|
|
@ -65,7 +65,7 @@ Here's a list of supported families
|
|||
| Gizmo | | |
|
||||
| Nukenodes | | |
|
||||
| Harmony.template | | |
|
||||
| Harmony.pallette | | |
|
||||
| Harmony.palette | | |
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Notice that the window doesn't close after hitting `Accept` and confirming the c
|
|||
|
||||
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 Maya this means creating a set with everything you want to publish and assigning custom attributes to it so it gets 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.
|
||||
|
||||
|
|
@ -424,7 +424,7 @@ One or more items (instances) could be published any time Publish process is sta
|
|||
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.
|
||||
It also provides clean and preferable way how to remove unwanted item from publishing.
|
||||
|
||||
### Usage
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ _**release date:** (2021-05-18)_
|
|||
**Enhancements:**
|
||||
|
||||
- Use SubsetLoader and multiple contexts for delete_old_versions [\#1484](ttps://github.com/pypeclub/OpenPype/pull/1484))
|
||||
- TVPaint: Increment workfile version on successfull publish. [\#1489](https://github.com/pypeclub/OpenPype/pull/1489)
|
||||
- TVPaint: Increment workfile version on successful publish. [\#1489](https://github.com/pypeclub/OpenPype/pull/1489)
|
||||
- Maya: Use of multiple deadline servers [\#1483](https://github.com/pypeclub/OpenPype/pull/1483)
|
||||
|
||||
**Fixed bugs:**
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ $ exec $SHELL
|
|||
|
||||
# install Python 3.7.10
|
||||
# python will be downloaded and build so please make sure
|
||||
# you have all necessary requirements installed (see bellow).
|
||||
# you have all necessary requirements installed (see below).
|
||||
$ pyenv install -v 3.7.10
|
||||
|
||||
# change path to pype 3
|
||||
|
|
@ -193,7 +193,7 @@ For more information about setting your build environment please refer to [pyenv
|
|||
<TabItem value="mac">
|
||||
|
||||
### MacOS
|
||||
To build pype on MacOS you wil need:
|
||||
To build pype on MacOS you will need:
|
||||
|
||||
- **[Homebrew](https://brew.sh)** - easy way of installing everything necessary.
|
||||
- **[CMake](https://cmake.org/)** to build some external OpenPype dependencies.
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ These are the important branches to remember.
|
|||
|
||||
**`develop`** - Development branch where we merge all PRs during the development
|
||||
|
||||
**`release/3.x.x`** - Testing branch for a release, once a release branch is crated, no new features
|
||||
**`release/3.x.x`** - Testing branch for a release, once a release branch is created, no new features
|
||||
are accepted for the given release. Bugfixes, however, are expected. Once the branch is stable it is
|
||||
merged to `main` and `develop` and `main` is tagged with a new release
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ Inside each PR, put a link to the corresponding PR.
|
|||
|
||||
Of course if you want to contribute, feel free to make a PR to only 2.x/develop or develop, based on what you are using. While reviewing the PRs, we might convert the code to corresponding PR for the other release ourselves.
|
||||
|
||||
We might also change the target of you PR to and intermediate branch, rather than `develop` if we feel it requires some extra work on our end. That way, we preserve all your commits so you don't loos out on the contribution credits.
|
||||
We might also change the target of you PR to and intermediate branch, rather than `develop` if we feel it requires some extra work on our end. That way, we preserve all your commits so you don't lose out on the contribution credits.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Idle manager
|
|||
|
||||
Timers manager
|
||||
|
||||
Statics server
|
||||
Statistics server
|
||||
|
||||
## System Admin
|
||||
|
||||
|
|
|
|||
|
|
@ -212,7 +212,7 @@ This event makes sure statuses Asset Version get synced to it's task. After chan
|
|||
|
||||
This event handler allows setting of different status to a first created Asset Version in Ftrack.
|
||||
|
||||
This is usefull for example if first version publish doesn't contain any actual reviewable work, but is only used for roundtrip conform check, in which case this version could receive status `pending conform` instead of standard `pending review`
|
||||
This is useful for example if first version publish doesn't contain any actual reviewable work, but is only used for roundtrip conform check, in which case this version could receive status `pending conform` instead of standard `pending review`
|
||||
|
||||
### Update status on next task
|
||||
Change status on next task by task types order when task status state changed to "Done". All tasks with the same Task mapping of next task status changes From → To. Some status can be ignored.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Artists can explore their site ID by opening OpenPype Info tool by clicking on a
|
|||
|
||||
Many different sites can be created and configured on the system level, and some or all can be assigned to each project.
|
||||
|
||||
Each OpenPype Tray app works with two sites at one time. (Sites can be the same, and no synching is done in this setup).
|
||||
Each OpenPype Tray app works with two sites at one time. (Sites can be the same, and no syncing is done in this setup).
|
||||
|
||||
Sites could be configured differently per project basis.
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ This attribute is meant for special use cases only.
|
|||
|
||||
One of the use cases is sftp site vendoring (exposing) same data as regular site (studio). Each site is accessible for different audience. 'studio' for artists in a studio via shared disk, 'sftp' for externals via sftp server with mounted 'studio' drive.
|
||||
|
||||
Change of file status on one site actually means same change on 'alternate' site occured too. (eg. artists publish to 'studio', 'sftp' is using
|
||||
Change of file status on one site actually means same change on 'alternate' site occurred too. (eg. artists publish to 'studio', 'sftp' is using
|
||||
same location >> file is accessible on 'sftp' site right away, no need to sync it anyhow.)
|
||||
|
||||
##### Example
|
||||
|
|
@ -62,7 +62,7 @@ Alternative sites work both way:
|
|||
|
||||
## Project Settings
|
||||
|
||||
Sites need to be made available for each project. Of course this is possible to do on the default project as well, in which case all other projects will inherit these settings until overriden explicitly.
|
||||
Sites need to be made available for each project. Of course this is possible to do on the default project as well, in which case all other projects will inherit these settings until overridden explicitly.
|
||||
|
||||
You'll find the setting in **Settings/Project/Global/Site Sync**
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ Let's imagine a small globally distributed studio which wants all published work
|
|||
For this use case admin needs to configure:
|
||||
- how many times it tries to synchronize file in case of some issue (network, permissions)
|
||||
- how often should synchronization check for new assets
|
||||
- sites for synchronization - 'local' and 'gdrive' (this can be overriden in local settings)
|
||||
- sites for synchronization - 'local' and 'gdrive' (this can be overridden in local settings)
|
||||
- user credentials
|
||||
- root folder location on Google Drive side
|
||||
|
||||
|
|
@ -137,19 +137,19 @@ Beware that ssh key expects OpenSSH format (`.pem`) not a Putty format (`.ppk`)!
|
|||
- Enable Site Sync module in Settings
|
||||
- Add side with SFTP provider
|
||||
|
||||
|
||||
|
||||
|
||||
- In Projects setting enable Site Sync (on default project - all project will be synched, or on specific project)
|
||||
- Configure SFTP connection and destination folder on a SFTP server (in screenshot `/upload`)
|
||||
|
||||
|
||||
|
||||
- if you want to force synching between local and sftp site for all users, use combination `active site: local`, `remote site: NAME_OF_SFTP_SITE`
|
||||
- if you want to allow only specific users to use SFTP synching (external users, not located in the office), use `active site: studio`, `remote site: studio`.
|
||||
- if you want to force syncing between local and sftp site for all users, use combination `active site: local`, `remote site: NAME_OF_SFTP_SITE`
|
||||
- if you want to allow only specific users to use SFTP syncing (external users, not located in the office), use `active site: studio`, `remote site: studio`.
|
||||
|
||||
|
||||
|
||||
- Each artist can decide and configure synching from his/her local to SFTP via `Local Settings`
|
||||
- Each artist can decide and configure syncing from his/her local to SFTP via `Local Settings`
|
||||
|
||||
|
||||
|
||||
|
|
@ -164,7 +164,7 @@ Site Sync server synchronizes new published files from artist machine into confi
|
|||
There might be a use case where you need to synchronize between "non-artist" sites, for example between studio site and cloud. In this case
|
||||
you need to run Site Sync as a background process from a command line (via service etc) 24/7.
|
||||
|
||||
To configure all sites where all published files should be synced eventually you need to configure `project_settings/global/sync_server/config/always_accessible_on` property in Settins (per project) first.
|
||||
To configure all sites where all published files should be synced eventually you need to configure `project_settings/global/sync_server/config/always_accessible_on` property in Settings (per project) first.
|
||||
|
||||
|
||||
|
||||
|
|
@ -190,7 +190,7 @@ To do this:
|
|||
- run OP from a command line with `syncserver` and `--active_site` arguments
|
||||
|
||||
|
||||
This is an example how to trigger background synching process where active (source) site is `studio`.
|
||||
This is an example how to trigger background syncing process where active (source) site is `studio`.
|
||||
(It is expected that OP is installed on a machine, `openpype_console` is on PATH. If not, add full path to executable.
|
||||
)
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ sidebar_label: Global
|
|||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Project settings can have project specific values. Each new project is using studio values defined in **default** project but these values can be modified or overriden per project.
|
||||
Project settings can have project specific values. Each new project is using studio values defined in **default** project but these values can be modified or overridden per project.
|
||||
|
||||
:::warning Default studio values
|
||||
Projects always use default project values unless they have [project override](../admin_settings#project-overrides) (orage colour). Any changes in default project may affect all existing projects.
|
||||
|
|
@ -77,7 +77,7 @@ Profile may generate multiple outputs from a single input. Each output must defi
|
|||
- All values that cause output resolution smaller than 1 pixel are invalid.
|
||||
|
||||
- Value without sign (+/-) in is always explicit and value with sign is
|
||||
relative. Output size for values "200px" and "+200px" are not the same "+200px" will add 200 pixels to source and "200px" will keep only 200px from source. Value of "0", "0px" or "0%" are automatically converted to "+0px" as 0px is invalid ouput.
|
||||
relative. Output size for values "200px" and "+200px" are not the same "+200px" will add 200 pixels to source and "200px" will keep only 200px from source. Value of "0", "0px" or "0%" are automatically converted to "+0px" as 0px is invalid output.
|
||||
|
||||
- Cropped value is related to center. It is better to avoid odd numbers if
|
||||
possible.
|
||||
|
|
@ -88,7 +88,7 @@ Profile may generate multiple outputs from a single input. Each output must defi
|
|||
|---|---|---|
|
||||
| ` ` | 2200px | Empty string keep resolution unchanged. |
|
||||
| `50%` | 1100px | Crop 25% of input width on left and right side. |
|
||||
| `300px` | 300px | Keep 300px in center of input and crop rest on left adn right. |
|
||||
| `300px` | 300px | Keep 300px in center of input and crop rest on left and right. |
|
||||
| `300` | 300px | Values without units are used as pixels (`px`). |
|
||||
| `+0px` | 2200px | Keep resolution unchanged. |
|
||||
| `0px` | 2200px | Same as `+0px`. |
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ sidebar_label: Nuke
|
|||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Project settings can have project specific values. Each new project is using studio values defined in **default** project but these values can be modified or overriden per project.
|
||||
Project settings can have project specific values. Each new project is using studio values defined in **default** project but these values can be modified or overridden per project.
|
||||
|
||||
:::warning Default studio values
|
||||
Projects always use default project values unless they have [project override](../admin_settings#project-overrides) (orage colour). Any changes in default project may affect all existing projects.
|
||||
|
|
@ -40,7 +40,7 @@ Custom templates are added into nuke's node graph as nodes. List of task types c
|
|||
|
||||
|
||||
|
||||
- multi platform path can be used in a variety of ways. Along the absolut path to a template file also an python formating could be used. At the moment these keys are supported (image example bellow):
|
||||
- multi platform path can be used in a variety of ways. Along the absolute path to a template file also an python formatting could be used. At the moment these keys are supported (image example below):
|
||||
- `root[key]`: definitions from anatomy roots
|
||||
- `project[name, code]`: project in context
|
||||
- `asset`: name of asset/shot in context
|
||||
|
|
@ -49,7 +49,7 @@ Custom templates are added into nuke's node graph as nodes. List of task types c
|
|||
|
||||
|
||||
#### Run Builder profiles on first launch
|
||||
Enabling this feature will look into available Builder's Prorfiles (look bellow for more informations about this feature) and load available versions into node graph.
|
||||
Enabling this feature will look into available Builder's Prorfiles (look below for more information about this feature) and load available versions into node graph.
|
||||
|
||||
### Profiles (Builder)
|
||||
Builder profiles are set of rules allowing artist Load any available versions for the context of the asset, which it is run from. Preset is having following attributes:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ sidebar_label: Standalone Publisher
|
|||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Project settings can have project specific values. Each new project is using studio values defined in **default** project but these values can be modified or overriden per project.
|
||||
Project settings can have project specific values. Each new project is using studio values defined in **default** project but these values can be modified or overridden per project.
|
||||
|
||||
:::warning Default studio values
|
||||
Projects always use default project values unless they have [project override](../admin_settings#project-overrides) (orage colour). Any changes in default project may affect all existing projects.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Project
|
|||
```
|
||||
|
||||
:::note Shot naming
|
||||
We do strongly recommend to name shots with their full hierarchical name. Avalon doesn't allow two assets with same name in project. Therefor if you have for example:
|
||||
We do strongly recommend to name shots with their full hierarchical name. Avalon doesn't allow two assets with same name in project. Therefore if you have for example:
|
||||
|
||||
```text
|
||||
sequence01 / shot001
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ Template groups `work` and `publish` must be set in all circumstances. Both must
|
|||
| version | Version number. |
|
||||
| subset | Subset name. |
|
||||
| family | Main family name. |
|
||||
| ext | File extention. (Possible to use only in `work` template atm.) |
|
||||
| ext | File extension. (Possible to use only in `work` template atm.) |
|
||||
| representation | Representation name. (Is used instead of `ext` except `work` template atm.) |
|
||||
| frame | Frame number for sequence files. |
|
||||
| output | |
|
||||
|
|
@ -160,7 +160,7 @@ group_1:
|
|||
|
||||
group_2:
|
||||
# `global_key` is iverrided
|
||||
global_key: "overriden global value"
|
||||
global_key: "overridden global value"
|
||||
```
|
||||
**Result**
|
||||
```yaml
|
||||
|
|
@ -173,7 +173,7 @@ group_1:
|
|||
|
||||
group_2:
|
||||
# `global_key` kept it's value for `group_2`
|
||||
global_key: "overriden global value"
|
||||
global_key: "overridden global value"
|
||||
```
|
||||
|
||||
### Combine Inner keys with Global keys
|
||||
|
|
@ -273,7 +273,7 @@ Presets are categorized in folders based on what they control or what host (DCC
|
|||
|
||||
### colorspace
|
||||
|
||||
Defines all available color spaces in the studio. These configs not only tell the system what OCIO to use, but also how exactly it needs to be applied in the give application. From loading the data, trough previewing it all the way to rendered
|
||||
Defines all available color spaces in the studio. These configs not only tell the system what OCIO to use, but also how exactly it needs to be applied in the give application. From loading the data, through previewing it all the way to rendered
|
||||
|
||||
### Dataflow
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ import Tabs from '@theme/Tabs';
|
|||
import TabItem from '@theme/TabItem';
|
||||
|
||||
|
||||
Ftrack is currently the main project management option for Pype. This documentaion assumes that you are familiar with Ftrack and it's basic principles. If you're new to Ftrack, we recommend having a thorough look at [Ftrack Official Documentation](http://ftrack.rtd.ftrack.com/en/stable/).
|
||||
Ftrack is currently the main project management option for Pype. This documentation assumes that you are familiar with Ftrack and it's basic principles. If you're new to Ftrack, we recommend having a thorough look at [Ftrack Official Documentation](http://ftrack.rtd.ftrack.com/en/stable/).
|
||||
|
||||
## Prepare Ftrack for Pype
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ The only action that is strictly required is [Pype Admin - Create/Update Avalon
|
|||
If you want to switch projects that are already in production, you might also need to run [Pype Doctor - Custom attr doc](manager_ftrack_actions#custom-attr-doc).
|
||||
|
||||
:::caution
|
||||
Keep in mind that **Custom attr doc** action will migrate certain attributes from ftrack default ones to our custom attributes. Some attributes will also be renamed. We make backup of the values, but be very carefull with this option and consults us before running it.
|
||||
Keep in mind that **Custom attr doc** action will migrate certain attributes from ftrack default ones to our custom attributes. Some attributes will also be renamed. We make backup of the values, but be very careful with this option and consults us before running it.
|
||||
:::
|
||||
|
||||
## Event Server
|
||||
|
|
@ -180,7 +180,7 @@ This event makes sure statuses Asset Version get synced to it's task. After chan
|
|||
|
||||
This event handler allows setting of different status to a first created Asset Version in ftrack.
|
||||
|
||||
This is usefull for example if first version publish doesn't contain any actual reviewable work, but is only used for roundtrip conform check, in which case this version could receive status `pending conform` instead of standard `pending review`
|
||||
This is useful for example if first version publish doesn't contain any actual reviewable work, but is only used for roundtrip conform check, in which case this version could receive status `pending conform` instead of standard `pending review`
|
||||
|
||||
Behaviour can be filtered by `name` or `type` of the task assigned to the Asset Version. Configuration can be found in [ftrack presets](admin_presets_ftrack#first_version_status-dict)
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ import TabItem from '@theme/TabItem';
|
|||
|
||||
The general approach to pype deployment is installing central repositories on a shared network storage which can be accessed by all artists in the studio. Simple shortcuts to launchers are then distributed to all workstations for artists to use. This approach ensures easy maintenance and updates.
|
||||
|
||||
When artist first runs pype all the required python packages get installed automatically to his local workstation and updated everytime there is a change in the central installation.
|
||||
When artist first runs pype all the required python packages get installed automatically to his local workstation and updated every time there is a change in the central installation.
|
||||
|
||||
:::note
|
||||
Automatic workstation installation and updates will not work in offline scenarios. In these case `pype install --force --offline` command must be triggered explicitly on the workstation
|
||||
|
|
|
|||
|
|
@ -66,6 +66,6 @@ Thanks to a very flexible and extensible system of presets, we're almost always
|
|||
|
||||
### Studio-Project-Configs
|
||||
|
||||
On top of studio wide pype config, we support project level overrides for any and all avriables and presets available in the main studio config.
|
||||
On top of studio wide pype config, we support project level overrides for any and all variables and presets available in the main studio config.
|
||||
|
||||
### Studio-Project-Scrips
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ Key specifies the resulting status and value is a list of statuses from which we
|
|||
```json
|
||||
{
|
||||
"status_update": {
|
||||
"_ignore_": ["in progress", "ommited", "on hold"],
|
||||
"_ignore_": ["in progress", "omitted", "on hold"],
|
||||
"Ready": ["not ready"],
|
||||
"In Progress" : ["_any_"]
|
||||
}
|
||||
|
|
|
|||
|
|
@ -45,9 +45,9 @@ This plugin is set to `true` by default so it will synchronize version of publis
|
|||
|
||||
path: `pype-config/presets/plugins/nukestudio/publish.json`
|
||||
|
||||
Plugin is responsible for cuting shorter or longer source material for review. Here you can add any aditional tags you wish to be added into extract review process.
|
||||
Plugin is responsible for cuting shorter or longer source material for review. Here you can add any additional tags you wish to be added into extract review process.
|
||||
|
||||
The plugin generates reedited intermediate video with handless even if it has to add empty black frames. Some productions prefer to use review material without handless so in the example, `no-handles` are added as tags. This allow furter review extractor to publish review without handles, without affecting other outputs.
|
||||
The plugin generates reedited intermediate video with handless even if it has to add empty black frames. Some productions prefer to use review material without handless so in the example, `no-handles` are added as tags. This allow further review extractor to publish review without handles, without affecting other outputs.
|
||||
|
||||
```python
|
||||
{
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Profile may have multiple outputs from one input and that's why **outputs** is d
|
|||
| **filter** | Filters definition. | dict | [here](#output-filters-filter) |
|
||||
|
||||
:::note
|
||||
As metioned above **all keys are optional**. If they are not filled at all, then **"ext"** is filled with input's file extension and resolution keys **"width"** and **"heigh"** are filled from instance data, or from input resolution if instance doesn't have set them.
|
||||
As mentioned above **all keys are optional**. If they are not filled at all, then **"ext"** is filled with input's file extension and resolution keys **"width"** and **"height"** are filled from instance data, or from input resolution if instance doesn't have set them.
|
||||
:::
|
||||
|
||||
:::important resolution
|
||||
|
|
@ -61,7 +61,7 @@ It is not possible to enter only **"width"** or only **"height"**. In that case
|
|||
:::
|
||||
|
||||
#### New representation tags (`tags`)
|
||||
You can add tags to representation created during extracting process. This might help to define what should happen with representation in upcomming plugins.
|
||||
You can add tags to representation created during extracting process. This might help to define what should happen with representation in upcoming plugins.
|
||||
|
||||
| Tag | Description |
|
||||
| --- | --- |
|
||||
|
|
@ -69,7 +69,7 @@ You can add tags to representation created during extracting process. This might
|
|||
| **preview** | Will be used as preview in Ftrack. |
|
||||
| **reformat** | Rescale to format based on width and height keys. |
|
||||
| **bake-lut** | Bake LUT into the output (if is available path in data). |
|
||||
| **slate-frame** | Add slate frame at the beggining of video. |
|
||||
| **slate-frame** | Add slate frame at the beginning of video. |
|
||||
| **no-handles** | Remove the shot handles from the output. |
|
||||
| **sequence** | Generate a sequence of images instead of single frame.<br />Is applied only if **"ext"** of output is image extension e.g.: png or jpg/jpeg. |
|
||||
|
||||
|
|
@ -331,7 +331,7 @@ If source representation has suffix **"h264"** and burnin suffix is **"client"**
|
|||
|
||||
|
||||
#### Default content values (`fields`)
|
||||
If you want to set position content values for all or most of burnin definitions, you can set them in **"fields"**. They will be added to every burnin definition in all profiles. Value can be overriden if same position key is filled in burnin definiton.
|
||||
If you want to set position content values for all or most of burnin definitions, you can set them in **"fields"**. They will be added to every burnin definition in all profiles. Value can be overridden if same position key is filled in burnin definition.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -348,7 +348,7 @@ If you want to set position content values for all or most of burnin definitions
|
|||
|
||||
/* example2 has 2 overrides. */
|
||||
"example2": {
|
||||
/* Top left value is overriden with asset name. */
|
||||
/* Top left value is overridden with asset name. */
|
||||
"TOP_LEFT": "{asset}",
|
||||
/* Top center will be skipped. */
|
||||
"TOP_CENTERED": null
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ This preset tells the creator tools what family should be pre-selected in differ
|
|||
|
||||
path: `pype-config/presets/tools/project_folder_structure.json`
|
||||
|
||||
Defines the base folder structure for a project. This is supposed to act as a starting point to quickly creat the base of the project. You can add `[ftrack.entityType]` after any of the folders here and they will automatically be also created in ftrack project.
|
||||
Defines the base folder structure for a project. This is supposed to act as a starting point to quickly create the base of the project. You can add `[ftrack.entityType]` after any of the folders here and they will automatically be also created in ftrack project.
|
||||
|
||||
### `__project_root__` [dict]
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ Keys are renderer names and values are templates IDs.
|
|||
"arnold": 46,
|
||||
"arnold_sf": 57,
|
||||
"gelato": 30,
|
||||
"harware": 3,
|
||||
"hardware": 3,
|
||||
"krakatoa": 51,
|
||||
"file_layers": 7,
|
||||
"mentalray": 2,
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@ pype publish <PATH_TO_JSON>
|
|||
- run Pyblish GUI
|
||||
|
||||
### `--debug`
|
||||
- print more verbose infomation
|
||||
- print more verbose information
|
||||
|
||||
--------------------
|
||||
|
||||
|
|
@ -260,9 +260,9 @@ pype tray --debug
|
|||
|
||||
## `update-requirements`
|
||||
|
||||
Synchronize dependecies in your virtual environment with requirement.txt file.
|
||||
Synchronize dependencies in your virtual environment with requirement.txt file.
|
||||
Equivalent of running `pip freeze > pypeapp/requirements.txt` from your virtual
|
||||
environmnet. This is useful for development purposes.
|
||||
environment. This is useful for development purposes.
|
||||
|
||||
```sh
|
||||
pype update-requirements
|
||||
|
|
|
|||
|
|
@ -7,11 +7,11 @@ sidebar_label: Setup Troubleshooting
|
|||
## SSL Server certificates
|
||||
|
||||
Python is strict about certificates when connecting to server with SSL. If
|
||||
certificate cannot be validated, connection will fail. Therefor care must be
|
||||
certificate cannot be validated, connection will fail. Therefore care must be
|
||||
taken when using self-signed certificates to add their certification authority
|
||||
to trusted certificates.
|
||||
|
||||
Also please note that even when using certificates from trusted CA, you need to
|
||||
update your trusted CA certificates bundle as those certificates can change.
|
||||
|
||||
So if you receieve SSL error `cannot validate certificate` or similar, please update root CA certificate bundle on machines and possibly **certifi** python package in Pype virtual environment - just edit `pypeapp/requirements.txt` and update its version. You can find current versions on [PyPI](https://pypi.org).
|
||||
So if you receive SSL error `cannot validate certificate` or similar, please update root CA certificate bundle on machines and possibly **certifi** python package in Pype virtual environment - just edit `pypeapp/requirements.txt` and update its version. You can find current versions on [PyPI](https://pypi.org).
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ sidebar_label: Update Notes
|
|||
|
||||
Due to changes in how tasks are stored in the database (we added task types and possibility of more arbitrary data.), we must take a few precautions when updating.
|
||||
1. Make sure that ftrack event server with sync to avalon is NOT running during the update.
|
||||
2. Any project that is to be worked on with 2.13 must be synced from ftrack to avalon with the udpated sync to avalon action, or using and updated event server sync to avalon event.
|
||||
2. Any project that is to be worked on with 2.13 must be synced from ftrack to avalon with the updated sync to avalon action, or using and updated event server sync to avalon event.
|
||||
|
||||
If 2.12 event servers runs when trying to update the project sync with 2.13, it will override any changes.
|
||||
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ module.exports = {
|
|||
algolia: {
|
||||
apiKey: '5e01ee3bfbb744ca6f25d4b281ce38a9',
|
||||
indexName: 'openpype',
|
||||
// Optional: see doc section bellow
|
||||
// Optional: see doc section below
|
||||
contextualSearch: true,
|
||||
// Optional: Algolia search parameters
|
||||
searchParameters: {},
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue