-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a format representation sequence path function for Loaders #821
Comments
A form of this was implemented with ynput/OpenPype#4313 - the template would be used to generate the path with the tokens in it. |
This is still relevant - but may be superseded by some openassetio logic being worked on by @antirotor |
Is your feature request related to a problem? Please describe.
Many loader plug-ins involved quite some code on finding the right file or file pattern for a sequence. They are trying to construct patterns like:
These currently all appear to be implemented over and over again, and also appear to parse this data from the filename itself even though most of these frames or udims or alike is information that was available at the time of publish.
Some examples
20
of the subset name todot
in front of the frame number even though I believe that's customizable to be another frame separator in OpenPype and something similar for Houdini's VDB Loaderos.listdir
and thenclique.assemble
A lot of these implementations have many points of failures. E.g. most of the
os.listdir
usages don't even check whether the result is a file and has the right extension - it might just pick up any other file in that folder instead. But the essence of what they are trying to do is mostly the same, and its detecting and formatting the following:####
or<f>
or$F4
etc.Describe the solution you'd like
I'd like a single recommended (and documented) approach on how a loader should retrieve the files of the publish and preferably even expose
get_representation_sequence
orformat_representation_path
or something along those lines that would make this loading logic of sequences in a certain way easily manageable for the developer implementing a Loader plugin.The tricky bit is if the function itself formats the path like e.g.
/path/to/publish/v001/filename.%04d.exr
that would make it non-trivial for the loader plugin developer to detect whether the files exist on disk or not. So we might need to consider also returning the full paths easily.Describe alternatives you've considered
The alternative is to pick one of the different implementations found in the codebase and use one, but they don't seem foolproof and generally result in many lines of code extra to maintain in a loader.
Additional context
There is an existing
get_representation_path
function which I believe returns the first filepath of the representation.[cuID:OP-4791]
The text was updated successfully, but these errors were encountered: