Integrator file naming

[BigRoy]

The current Integrator is naming the integrated files based on the families of the extractor.

For example the output model, a mayaAscii file, gets saved to <asset>/publish/v001/model.ma.

By using this naming convention we introduce a couple of downsides:

1. We can't have multiple extractors with a same family and extension to be integrated correctly at the same time. For example having two review cameras in the scene will extract both (with same extractor) but integrate only one (since it will overwrite the first with the last integrated since they have the same name). The same would also happen with two extractors extracting a single instance with a same extension.
2. The files will be called model.ma, review.mov, review.gif, etc. Most applications will use solely the filename to display what file it is. For example when referencing the file in Maya the reference editor will solely display model. The same would be for video players solely showing review. It would be much clearer if they would also display the asset's name. Therefore it might make more sense to prepend filenames with the asset's name, like for character ben: ben_model.ma, ben_rig.ma and ben_review.mov.

The reference editor in an animation scene would then be able to show:

- ben_rig.ma
- window_model.mb
- gun_model.mb
- gun2_rig.mb

A custom UI could also solve this (and it should in the long run for managing references!), but since most applications show at least the file name I think it's great to have this information available to you even if you step into a custom viewer (eg. Quicktime, a browser, Maya or another tool not using a custom scripted interface for the pipeline).

I'm raising this issue to see if we can get to a better naming convention for our published files, or whether there are enough pros to stick with the current one.

What do you think?

[mottosso]

Sounds good.

For example having two review cameras in the scene will extract both (with same extractor) but integrate only one (since it will overwrite the first with the last integrated since they have the same name)

This is reason enough to add an additional layer onto each file-name I think.

Most applications will use solely the filename to display what file it is.

This on the other hand is a bit of a pandoras box. It makes you rely on the software to display metadata about your file, which begs the question, what metadata should be shown? And once you've decided, it will be unchangeable and forever imprinted into all files.

Metadata is better left to other things, file management is complicated enough as it is to also have to worry about what some applications choose to visualise files as.

Therefore it might make more sense to prepend filenames with the asset's name, like for character ben: ben_model.ma, ben_rig.ma and ben_review.mov.

+1

[BigRoy]

This is reason enough to add an additional layer onto each file-name I think.

Ok, currently I'm testing the following layer of naming:

output_name = '{asset}_{family}'\
              .format(asset=data['asset'],
                      family=instance.data('family'))

# If this is a variation append it to the name
variation = instance.data('variation', None)
if variation is not None:
    output_name += '_{0}'.format(variation)

output_name = output_name.lower()   # ensure lowercase

This would result in:

- ben_model.ma
- ben_rig.ma
- ben_review_turntable.mov
- ben_review_turntable_high.mov

In this above output the CollectCameras adds the retrieved name as variation data so it saves the name of the camera (without _CAP) within the file's name.

This would mean the selector provides additional information about whether it would need a variation suffix. In this scenario a single selector could do it based on a name or attributes on a node in the scene to extract multiple variations of a single asset, eg. low-res and high-res. Into something like this:

- ben_model_low.ma
- ben_model_high.ma

With this layer of naming there currently isn't anything to ensure the variation that is appended to the name is consistent with how one wants to name low-res and high-resolution versions. (Or maybe we have additional levels of versions?)

In theory one could implement a Validator, for example: ValidateModelVariation.

# pseudocode
class ValidateModelVariation(publish.api.Validator):
    def process(instance):
        variation = instance.data('variation', None)
        assert variation in [None, 'high', 'low', 'proxy']

I'm not sure this is the best way forward. What do you think?

[mottosso]

Where did "variation" come from? I think it sounds too complex. model, rig, lookdev etc. is already subdividing an asset, why not just keep on using those?

• rigLow
• rigHigh
• modelHigh
• modelLow
• modelPink

[BigRoy]

Where did "variation" come from? I think it sounds too complex. model, rig, lookdev etc. is already subdividing an asset, why not just keep on using those?

I'm more thinking about where the information or extra naming comes from. Are you saying that we make additional families?

How would that work for example for the CollectCameras that captures each camera? Would each camera be its own family?

[mottosso]

How would that work for example for the CollectCameras that captures each camera? Would each camera be its own family?

Each camera could have it's own name, like turntable, face and problemArea etc. which would end up as ben_turntable.mov, ben_face.mov, ben_problemArea.mov. If the family is to get included, maybe that could be a parent directory?

v001
└── review
    ├── ben_problemArea.mov
    ├── ben_turntable.mov
    ├── ben_turntable.gif
    ├── ben_face.mov
    └── ben_face.gif