We’re trying to work out what to do about file sequences when read by a file format plugin. Suppose I have a sequence of OBJ files numbered foo.001.obj, foo002.obj… and want to make a value clip which ties these into a single animated object. We run into a whole bunch of problems. File format plugins don’t understand sequences, so what we get if we read these files (say, using the Adobe plugins) is that each file is treated separately. The prim name is based on the file name, so each frame has a different prim path. The attribute values are set at the default time, not as time samples, and there’s no metadata for the start and end time, all of which are required to make a value clip.
I’ve written some terrible Python code to massage file sequences into something that can be given to usdstitchclips, but I can’t help feeling that this could be easier if file format plugins were aware of time. A plugin could perhaps, parse file names to see if they conform to the format used by usdstitchclips (foo.###.obj) and if so, use time samples, set the start/end metadata and not include the time in the prim path. This behaviour could perhaps be controlled via an argument to the plugin. For our own plugins, we could implement this, but it would be good to know what everyone else does and whether there’s a possibility of coming to some standard. The ideal result from my point of view is that somebody points me to the part of the API which already sorts this out, but which I haven’t yet found.
I can confirm there’s no core API’s to help you do this, but it absolutely could be implemented by a FIleFormat plugin designed to do so. Making it be a dynamic FileFormat would make specifying the arguments a little easier (though would constrain you to using payload arcs to bring them in).
The plugin can’t generate clips (external files), so would be producing a “flat” layer that contained all the data/timeSamples, and generating the complete animation could be done lazily by the plugin. But also highlights the complexity of making the plugin robust: because scene topology cannot be time-varying, unless the plugin operates under the assumption that all the input files contain the same topology, it will basically need to do everything that usdstitchclips does, e.g. generating a unioned topology to present when the “layer” is first opened. And that’s true even if you added arguments to the adobe plugin so that it could just present each obj individually in the form/layout you require… and in that case you’d still want a “primary clip container” FileFormat with its own extension that simply creates a ClipSet and fills in the data (and topology) needed to access the individual obj’s as clips… if that makes sense?
Thanks for the reply. This actually goes further than I was envisioning in that I wasn’t expecting the plugin to make a complete animation or the extra value clip files. I just wanted the plugin to produce a single time sample in a form that could then be fed to usdstitchclips. Currently, we’re using Python code to read each source file, clear the default value for each attribute and write it back again as a time sample, set the stage metadata and write the stage out again as a crate file. Then we feed the crate files into usdstitchclips. It would be nice to avoid the nasty Python step and just create the value clip from the source files. Of course, the conversion to crate files makes everything much more efficient in the end, so we can think of that as a feature rather than a bug.
Another possibility would be if perhaps the value clip mechanism could allow default-valued attributes to be treated as time-sampled. You’d need to specify which attributes you wan this to apply to, and I’m sure I’ve not thought of all the implications….