trackable variants
We would need an option to add variants from the overview and define ahead of time.
-Example 01
Let say we’re working on a show with Dino’s
We need multiple triceratops in a scene and we don’t want to have a 1 on 1 copy of them, that would look silly.
I would like to have the same model and rig, animation cycles, but would like to have variants of the texture, maybe some have an extra scars, a little color variation etc. etc.
I don’t want to create new tasks as they 3 variants we've are all so slightly different that if the client to decide that the overall color of the Dino should be slightly more brown instead of green we need to adjust 3 (in our case substance painter) files.
Or if the model changes for some reason, again changing/adjusting 3 files
So i just want to be able to adjust that one file and have a folder that we can manually turn on/off for the extra scars etc. etc. etc.
We can to that right now at the publish and add a variant name, but we’ve no way to track it or define to the artist which versions we’ve need except for an note in the task.
And textureMain and A can be approved but textureB maybe needs some small adjustments
-Example 02
We’ve got a show with some “creative” comp shots. for some of these cases we already know that we need to create 3 versions of that shot which the client will decide later on which one will be finalized, this way again, we can have 1 nuke/aftereffects file where we can create the work in, but we can publish to the different variants to address feedback on just one particular version, we can omit the versions that we don’t need in the end.
But we can (in the hopefully near future) track time on it, which will also be important.
My suggestion would be a variant task.
So a variant task you can only add to a task.
You can name it, and have all the things setup in the overview. task progress, publish to it. (maybe don’t have someone assigned to it as you’re working from the same file that should be inherited from the mainTask
But if you open a variant task from the launcher or the browser, you’ll just open the asset/shot from the parent task and no other project file will be created.
I am aware that this can cause issue’s as you’re working in 1 work file, and can alter other versions if not careful (luckily we publish the work file along so we can always revert back)
Maybe if variant are present we can have a popup when the program start that you’re working with variant in a single file.
Also described here
https://community.ynput.io/t/defining-product-variant-ahead-of-time/1368
Log in to comment and vote
Comments5
Mustafa Zaky Jafar
The more I read through discussion here and on forums, the more I think you want something like
milestones/sub-tasksper task.Let me summarize these discussions while adding my 2 cents.
The current situation:
Currently, variants are totally under artist control and creator tool can show suggestions (set by admins) but artists are still free to name the products whatever they want.
Possible solutions:
Use proper communication e.g. adding todo list for artists and follow up with them.
Add more tasks and omit the unnecssary ones while you go. e.g. keep task A and omit task B.
Template workfiles, they can be quite useful where artists can always get a workfile with pre-created products.[Not implemented], you can have a system to force particular products to be created or exist on each task.
[Not implemented] we can add
milestones/sub-tasksper task which imo sounds like tracked todo list per task.robert okker
Use proper communication e.g. adding todo list for artists and follow up with them.
-thats the problem now, you can add them thats fine but you cant track them.
How can you easily track the status of that variant?
You cant in this instance
Add more tasks and omit the unnecssary ones while you go. e.g. keep task A and omit task B.
-but by creating new task you’re creating new tasks, not variants, so a small change or a small variant will create a fully new work file etc
Template workfiles, they can be quite useful where artists can always get a workfile with pre-created products.-not enough control from production and or supervisor,
[Not implemented], you can have a system to force particular products to be created or exist on each task.
-doesnt sound really flexible, should be easy as just creating a new variant to track
[Not implemented] we can add
milestones/sub-tasksper task which imo sounds like tracked todo list per task.-a sub-task should be the way to go.
A sub-task should work, but again, we’ve to be careful not to create a new taks. (or at least have this option)
So a sub-task should could open the same workfile as the parent, its almost more and empty task where you can publish to, it doesnt create a folder structure on disk and sub-task are automatically filled in into the variant dropdown menu.
Variants are such an important workflow thing, it saves massive amounts of artist time to just add little tweaks instead starting over or having to do difficult in-exports etc.
Luke Inderwick
A strong use case for sure.
Do you think “sub-task” would solve this?
A sub-task isn’t a full on task within a task but something smaller.
A sub-task always lives on a task and can have a name, assignee, status (done/not done) and start/end date. Sub-tasks will be taken into account in the pipeline when launching a task.
robert okker
well to a certain part yes.
If we could open the work files from the mainTask then it could work.
Or we could off course just add a taskType that is called variant and make sure no program is attached to that so you cant open it with hose (sort of hacky workaround)
And then subtasks could work. there is only one big but….
How is that getting resolved in the folder hierarchy when published etc, although now with ayon artist rarely are looking on the server anymore as they get them all in trough ayon, i’m a bit allergic to a messy structure ;)
Milan Kolar
Actually that is exactly how our upcoming subtasks are designed. They don’t provide a new workfile (well depending on your anatomy), but instead just act as a simple division of work within a task. I have a feeling that they match this use case pretty much exactly.