I’m trying to build an asset lib project for our studio, pretty standard stuff, one project to house all the assets we may want to use in the future on other shows.
I’m trying to build a sort of ‘one-stop’ solution though to allow:
A supe (for example) to go to the library and find Assets owned by the lib ‘project’
And, importantly, Assets ‘linked’ to the lib from other actual shows/projects.
The purpose of this would be so that, as we go through a show, we can link the actual show Asset to the Library for two reasons:
So that at the end of the show/project we have a neat list of everything we want to re-publish to the Library
And so, as the project goes on, we have somewhere to go if for example a supe wants to poach an asset from another live project; without having to dive into every project to check what they might have.
I’ve been exploring cross-project linking, and I see there’s an “AssetShotConnection” entity-relationship view you can enable which kind of does what I need.
Per this Autodesk article: Help | Cross-Project Asset Linking | Autodesk
I can view that in the Lib and filter for all entries where the “Linked Project” is the Lib project, however that ends up showing multiple entries per-asset because of course it’s an Asset<>Shot connection view; i.e. it’ll show one entry for every single time that Asset is linked to a Shot.
So, in theory, I could just enable “AssetProjectConnection” in ShotGrid site prefs right?
Well, that doesn’t seem to work and even worse it has broken my AssetShotConnection pages now, which is fun (off to Autodesk Support I go! ).
Has anyone got some magic solution to this?
I guess I could maybe make my own project entity link on the Asset level and then try adding that connection in site prefs; like AssetRelatedProjectConnection.
For sure I could easily just make a global/shared page and call it a day, but what’s the fun in doing anything the easy way!
Me and @thomass have been toying with a similar idea to this. We haven’t found any good solution, and also, a base asset used on two projects, might actually have turned into two new ones. (A plain chair could have become more weathered in one project, and might look broken in the other). How to treat this would be a philosophical question I assume.
One way could be to have an event deamon, copy pasting an asset into your asset library once it reaches a certain state (done) and add a few parameters on the copied asset, such as what project it originated from. That way you would have different assets of the same which would make it easier to re-use directly.
Doing that could be with another event deamon or script that would let you copy the asset from the lib into a new project. What would also need to be done then, is to create the new folders on your network etc or to use existing folders. not sure how that would work in practice.
Thanks for replying with your experience, nice to see how other people are operating within these parameters.
What you’ve ended up doing sounds similar to where I landed in the end; a necessary ‘good enough’ case.
Our process is basically now:
Supes, as a show is In Progress, use the ‘Linked Project’ field on the Asset level to link a Show’s asset to the Asset Library.
I have a shared/global page looking just at Assets where the Linked Project is the Asset Lib
This is a workaround for the fact that, despite there being cross-project linking, you can’t seem to just grab a list of what has been linked to the ‘linked’ project
I’ve made a URL page on the Asset Lib which just points to this global page as a poor-mans workaround, and I have this other question for trying to remove the nav bar: Embed ShotGrid Page in ShotGrid Page - Hide Nav
When a show is done we review the global page of what has been linked and decide what to migrate.
It’s great to see someone having faith in a status-driven trigger but for us we have an Asset-level AMI to migrate to the lib, the AMI will only work if the Asset is Approved as a sort of nuclear-weapon two key turn type deal
What I like about your approach is in considering variants and generational asset improvements/changes show-by-show. That’s a great idea to then back link the migrated asset to the originating project so you have a path to later identification.
For the on-disk process, we did consider symlinking back to the original asset but went with a full copy migrate instead.
We archive all our shows to nearline then tape to adhere to client 6mth > 3yr backup policies so we’d prefer to keep our lib in one consolidated directory.
Interesting. We haven’t progressed in our ambitions here, but it is also based on the low need for it.
However I think it could be cool for @fptr_managers to consider some sort of Default asset project with some built in features, that always aggregated all assets from all projects into one place. But with all our various pipelines, I am guessing that this is not that easy.
Ah and have that page completely independent, I didn’t think of that. And make that page a grid view, that could have been a nice embryo to start with.
).