Asset task options implementation

davidlatwe commented 3 years ago

Intooduce Asset Task Option

This feature aims to allow each asset to have different config in different task at different period of production time, which could be useful in publish process or other part of pipeline.

Setup

Register task options by adding "options" into each "config.tasks" field in Avalon database's project document. The peroject document would be like this:

{
    "type": "project",
    "config": {
        "tasks": [
            {
                "name": "rigging",
                "options": {
                    "autoModelUpdate": {
                        "label": "Auto update model",
                        "default": false,
                        "help": "Auto update model to latest version after model publish."
                    }
                }
            },
            {
                "name": "otherTaskThatHasNoOption"
            }
        ]
    }
}

And in .config.toml file:

[[tasks]]
name = "rigging"

[tasks.options.autoModelUpdate]
label = "Auto update model"
default = false
help = "Auto update model to latest version after model publish."

[[tasks]]
name = "otherTaskThatHasNoOption"

And the asset document will be added one extra field data.taskOptions when it's been applied:

{
    "type": "asset",
    "name": "Foo",
    "data": {
        "label": "Foo",
        "taskOptions": {
            "rigging": {
                "autoModelUpdate": {
                    "value": false
                }
            }
        },
        "tasks": [
            "rigging",
            "otherTaskThatHasNoOption"
        ]
    }
}

Usage

To apply/change task options to each asset, we implement a new widget into Avalon's project manager tool.

With this, you can:

View and update task option on each asset.
Able to update multiple tasks' options on multiple assets in one action when enabled "Batch Edit".

Notes

This widget is hidden by default, you need to drag it out from the right side of the window.
Option setup change will be written to database only when you pressed the "Save" button.
Current edit will lost if you changed the selection of asset or task.
Task widget's view has been enabled multi-selection for editing multiple task option on each asset. (This only applys to Project Manager, does not affect other tools)

tokejepsen commented 3 years ago

Not sure I entirely get the end goal of this?

Is it like a per task metadata, so the config can disable/enable plugins?

davidlatwe commented 3 years ago

Is it like a per task metadata, so the config can disable/enable plugins?

Yes, per task metadata that can be applied to each asset, and for example, like in publish plugins, can change the behavior based on those metadata in each asset.

davidlatwe commented 3 years ago

Our use case is, a rigger can set for one or more assets' rigs that is currently working on, which can be safely auto updated when model is being published.

tokejepsen commented 3 years ago

Side question about "auto update". How are you tracking this and when does it get triggered?

BigRoy commented 3 years ago

I like the fact of having specific rules/settings for an Asset but I do have some doubts about how this works. To get a clear picture I have a question first:

Could this also just be an "Asset" specific setting? As in, does it really need to be on the Task?

I imagine this could also just be on the asset's data

rigFaceJointLimit: 10
rigBodyJointLimit: 20
rigAutoUpdate: True

Seems like that was how it was originally intended (to be specific data to that asset). In that sense it's more of User Interface front-end for asset data, which I think is a great step forward. E.g. also allowing to set an FPS override or resolution setting for a Shot in the Project Manager.

I guess the specification could allow for assetOptions that apply only to specific tasks (allowedTasks: ["rigging"])?

davidlatwe commented 3 years ago

Side question about "auto update". How are you tracking this and when does it get triggered?

@tokejepsen We have a simple dependency tracking mechanism, but only in Maya. When publishing, the instance that is being published will lookup the history and see if any node that is part of loaded subset. If so, the version document's _id of that loaded subset will be written into the instance's version document for future lookup.

Could this also just be an "Asset" specific setting? As in, does it really need to be on the Task?

