Incorrect serialisation of numerical attributes

[fabal]

Description of Issue

Hi there,
we're getting corrupted files when serialising a layer to a USD ascii file using version 0.8.1: values of numerical attributes are missing.

The same code will work using the python bindings

Steps to Reproduce

    string stagePath("/tmp/out.usda");

    {
        auto stage = UsdStage::CreateNew(stagePath);

        auto prim = stage->DefinePrim(SdfPath("/prim"));
        auto attr = prim.CreateAttribute(TfToken("doubleAttr"), SdfValueTypeNames->Double);
        attr.Set(12.0);
        auto attrStr = prim.CreateAttribute(TfToken("stringAttr"), SdfValueTypeNames->String);
        attrStr.Set("ok");
        auto attrArray = prim.CreateAttribute(TfToken("floatArrayAttr"), SdfValueTypeNames->Float3Array);
        VtVec3fArray v(2);
        v[0] = GfVec3f(1.2, 3.4, 5.6);
        v[1] = GfVec3f(7.8, 9.0, 10.0);
        attrArray.Set(v);

        auto root = stage->GetRootLayer();

        string layerStr;
        root->ExportToString(&layerStr);
        cout << layerStr << endl;

        root->Save();
    }

    auto stage = UsdStage::Open(stagePath);

With this output:

#usda 1.0

def "prim"
{
    custom double doubleAttr = 
    custom float3[] floatArrayAttr = 
    custom string stringAttr = "ok"
}

System Information (OS, Hardware)

centos 6

Package Versions

USD-0.8.1
gcc-4.8.3
boost-1.55.0
tbb-4.4.2

Build Flags

USD standard release flags.

[sunyab]

Hi @fabal, sorry for the trouble! I'm able to reproduce this issue locally and am looking into this now. I believe this may be related to the new functionality for disabling Python in USD builds. This involved adding a #define to some headers that may be affecting clients who build against USD.

As a workaround, could you try defining PXR_PYTHON_SUPPORT_ENABLED when building your code against USD, either by adding a -DPXR_PYTHON_SUPPORT_ENABLED to your compiler command line or adding a #define PXR_PYTHON_SUPPORT_ENABLED before including any USD headers in your code. This fixed the problem for me locally. We're working on a fix to make this unnecessary going forward.

[jtran56]

Filed as internal issue #152351.

[fabal]

Hi @sunyab , I confirm the workaround is working.
Thanks.