Integrator file naming about pyblish-magenta HOT 5 OPEN

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

from pyblish-magenta.

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?

from pyblish-magenta.

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

from pyblish-magenta.

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?

from pyblish-magenta.

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

from pyblish-magenta.