Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement final touches for compatibility with Allzpark.
Overall it's quite compatible, with a few minor adjustments to the overall workflow.
See aforementioned website for details and background.
Because Allzpark changes the fundamental nature of how a host is launched and assets specified with Avalon, we'll need to adjust how users interact with it.
Here's some ideas for how to accomplish that.
Upon entering a host, the Avalon Landing Screen appears.
It'll display three things.
Clicking on a recent item takes you immediately into the latest file for that task. The goal of this dialog is to get out of the way; it isn't the first time an artist launches this app, the only thing on their mind is to carry on with what they were doing the day before.
Behind the Landing Screen is the new Context Manager.
This'll account for more complex choice, or first-choice. When a new task or project is started. It'll resemble Allzpark, but rather than changing project, it'll change asset, task and scene file.
Clicking on the asset or task brings up a floating tree-view of available assets, this is to fill in for what was provided by the Avalon Launcher, with visual hierarchy etc.
..from within the old Launcher before actually launching a host, like Maya.
The Launcher then does two things.
It can do that because it has all of the information, (1) project, (2) asset, (3) task and (4) application.
In the Colorbleed Config, users have the option to not only edit the task, but re-create this working directory post-launch, because the directory is (sometimes, depending on preference) relative the task.
Like Launcher, it has all the information and can perform this kind of action, but it means code is duplicated an so is responsibility. Now both the launcher and host requires access to the underlying application definition, both require relevant write-permissions and access to the same set of environment variables.
The way both of these determine what this path should look like, and what the missing pieces are, is..
In order for Allzpark to accommodate for these, (1) and (2) can remain as-is, but as there is no more application template (replaced by Rez packages)
Option 1 - Package environment variable
name = "maya" version = "2019.3" def commands(): global env env["APPLICATION_DEFAULT_DIRS"] = "scenes;images;renders/comp;renders/lut"
Core could then query this variable for optional additional directories to create.
Option 2 - Core Integration
The Avalon core integration of a host like Maya determines what folders to generate per default, which can either remain fixed (do these default change often?) or customisable somehow. This would be the simplest option, but also least flexible (and implicit).
Option 3 - Config
The config provides an optional e.g.
Option 4 - Plug-in
Creating, Loading, Publishing and Managing content is currently governed by individual plug-ins, relative a particular "family" of data, such as
class MayaPath(api.WorkingDirectory): apps = ["maya"] def process(self, config, context): import os template = config["template"]["work"] root = template.format(**context) os.makedirs(root) for dirname in ("scenes", "images", "renders"): abspath = os.path.join(root, dirname) os.makedirs(abspath) fname = os.path.join(root, "workspace.mel") with open(fname, "w") as f: f.write("""\ //Maya 2019 Project Definition workspace -fr "mayaAscii" "scenes"; workspace -fr "shaders" "renderData/shaders"; """)
The advantage is uniformity with other plug-ins, at the cost of one more layer of plug-ins to manage. But then there's other paths, like where things go when you publish. There's currently no strict requirement for there to be exactly two paths; "work" and "publish" as the defaults are called. You could have any number of templates, or not use templates at all; handling paths in plug-ins in any way you want.
But applications do need a location to store its files, and output needs somewhere to go.
Maybe a more apt approach would be to have Template plug-ins?
Option 6 - Template Plug-ins
These would kick in whenever a template is used, for whatever purpose.
from avalon import api class WorkTemplate(api.Template): templates = ["work"] def process(self, template, config, context): ... class PublishTemplate(api.Template): templates = ["publish"] def process(self, template, config, context): ...
For example, from a loader plug-in.
def process(self, name, namespace, context): from avalon import api api.template(...)
No, that probaby doesn't make sense.. templates won't know about the app, other than by name.
Not 100% confident about the right approach here.