Add OpenUSD to the build

[jwnimmer-tri]

This is a sub-task of #17833.

I'm filing it separately because it will involve a non-trivial amount of details that are mostly unrelated to the multibody and parsing side of Drake.

The call to action is to be able to run a unit test inside Drake that loads some minimal *.usd file by calling into OpenUSD and call some various accessor functions that interrogate the loaded scene. Basically a "proof of life" that we've successfully linked to a copy of OpenUSD can be run without crashing.

• [workspace] Add OpenUSD as an optional dependency #20923
• [workspace] Add boost_internal #21037
• [parsing] Add UsdParser smoke test stub #21028
• [onetbb] Hotfix for include path hijinks #21058
• [workspace] Build OpenUSD in macOS CI #20990
  • Needs un-revert
• [workspace] Upgrade openusd_internal to latest release v24.03 #21078
• [workspace] Straighten out repo rules for MOSEK, TBB, OpenUSD #21155
• [workspace] Upgrade openusd_internal to latest release v24.05 #21340
• [workspace] Fix OpenUSD namespace #21407
• [workspace] Fix OpenUSD plugin loading #21408
• OpenUSD compilation errors on Ubuntu 24.04 #21456
• Disable unwanted stack dumps polluting in /tmp:
  • Writing stack for smoke_test to /tmp/st_smoke_test.rl8KNi because of ERROR.
• Sanity check any vendored sub-libraries inside of OpenUSD
• Remove private symbol nerf(s) from exported_symbols_test.py
  • "3tbb6detail" in KNOWN_BAD_SYMBOLS_SUBSTR
• Ensure private symbols (i.e., just make sure CI passes)
• Try to remove global constructors barf
• Fix hardcoded runfiles paths that don't play nice with installed libdrake
• Cross-check on license file installs
• Un-pin the boost_internal external (rm commit_pin = True)
• Switch the feature default from opt-in to opt-out

[jwnimmer-tri]

I'll post here some info I've gathered on the build system front. As I learn more, I'll probably circle back and edit the summary in this post, as well as the original post.

---

One aspect of building OpenUSD is to identify any required dependencies, and any optional dependencies that we would like to opt-in to.

We need to check the licenses of those dependencies, and how to integrate them into our build. On first skim, all of the licensing questions will be easy (the licenses are unremarkable) and the only question on that front will be ensuring that we properly redistribute all of the notice texts.

The main question will be integrating OpenUSD and its dependencies the build system.

Some of the dependencies are already vendored:

• OpenUSD/pxr/base/js/rapidjson
• OpenUSD/pxr/base/tf/pxrDoubleConversion
• OpenUSD/pxr/base/tf/pxrLZ4
• etc

For these, we just need to be sure to obey ODR -- if we have another copy of the library in Drake, we either need to unify them in the workspace, or else ensure that their names will not conflict. For example in the case of pxrDoubleConversion the OpenUSD code has already patched in their own custom namespace, and so it would not conflict with our VTK copy of double-conversion (which is also wrapped in a custom namespace).

---

One required, non-vendored dependency is libtbb.

We already link a copy of libtbb as part of our MOSEK integration. I'm inclined to use the MOSEK version of TBB even in our non-MOSEK builds. I think it would simplify testing to always pin a single version, instead of different versions depending on build flags.

---

Another required, non-vendored dependency is boost.

It's a little tricky to figure out the exact subset of boost that is required (because the OpenUSD code mixes the Python bindings next to the non-Python sources, so I'm not sure exactly which OpenUSD files we need in Drake), but as a first approximation I'm seeing:

$ find OpenUSD/pxr/base OpenUSD/pxr/usd -name testenv -prune -o -name plugin -prune -o -name 'py*' -prune -o -name 'wrap*' -prune -o -name 'module.cpp' -prune -o -name '*Module*' -prune -o -name '*Py*' -prune -o -name 'pch.h' -prune -o -name '*.dox' -prune -o -type f -exec grep -h -e '#include.*<boost' \{\} + | sort -u
#include <boost/any.hpp>
#include <boost/intrusive_ptr.hpp>
#include <boost/multi_index_container.hpp>
#include <boost/multi_index/hashed_index.hpp>
#include <boost/multi_index/identity.hpp>
#include <boost/none.hpp>
#include <boost/numeric/conversion/cast.hpp>
#include <boost/optional.hpp>
#include <boost/optional/optional_fwd.hpp>
#include <boost/preprocessor/...lots...>
#include <boost/ptr_container/ptr_set.hpp>
#include <boost/smart_ptr/intrusive_ptr.hpp>
#include <boost/utility.hpp>
#include <boost/variant.hpp>
#include <boost/vmd/is_empty.hpp>

Drake has a policy of not using Boost, because of ABI conflicts with other libraries that users might want to use that also use Boost, but of a different version.

That doesn't matter for things like BOOST_PP macros which evaporate in the object code, but will matter for anything with linkage.

Possibly we could use BCP to re-namespace the subset of Boost that we need for OpenUSD.

There are some heros trying to de-boostify OpenUSD with pull requests; possibly we could pour our fuel on that fire instead of working around the problem. TBD.

[jwnimmer-tri]

The next task is to identify exactly which modules of OpenUSD would be required to parse *.usd files into Drake. For example, we might need usd/usd and usd/usdGeom and usd/usdPhysics. Once we know that starting point, we can figure out the transitive closure of which dependencies are in play, and then start working out how to incorporate each of them.

[sherm1]

cc @erwincoumans

[jwnimmer-tri]

Perhaps a the first goal should be to get usdcat working? If that program runs successfully, that seems like a good proxy for what the Drake integration would need, at least as a first pass.

[jwnimmer-tri]

It looks like we might need to cherry-pick some patches from open pull requests, so that we can use a non-ancient version of TBB:

PixarAnimationStudios/OpenUSD#1600 (comment)

PixarAnimationStudios/OpenUSD#2825

[jwnimmer-tri]

The boost problem is a bit more acute than I had realized. For now in #20994 we've disabled OpenUSD in CI.

I'll try to get boost compiling in CI in perhaps the next two weeks.

[sherm1]

cc @hong-nvidia