@BigRoy (Hmm, maybe I shouldn't use the phrase "to each asset", since it does sounds like applying same settings to every asset ?)

Yes, it's asset specific settings when you apply options from those has been registered in project's tasks.

Before those option being applied to any assets, we need a way to define and present those options, and binding them with tasks seems a good fit.

E.g. also allowing to set an FPS override or resolution setting for a Shot in the Project Manager. I guess the specification could allow for assetOptions that apply only to specific tasks (allowedTasks: ["rigging"])?

Ah, need to think about this, organizing those option into project document's "config.assetOptions" with "allowedTasks" entry seems to be more flexible !

davidlatwe commented 3 years ago

If we move the option's defenition it into a higher scope like "assetOptions", then the project document would be like:

{
    "type": "project",
    "config": {
        "assetOptions": [
            {
                "name": "rigAutoModelUpdate",
                "label": "Auto update model",
                "default": false,
                "help": "Auto update model to latest version after model publish.",
                "onTasks": [
                    "rigging"
                ]
            },
            {
                "name": "shotFps",
                "label": "Frame rate",
                "default": 24,
                "help": "Override frame rate for shot.",
                "onTasks": [
                    "layout",
                    "animating",
                    "lighting"
                ]
            }
        ]
    }
}

.config.toml:

[[assetOptions]]
name = "rigAutoModelUpdate"
label = "Auto update model"
default = false
help = "Auto update model to latest version after model publish."
onTasks = [
    "rigging"
]

Which is a bit better to write 👍

And the asset document that has been applied would be like:

{
    "type": "asset",
    "name": "Foo",
    "data": {
        "label": "Foo",
        "assetOptions": {
            "rigAutoModelUpdate": {
                "value": false
            }
        },
        "tasks": [
            "rigging"
        ]
    }
}

davidlatwe commented 3 years ago

A note to self: Need to pay attention on existing entries in assets like "startFrame" or "endFrame" (or "frameStart", "frameEnd"), since those may have been written into the asset document in existing production, so the landing opint of those assetOptions may not be able to like the example asset document above. 🤔

So to compat (able to edit in GUI) those existing options, new assetOptions may have to live directly under "data" field in asset document, like this:

{
    "type": "asset",
    "name": "Foo",
    "data": {
        "label": "Foo",
        "rigAutoModelUpdate": true,
        "tasks": [
            "rigging"
        ]
    }
}

{
    "type": "asset",
    "name": "shot01",
    "data": {
        "label": "shot 01",
        "frameStart": 100,
        "frameEnd": 200,
        "fps": 24,
        "tasks": [
            "rigging"
        ]
    }
}

And the existing "frameStart" for example, can be defined like:

[[assetOptions]]
name = "frameStart"
label = "Start frame"
default = 100
help = "The start frame of the shot."
onTasks = [
    "layout",
    "animating",
    "lighting"
]

BigRoy commented 3 years ago

new assetOptions may have to live directly under "data" field in asset document

Exactly what I was expecting yes. I imagined these new "rig specific settings" similar to an Asset/Shot specific setting like Resolution/FPS (if overridden from a project's default) or things like that.

Would love to know whether that would work for your use cases?

davidlatwe commented 3 years ago

Yeah, that would work in our case even better 🚀

davidlatwe commented 3 years ago

I have refactored to adopt "assetOptions", but noted that the config-1.0 schema also need to be updated as well since "assetOptions" is a new property in project config.

Or should we make a config-1.1 schema ? Or config-2.0 ?

mkolar commented 3 years ago

Coming late to the party, but good to see what you guys agreed on at the end. It is a lot more flexible and easily expandable to many other types of parameters than the original concept.

davidlatwe commented 3 years ago

Or should we make a config-1.1 schema ? Or config-2.0 ?

I will add config-1.1, since it's a minor change.

BigRoy commented 3 years ago

What's the status on this? Anyone using this in production?

davidlatwe commented 3 years ago

Or should we make a config-1.1 schema ? Or config-2.0 ?

I will add config-1.1, since it's a minor change.

I think the last comment I wrote was the last piece but somehow I never finish it. 😮 But I did put this into our production branch.

getavalon / core