I was wondering is there a exposed way of tracking asset instances in shot?
Use cases
Production telling artist what assets are there in a shot. This way layout can procedurally builds the scene where it brings in the right assets?
1uery how many asset instances exists on the shot and then query the published file database for the file paths which build the lighting scene?
Production telling artist which asset instance are deprecated. Which mean even if the published file exists for that asset instance, the scene builder ignores this
Maybe I’m misreading this, can you not use the “asset” field on a shot?
Sure, but I don’t see any option in telling the layout how many iteration/instances of the asset should be used for the shot?
You can only link one asset entity only. Now if there was field we can edit to specify a quantity then we can get somewhere.
We still have an issue about how does production convey to artists that a asset instance is depecrated from the shot, eg layout generates a cache of 3 humans but the client decides that human 2 is longer in the shot. We need a way to tell lighting not to pick up that human 2.
If there’s more than one instance of asset “human” in two shots, and the instance “narrative identity” is uniquely identifiable from shot-to-shot (eg. “the human standing beside the red car”) then you have to make sure that when you remove them from the two shots, that it is the same “narrative” instance.
In which case you really want to have “named instances” – ie. an AssetInstance custom entity …which doesn’t exist :-/ …and the shot will need another field asset_instances, since the “asset” field is locked to “Asset” entities only.
Hoping I’m not overthinking this, but I’ve run across this a few times and it always ends up being an ad-hoc manual repair job for someone downstream: in “shot_a” they cache the human standing beside the red car as “human1” and in “shot_b” they cache it out as “bobby13x”. Which makes it a bummer for lighting.
Hope you have the bandwidth to do a nice elegant, over-engineered solution
In my experience if you want a count of instances of an asset in a shot Matt’s approach of using the connection entity is enough.
If you need to store per asset instance data (their location in a scene for example) you could still get away with the connection entity approach by adding something like a text field to the connection entity and having your pipeline dump serialized data of all asset instances in that field. This, however, isn’t super user friendly and might not scale.
If you need more precise per asset instance data, you’ll need to go down the route that @dougm suggests which isn’t that hard.
Enable a custom project entity and call it AssetInstance
Create a multi-entity field from Shot to AssetInstance
Create a single entity field from AssetInstance to Asset
Add any meta data tracking fields required by your pipeline to AssetInstance
Hi Patrick! We’re going down the route of an Instance entity. Since it would seem that the definition of an Instance is “a single relationship of an instance of a single Asset appearing in a single Shot”, why create a "multi-entity field from Shot to Instance"? Wouldn’t that result in a (reverse) multi entity Shots field on the Instance schema? Shouldn’t that be “create a single-entity field from Instance to Shot”? Not to question your infinite wisdom… I’m basically wondering if we’re overlooking a use-case.
I guess this boils down to how you’re using and defining your “instance”. If it is indeed tied down to a specific shot, a single entity link fromInstancetoShot (creating a multi entity reverse) would be perfect.
If however you’re defining an instance as more of a variant or override, in that case having a single instance linked to multiple shots might make sense. For example, a single asset’s position or texture override might make sense in multiple shots.
This being said, based on your reaction, the former sounds like it might be making more sense in your case.
