Creating a Custom FX Asset Type and Folder Structure in ShotGrid

Pipeline Integrations
1

Hello,

At our studio, we’re exploring the possibility of creating a new Entity Asset type. Specifically, we want to separate FX asset types and store them in a distinct physical location within our schema.

Our desired folder structure is as follows:
Schema folder
|-project location folder
|- assets
| - sequences
| - FX ← this folder we need

We have a general idea of how to create this structure, but we’re uncertain about linking the necessary fields. Is it possible to create a Collection Entity similar to Asset in ShotGrid and name it FX?
We are aware of customEntities; could they be of use in this scenario?
Has anyone implemented something similar?

2

How would the new FX asset type differ from other assets?

You could use a “Type” list field on the default asset entity and organize your assets like that. For example:

Type List
FX
Vehicle
Character
Building

This way your assets remain under the same umbrella and can be tracked, resourced, scheduled together. Creating a new custom entity to track an asset will also force a bit of a new branch that would make production management tricky imo.

3

While they are not significantly different, we would like to store FX-type assets in a separate location on the physical disk within the Shotgun schema.

In our templates, we currently have these options:
shot_work_area_houdini:
definition: ‘@shot_root/work/houdini’
root_name: ‘some_disk1’

shot_publish_area_houdini:
definition: ‘@shot_root/publish/houdini’
root_name: ‘some_disk2’
etc…

We want Shotgun to save FX assets type on disk2 and all other assets on disk1.
Can we utilize schemas to achieve this? We are considering using a custom entity as one potential solution, but we are open to suggestions for a better approach.

4

IMHO, if the new entity doesn’t give you anything more than that asset entity then the location of the FX assets should be handled by your template.

Creating a new entity and make it behave like the asset entity could be a lot of work as FPT has some assumptions and rules as to how it deals with the Asset entity type.

We do something similar using pathing template. We have a default value and then an override.

You could do something like

asset_publish
definition: ‘@asset_root/@type/publish/houdini’
root_name: ‘some_disk1’

asset_publish
definition: ‘@asset_root/FX/publish/houdini’
root_name: ‘some_disk2’

5

This could work, maybe we can make that

thank you!

6

Hello,

Unfortunately, this approach doesn’t work for us.

We have multiple servers and have organized our assets in the following way:

Simulations and related renders are stored on disk1.
All other assets are stored on disk2.
The problem arises when we try to override paths—it ends up overriding all of them.

Here’s our initial setup:

  shot_root: sequences/{Sequence}/{Shot}/{Step}
  asset_root: assets/{sg_asset_type}/{Asset}/{Step}    
  sequence_root: sequences/{Sequence}

   asset_work_area_houdini:
      definition: '@asset_root/work/houdini'
      root_name: 'secondary'

We attempted the following solution as suggested:

  shot_root: sequences/{Sequence}/{Shot}/{Step}
  asset_root: assets/{sg_asset_type}/{Asset}/{Step}  
  asset_root_fx: assets/FX/{Asset}/{Step}  #fx asset root path
  sequence_root: sequences/{Sequence}

   asset_work_area_houdini:
      definition: '@asset_root/work/houdini'
      root_name: 'secondary'
   asset_work_area_houdini:
      definition: '@asset_root_fx/work/houdini' #now we override
      root_name: 'secondary'

Unfortunately, our tk-multi-workfiles2 can’t correctly resolve the paths for assets, as it gets confused by the overridden paths and attempts to save every scene there.

Ideally, we need a solution where our configuration can dynamically change each time we select an FX asset in tk-multi-workfiles2.

@Rachit_Singh did you had any problem like this when you override paths?

7

Hey @banjac90 you will need to make use of the include: key in tmplates.yml to override keys that already exist, but this may not make sense for your usecase.

See: Template.yml per-project includes - #7 by tannaz

To achieve your original goal, you can have similar definitions but different named templates.

   asset_work_area_houdini_default:
      definition: '@asset_root/work/houdini'
      root_name: 'secondary'
   asset_work_area_houdini_fx:
      definition: '@asset_root_fx/work/houdini'
      root_name: 'secondary'

Then any tk-apps or engines using these template names in configurations would need additional environment yml files configured with these values, and the pick_environment.py hook (tk-core/hooks/pick_environment.py at master · shotgunsoftware/tk-core · GitHub ) would direct to the appropriate environment yml based on the context (ie. FX asset type).

8

Thank you very much!

I will try it right away

9

Hello,

Thanks to @Halil , I was able to resolve our use case.

First, to correct myself: we needed to separate every FX step, not just assets. So, every FX step goes to a different location, regardless of the asset type (FX, LookDev, etc…)

It wasn’t so hard in the end. :blush:
I did need different YAML files, but only one additional file:
asset_step_fx.yml. with usual asset_step.yml.

asset_step_fx.yml.

engines:
  ...
  tk-houdini: "@settings.tk-houdini.asset_step_fx" #instead of @settings.tk-houdini.asset_step
  ...

In the templates, I separated the definitions:

    asset_work_area_houdini:
        definition: '@asset_root/work/houdini'
        root_name: 'secondary'        
    asset_work_area_houdini_fx:
        definition: '@asset_root/work/houdini'
        root_name: 'quaternary'

Additionally, tk-houdini, tk-multi-workfiles2, and others now have separate definitions for FX templates. Here’s an example for tk-multi-workfiles2:

tk-multi-workfiles2

# asset_step
settings.tk-multi-workfiles2.houdini.asset_step:
  ...
  template_work: houdini_asset_work
  template_work_area: asset_work_area_houdini
  ...

# asset_step_fx
settings.tk-multi-workfiles2.houdini.asset_step_fx:
  ...
  template_work: houdini_asset_work_fx
  template_work_area: asset_work_area_houdini_fx
  ...

The rest was resolved with pick_environment.py which directs the appropriate environment YAML:

        if context.entity and context.step:
            # We have a step and an entity.
            if context.entity["type"] == "Shot":
                return "shot_step"
            if context.entity["type"] == "Asset":
                if context.source_entity.get('step', {}).get('name') == "FX": 
                    return "asset_step_fx"
                return "asset_step"

I’m sharing this code here in case anyone else might find it useful in the future.

Thank you again!

4 Likes