pixaranimationstudios / openusd

Universal Scene Description

Universal Scene Description

Universal Scene Description (USD) is an efficient, scalable system for authoring, reading, and streaming time-sampled scene description for interchange between graphics applications.

For more details, please visit the web site here.

Build Status

	Linux	Windows	macOS
dev
release

Additional Documentation

• User Documentation and Tutorials
• API Documentation
• Advanced Build Configuration

Getting Help

Need help understanding certain concepts in USD? See Getting Help with USD or visit our forum.

If you are experiencing undocumented problems with the software, please file a bug.

Supported Platforms

USD is primarily developed on Linux platforms (CentOS 7), but is built, tested and supported on macOS and Windows.

Please see VERSIONS.md for explicitly tested versions.

Dependencies

Required:

• C/C++ compiler
• CMake
• Boost
• Intel TBB

Optional:

• Python

See 3rd Party Library and Application Versions for version information.

Additional dependencies are required for the following components. These components may be disabled at build-time. For further details see Advanced Build Configuration.

Imaging and USD Imaging

Required:

• OpenSubdiv

Optional:

• OpenEXR
• OpenImageIO
• OpenColorIO
• OSL (OpenShadingLanguage)
• Ptex

usdview

Required:

• PySide6 or PySide2
• PyOpenGL

Getting and Building the Code

The simplest way to build USD is to run the supplied build_usd.py script. This script will download required dependencies and build and install them along with USD in a given directory.

Follow the instructions below to run the script with its default behavior, which will build the USD core libraries, Imaging, and USD Imaging components. For more options and documentation, run the script with the --help parameter.

See Advanced Build Configuration for examples and additional documentation for running cmake directly.

1. Install prerequisites (see Dependencies for required versions)

• Required:
  • C++ compiler:
    • gcc
    • Xcode
    • Microsoft Visual Studio
  • CMake
• Optional (Can be ignored by passing --no-python as an argument to build_usd.py)
  • Python (required for bindings and tests)
  • PyOpenGL (required for usdview)
  • PySide6 or PySide2 (required for usdview)

2. Download the USD source code

You can download source code archives from GitHub or use git to clone the repository.

> git clone https://github.com/PixarAnimationStudios/OpenUSD
Cloning into 'OpenUSD'...

3. Run the script

Run the build_usd.py script to build and install USD. Note that the build script is structured with an out-of-source build in mind -- installing a build into the
directory where the repository was cloned is untested.

Linux:

For example, the following will download, build, and install USD's dependencies, then build and install USD into /path/to/my_usd_install_dir.

> python OpenUSD/build_scripts/build_usd.py /path/to/my_usd_install_dir

MacOS:

In a terminal, run xcode-select to ensure command line developer tools are installed. Then run the script.

For example, the following will download, build, and install USD's dependencies, then build and install USD into /path/to/my_usd_install_dir.

> python OpenUSD/build_scripts/build_usd.py /path/to/my_usd_install_dir

Windows:

Launch the "x64 Native Tools Command Prompt" for your version of Visual Studio and run the script in the opened shell. Make sure to use the 64-bit (x64) command prompt and not the 32-bit (x86) command prompt.

See https://docs.microsoft.com/en-us/cpp/build/how-to-enable-a-64-bit-visual-cpp-toolset-on-the-command-line for more details.

For example, the following will download, build, and install USD's dependencies, then build and install USD into C:\path\to\my_usd_install_dir.

C:\> python OpenUSD\build_scripts\build_usd.py "C:\path\to\my_usd_install_dir"

4. Try it out

Set the environment variables specified by the script when it finishes and launch usdview with a sample asset.

> usdview OpenUSD/extras/usd/tutorials/convertingLayerFormats/Sphere.usda

Contributing

If you'd like to contribute to USD (and we appreciate the help!), please see the Contributing page in the documentation for more information.

openusd's Issues

usdMaya for OSX

Hi !

I'm trying to build usdMaya but I think that's not possible because on the MAC even Maya 2017 it was still built with libstdc++, and USD it's using C++11 everywhere, but useMaya refers to the MPxData which has the interfaces refer to the std::ostream directly, so there is the conflict on the linking.

Undefined symbols for architecture x86_64:
"MPxData::readBinary(std::__1::basic_istream<char, std::__1::char_traits >&, unsigned int)", referenced from:
vtable for UsdMayaStageData in stageData.cpp.o
"MPxData::writeASCII(std::__1::basic_ostream<char, std::__1::char_traits >&)", referenced from:
vtable for UsdMayaStageData in stageData.cpp.o
"MPxData::writeBinary(std::__1::basic_ostream<char, std::__1::char_traits >&)", referenced from:
vtable for UsdMayaStageData in stageData.cpp.o

-lpthreads does not work in manjaro

/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status

gcc -dumpspecs | grep --color pthread
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
%{!mandroid|tno-android-ld:%{pthread:-lpthread} %{shared:-lc} %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}};:%{shared:-lc} %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}} %{!static: -ldl}}
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) %{!fno-use-linker-plugin:%{!fno-lto: -plugin %(linker_plugin_file) -plugin-opt=%(lto_wrapper) -plugin-opt=-fresolution=%u.res %{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}} }}%{flto|flto=:%<fcompare-debug} %{flto} %{fno-lto} %{flto=} %l %{no-pie:} %{pie:-pie} %{fuse-ld=:-fuse-ld=%} %{gz:%e-gz is not supported in this configuration} %X %{o_} %{e_} %{N} %{n} %{r} %{s} %{t} %{u_} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}} %{static:} %{L_} %(mfwrap) %(link_libgcc) %{!nostdlib:%{fvtable-verify=std: -lvtv -u_vtable_map_vars_start -u_vtable_map_vars_end} %{fvtable-verify=preinit: -lvtv -u_vtable_map_vars_start -u_vtable_map_vars_end}} %{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):%{!shared:libasan_preinit%O%s} %{static-libasan:%{!shared:-Bstatic --whole-archive -lasan --no-whole-archive -Bdynamic}}%{!static-libasan:-lasan}} %{%:sanitize(thread):%{static-libtsan:%{!shared:-Bstatic --whole-archive -ltsan --no-whole-archive -Bdynamic}}%{!static-libtsan:-ltsan}} %{%:sanitize(leak):%{static-liblsan:%{!shared:-Bstatic --whole-archive -llsan --no-whole-archive -Bdynamic}}%{!static-liblsan:-llsan}}}} %o %{!nostdlib:%{!nodefaultlibs:%{mmpx:%{fcheck-pointer-bounds: %{static:--whole-archive -lmpx --no-whole-archive %:include(libmpx.spec)%(link_libmpx)} %{!static:%{static-libmpx:-Bstatic --whole-archive} -lmpx %{static-libmpx:--no-whole-archive -Bdynamic %:include(libmpx.spec)%(link_libmpx)}}}}%{mmpx:%{fcheck-pointer-bounds:%{!fno-chkp-use-wrappers: %{static:-lmpxwrappers} %{!static:%{static-libmpxwrappers:-Bstatic --whole-archive} -lmpxwrappers %{static-libmpxwrappers:--no-whole-archive -Bdynamic}}}}}}} %{mmpx:%{fcheck-pointer-bounds:%{!static:%{m16|m32|mx32:;:-z bndplt }}}} %{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=:%} 1): %:include(libgomp.spec)%(link_gomp)} %{fcilkplus:%:include(libcilkrts.spec)%(link_cilkrts)} %{fgnu-tm:%:include(libitm.spec)%(link_itm)} %(mflib) %{fsplit-stack: --wrap=pthread_create} %{fprofile-arcs|fprofile-generate_|coverage:-lgcov} %{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address): %{static-libasan:%:include(libsanitizer.spec)%(link_libasan)} %{static:%ecannot specify -static with -fsanitize=address}} %{%:sanitize(thread): %{static-libtsan:%:include(libsanitizer.spec)%(link_libtsan)} %{static:%ecannot specify -static with -fsanitize=thread}} %{%:sanitize(undefined):%{static-libubsan:-Bstatic} -lubsan %{static-libubsan:-Bdynamic} %{static-libubsan:%:include(libsanitizer.spec)%(link_libubsan)}} %{%:sanitize(leak): %{static-liblsan:%:include(libsanitizer.spec)%(link_liblsan)}}}} %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}} %{!nostdlib:%{!nostartfiles:%E}} %{T_}

only will work with "make -j 4 -pthread install"

lots of outdated lib requirements warnings in rolling releasing distros, for example Could NOT find BISON: Found unsuitable version "3.0.4", but required is exact version "2.4.1" (found /usr/bin/bison)

Maya crash on usdImport of geo with creased edges

As in the subject, importing a usd with edge creases into maya crashes maya.. (the same USDs work fine in katana and viewed properly in usdview)

Stack trace:
Tarray::changeLogicalSizeBy(int)
MFnMesh::setUVs(MFloatArray const&, MFloatArray const&, MString const_)
PxrUsdMayaTranslatorMesh::AssignUVSetPrimvarToMesh(UsdGeomPrimvar const&, MFnMesh&)
PxrUsdMayaTranslatorMesh::Create(UsdGeomMesh const&, MObject, PxrUsdMayaPrimReaderArgs const&, PxrUsdMayaPrimReaderContext)
/opt/pixar/usd/third_party/maya/lib/libusdMaya.so(+0x7cf98) [0x7f66bded8f98]
usdReadJob::DoImport(UsdTreeIterator&, UsdPrim const&)
usdReadJob::doIt(std::vector<MDagPath, std::allocator >)
usdTranslatorImport::reader(MFileObject const&, MString const&, MPxFileTranslator::FileAccessMode)
THfileConverter::reader(TsceneFile&)
TfileTranslator::read(TsceneFile&)
TglobalTranslator::doReadFile(TsceneFile&, bool, bool)
TfileUtil::readFile(TsceneFile_, bool, bool, bool)
TfileImporter::importFileToSceneFile(TsceneFile_, TsceneFile&, bool, bool, Tstring const_, TnamespaceSwapper_, TfileTranslator_, Tnamespace*)
TfileImporter::importFile(TsceneFile, bool, bool, TglobalTranslatorBase::TrefIOMode, Tstring const_, TnamespaceSwapper_, bool)
TfileCmd::handleFileImportFlag(TargDatabase&, TsceneFile_, TnamespaceSwapper_)
TfileCmd::handleFlags(TargDatabase&, TsceneFile_, TnamespaceSwapper_, TgraphDiff_)
TfileCmd::handleFlags(TargDatabase&, Tstring const&)
TfileCmd::doCommand(TargList&)
Mel_Command_Dispatch(SphNode_)
node_exec
sophia_call_executable
SophiaExecutable::evaluate(void_)
TcommandEngine::executeCommand(SophiaExecutable_, void_)
TevalEchoCmd::doCommand(TargList&)
Mel_Command_Dispatch(SphNode_)
node_exec

Completion of error handling

Would you like to add more error handling for return values from functions like the following?

• fprintf ⇒ TfScriptModuleLoader::WriteDotFile
• sigaction ⇒ TfInstallTerminateAndCrashHandlers

Windows Quath copy constructors are not properly decorated

System Information (OS, Hardware, etc.)

Windows

Steps to Reproduce

1. Make another library that uses Quath from gf.dll
2. Try to compile

Error should be something like:

Error LNK2019 unresolved external symbol "public: __cdecl GfQuath::GfQuath(class GfQuatd const &)" (??0GfQuath@@qeaa@AEBVGfQuatd@@@z) referenced in function CSharp_pxr_new_GfQuath__SWIG_4 UsdCs C:\src\usd\UsdBindings\vs2015\UsdCs\usdCs_wrap.obj

It just needs GF_API before the constructors, however this generated more questions:

Seems like this should be part of the Jinja template, but isn't currently?

It also seems like many functions are not prefixed with the declspec/GF_API -- is that intentional?

_usdAbc fails to build on OSX

Compilation of boost::python bindings on OSX is sensitive to the order of #includes, in particular, pyport.h overriding symbols defined in cctypes. This is due to a bug in Python, that was fixed in 2.7.13 - https://bugs.python.org/issue10910

in _usdAbc, the #include of wrapAlembicTest.h before def.hpp triggers this bug, but can be worked around by switching the order of #includes, as it is in a few other wrap*cpp files in the USD codebase, making it an exception to the general coding convention of #include'ing higher-level headers first.

I'm happy to reorder the #includes in wrapAlembicTest.cpp in dev for now, and will make a pull request against this issue.

---

In file included from /Users/asluk/Desktop/bin/usd-dev/USD/pxr/usd/plugin/usdAbc/wrapAlembicTest.cpp:26:
In file included from /usr/local/include/boost/python/def.hpp:11:
In file included from /usr/local/include/boost/python/make_function.hpp:10:
In file included from /usr/local/include/boost/python/default_call_policies.hpp:10:
In file included from /usr/local/include/boost/python/to_python_value.hpp:12:
In file included from /usr/local/include/boost/python/handle.hpp:11:
In file included from /usr/local/include/boost/python/errors.hpp:13:
In file included from /usr/local/include/boost/function/function0.hpp:11:
In file included from /usr/local/include/boost/function/detail/maybe_include.hpp:13:
In file included from /usr/local/include/boost/function/function_template.hpp:13:
In file included from /usr/local/include/boost/function/detail/prologue.hpp:17:
In file included from /usr/local/include/boost/function/function_base.hpp:20:
In file included from /usr/local/include/boost/assert.hpp:84:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iostream:38:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ios:216:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:466:15: error: C++ requires a type specifier for all declarations
char_type toupper(char_type __c) const
^

Maya: bug switching sub-assembly representation from Full to Collapsed

To create the assets used in the repro below, I first completed the endToEnd tutorial through the creation of Room_set.usd

To reproduce:

Create an assembly, set the it to Expanded, and set one of the children to Full:

import maya.cmds as cmds
root = cmds.assembly(name='testAss', type='pxrUsdReferenceAssembly')
cmds.setAttr(root + '.filePath', '/Volumes/sv-dev01/devRepo/chad/projects/usd/tutorials/endToEnd/models/Room_set/Room_set.usd', type='string')
cmds.assembly(root, active='Expanded', edit=True)
sub = 'NS_testAss:Ball_1'
cmds.assembly(sub, active='Full', edit=True)

Now set the child to Collapsed:

cmds.assembly(sub, active='Collapsed', edit=True)

What we should see is the Ball asset as a proxy, instead we see the entire Room_set, offset by the ball's xform.

Cmake OpenEXR detection should detect library suffixes

OpenEXR library builds add suffixes on Windows and macOS, such as -

`Iex-2_2.dll

libIex-2_2.12.0.0.dylib
`
On Linux, the Cmake script doesn't fail because I imagine that the names have been resolved either through renaming or symlinks.

Linking against symlinked versions of the libraries is not user-friendly on Windows or macOS, because on those platforms users have the ability to move applications, and they do, no matter how many times you ask them not to do. So, linking against the real dylibs/dlls would be beneficial to end users.

The Cmake script goes to the trouble of extracting the OpenEXR version number, in the example case it discovers

2.2.0

Inconsistently, OpenEXR does not suffix Half.dll. Just throwing that out there as a note.

It would be very helpful if the Cmake detection script, after failing to find Iex.dll or Iex.dylib, ran again using a regex or something to allow for the fully suffixed libraries to be detected.

macOs libraries compiling but not working

I got all the libraries compiled in macOS... but when I try to import them in python 2.7, I'm getting an error
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python/pxr/Gf/__init__.py", line 31, in <module> from pxr import Tf File "/usr/local/lib/python/pxr/Tf/__init__.py", line 85, in <module> from . import _tf ImportError: cannot import name _tf

This is just one example but I'm getting the same problem with all of them...
I tried with Debug and Release libraries from xcode.

Some one is getting the same problem???

Use a standard python site-packages directory

The pxr module is located in $USD_PREFIX/lib/python but it would be great if it was stored using python's standard layout $USD_PREFIX/lib/python2.7/site-packages.

two reasons:

• it let's users run pip install PyOpenGL --prefix=$USD_PREFIX and it will just work.
• eventually we're going to need to deal with python3. yep, start embracing that idea because python2's EOL is coming :)

In general I've found that it just makes life easier to organize these things the way that python wants you to.

Side note: it would be good to add PyOpenGL to the list of USD's dependencies.

Cannot build Maya plugin & Alembic plugin properly on Fedora 23

CMake run with warnings cannot generate safe runtime search path for _usdAbc, usdAbc, _usdMaya, usdMaya target.
make built successfully, but when I try to load pxrUsd.so in Maya, an error occur :

// Error: line 1: Unable to dynamically load : /usr/local/third_party/maya/plugin/pxrUsd.so
/usr/local/third_party/maya/plugin/../../../lib/libglf.so: undefined symbol: _ZN4Ptex4v2_29PtexCache6createEimbPNS0_16PtexInputHandlerEPNS0_16PtexErrorHandlerE //
// Error: line 1: /usr/local/third_party/maya/plugin/../../../lib/libglf.so: undefined symbol: _ZN4Ptex4v2_29PtexCache6createEimbPNS0_16PtexInputHandlerEPNS0_16PtexErrorHandlerE (pxrUsd) //

And when I open .abc file using usdview, it can't determine file format.

I'm using Fedora 23 and Maya 2016, hope you can help, thank you :)

CMake log:
-- Boost version: 1.58.0
-- Found the following Boost libraries:
-- iostreams
-- python
-- regex
-- system
-- program_options
-- Using default system allocator because PXR_MALLOC_LIBRARY is unspecified
-- Found PySide Tools: /usr/bin/pyside-uic, /usr/bin/pyside-rcc
-- Configuring done
CMake Warning (dev) at cmake/macros/Public.cmake:63 (add_dependencies):
Policy CMP0046 is not set: Error on non-existent dependency in
add_dependencies. Run "cmake --help-policy CMP0046" for policy details.
Use the cmake_policy command to set the policy and suppress this warning.

The dependency target "/usr/lib64/libboost_program_options.so" of target
"sdfdump" does not exist.
Call Stack (most recent call first):
pxr/usd/bin/sdfdump/CMakeLists.txt:1 (pxr_cpp_bin)
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning at cmake/macros/Public.cmake:131 (add_library):
Cannot generate a safe runtime search path for target _usdAbc because files
in some directories may conflict with libraries in implicit directories:

runtime library [libz.so.1] in /usr/lib64 may be hidden by files in:
  /usr/local/lib

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
cmake/macros/Public.cmake:606 (pxr_shared_library)
pxr/usd/plugin/usdAbc/CMakeLists.txt:9 (pxr_plugin)

CMake Warning at cmake/macros/Public.cmake:467 (add_library):
Cannot generate a safe runtime search path for target usdAbc because files
in some directories may conflict with libraries in implicit directories:

runtime library [libz.so.1] in /usr/lib64 may be hidden by files in:
  /usr/local/lib

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
pxr/usd/plugin/usdAbc/CMakeLists.txt:9 (pxr_plugin)

CMake Warning at cmake/macros/Public.cmake:131 (add_library):
Cannot generate a safe runtime search path for target pxrUsdMayaGL because
files in some directories may conflict with libraries in implicit
directories:

runtime library [libtbb.so.2] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib
runtime library [libpython2.7.so.1.0] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib
runtime library [libtbbmalloc.so.2] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
third_party/maya/lib/pxrUsdMayaGL/CMakeLists.txt:3 (pxr_shared_library)

CMake Warning at cmake/macros/Public.cmake:131 (add_library):
Cannot generate a safe runtime search path for target _usdMaya because
files in some directories may conflict with libraries in implicit
directories:

runtime library [libpython2.7.so.1.0] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib
runtime library [libtbb.so.2] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib
runtime library [libtbbmalloc.so.2] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
cmake/macros/Public.cmake:293 (pxr_shared_library)
third_party/maya/lib/usdMaya/CMakeLists.txt:3 (pxr_shared_library)

CMake Warning at cmake/macros/Public.cmake:131 (add_library):
Cannot generate a safe runtime search path for target usdMaya because files
in some directories may conflict with libraries in implicit directories:

runtime library [libpython2.7.so.1.0] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib
runtime library [libtbb.so.2] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib
runtime library [libtbbmalloc.so.2] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
third_party/maya/lib/usdMaya/CMakeLists.txt:3 (pxr_shared_library)

CMake Warning at cmake/macros/Public.cmake:467 (add_library):
Cannot generate a safe runtime search path for target pxrUsd because files
in some directories may conflict with libraries in implicit directories:

runtime library [libtbb.so.2] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib
runtime library [libpython2.7.so.1.0] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib
runtime library [libtbbmalloc.so.2] in /usr/lib64 may be hidden by files in:
  /usr/autodesk/maya2016.5/lib

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
third_party/maya/plugin/pxrUsd/CMakeLists.txt:3 (pxr_plugin)

-- Generating done
-- Build files have been written to: /home/myname/Documents/Git-Repo/USD/build

Shouldn't detect X11 on macOS

The bit of code below will mess up macOS users with X11 installed, in the sense that an X11 dependency will be baked into USD. When a developer builds, say a Maya plugin for USD, and then attempts to distribute it to an artist, the artist will be doomed to install X11. Since the graphics functions on macOS don't use X11, X11 should not be searched for at all on macOS. Ditto for Windows of course.

if (PXR_BUILD_IMAGING)
    # --OpenImageIO
    find_package(OpenImageIO REQUIRED)
    # --OpenGL
    find_package(OpenGL REQUIRED)
    find_package(GLEW REQUIRED)
    # --Opensubdiv
    find_package(OpenSubdiv 3 REQUIRED)
    # --Ptex
    find_package(PTex REQUIRED)
    # --X11
    find_package(X11)
    # --Qt
    find_package(Qt4)
    if (QT4_FOUND)
        find_package(PySide REQUIRED)
    endif()
endif()

Remove unnecessary null pointer checks

An extra null pointer check is not needed in functions like the following.

• GlfUVTextureStorageData
• HdMeshTopology::SetQuadInfo

Python bindings not importing on OSX

I know that the OSX build is currently experimental, but just want to verify that I'm seeing the currently expected behavior wrto Python bindings:

from pxr import Tf
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python/pxr/Tf/init.py", line 85, in
from . import _tf
ImportError: cannot import name _tf

Likely due to http://stackoverflow.com/questions/2488016/how-to-make-python-load-dylib-on-osx , but I haven't found the right combination of xcode build settings to build _tf as a bundle with an .so extension yet, if that's the expected fix.

Cheers!
-a.

macOS requires boost 1.61.0

Per Sunya's investigation, we should note that macOS requires boost 1.61.0.

ee43e6e

Use Qt5 and PySide2

USDSchemaGen semicolons

Hello.. I'm going to submit this as an issue while we get our fork workflow up between the public github repo and our own internal one and can easily branch...

Running the usdGenSchema command creates header file class definitions that do not close the class declaration with a semicolon which causes an error on compilation. The offending code is in the cmake file when reading in the usdGenSchema.py file to replace the pxrpythonsubst with the configured python executable before writing back out for install. Code is here: https://github.com/PixarAnimationStudios/USD/blob/2eb01f5cd4c2dae4e1ef9912ca27a93083bb6ef4/cmake/macros/Public.cmake#L34

Offending code is:

file(READ ${pyFile} contents)
string(REGEX REPLACE "/pxrpythonsubst" ${PXR_PYTHON_SHEBANG} contents "${contents}")
file(WRITE ${CMAKE_BINARY_DIR}/${pyFile} ${contents})

If we do a file read cmake operation and semicolons are found it is treated as a list, so the file write operation will remove all semicolons from the output. The fix is easy, wrap with quotes so it is treated as a string i.e.

file(WRITE ${CMAKE_BINARY_DIR}/${pyFile} "${contents}")

Thanks
Eoin

reserved identifier violation

I would like to point out that identifiers like "_DrawTargetPerContextMap" and "_HasKind" do eventually not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

Req: Expose default asset resolver in API so a custom resolver can defer to it's implementation

If one is writing a custom asset resolver and needs similar filesystem behaviour to that provided by the default asset resolver then the Ar_DefaultResolver code needs to be duplicated in the custom implementation.

If the Ar_DefaultResolver class could be exposed as part of the public API then a custom resolver could either derive from or contain an internal instance of this class and defer to it's implementation.

Alternately, if there was API to get the previous 'current' or default asset resolver such that it could be called in the constructor of a custom resolver. e.g. ArGetDefaultResolver().

Build fails with "'isnan' was not declared in this scope" on Ubuntu

See below for extract. I'm building on Ubuntu 16.04, 64-bit, and have got the following when building either the release, or the tip of trunk.

[ 25%] Building CXX object pxr/base/lib/gf/CMakeFiles/gf.dir/bbox3d.cpp.o
[ 25%] Building CXX object pxr/base/lib/gf/CMakeFiles/gf.dir/camera.cpp.o
[ 25%] Building CXX object pxr/base/lib/gf/CMakeFiles/gf.dir/colorRamp.cpp.o
In file included from /root/parts/usd/build/include/pxr/base/gf/colorRamp.h:28:0,
from /root/parts/usd/src/pxr/base/lib/gf/colorRamp.cpp:24:
/root/parts/usd/build/include/pxr/base/gf/rgb.h: In member function 'bool GfRGB::IsValid() const':
/root/parts/usd/build/include/pxr/base/gf/rgb.h:80:49: error: 'isnan' was not declared in this scope
bool IsValid() const { return !isnan(_rgb[0]); }
^
/root/parts/usd/build/include/pxr/base/gf/rgb.h:80:49: note: suggested alternative:
In file included from /root/parts/usd/build/include/pxr/base/arch/math.h:36:0,
from /root/parts/usd/build/include/pxr/base/gf/math.h:27,
from /root/parts/usd/build/include/pxr/base/gf/colorRamp.h:27,
from /root/parts/usd/src/pxr/base/lib/gf/colorRamp.cpp:24:
/usr/include/c++/5/cmath:641:5: note: 'std::isnan'
isnan(_Tp __x)
^
pxr/base/lib/gf/CMakeFiles/gf.dir/build.make:386: recipe for target 'pxr/base/lib/gf/CMakeFiles/gf.dir/colorRamp.cpp.o' failed
make[2]: *** [pxr/base/lib/gf/CMakeFiles/gf.dir/colorRamp.cpp.o] Error 1
CMakeFiles/Makefile2:1345: recipe for target 'pxr/base/lib/gf/CMakeFiles/gf.dir/all' failed
make[1]: *** [pxr/base/lib/gf/CMakeFiles/gf.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

macOS Sierra 10.12 support, since macOS Sierra supports USD natively it would be great to get this running

macOS Sierra will be released this Tuesday, 9/20 and I have been trying to get this USD build to work with the Golden Master. Since USD is natively supported in macOS Sierra I think it shows tremendous promise. I am already able to do things that I would never be able to do in Collada’s DAE files.

Has anyone gotten this USD build to work in macOS Sierra using the dev branch?

I am stuck on installing and compiling the Qt 4.8 dependancy. I have gotten all the way to Qt 4.8 and tried compiling Qt 4.8.6 with the El Capitan patch here https://github.com/Homebrew/formula-patches/blob/master/qt/el-capitan.patch which works but also Apple’s (Quicktime) QTKit framework has been removed in Sierra and I am getting this error…

In file included from ../../../3rdparty/phonon/qt7/quicktimevideoplayer.mm:18:
../../../3rdparty/phonon/qt7/quicktimevideoplayer.h:23:9: fatal error: 'QTKit/QTDataReference.h' file not found

import <QTKit/QTDataReference.h>

    ^

1 error generated.
make[4]: *** [.obj/release-shared/quicktimevideoplayer.o] Error 1
make[3]: *** [release] Error 2
make[2]: *** [sub-qt7-make_default] Error 2
make[1]: *** [sub-phonon-make_default] Error 2
make: *** [sub-plugins-make_default-ordered] Error 2

I should note that both Qt 4.8 and Apple’s (Quicktime) QTKit framework are at end of life and have been deprecated and are no longer being supported. Apple’s QTKit was replaced with AVFoundation. We may have better luck with Qt5 and Pyside2?

There may be other issues here with macOS Sierra? If so, we should track them here and get this USD build working. :-)

It looks like you can install most of the dependancies in macOS Sierra using brew. For example ( http://macappstore.org/cmake-2/ )

Here is my go at it!

1 - brew install cmake
2 - MacOS Sierra - Python 2.7.10 is already installed
3 - brew install boost
4 - brew install openexr
5 - brew install double-conversion
6 - brew install tbb ( This is Intel TBB )
7 - No brew recipe for opensubdiv so...

git clone https://github.com/PixarAnimationStudios/OpenSubdiv
mkdir build
cd build
cmake -D NO_MAYA=1 -D NO_PTEX=1 -D NO_DOC=1
-D NO_OMP=1 -D NO_TBB=1 -D NO_CUDA=1 -D NO_OPENCL=1 -D NO_CLEW=1
-D GLFW_LOCATION="YOUR GLFW INSTALL LOCATION"
..
make

8 - brew install glew
9 - No elegant brew recipe for Open Image IO (oiio) so...

Install Open Image IO (oiio) dependancies - brew install libjpeg libtiff libpng
Download current stable release of oiio - https://github.com/OpenImageIO/oiio/archive/release.zip
unzip oiio-release.zip
cd oiio-release
make

10 - brew install ptex
11 - brew install qt ( Stuck! brew install qt or qt4 fails, also even after trying to directly compile Qt 4.8.6 with the El Capitan patch https://github.com/Homebrew/formula-patches/blob/master/qt/el-capitan.patch which works, but Apple's deprecated (Quicktime) QTKit is removed in macOS Sierra and I get the error above... )

Mismatched Tags Warnings

Platform: Mac OSX
Compiler: Apple LLVM version 7.3.0 (clang-703.0.31)

There are currently several occurrences of -Wmismatched-tags being triggered when building on newer compilers, such as relatively current clang. This comes from forward declarations of types not matching the way in which they were defined, i.e. one uses the keyword struct and another uses class. These should be cleaned up.

Maya: VariantSets not working with referenced assemblies

To create the assets used in the repro below, I first completed the endToEnd tutorial through the creation of Room_set.usd

To reproduce:

• Create a pxrUsdReferenceAssembly and point it at Room_set.usd and set it to expanded:

  import maya.cmds as cmds
  n = cmds.assembly(name='testAss', type='pxrUsdReferenceAssembly')
  cmds.setAttr(n + '.filePath', '/projects/usd/tutorials/endToEnd/models/Room_set/Room_set.usd', type='string')
  cmds.assembly(n, active='Expanded', edit=True)

• select 'NS_testAss:Ball_1' assembly node and open the AttributeEditor: nothing is displayed under VariantSets. 'shadingVariant' should be listed there.

I did a brief investigation, starting from the assembly Attribute Editor template, and from what I can tell the problem stems from the fact that the prim gathered by UsdMaya.GetPrim('NS_testAss:Ball_1') does not take the assembly's primPath attribute into consideration, which is '/Ball' in this case:

from pxr import UsdMaya, Usd, UsdUtils
node = 'NS_testAss:Ball_1'
usdPrim = UsdMaya.GetPrim(node)
print "assembly file:", getAttr(node + '.filePath')
print "assembly prim:", getAttr(node + '.primPath')
print "name:", usdPrim.GetName()
print "variants:", usdPrim.GetVariantSets().GetNames()

This prints:

assembly file: /projects/usd/tutorials/endToEnd/models/Ball/Ball.usd
assembly prim: /Ball
name: /
variants: []

Notice the name of the prim for the assembly is '/' instead of '/Ball'.

If I use Ball.usd and the root prim directly, I get the expected variant set:

stage = Usd.Stage.Open('/projects/usd/tutorials/endToEnd/models/Ball/Ball.usd')
rootPrim = stage.GetPrimAtPath('/Ball')
print "name:", print rootPrim.GetName()
print "variants:", rootPrim.GetVariantSets().GetNames()

name: /Ball
variants: ['shadingVariant']

It might be worth mentioning that when I select the 'NS_testAss:Ball_1' assembly node the following warning is printed in the script editor:

# Warning: UsdMayaReferenceAssembly::computeOutStageDataNS_testAss:Ball_1: Stage primPath '/Room_set'' not a parent of primPath '/Ball'. Skipping variant assignment. #

No make file generated from cmake on OSX? Any tips on building the xcodeproj file?

Hi USD Wizards,

I'm trying to build USD on OSX and have been following the instructions at https://github.com/PixarAnimationStudios/USD. After hunting down the required libraries, I managed to get cmake mostly error free and completing with the comforting line:

-- Generating done
-- Build files have been written to: /Users/pkanyuk/USD/build

However, there are no Makefiles in the build directory, which makes running the command specified in the docs: make -j <NUM_CORES> install, impossible. I take it that may be a copy-paste typo and the intention is to build the resulting usd.xcodeproj project. I attempted to do that with:

/usr/bin/xcodebuild -target install

But this failed due to glPlatformContextDarwin.h not being in build/include/pxr/imaging/garch. Fine, I copied it over, but then I got the build error:

/Users/pkanyuk/USD/pxr/imaging/lib/garch/glPlatformContextGLX.cpp:27:10: fatal error: 'boost/functional/hash.hpp' file not found

I do have boost installed, and the relevant file is at /usr/local/include/boost/functional/hash.hpp, but sure enough the compile command did not have a -I argument with boost. That leads me to believe either CMake failed to configure the xcodeproj file correctly, or there really is a Makefile that's missing, and I'm going down a dangerous path. Any tips?

Thanks!
-- Paul

Simplified installation process (package manager?)

Steve would never have approved the installation process. Why not use some kind of package manager that takes care of all the dependencies and paths for you?

linker errors when building _tf

This is because wrapTestPyAnnotatedBoolResult is enabled in the Python bindings, but not in the build. I have a fix.

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -L/Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/tf/Debug -F/Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/tf/Debug -filelist /Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/tf/usd.build/Debug/_tf.build/Objects-normal/x86_64/_tf.LinkFileList -install_name @rpath/_tf.so -Xlinker -rpath -Xlinker /Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/tf/Debug -Xlinker -rpath -Xlinker /Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/arch/Debug -mmacosx-version-min=10.11 -Xlinker -object_path_lto -Xlinker /Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/tf/usd.build/Debug/_tf.build/Objects-normal/x86_64/_tf_lto.o -Xlinker -no_deduplicate -dynamiclib -Wl,-headerpad_max_install_names /Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/tf/Debug/libtf.dylib /Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/arch/Debug/libarch.dylib /usr/lib/libm.dylib /Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib /usr/local/lib/libboost_python-mt.dylib /usr/local/lib/libboost_iostreams-mt.dylib /usr/local/lib/libdouble-conversion.dylib /usr/local/lib/libtbb.dylib /usr/local/lib/libtbbmalloc.dylib -single_module -Xlinker -dependency_info -Xlinker /Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/tf/usd.build/Debug/_tf.build/Objects-normal/x86_64/_tf_dependency_info.dat -o /Users/asluk/Desktop/bin/usd-dev/USD/build/pxr/base/lib/tf/Debug/_tf.so

Undefined symbols for architecture x86_64:
"wrapTf_TestPyAnnotatedBoolResult()", referenced from:
WrapModule() in module.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Locale assumptions in prettyPrint.py

Line 32 of Usdviewq/prettyPrint.py sets a hardcoded locale.

import locale
locale.setlocale(locale.LC_ALL, 'en_US')

My home Linux system, which is not a Redhat or Centos derived platform fails on this line with

locale.Error: unsupported locale setting

My first thought is setting this locale required? It may impose restrictions on non-Linux platforms. If this call desirable I would wrap it with a try: except locale.Error: to allow usdview to work even when the locale is not available.

On my system, here is the output of locale -a

C
en_US.utf8
POSIX

Unnecessary sip import in usdviewq

in MainWindow.reloadVaryingUI() -

https://github.com/PixarAnimationStudios/USD/blob/2eb01f5cd4c2dae4e1ef9912ca27a93083bb6ef4/pxr/usdImaging/lib/usdviewq/mainWindow.py#L1283

I believe this can be removed. Thanks!

Missing boost INCLUDE_DIRS in pxr/imaging/lib/garch/CMakeLists.txt

glPlatformContextGLX.cpp includes boost/functional/hash.hpp
but boost is not added to the include paths for the garch library.

Katana: Assigned PxrRis NetworkMaterial from USD crashes renderman

Rendering an object with a USD NetworkMaterial assigned to it crashes Renderman(21.1)
please find attached recipe/usd produced this issue with me.
shdNetwork.tar.gz

UsdAbc should allow non-HDF5 builds of Alembic

If Alembic is built without HDF5 support, the AbcCoreHDF5/ headers are not published, and alembicReader.cpp will not compile. Since HDF5 support is deprecated, it should be possible to build without it. Perhaps the UsdAbc Cmake script could detect the existence of the AbcCoreHDF5 headers, and add a preprocessor directive such as HAVE_NO_HDF5 if appropriate.

building USD as static library

is there any chance to build USD as a static library?

invalid public link in the readme

https://github.com/PixarAnimationStudios/USD/blame/master/README.md#L22:

http://openusd.org/docs/Getting-Help-With-USD.html is resolving to http://graphics.pixar.com/usd/docs/Getting-Help-With-USD.html, and that's returning a 404.

Inconsistent opensubdiv3 headers

The build system in FindOpenSubdiv.cmake looks for ${OPENSUBDIV_INCLUDE_DIR}/opensubdiv/version.h, but the source code in pxOsd is referencing #include <opensubdiv3/far/topologyRefiner.h>. I'm not sure if opensubdiv or opensubdiv3 is the preferred include path, but on my Arch Linux system the opensubdiv package put them under /usr/include/opensubdiv

Remove PShader from UsdShade

If I remember correctly, PShader is a legacy Presto-specific shader schema -- it shouldn't be distributed, should it?

NOOB - Running USD

Hi, i'm very new to USD as well is Running GITHub OpenSource applications.

Could someone kindly show me a guide on how to get up and running with USD ( as if i'm opening up 3D's Max or any regular pre-packaged requiring User installation to C Drive plus desktop icons.

lol, Yes i'm a noob to Code, not ashamed. hahah.

Back to the matter at hand. So i downloaded VisualStudio15 and Linked the Repo On Github as instructed by tutorial.

So what do i do now? how do i get to use USD like normal software as i have seen in Some Pixar examples illustrating the strength of USD. Being a software enthusiast, i really want to give this a go but dont know how :(

I also have Python Commnd & Python GUI installed, i do see on the video examples, they load it using Python if im not mistaken.

Please help guys, i have tried to explain my issue as best as i can and looking for Solutions, I would be very greatful.

P.S ( does anyone know how to create a GitHub / Opensource / General (Installer) so that after you download all the zipped files and or folders. You just run the Installer, determine location path contain your software files..Set an installation path or after locating Files. It Reads (a pre-written code or script file provided by the creator so it works with The Installer) or copy over a "plugin" script to the folder containing the downloaded file (or customize the coded document by simply copy over and editing a simple line of code that the Installer searches for once you determine folder location so the installation can begin / or better Run The Software Direct From The Installer (installation not necessary)

lol, i'm sure i sound pretty idiotic right now. but ah well.

_XOPEN_SOURCE and _POSIX_C_SOURCE warnings when building on Linux

Platform: RHEL7
Compiler Version: gcc 4.8.5

When building USD on Linux, we get many warnings due to redefinitions of the _XOPEN_SOURCE and _POSIX_C_SOURCE macros. This is likely due to Python headers not being included at the top of files as required (see https://docs.python.org/2/c-api/intro.html#include-files). We should be able to fix this by moving these headers up in the include order.

cmake drops opensubdiv defines intended for Hd

This is because the CMakeLists for Hd is using _add_define(), the effects of which have already been applied by the time individual libraries are reached, instead of add_definitions().

https://github.com/PixarAnimationStudios/USD/blob/2eb01f5cd4c2dae4e1ef9912ca27a93083bb6ef4/pxr/imaging/lib/hd/CMakeLists.txt#L10

I have a fix.

CMake GLEW handling on Windows is broken-ish

On Windows, when statically linking against Glew, GLEW_STATIC must be defined, here is the relevant part of glew.h:

/*
 * GLEW_STATIC is defined for static library.
 * GLEW_BUILD  is defined for building the DLL library.
 */

#ifdef GLEW_STATIC
#  define GLEWAPI extern
#else
#  ifdef GLEW_BUILD
#    define GLEWAPI extern __declspec(dllexport)
#  else
#    define GLEWAPI extern __declspec(dllimport)
#  endif
#endif

So on Windows when using glew32.lib (or glew32d.lib, which OpenSubdiv/USD doesn't support!) -> no switch needed.

When using glew32s.lib (glew32sd.lib) -> -DGLEW_STATIC is required.

Also, OpenSubdiv should guard against glew leaking into the public headers/templates, which I think is what I ran into -- will file a separate bug.

USDMaya: Layer modifications preserved after stage cache cleared

Hello, if we take the file below, save it as cube.usd, and run the code beneath it we see that the cube.usd layer, when re-loaded, remains modified, rather than reverting to it's virgin (xform at the origin) state as we would expect.
We've tried manually clearing the stage cache etc - makes no differerence. We're thinking that this might be to do with the layer cache (which we don't seem to heave easy access). Is this possibly desired behaviour? If so, would be good to at least have a way of forcing our desired behaviour (use case - user build a scene in USDMaya, makes modifications to the USD data in memory, decides to restart their work from scratch, creates new empty scene in maya, builds scene again)

'

usda 1.0

(
defaultPrim = "World"
)

def "World"
{
def Mesh "Cube"
{
int[] faceVertexCounts = [4, 4, 4, 4, 4, 4]
int[] faceVertexIndices = [0, 1, 3, 2, 2, 3, 5, 4, 4, 5, 7, 6, 6, 7, 1, 0, 1, 7, 5, 3, 6, 0, 2, 4]
point3f[] points = [(-0.5, -0.5, 0.5), (0.5, -0.5, 0.5), (-0.5, 0.5, 0.5), (0.5, 0.5, 0.5), (-0.5, 0.5, -0.5), (0.5, 0.5, -0.5), (-0.5, -0.5, -0.5), (0.5, -0.5, -0.5)]
}
}
'

`
from pxr import UsdGeom

from maya import cmds
from pxr import UsdMaya

cmds.loadPlugin('pxrUsd')
cmds.file(new=True, force=True)

'''
Using maya to open the layer for modification but could as easily do it with pure USD API
'''
proxy = cmds.createNode("pxrUsdProxyShape")
cmds.setAttr("%s.filePath" % proxy, "cube.usd", type="string")
theStageCache = UsdMaya.StageCache.Get()
stages = theStageCache.GetAllStages()
stage = stages[0]

'''
Modify the transform in a fairly obvious way
(I'm sure there's a nicer way to do this!)
'''
prim = stage.GetPrimAtPath('/World/Cube')
geo = UsdGeom.Xformable(prim)
op = geo.MakeMatrixXform()
matrix = op.GetOpTransform(0)
translate = matrix.ExtractTranslation()
translate[2] = translate[2]-20
matrix.SetTranslate(translate)
op.Set(matrix, 0)

'''
Now create a new maya scene, reopen the layer, and you will see that the
cube is still in it's modified position (rather than at the origin)
'''
cmds.file(new=True, force=True)
proxy = cmds.createNode("pxrUsdProxyShape")
cmds.setAttr("%s.filePath" % proxy, "cube.usd", type="string")
`

katana PxrUsdIn doesn't respect custom attrs

writing usd with custom attribute on objects using USD_UserExportedAttributesJson attribute, then reading this usd in Katana, then the custom attrs are not read and not available for Katana except if the attributes were written in the "primvars:" namespace.

I expected writing some static/constant attrs out as material tags and texture tags that don't need to be in primitive scope and doesn't need interpolation.

USD versioning tags

Hi,

I heard that the current version was 0.7, but I'm not sure if it is possible to get this specific version
easily as there is no release point tags in the USD git repo.

It would be great to get such version tags before we get to many commits.

Thanks

Importing in Maya a usd with RFM shader contains PxrSeExpr

Importing a usd that was exported with RFM shaders where the shading network has a PxrSeExpr crashes maya.
The usd file seem to be correct when viewed in usdview or usdedit

has_seExpr.usda.tar.gz

Maya plugin can sometimes hang

The USD Maya plugin can sometimes hang. We've tracked this issue down to an incompatibility with TBB and Autodesk suggested that we build with -Wl,-Bsymbolic to workaround the issue while they address it on their end. This workaround works and we will be rolling it out into a cmake option that you can turn on: PXR_MAYA_TBB_BUG_WORKAROUND.

Autodesk has said that this is fixed in Maya 2017 and Maya 2016 Extension 2 SP2, though we have not verified this.

Usda ascii parser is too restrictive for asset paths

Paste the following to a text file named asset.usda (which was generated without error using the python API), and attempt to usdcat or usdedit it. You will get something like:

Failed to open 'asset.usda' -
Error in 'textFileFormatYyerror' at line 3074 in file pxr/pxr/usd/sdf/textFileFormat.yy : 'syntax error at 'fr' in </root.assAttr> on line 11 in file /scratch/asset.usda
'
Error: Failed to open file asset.usda, exiting.

The ascii parser is very restrictive in what it allows in asset paths... partly due to some internal tricks we play for fast dependency analysis, partly because we were over-fitting for filesystem-based paths. People want to use UIR's that require many non-alnum characters, and we need to provide for being able to parse them out of ascii robustly.

TOC in BUILDING.md busted

I'm not sure if this is just misunderstanding the markdown rules or if there's a conversion error somewhere (because the pattern we're following seems rational), but all of the TOC links are broken. The identifiers generated for the sections use exclusively lowercase, but our references in the TOC use the same capitalization as the section headers themselves.

--spiff

Debug build TBB and Python CMake issues

System Information (OS, Hardware, etc.)

Windows

CMake fails to find tbb_debug.lib when it is present and attempts to use pythonXX_d.lib, even when it's not present.

The TBB issue is due to a hard coded string, which seems like it should be easy to fix, I'm not sure what's going on with Python.

Need to forward declare struct _PathItemHeader;

_PathItemHeader needs to be forward declared in crateFile.h. For whatever reason, MSVC takes the declaration in _ReadPathsRecursively to be declaring _PathItemHeader as a nested class, and so the compilation of crateFile.cpp fails.

Adding

struct _PathItemHeader;

around line 67 of crateFile.h solves it.

Cmake Alembic detection script needs to recognize newer Alembic builds.

On Windows, Alembic no longer builds to many small libraries, instead only a single DLL and lib are generated.

That means that the detection should look something like this:

    find_library(ALEMBIC_LIBRARY
                 NAMES Alembic
                 PATHS ${LIBRARY_PATHS})

    set(ALEMBIC_LIBRARIES ${ALEMBIC_LIBRARY})

    get_filename_component(ALEMBIC_LIBRARY_DIR ${ALEMBIC_LIBRARY} PATH)

A possible solution would be to add a detection phase in the Cmake script, along the lines of

if (NOT ALEMBIC_ABC_LIBRARY_FOUND)
   message("Historic Alembic not detected, looking for modern Alembic")
   .... then do something like what I listed above.
endif()

Have Qt4, but don't have PysideTools, build fails

If one has Qt4 but not PysideTools (a likely scenario), the build will fail on usdviewq because it calls the PysideTools to wrap usdviewq. Could we add something like this to the usdviewq/CMakeLists.txt file? (Not sure if PYSIDEUICTOOLS_FOUND the right variable to key from, but you get the gist)

 if (NOT QT4_FOUND)
     message(WARNING "Not building ${PXR_PACKAGE} because of missing dependency: Qt4")
     return()
 endif()

+if (NOT PYSIDEUICTOOLS_FOUND)
+    message(WARNING "Not building ${PXR_PACKAGE} because of missing dependency: PysideTools")
+    return()
+endif()
+