The current setup expects that you are always contributing to the immediate asset you are in. How would this work when you need a more robust work structure by using e.g. Ayon VariantAsset? A work structure like:
vehicles {ShowAsset}
porsche911 {SubAsset}
main {VariantAsset}
damaged {VariantAsset}
The publisher does not recognize that I want to e.g. contribute a damaged model to porsche911 because I can’t pick the target asset. Would it make sense to be able to contribute to parent assets?
This would help so much with managing work files and not compile all the work files under a single asset. Especially when build many many variants for a single asset.
I would have expected the first questions to be ‘how can we simplify the configuration’ instead of ‘how can we extend it’.
In this case however I wonder why you need separate folders.
It should be entirely possible to contribute from e.g. separate tasks on a single folder to different variants within the current folder’s target product (usdAsset). So that the variants do not need to be from the same workfile. This is actually what I would recommend.
However, if for whatever reason you want separate assets to work in but one target asset I believe it should be capable of publishing your products to the other folder - and then it should also do the asset/shot contributions to the target product under that other folder.
Note: that I am using folder as terminology instead of asset because that matches better the terminology used in AYON and avoids the confusion about where we are referring to the USD asset file instead of the folder entity.
Would love to see what you’re already doing with the system to see where you get stuck! Screen recordings are welcome
I may follow up then with a recommended workflow example recording from my end if that helps.
Which workfile contains the latest damaged variant and which one has the main variant?
Now scale this up, 100 workfiles containing 5 variants and keeping track of what version contains what variant.
That is why having separate folders for each variant is very helpful. Not impossible, but super helpful.
Awesome.
ah, sorry. I was using ftrack terminology earlier. So sorry about that.
Unfortunately we are a TPN studio so we have a closed network. We can’t do screen recordings or have any internet access on our workstations.
In short the system is working great as it was intended to be used. I get stuck once I try to use it as we prefer to work i.e. a folder for each variant. So if I’m modeling and I’m in the “main” folder (and I put “Main” as my Ayon variant), the asset hierarchy it creates is Main:main/geo/. Just like one would expect but not the contribution I want.
I understand that this might touch on how variants are fundamentally perceived in Ayon and might not fit with how we would like.
What I meant was - you can have multiple tasks under the folder. This way you can also assign different users to each task, track their status separately and for your use case - they’d also each have their own workfiles. Win-win.
Shouldn’t that solve it?
I think also this, may be better solved by using tasks instead of separate assets. But I’ll tag @milan and @murphy to see if they have remarks on your approach from a different POV.
But you could have e.g.
model_main (modeling task)
model_damaged (modeling task)
look_main (look task)
look_damaged (look task)
All under one folder asset/char_hero for example.
My next question was going to be about purpose contributions.
Let’s discuss it! But, can you create a separate topic for that?
That’s a good idea. I did not realize you could have multiple tasks of the same type per folder. Let me bring this up with the team. Thank you!
(The only issue I see is we need to make sure artists use unique Ayon-variants across all modeling tasks within a folder so they don’t clash when publishing. They should then make sure to use the task name as the variant.)
No worries, I was half joking. Although I do care about adding purposes I was not about to ask for it.
There is actually a trick where you can enforce this - by using product name profiles to include the task name in the product name. However then I think you may get issues with the default target variant {variant} because those would not be unique.
Anyway, definitely stuff to play around with I’d say. Let me know where you land and what worked and what didn’t.
Although I do care about adding purposes I was not about to ask for it.
You asking about, already gives me purpose. By all means, don’t feel held back to create topics for those. They don’t necessarily have to be in the realm of “make this for me now” (preferably not, hehe) but a “would this be nice?” or “how could we do this?” topics are welcome!
I tried this out in a tmp project and it worked well for the most part. The only small hiccup was when I loaded the usd into Maya. Then all the variants loaded under the same item called “Render” since that is what we call all the variants in the publisher. After replacing {variant} for {task} as an input for the “Variant Name” (in the USD contribution publish settings) they now assembled under their own separate items and I can switch between the variants. Just wanted to point that out.
… yeah. My next question was going to be about purpose contributions. 
Although I do care about adding purposes I was not about to ask for it.
