Animation from file sequences

Community USD
1

I’m looking into loading animation via a file sequence, such as a set of numbered OBJ files. File format plugins will load each file as a prim with default attribute values. We need to convert these to a single USD prim with time samples for each frame. It looks like this can be done via a ValueClip, but in case it exists and I haven’t found it, is there any support for this type of thing in the file format plugin API itself? I can imagine the DCC passing a file path template, say, /assets/foo###.obj and the file format plugin could do the rest, The main issue I can see is that the individual file assets would need to be resolved separately. The template file name can’t be resolved because that file doesn’t exist, and asset resolution needs to be done before the file format plugin gets called.

Jerry

2

I’m not sure to fully understand what your issue is, but if you want to have a mesh defined by a sequence of individual files on disk, Value Clips are indeed what you are looking for.

For example, given a mesh.usda layer stored in the same folder that a serie of mesh.001.abc, mesh.002.abc, mesh.003.abc, etc, you could animate a mesh on 25 frames like:

#usda 1.0
(
	startTimeCode = 0
	endTimeCode = 25
)

def Mesh "TheAnimatedMesh" (
    clips = {
        dictionary default = {
            string templateAssetPath = "./mesh.###.abc"
            double templateEndTime = 25
            double templateStartTime = 1
            double templateStride = 1
            string primPath = "/ThePathToTheMeshInsideTheABCFiles"
        }
    }
)
{
}
3

Ah, sorry, I missed the part where you wanted the FFP itself to handle the template path itself.

4

Your observations are correct, @jerry.huxtable , and for that reason, there was a recent (25.05 or .08??) enhancement to dynamic fileFormat/payload attribute/argument resolving to ensure that asset valued inputs to the payload/format did get resolved before being converted to FileFormatArguments. I think we’d want to be cautious about introducing another template expansion at this low-level (and affecting composition-performance), especially in advance of considering the upcoming project to allow primvar and time/frame substitutions in asset-attribute values.

Back to your starting point, the big friction you’re going to run into with your default-bearing OBJ files as value clips is that value clips require timeSamples, ignoring default values. And I think the template-clips semantics require each clip to contain timeSamples in the range indicated by its template substitution, though it would be interesting to see what happens if each of your clips contained the same timeSample (since in that case, at least the value is held throughout the time-range… I suspect that GetTimeSamples() will malfunction, though.

5

While writting the (misguided) example above, I noticed that the templated layer paths wouldn’t be included in a USDZ archive:

usdzip.bat -a demo-valueclips.usdz .\mesh.usda

Warning: in _GetTemplatedClips at line 284 of C:\g\136396354\USD\pxr\usd\usdUtils\assetLocalization.cpp -- Clips directory 'F:\tmp\abc\demo-valueclips.usdz[.]' is not a valid directory on the filesystem.
Warning: in _EnqueueDependency at line 103 of

C:\g\136396354\USD\pxr\usd\usdUtils\assetLocalization.cpp -- Failed to resolve reference @./mesh.###.abc@ with computed asset path @F:\tmp\abc\demo-valueclips.usdz[mesh.###.abc]@ found in layer @F:\tmp\abc\demo-valueclips.usdz@.

I wonder what additional difficulty FFP level path templating would bring regarding USDZ generation ?

6

@charlesfleche , I consider that a bug in the localization code, which does attempt to resolve template clip asset paths. If you can boil down a small repro (preferably usd or abc clips, not obj), would you file a GitHub Issue?

1 Like
7

Here is the repro: usdzip warns, but works, when resolving templated value clip references · Issue #3851 · PixarAnimationStudios/OpenUSD · GitHub

However, upon closer look, it seems that usdzip emits a warning, but eventually creates a valid package.

8

Thanks everyone!

I discovered very quickly that value clips weren’t going to work for this. I got confused by this part of the value clip documentation:

By default, if a value clip does not contain time samples for an attribute, a time sample at the clip’s active time will be generated using the default value for the attribute authored in the clip manifest. If no default value has been authored, the fallback value for the attribute’s data type will be a value block.

I now see what it means :slight_smile:

We have control over the file format plugin though, so we could pass it an argument to say which time to generate a single sample for. Then we should be able to tie it all together with a value clip. Although I said originally we’d like the file format plugin to handle the sequence, value clips make more sense because they can load only the data they need for a particular time.