Giters

PixarAnimationStudios / OpenUSD

Universal Scene Description

Home Page:http://www.openusd.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unexpected timeScale added when flattening layerstack with mixed TCPS values

marktucker opened this issue · comments

commented

Description of Issue

When combining layers with different TimeCodesPerSecond values, USD automatically compensates for these differing values so all time samples from all layers are put on a consistent timeline. When calling UsdUtils.FlattenLayerStack, the implicit time scaling based on these these TCPS differences get "hardened", as do any explicit timeScale factors set on the sublayer composition arc. But if a sublayer has references, a timeScale will be added to the reference that includes the implicit time scaling based on the TCPS differences. This is incorrect, because the TCPS differences of the referenced layer will already be applied based on the new layers TCPS value. Hardening this into a timeScale value results in applying the (previously implicit) time scale explicitly as well as applying the new implicit TCPS based timescale, resulting in an incorrect final time scaling.

Steps to Reproduce

  1. Open the attached 25FPS.usda file in usdview. Note the animation.
    time_scaling.zip
  2. In the Interpreter window, run:
from pxr import Usd, UsdUtils
s = Usd.Stage.Open("25FPS.usda")
UsdUtils.FlattenLayerStack(s).Export("Flattened.usda")
  1. Open the resulting Flattened.usda in usdview, and see the difference. The two outputs (25FSP.usda and Flattened.usda) should be identical, but are not because of the timeScale authored on the reference of 20FSP.usda during the flattening.

Package Versions

USD 24.03

commented

Filed as internal issue #USD-9645

commented

Oh dear - this sounds like a codesite we forgot to update when taking on the burden of automatically applying TCPS differences as part of the MapFunction.

Were you going to look at this, @marktucker , or shall we?

commented

I didn't have any plans to look into this because when users report errors like this, it generally indicates a mistake earlier in the process, and they didn't actually intend to have different USD files with different FPS values. Once everything is authored with the same FPS this problem goes away.