2022-03-10 Pipeline, Assets & I/O Meeting

Meetings
1

Everyone is welcome on the Google Meet linked below every other Thursday, at 17:00 CET.

Present: Bastien Montagne, Julian Eisel, Michael Kowalski, Sybren Stüvel

The meeting covers the pipeline & I/O module in a broader sense, including some topics hosted in other modules (e.g. some I/O python add-ons, or overrides and .blend file I/O from the Core module).

Links

USD Libraries In Blender

Michael Kowalski, the main developer working on USD integration in Blender, has requested that USD libraries get linked dynamically instead of statically.

  • Important goal: get Python bindings. In general: allow addons to do more with USD.
  • Add the USD Imaging module. This would allow creating geometry from USD primitive shapes (cones, spheres, etc.). Not a a big library.
  • We could add the USD Imaging module in Blender 3.2, and target Blender 3.3 for the Python bindings and the dynamic linking.
  • Michael can be the lead on this, with the help from platform maintainers. He’s working on Windows primarily. Sybren will give a script to set up a CentOS7 Linux virtual machine for experimenting.
  • Michael will explore to see how much work the transition will be, final decision will likely be made the next meeting (or the one after that, depending on the time needed to set up a Linux development environment for Michael).

Sybren nagged on the USD issue tracker about TBB compatibility issues and GCC-11 compatibility issues.

Other Topics

Sybren has been working on a new generation of Flamenco (announcement).

Julian is working on outliner improvements (T95802) for library overrides. There are two views under development:

  • Individual properties that are overwritten
  • The hierarchy over the overrides (overridden mesh property, inside object, inside collection, inside scene, etc.)

Bastien hopes to merge his underlying work to master next week.

Next Meeting

The next meeting will be on Thursday 24th March, 17:00 CET/Amsterdam time.

The provisional meeting agenda will be linked in the #pipeline-assets-io-module channel before the meeting.

1 Like
2

I won’t be able to attend the meeting, however I think it’s good to clarify the request for dynamically build USD libs was actually a request to include the USD python bindings. And there’s a second independent request to enable the USD Imaging components in our USD build.

The python bindings naturally lead to a dynamic libs since we don’t want to link that monster of a library into several separate binaries, it’s good to realize the end goal here were the python bindings since just having a dynamic lib isn’t much of a goal on its own.

as for the imaging components, the requirements list nothing of concern, we have all required deps and 4 out of the 5 optional ones (no ptex for blender as of now)

From a windows platform perspective I see no technical objections to either request, but the IO module will have to decide if adding/supporting these things is something we’d want to do.

Regardless of the outcome USD will be dynamically linked on windows for 3.2 since it chips off about 950 megabytes off our lib folder.

2 Likes
3

If we start using dynamically linked libraries on Linux and macOS that’s potentially a big project. That involves changes to both the library and Blender build systems, and not just USD because it also depends on other libraries. Another thing is ABI compatibility with binary add-ons, graphics/compute drivers and the VFX platform, where we currently rely on symbol hiding on Linux and macOS.

This may be worth it, however getting the Python bindings working with static linking can also be considered.

4

Good point, that could be problematic. We build USD in a usdBlender namespace and while that may alleviate some of the ABI compat concerns, but yeah there’s plenty of dragons still there. It’s good to know that the end goal is shipping the python bindings rather than just USD being dynamic… for …reasons… since it allows different angles for solving the issue.

I say let first let the module internally decide if these are things they want, and worry about the technical fallout later. Don’t get me wrong, it’ll be significantly more work than flipping a switch and rebuilding, but things being work shouldn’t stop us from offering new features to users that the modules think are worth having.

2 Likes