Code Monkey home page Code Monkey logo

Comments (5)

mottosso avatar mottosso commented on July 24, 2024

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.

BigRoy avatar BigRoy commented on July 24, 2024

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.

mottosso avatar mottosso commented on July 24, 2024

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.

BigRoy avatar BigRoy commented on July 24, 2024

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.

mottosso avatar mottosso commented on July 24, 2024

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.

Related Issues (17)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.