Houdini->Maya, small time inaccuracies at FPS=23.976

[Phil Sloggett]

Hi guys,

We're running a project at 23.976fps - not uncommon, but we're only now noticing strange time-offset issue with alembic caches exported from Houdini back in to Maya. 

We're seeing very small time offsets (~0.001 frames) on loaded caches. This is significant enough that the alembic node may serve up the wrong cache-frame for any given maya frame.

This problem doesn't seem to occur going from Maya to Houdini, so we're a suspicious of Maya introducing some rounding error moving to a lower precision.

The "problem" may somewhat invisibly exist when exporting from Maya too... inspecting "time per cycle" of two alembic caches, in python, saved from the different sources produces:

0.0417083750417 # <- written from Houdini FPS=23.976
0.0417083333333 # <- written from Maya at FPS=23.976

Ive attached a file that runs from frame 1001-1024 exported from houdini at 23.976fps, which, when imported in to Maya, yields a start and end frame of 1001.001 and 1024.001. The same export in the range 1-24 doesnt give the strange offset - which again smells alot like float precision....

Anyone else battling this at all?

Potentially a clue -- We did notice this getFPS method of the AlembicNode which explicitly casts Mayas time to a float internally, while still yielding a double result...
https://github.com/alembic/alembic/blob/8d60a897551d6ebc6975483cdd95eb46745198ae/maya/AbcImport/AlembicNode.cpp#L383

Appreciate any help!

Phil

[Sybren A. Stüvel]

On 25-09-19 09:27, Phil Sloggett wrote:

We're running a project at 23.976fps - not uncommon, but we're only now noticing strange time-offset issue with alembic caches exported from Houdini back in to Maya.

I'm suspecting that Maya has a hardcoded 24 FPS assumption when importing Alembic. This caused issues when writing an Alembic file at 30 FPS from Blender and importing into Maya; see this report in the Blender tracker: https://developer.blender.org/T55288. I can only explain the observed behaviour by incorrect assumptions about the frame rate and bad interpolation between frames. This shouldn't directly cause out-of-sync errors like you're seeing, but it does show that Maya makes some strange assumptions when loading Alembic.

Also see the discussion at https://groups.google.com/d/msg/alembic-discussion/f0P3bKNe_qQ/XhU6FfqzEAAJ about this.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

[Dorian Fevrier]

I think you catched it Phil ! Good job!

MTime is always in double and, for an unknown reason, there is a float here.

https://download.autodesk.com/us/maya/2010help/API/class_m_time.html

In float, 23.976 is actually:

23.9759998321533203125

In double, it is:

2.39759999999999990905052982271E1

https://www.h-schmidt.net/FloatConverter/IEEE754.html

http://www.binaryconvert.com/convert_double.html

In python:

>>> e = 2.39759999999999990905052982271E1 - 23.9759998321533203125
>>> e * 1001
0.0001680145254567833

So it looks like a precision issue.

I don’t understand why getFPS() use a float, specially as it return a double. It really looks like a bug to me.

What do you guys think?

[Dorian Fevrier]

Phil, I’ve created an issue and a PR: https://github.com/alembic/alembic/issues/234

If you can test it, it would be great. If you can’t test, please provide an explicit reproducible use case (light Alembic + code snippet?) so someone else can test.

Thanks in advance.

--
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.
To view this discussion on the web visit

https://groups.google.com/d/msgid/alembic-discussion/447652670.16664185.1569423558297%40mail.yahoo.com

.

[Phil Sloggett]

Thats fantastic Dorian! I should have an opportunity to test tomorrow or Friday, will reply again here.

FYI in my original post there was a repro cache file attached...
an e.g. code snippet might be:

result_node = maya.cmds.AbcImport("test_imprecise_framerate_from_houdini.abc")

abc_start_frame = maya.cmds.getAttr("{0}.startFrame".format(result_node))

acceptable_tolerance = 0.000001  # ?

assert abs(1001.0 - abc_start_frame) < acceptable_tolerance

.

[pa...@findesign.com.au]

We found that the problem is not with the alembic but with maya API. MTime internally uses  23.97602397602397772  for FPS where time samples from houdini (and other DCC apps) are exported using 23.976. 

Since alembic time is in seconds this introduces slight time shift over time. We "fixed" it by calculating time instead of relying on MTime built in conversion.

    double inputTime = t.as(MTime::kSeconds);  //this is incorrect when FPS is 23.976 

    if(MTime::uiUnit() == MTime::k23_976FPS)

    {

        double frame = t.as(MTime::k23_976FPS);

        inputTime = frame / double(23.976);

    }