time units in Alembic?

[Spiff]

Everything I've read on Alembic, including the source code, claims time is measured in seconds.  We assume that when reading abc files in USD, and setup metadata and time-scaling appropriately.  But most abc files that people wind up sending in in gitHub issues wind up playing back super-slowly, the likeliest explanation for which seems to be that the animation is actually in (24fps) frames rather than seconds.

Are DCC's known to not honor the Alembic standard in this respect (or am I misinterpreting the standard?)?  If time units are actually variable, is there any data in the file that can tell us what they are?

Thanks!

--spiff

[Alex Suter]

Hey Spiff,

They should be seconds. 100%. Any chance the files are reporting which package is generating them?

That said, it would be an easy coding mistake to make, writing outnone sample per frame and not converting the time sample to seconds...

       — Alex

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lucas Miller]

Right as Alex said, it's either a simple coding mistake for those used
to thinking of only frames, or they are using the intrinsic default
time sampling which is 1 second per frame, so the index and time are
the same.

DCCs respect it.

Lucas

[Spiff]

Thanks for the confirmation, guys! One user reported that they were using Blender, which I know only recently added Alembic support. Still, it's not totally clear whether it is due to the software or user error. But clearly they were seeing a different playback rate in Blender... I'll follow up with the users, and report back here - thanks again!

[Spiff]

Actually, Lucas, you mentioned there's an intrinsic time sampling of 1 second per frame - is there a way to query that so we could handle it if a dcc is not changing it?

[Dorian Fevrier]

@Spiff, you don't need to query anything: If the sample time is 1, it's one second.

The only thing most DCC change is FPS. If your DCC is setted in 25 FPS and export an abc of one sample per frame, you will have 25 samples per seconds, if you put your alembic in a DCC setted in 24 FPS, samples will not match. If you put your alembic in a DCC setted in 25 FPS, samples will match frames.

That's as easy. :)

If the DCC exports alembic with 1 as 1 frame, you need the DCC FPS to increase alembic speed by 25 or 24 (or other).

[Spiff]

Thanks, Dorian!  I think what I'm stumbling on is how to know - just given an abc file - what fps we shouold assume?  I cannot find anything in the core distro that mentions 'fps' or 'framesPerSecond' other than test comments and as a application option to the AbcOpenGL playback tool in the SceneWrapper class.

--spiff

[Lucas Miller]

You don't assume FPS playback IN the file, the DCC determines how fast
it will try to play back its data coming from multiple sources, and
the reader does the best it can based on the samples it has.

[Spiff]

I get that it is the purview of the consuming DCC to ultimately decide playback fps (though it really behooves the exporting app to know about that target fps so that it can sample for it appropriately, so e.g. animators can animate in comfortable 24fps, but during export sample on 0.8's for 30FPS playback in rendering apps).  But how can the reader "do its best" if it doesn't know how the samples in the file map to seconds?  I guess I'm looking for the equivalent of USD's 'timeCodesPerSecond', which is scene metadata that tells a consuming app how the ordinates found in the file (which we perhaps confusingly call TimeCodes) map to seconds.

Cheers,

--spiff

> email to alembic-discussion+unsub...@googlegroups.com.

[Lucas Miller]

> But how can the reader "do its best" if it
> doesn't know how the samples in the file map to seconds?

Ahhh, this is what TimeSampling is for, to map an index to seconds.
You can get all TimeSamplings in a file, along with the max number of
samples for each one via:

IArchive::getNumTimeSamplings
https://github.com/alembic/alembic/blob/1.7.8/lib/Alembic/Abc/IArchive.h#L162

IArchive::getTimeSampling
https://github.com/alembic/alembic/blob/1.7.8/lib/Alembic/Abc/IArchive.h#L158

IArchive::getMaxNumSamplesForTimeSamplingIndex
https://github.com/alembic/alembic/blob/1.7.8/lib/Alembic/Abc/IArchive.h#L168

AbcCoreAbstract::TimeSampling
https://github.com/alembic/alembic/blob/1.7.8/lib/Alembic/AbcCoreAbstract/TimeSampling.h

Lucas

[Dorian Fevrier]

If you want to "guess", you can try to get the number of sample per second and find sequencial patterns but it's not perfect.

[Spiff]

Thanks, Lucas!  This prompted me to take a closer look at our translator, and it looks like we are doing a double time-scaling attempting to convert seconds to 24fps, then declaring the timeCodes are in seconds!  Alex, I don't know how you guys have been using this in production at all :-(

Thanks, Alembic community - I'll ask the USD community how they'd like us to fix this.

--spiff

[Alex Suter]

With great success, Spiff. ;)

Like Lucas said, the readers deal with their own FPS and the cached data is read and interpolated appropriately. Maybe that's the difference? We could sample at 24fps and read at 60fps and the data would usually still look good because we interpolate between samples pretty well. The biggest issues for us where interpolation can go sideways are rotational objects like helicopter blades or wheels. We handle that either by increasing the number of between-frame samples when caching it out or by ensuring that we export with a stack of transforms instead of one big matrix since Alembic supports both.

Maybe I'm not understanding the problem?

--

You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

[Spiff]

Glad it hasn't been impeding you, Alex!  I guess I'm applying too much Pixar mind-set: we have traditionally not expected our readers to apply any time transformations, therefore relying on the data to be in the right timeframe already.  We're just starting to relax that a bit to try to make it easier to render at 30fps for data exported out of presto at 24fps, sampled on 0.8's, e.g.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.