# Notes: meeting with Thierry about Project Setup

Thierry Paalman, from https://submarine.nl

## Existing software they use for project management

Avalon:
- https://avalon.samvera.org
- https://getavalon.github.io/2.0/

Aeon (Ayon?):
- https://github.com/ynput

## Versioning Workflows

Would love if Blender had some sort of built-in "version control":

- An asset can have multiple concurrent versions, each saved as a different file.
- Blender understands this multi-file scheme.
- When a new version of an asset is available, the user decides on a per-file basis (e.g. in an animation file, lighting file, etc.) whether the linked asset gets updated to the newest one or not.

He mentioned looking at Nuke as an example of how this can work.

The idea is that you can have asyncronous updates of assets, where the *artist* is in control of when/if a used asset is updated in a given context. (As opposed to a typical version control workflow, where the artist pulls changes and all files automatically use the newest version of an asset.)

## Blender Version Range

It would be really useful if projects could specify an accepted Blender version range. Then when someone tries to open a blend file in the project with a version of Blender outside that range, they get e.g. a prominent warning that they're using the wrong Blender version.

## Python API

Defining project variables in a Blender-specific TOML file or whatnot doesn't sound ideal to him. They use many different pieces of software, not just Blender, and it would be better if they could handle all variables in a centralized place.

For example, the pixel resolution of the over-all production should be the same across all software. If they have to manage that in a separate place for each piece of software, that would be annoying and error prone.

This also potentially applies to more than just project variables, but also to other project-level things like which OCIO config to use.

After discussing this for a bit, we landed on the idea that Blender's Project Setup system should be exposed to Blender's Python API, and can be managed there. This would likely have been the case anyway (why wouldn't we expose that to Python?). But more specifically, the idea is that the Python API is actually the main thing, and the TOML-based system would just be implemented in terms of that API. Then studios, if they wish, can instead implement their own addon that either supplements or replaces the included TOML-based system, and can set project variables based on e.g. queries to their own centralized project database.

## Project Variables

We discussed the question of whether the use of project variables should be specified by the Project (e.g. the project says "the render resolution is 1920x1080") or whether they should be determined in each blend file (e.g. the x-resolution property says "I'm using the variable RES_X").

Both have pluses and minuses, and likely different use cases, and therefore we may want to support both in some fashion.

However, through discussion, we came up with a different way of conceptualizing Project-specified use.

For context: the motivating use case we based this idea off of is a production that has a final film resolution that all final shots are rendered for, but *also* a "mobile phone" resolution for rendering video textures for phone screens in shots where characters are video calling other characters.

In this kind of situation, the production has multiple render resolutions, but each one should be standardized across the production.

The idea we came up with (without any consideration yet for implementation complexity) is that e.g. the project variable for render resolution can be set up with multiple possible values. Then within a blend file, the user is limited to selecting one of those preset values. In other words, rather than the project enforcing that all render resolutions are set to a specific value, it gives a set of acceptable *options*.

Note that this is different from typical presets: when a typical preset is selected it simply sets the values of the relevant properties, and after that has no association with them. Whereas this system would track which option was selected, and when the values for that option are changed in the project, the values in all the files using that option would change to match as well.