-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loader - allow asset multiselection and bulk load #453
Comments
Interesting. Visually it looks neat (I like that bar on the left hand-side). Nice job. To understand correctly it's grouping the right hand side (Subsets) into 'randomly colored' groups per subset name so that still all the individual publishes of each asset can be seen. You are also unhiding an Asset column so there it's also clear from what asset each subset comes from. I wonder how much speed-up this delivers as you work through it as an Artist. As I can imagine you'll still need to scavenge through the right-hand side. But I can imagine someone set dressing with solely models just selecting all assets on the left-hand side and and then limiting families to only I'd love to try this out and maybe let some artists play to see if they have comments or remarks. Also, I just wanted to link this video as a reference from Pixar on how they load setdress models. It could inspire more things. |
that's precisely what's going on.
To us a great speed up actually. We were just making a town and some forests. In both occasions we need to bring a lot of assets it and with this and consistent naming, it's a single import action. Selecting all assets that start with For trees for instance we'd have multiple variants as subsets in each asset, so Oak would have When we prepare the code to be compatible with core, we'd love for you to try it out and give more feedback of course. |
yeah that looks like USDs with proxy looks already applied. With avalon we'd normally first load models and and apply |
This particular tool could just be forcing to load a "model subset" of course, hence it being simplified. However, I'll try and refrain from going into that particular video too much and try to keep this issue discussion related to your approach. |
This feature could be interesting for making on-demand edits of different subsets. |
What kind of on-demand edits would you want to be making to different subsets? Not sure I understand your use case. :) |
The workflow is to find the types of versions we want (animation, plate, lighting, compositing) in Ftrack, and RV (but any sequence player could do) to sequence them together for reviewing. With this feature we could do the same but in Avalon. |
Just a note that this feature has been deployed to a few of our clients for a while now and the artist feedback is overwhelmingly positive. It's literally used on a daily basis, so we're very happy. We'll prepare PR soon. |
Problem
This is a repeating request from multiple clients to speed up set dressing. Usually when set dressing artists need to import a lot of assets at the same time especially when making cities forests and similar location which need a lot of individual assets with smaller variation in them. Currently this takes ages, becuase to import 10 trees (unless they are subsets) I need to click on asset, right click subset, load...repeat.
Proposed Solution
The solution would be to allow artist to select any number of assets on the left, which would show the union of all their available subsets on the right. The artist could import say 10 buildings at the same time. The problem of course is knowing what subsets belong to what asset and so on. We've tried solviing this with some grouping and color coding to make it clear what is going to be affected. I'm attaching a preview without much more explanation in hope that the UIX is clear enough on it's own, If it isn't we might want to think a bit more.
We've deployed this to testing now and the first feedback from artists is very positive. Have a look
Additional context
Combined with #346 this might become mighty set dressing tool.
To make PR we'll first have to get in line with current state of avalon-core, which is almost done, so we have some time to discuss possible changes.
The text was updated successfully, but these errors were encountered: