I guess multi entity fields are dictionnaries, as it’s impossible to use a calculate field to get them either:
‘assets’ type (Multi-Entity) is not supported in calculated fields. Currently supported types are (Calculated, Currency, Duration, Float, List, Number, Percent, Text)
Is there a way to link assets to a shot in a list, so that we can multiply the same entries?
Simply getting the asset name would be ok as long as user can only enter real Asset entities names
Thanks for your message - the Assets field on the Shot entity will only allow you to populate Assets that already exist, as long as they don’t have “Create” permissions for Assets. When you try and populate an Asset that doesn’t exist, a little prompt asks if you want to create this Asset, but if you have permission turned off, it won’t let the user do this.
It is not possible, however, to have the same Asset listed more than once.
May I ask what your reason is for needing to add the same Asset multiple times? Are you trying to log the number of times that specific Asset was used in that Shot?
I am working on a tool which will build maya shot scenes from the ground up, based on shot assets list.
We may need to load several time an asset in the 3d scene (in my screenshot in first post, we would need the prop “ballon” twice for instance)
Is there any other way to easily list assets on a shot?
It seems a possible way is to use Asset Shot Connections:
By adding an integer field “multiple”, users can chose how many times an asset is to be loaded in a shot.
While being really practical to use the API, It seems like a really convoluted way of listing things for users:
• They don’t get the information on the Shots page,
• They have to use several different pages to input very closely tied data
• They can’t easily copy paste their multiplicator
It would be way more quick and efficient for them to just list their assets in a Shot Field like ‘assets’, but which would be a list (as they would be able to populate this list with multiple instance of a same item).
Connection Entities are definitely the way we’d recommend tracking something like multiple instances of a given Asset in a Shot. There are a couple of ways you could go about more quickly entering in how many instances of each across multiple Shots.
First Method
On your Shot detail page, ensure you’ve exposed your “Instances/Count/Quantity” field on the Assets tab. Then on your Shot page, enter into Detail view. There you can quickly switch between Shots and enter the quantities.
This other method involves exposing a List page for the connection entity itself. To do this first navigate to your Site Preferences > Advanced > Enable List Pages for Connection Entity Types. In the text entry box there, add AssetShotConnection. Save your changes.
Navigate back to your Project and in your “Other” menu in the project nav you should see an “AssetShotConnection” page now available that looks like the screenshot below. Here I’ve grouped the connections by their Shot, and I can quickly go down the list entering in quantities of each Asset in each Shot.
I ended up using your second solution, and designed a page for users who do assets breakdown lists so that they can get both pannels side to side as widgets:
Great solution with the canvas widgets! I agree, a page-wide filter that could affect multiple widgets at once would be useful. You can send your ideas directly to the product team; this post explains how.
Just wanted to clarify, does the Shotgrid DB use the two entities used in the connection as the primary key in the database?
For example, with the AssetShotConnections entity mentioned above, when I try to create a new AssetShotConnection instance with the same Asset/Shot values that already exist in another instance, I get this error message:
My desired setup on this entity is to be able to have multiple AssetShotConnection entities that share the same Asset/Shot connection, but other fields are different.
For example, if I had an “Instance Number” field to keep track of each individual instance of an Asset in a Shot, like this:
then I could store other things unique to this connection, such as PublishedFile entities that are specific to a certain character.
With this method, on the “Shots” page, I would like to be able to also merge two fields to create a unique display name for each of these AssetShotConnection entities like this:
I’m just curious as to why ShotGrid seems to use both entities in a Connection entity as the primary key (as shown by the error above), rather than just use the ID field like every other kind of entity in the DB.
You could make this more complex by adding a Variation Group so that you can publish files to a Variation Group and not its individual variation, but use the Variation entity to track the Shot Build table.
When someone creates a multi-entity field it creates a new database table that contains a unique constraint on the id of the two entities used in the connection. Connection entities are not behaving like others entities, they are a way to do a many-to-many connection but it cannot contains duplicate. Also, multi-entity fields are not available on connection entities.
With the details given I can think of 3 ways of storing the informations:
Duplicating the asset entities for each different PublishedFile and use those in the connection entities
You cloud also create another multi-entity field per instance, but that does not scale well
Use a customEntity to define the different instances like Ricardo suggested
I believe that Ricardo’s idea should provide less data duplication…
Can you explain what you mean by “there are a way to do a many-to-many connection…”? Can you perhaps provide an example of what you mean?
Can you explain this more as well? I thought you just said in the paragraph above that multi-entity fields are not available on connection entities?
What exactly the reasoning behind Connection Entities using the id of the two entities used in the connection as the primary key in the database? Isn’t this just locking down functionality for users? It would be great to know why the database was architected in this way, because right now it just seems like it may just be causing needless roadblocks for users like me.
Hello Bryce,
For the first topic I mean they (connection entities) are a way of doing many to many connection
As for the second topic, (like I said it does not scale well)
that would be to create multiple multi-entity field on Asset that allows shot and that could be named instance1, instance2, …, instanceX
Now about the database architecture, the connection entities were designed to provided additionnal details when two entities are linked together. Treating the connection entities like all other entities would bring some technical complications. It could be propose as a feature request.
an example of a Connection Entity and it’s functionality is the PlaylistVersionConnection entity that can store some additional playlist specific version info.
For example, it stores the Reason for Review field which is the Version Description as displayed in the Client Review site, and is playlist specific (but linked to the Version).
I did some reading on DB architecture so I can better say what I’m trying to achieve. I did a quick UML mockup with Vertabelo (I did not add all fields on each entity in the diagram for simplicity).
I think what I’d like to be able to do is add a new field (instance) to the AssetShotConnections (renamed here to AssetInstances), where I also use this new field (instance) as an additional primary key (PK) in the database. I want it to serve the same purpose as a many-to-many relationship of assets to shots, but to enforce uniqueness based on 3 fields: asset_id, shot_id and instance.
As a side note, this would allow us to associate a published file with a particular AssetInstance, which would be nice.
Is it possible to set what fields are primary keys in ShotGrid right now? If not, I can create a new CustomProjectEntity as mentioned by Ricardo, but that new entity would have id as the PK in the database, instead of the 3 fields mentioned above. Therefore I would have to enforce uniqueness manually when creating new AssetInstance instances by first querying the ones that already exist with the above 3 primary keys.
Would this work?
Actually create the Asset instances as Assets, and then link them to a Parent Asset using the existing Parent Asset/Sub-Assets fields? The missing part would be the link between the Shot and the Parent Asset, but you could write an Event Daemon to make that link based on Sub-Asset activity
Yeah that would also work, either that or a CustomProjectEntity.
You are not able to alter the ShotGrid Database in that way (altering the primary keys etc) considering the ShotGrid product runs on top.
However I would argue that you don’t need to either as we already offer viable solutions above. The experience can be improved with some custom tools to aid in the Shot Build workflow or some alterations to your Toolkit code.
As well as some design changes and custom page setups in the Web UI.
You can already do this if you would architect your schema to use either the Parent Asset/Sub Asset workflow or by adding a CustomProjectEntity.
Hello @brycegbrazen ,
I dont have the details on how all of those would be used but the schema that @Ricardo_Musch proposed should not have primary key validation to do on your end:
A customEntity(Instance) with:
an Entity field that points on Assets
a Multi-entity field that point on Shots
And on the resulting instance_shot_connection entity:
