Unexpected warnings when converted to a USDz format

[Ayaoayao]

Description of Issue

I converted a file to USD with various extensions.

The file was successful with the usda format but I didn't get the luck when converting it into usdz format.

The conversion raised a warning,

Warning: in UsdUtilsCreateNewARKitUsdzPackage at line 1240 of D:\***\Tools\USD\pxr\usd\usdUtils\dependencies.cpp -- The given asset 'C:\Users\****\Desktop\Top.usdc' contains one or more composition arcs referencing external USD files. Flattening it to a single .usdc file before packaging. This will result in loss of features such as variantSets and all asset references to be absolutized.

However, in my code, I used UsdReferences::AddInternalReference.

The expected result would be, that the MeshPrimDef is referred.

#usda 1.0
(
    defaultPrim = "Top_file"
    upAxis = "Z"
)

def Xform "Top_file"
{
    def Material "RGBMaterial_255_255_0_255"
    // define materials

    def Xform "MeshInstance" (
        prepend references = </MeshPrimDef>
    )
    {
        rel material:binding = </Top_file/RGBMaterial_0_255_0_255>
    }

    def Xform "MeshInstance_1" (
        prepend references = </MeshPrimDef_1>
    )
    {
        rel material:binding = </Top_file/RGBMaterial_0_255_0_255>
        matrix4d xformOp:transform = ( (1, 0, 0, 0), (0, 1, 0, 0), (0, 0, 1, 0), (1.1702733075334646, 2.0827494916641736, -2.6665265631429134, 1) )
        uniform token[] xformOpOrder = ["xformOp:transform"]
    }

    def Xform "MeshInstance_2" (
        prepend references = </MeshPrimDef_1>
    )
    {
        rel material:binding = </Top_file/RGBMaterial_202_209_238_255>
        matrix4d xformOp:transform = ( (1, 0, 0, 0), (0, -3.491481338843e-15, 1, 0), (0, -1, -3.491481338843e-15, 0), (-0.020264680311807087, -0.46326917639803156, -0.15284553567649606, 1) )
        uniform token[] xformOpOrder = ["xformOp:transform"]

        over "Body2"
        {
            rel material:binding = </Top_file/RGBMaterial_255_0_0_255>
        }
    }
}

over Xform "MeshPrimDef" (
    kind = "component"
)
{
    def Mesh "Body1"
    {
    // body content
    }
}

over Xform "MeshPrimDef_1" (
    kind = "component"
)
{
    def Mesh "Body2"
    {
     // body content
    }
}

Manually converting the usdz to usda with usdcat shows the final file is more like a monolithic one

    def Xform "MeshInstance" (
        kind = "component"
    )
    {
        rel material:binding = </Top_file/RGBMaterial_0_255_0_255>

        def Mesh "Body1"
        {
            // duplicated content instead of references
        }
        def Mesh "Body2"
        {
           // duplicated content instead of references
        }
        def Mesh "Body2"
        {
           // duplicated content instead of references
        }
    }
// following over Xform
}

System Information (OS, Hardware)

Edition Windows 10 Enterprise Version 21H2 OS build 19044.2006

Package Versions

v22.08

Build Flags

['--no-python', '--no-imaging', '--build-monolithic']

[spiffmon]

You are correct that internal references should not be triggering that warning, nor causing flattening. But more importantly, I don't think Apple devices have needed any of those "arkit" restrictions for years. I will folllow up with @dgovil and others at Apple to see if they can contribute precise updates to the USDZ creation utilities. But in the meantime, I think you should get good results using the "normal" UsdUtilsCreateNewUsdzPackage, as long as you follow the USDZ specification in selection of textures, etc.

[dgovil]

Yeah the arkit restrictions of yore should no longer be needed as long as all the references resolve properly within the USDZ. I'd recommend looking at https://developer.apple.com/documentation/realitykit/validating-usd-files?changes=_3 to see what USD features are supported. Unsupported features would just not be represented on load, but should not block a load.

Variants are a good example, where you can't modify them but the default variant will load fine. Effectively you'd get a flattened view of the stage on import.

UsdUtilsCreateNewUsdzPackage should do the trick as long as the resulting USDZ is self contained

[Ayaoayao]

Many thanks for your feedback, I will give the UsdUtilsCreateNewUsdzPackage a try!

[tallytalwar]

Filed as internal issue #USD-7718