Looking at the usd export of a point deformed mesh, can see there's 400 frames of animation of position data, but then there's 400 frames of identical ‘faceVertexCounts’ information clogging up the cache:


Those entries run for the full 400 frames, just rows of 4 4 4 4 4.

A quick google says faceVertexCounts is as it sounds, the number of verticies per poly. It also says that if there's time entries, it's there because the mesh is changing topology over time.

I know in this case the mesh topology doesn't change; It's a plant that we're loading, adding a bit of keepalive wiggle, and writing it out again.

Is there a way we can tell lops this, so it doesn't write out all that needless per frame data?

Annnd naturally I find it after posting:

so USD isn't smart enough to figure this out upon stitching?

If it's all dependent on that manual dropdown how would one optimize changing topology that changes just once at f 200? where in theory you need just 2 timesamples instead of 400

tamte
so USD isn't smart enough to figure this out upon stitching?

If it's all dependent on that manual dropdown how would one optimize changing topology that changes just once at f 200? where in theory you need just 2 timesamples instead of 400

The usdc format deduplicates data in the file, but it's up to the file writer to limit the time sample data to just those that are meaningful. Since houdini is either time dependent or not, I don't think it tracks that with enough granularity to deduplicate time samples on write.

There is probably more that we could do during the stitching process, but it would be complicated to implement, complicated to control/manage, and of dubious value (because of the existing USDC data deduplication and the fact that in Hydra, which there could be a real benefit to ensuring topology doesn't change over time, attributes are either time-varying or they aren't - so being time varying at only one time doesn't really make things better). So it has not been a high priority item for us.

I was thinking more in the sense of as the data is being written into the clip it would just keep adding time samples and whenever there is a discontinuity it would write previous and current sample, if they are the same, it would just write the previous

essentially optimizing during stitching, and then if at the end it ends up with only 1 time sample it means that the data was constant among all timesamples and it can mark it constant
if it has 2+ timesamples it's time varying, but I assume clips don't have to have timesaples for every timestep aka baked/raw sample, do they?

so essentially my expectation was that the stitching would figure out whether data is constant or time varying without any hint and if time varying it would store just minimal set of data to describe the time changes in the data, not every single step

since this process may be slower than blindly adding time data or completely ignoring it there can be hints, if I say it's constant it would just write the first timesample and not bother even reading others from other stitched frames, etc.
but using such hints would also introduce possible errors coming from misjudgement of the data
so while I understand those hints may be helpful for LOPs especially to know whether to update from SOPs or not they should not be required for stitching as that should be literally deduplicating as it goes

I assumed that goal stitching/deduplication is to get the most optimized stitched usd with minimal amount of data written to accurately represent the data as it is in every independent .usd file or frame hopefully without relying on hints as it should clearly know after the usd is stitched which data is constant, time varying whether its values, topology, …

and while I know nothing about if this is the case or how stitching of usd works from usd api point of view or from additional sesi processing layer, from Matts example it's clear that deduplication or optimization of the data didn't happen in a way I'd expect

I think for USD even one timesample is timevarying. Constant would mean that there are no timesamples, and only a default value is used. In that case when stitching files where it animating, since there can be only one default value, only the first value is recorded.
I think the only thing saved by only recording sparse time samples is the size of an ascii format usd file.

jsmack
I think for USD even one timesample is timevarying. Constant would mean that there are no timesamples, and only a default value is used.

I guess what I'm trying to say, it should be up to the stitching process to figure out whether the data is static or timevarying from the data provided frame by frame
but most importantly even if we use hints, and static are always static, for timevarying I don't see why we would need to have duplicate value timesamples stored, I'm not saying it should appear timevarying only on certain frames, I'm saying it should be smart enough to store only minimal set of timesamples needed to recreate the original per frame data, so if it knows it's stitching always the same topology data, it should result only in one timesample and then as a postprocess it can see there is only one and can change the property to static, or keep timevarying but just one timesample instead of 400 equal timesamples, well, in theory, that's how I'd imagine deduplication, but I don't know how it works or if there is a process that does this on write or stitching

There's a difference between authoring 400 equal timesamples and just 1, which is that another opinion can change the values on a sparse set of frames without changing the values on the remaining frames. If only one time sample was authored, the animation will be come an interpolation between the sparse keys.

jsmack
There's a difference between authoring 400 equal timesamples and just 1, which is that another opinion can change the values on a sparse set of frames without changing the values on the remaining frames. If only one time sample was authored, the animation will be come an interpolation between the sparse keys.

makes sense, but still an option to automatically create sparse timesamples upon stitching would be handy
so I guess that's my question, is there a way to stitch per frame usd and automatically deduplicate into sparse timesamples?