Adding a minimum OpenUSD version to VFX Platform

[dhruv...@gmail.com]

Hi folks, 

After discussion in the AOUSD TAC, we'd like to start the discussion of including a recommended minimum OpenUSD version to the VFX Platform.

We believe that OpenUSD is used by a large portion of VFX software today, and would like to start aligning the versions used by DCCs so that we can have better compatibility stories going forward. USD has been quite stable as a software library so we have fewer concerns now about the rapid rate of improvement (as was previously stated here https://groups.google.com/g/vfx-platform-discuss/c/r_CTOXh2ChM)

Our thought is that this should be a minimum version of USD per CY, which would allow DCCs to move up to newer versions if they choose, but allows us to at least provide a floor on feature support matrices and allows us to take a more principled stance on planning how features are rolled out (or even deprecated).

Our thought is that OpenUSD does a fairly significant release at SIGGRAPH each year (25.8 this year), and it's a good version to align the VFX Platform against as a minimum.  This is the version that usually has the major feature completions for a given year, and therefore could really help align DCCs support for even things like file interchange.

Anyway, just wanted to propose that and see if folks had any thoughts.

Cheers

Dhruv

[Larry Gritz]

Some kind of coordination here would be very welcome.

I am worried about this whole "minimum" thing, that's where it gets tricky. You can still have multiple incompatible versions in play. Most of the other things in VFX Platform are, for better or worse, often interpreted as much as a maximum as a minimum. And of course, nobody hears the gong at the stroke of midnight on Jan 1 and switches their shows from from the (year) to (year+1) versions of everything all at once.

So I hope the discussion also will lead to a little more clarity about (a) how and when everybody expects to retire the versions described in prior VFX Platform years (we have some vague "three years back" guidance, but c'mon), and (b) for the foundational open source projects, what are reasonable expectations about the link back-compatibility guarantees they should live up to -- and what in particular can we expect from OpenUSD?

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/c832419b-c669-4519-a58a-5e745c3f110dn%40googlegroups.com.

--

Larry Gritz

l...@larrygritz.com

[dhruv...@gmail.com]

In general, USD tends to not introduce any breaking changes within the XY.8 to (XY+1).8 cycle. So someone who builds against USD 24.8 should largely be able to have their code work against 25.5 for example without work. (as much as any library can guarantee that is). The reverse of course isn't true, but I think thats true for other libs too (ie you can't use a new symbol from OpenEXR 3.3.5 in OpenXR 3.3.0 just to pick a strawman) so you can avoid the versionitis. 

I do this quite regularly in our pipeline when we update platform versions, and USD has so far been one of the least churn projects for me to update against. 

Having the minimum at least provides some encouragement to keep DCCs moving forward with versions , especially versions we can make sure work with the rest of the platform for that year. 

To your other questions:

a) In a more general sense, I think the only expectation of anything in the platform is that DCC vendors and library vendors are aligning. I'm not sure if the problem is USD specific necessarily or is solved for other libs either? But if there's precedence we can try and map accordingly.

b) USD already follows the CY-3 guidance from VFXPlatform for build compatibility where possible. (remind me to kvetch at SIGGRAPH this year because I want C++20 support in the platform please :-D )

[Colin Doncaster]

I’d be curious to understand what the impact this would have from an implementation/execution perspective?  

Say everyone agrees on a version at the end of 2025 and all of the vendors conform to that for CY2026, what would the expectation be then when a new OpenUSD is released Q1 2026?  Is the industry on hold until DCC’s move up in 2027?  

OpenUSD is clearly more than just a scene description, as many vendors are adopting Hydra and Storm (Hydra 2.0 procedurals etc.) it makes it harder to potentially cherry pick fixes and features.  Unlike a lot of the other libraries OpenUSD is more comparable to Qt in scope than OIIO or OpenEXR.  

Have there been discussions around a LTS version of OpenUSD in the future?  

Indeed the API seems forwards compatible without recent recompilation frustration, would there be a guarantee on ABI level compatibility for studios and vendors who aren’t in a position to recompile? 

I believe a 1.0 draft of the schema was also presented at Siggraph last year, should the OpenUSD schema version be considered in the VFX reference platform?  If for nothing else to ensure assets are future proofed?  

I’m not opposed to the idea, I’m just curious if there would be frustration in the other direction if these compatibility concerns weren’t clear. 

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/52197a94-92f3-4a17-aacf-7bf65e4d7176n%40googlegroups.com.

[Brecht Van Lommel]

I think this is generally good, and would be good for MaterialX too

For reference, I believe these are the default versions for some DCCs for VFX platform 2023, 2024 and 2025.

* Maya 2024: 22.11

* Maya 2025: 23.11

* Maya 2026: 24.11 (?)

* Houdini 20.0: 23.08

* Houdini 20.5: 24.03

* Houdini 21.0: (?)

* Blender 3.6 LTS: 23.05

* Blender 4.2 LTS: 24.05

* Blender 4.5 LTS: 25.02 or 25.05 (Undecided)

For these, perhaps even the 25.11 release could be the minimum. Though I'm not sure what exactly to do with a VFX platform minimum version when deciding on a version for Blender, if there is anything to do. The Maya and Houdini versions are quite far apart within the same VFX platform year, and I guess that won't change?

--

[Larry Gritz]

Yeah, I think most of these projects are very backward-compatible within each year's set of patch releases, but generally guarantee nothing from one year to the next (often switching to a totally different namespace). I was actually musing about whether we want to set the bar higher than that.

On Mar 28, 2025, at 12:58 PM, dhruv...@gmail.com <dhruv...@gmail.com> wrote:

In general, USD tends to not introduce any breaking changes within the XY.8 to (XY+1).8 cycle. So someone who builds against USD 24.8 should largely be able to have their code work against 25.5 for example without work. (as much as any library can guarantee that is). The reverse of course isn't true, but I think thats true for other libs too (ie you can't use a new symbol from OpenEXR 3.3.5 in OpenXR 3.3.0 just to pick a strawman) so you can avoid the versionitis. 

--

Larry Gritz

l...@larrygritz.com

[Larry Gritz]

On Mar 28, 2025, at 1:18 PM, Colin Doncaster <co...@peregrinelabs.com> wrote:

Indeed the API seems forwards compatible without recent recompilation frustration, would there be a guarantee on ABI level compatibility for studios and vendors who aren’t in a position to recompile? 

Just to be sure we're all using the same nomenclature:

"backward compatible" means that new versions accept the calls or read the files meant for older versions (i.e. things built for or by 1.3 will still be expected to work with 1.4).

"forward compatible" means the old one can read the files (for example) output by later versions of the software. This is much harder to achieve, and mostly not expected by users.

--

Larry Gritz

l...@larrygritz.com

[Colin Doncaster]

Of course, I was referring to the API itself vs the artifacts - ie. there shouldn’t be too much housekeeping to recompile code that worked with 25.x when moving to 26.x.  

[David Aguilar]

On Friday, March 28, 2025 at 1:31:03 PM UTC-7 Larry wrote:

On Mar 28, 2025, at 1:18 PM, Colin wrote:

Indeed the API seems forwards compatible without recent recompilation frustration, would there be a guarantee on ABI level compatibility for studios and vendors who aren’t in a position to recompile? 

Just to be sure we're all using the same nomenclature:

"backward compatible" means that new versions accept the calls or read the files meant for older versions (i.e. things built for or by 1.3 will still be expected to work with 1.4).

"forward compatible" means the old one can read the files (for example) output by later versions of the software. This is much harder to achieve, and mostly not expected by users.

I don't think ABI (binary) compatibility is tenable. The last time I checked, the open source USD builds put their symbols into a versioned namespace that matches the library's version. In that respect, every single version is not ABI-compatible with any other version whatsoever.

Having a minimum supported version with API (source) compatibility and backwards-compatibility recommendations seems reasonable. One benefit that vendor plugins (e.g. HoudiniUsdBridge, Maya-USD, NukeUsdPlugins, etc.) would get from having this is that they'd have a better idea as to when it's okay to remove #ifdefs for older versions. Are there other benefits we'd get or that we're looking to attain by recommending a minimum version?

[dhruv...@gmail.com]

> Say everyone agrees on a version at the end of 2025 and all of the vendors conform to that for CY2026, what would the expectation be then when a new OpenUSD is released Q1 2026?  Is the industry on hold until DCC’s move up in 2027?  

This is one reason we specify it as a minimum. It's to help reduce the ecosystem being dragged, and having as wide a spread of versions within a given CY.

DCC's could move ahead of the minimum at any point, the issue you mentioned would happen today as well so this wouldn't make it any worse, but should make it faster to be able to adopt versions faster/more consistently.

> Have there been discussions around a LTS version of OpenUSD in the future?  

There have been suggestions around it, but I think LTS is a fairly loaded term. 

I think the more apt description would be that we could treat the X.8 (siggraph aligned release) as the baseline for the following.

Its not really semver, but the closest semver equivalent would be that the X.8 release is equivalent to another libraries X.0 release.

> Indeed the API seems forwards compatible without recent recompilation frustration, would there be a guarantee on ABI level compatibility for studios and vendors who aren’t in a position to recompile? 

I'm not sure that's possible in a pragmatic sense. USD has the full version string in the namespace, so you'd have to at least recompile to account for that. Additionally, various vendors do customize the namespace as well. 

Hypothetically, if you were to have a system that uses a consistent namespace, I think you could make reasonable ABI guarantees but I think you'd still have invariable issues with forwarded symbols from dependencies etc that might infect your linkage. 

> I believe a 1.0 draft of the schema was also presented at Siggraph last year, should the OpenUSD schema version be considered in the VFX reference platform?  If for nothing else to ensure assets are future proofed?  

Hmm, that's an interesting prospect. Having the formal specification of OpenUSD in the platform would be redundant from my perspective, because any given OpenUSD version proposed for the corresponding year would already be a superset of a given spec version too.

[Colin Doncaster]

As a third party vendor one of the promises of OpenUSD is to be able to build a single Dynamic Payload/Hydra 2.0 procedural and have it work across all DCC’s.  It’s like the promise of RIB 30 years later.

With every vendor using a different version of OpenUSD at the moment that’s not possible, and we’d still need to ship a unique build of a procedural for each of the DCC’s.  

If every vendor is building USD within their own namespace, regardless of the version lock, it seems that this would be an ongoing issue?  Or would the procedural and dynamic payload API’s live outside the unique namespaces allowing a single binary to be used across multiple DCC’s? 

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/d8881d72-6f01-4ce8-968c-3231c068633fn%40googlegroups.com.

[Colin Doncaster]

> On Mar 28, 2025, at 7:30 PM, dhruv...@gmail.com <dhruv...@gmail.com> wrote:
>
> > Say everyone agrees on a version at the end of 2025 and all of the vendors conform to that for CY2026, what would the expectation be then when a new OpenUSD is released Q1 2026? Is the industry on hold until DCC’s move up in 2027?
>
> This is one reason we specify it as a minimum. It's to help reduce the ecosystem being dragged, and having as wide a spread of versions within a given CY.
> DCC's could move ahead of the minimum at any point, the issue you mentioned would happen today as well so this wouldn't make it any worse, but should make it faster to be able to adopt versions faster/more consistently.

I don’t disagree that it would be good to cite some sort of minimum - but I think the bigger issue is that DCC’s aren’t keeping up with releases as quickly as the OpenUSD community likes. It would be good to understand why that is before using the VFX reference platform as a means of enforcement?

I wonder if this comes down to the monolithic design, where it’s not just the scene composition USD component that DCC’s are building upon, but HDR and Imaging which adds more complexity to migration.

> > Have there been discussions around a LTS version of OpenUSD in the future?
>
> There have been suggestions around it, but I think LTS is a fairly loaded term.
> I think the more apt description would be that we could treat the X.8 (siggraph aligned release) as the baseline for the following.
> Its not really semver, but the closest semver equivalent would be that the X.8 release is equivalent to another libraries X.0 release.

With the wider adoption of OpenUSD I suspect enterprise and manufacturing are going to eventually want some sort of LTS.

>
> > Indeed the API seems forwards compatible without recent recompilation frustration, would there be a guarantee on ABI level compatibility for studios and vendors who aren’t in a position to recompile?
>
> I'm not sure that's possible in a pragmatic sense. USD has the full version string in the namespace, so you'd have to at least recompile to account for that. Additionally, various vendors do customize the namespace as well.
> Hypothetically, if you were to have a system that uses a consistent namespace, I think you could make reasonable ABI guarantees but I think you'd still have invariable issues with forwarded symbols from dependencies etc that might infect your linkage.

As per my other reply, as a third party it would be nice to be able to build a USD plugin and have it work across DCC’s - if each DCC is stuffing their flavour of USD into a namespace this becomes a bit of a housekeeping problem.

> > I believe a 1.0 draft of the schema was also presented at Siggraph last year, should the OpenUSD schema version be considered in the VFX reference platform? If for nothing else to ensure assets are future proofed?
>
> Hmm, that's an interesting prospect. Having the formal specification of OpenUSD in the platform would be redundant from my perspective, because any given OpenUSD version proposed for the corresponding year would already be a superset of a given spec version too.

It might be good to cite the schema version along with the OpenUSD version, although it feels redundant it might be good to know what .usd files are compatible with what CY’s?

I appreciate the discussion and the complexity of the situation. :)

[Larry Gritz]

On Mar 28, 2025, at 4:24 PM, David Aguilar <dav...@gmail.com> wrote:

I don't think ABI (binary) compatibility is tenable. The last time I checked, the open source USD builds put their symbols into a versioned namespace that matches the library's version. In that respect, every single version is not ABI-compatible with any other version whatsoever.

Right, that how all the projects currently work -- 100% incompatible from one year to the next because every last symbol moves to an entirely new namespace.

Sorry, this is going to get pretty "inside baseball." 

This "change the whole namespace" approach is foolproof from the library's standpoint, since you can never accidentally link against the wrong version of the library, but has a couple of drawbacks:

1. You can't easily write a plugin that uses library, for example, that would work with DCC A that uses Package 3.1 and also DCC B that uses Package 3.2.

2. The library authors may be saddled with support and bug fixes for users still stuck on multiple very old versions of the library.

In OIIO, I'm experimenting going forward with an alternative approach wherein

* What's in the v3_1 inner namespace just stays there for next year, too.

* Next year, new stuff and things that truly have to change go in v3_2, while things that don't change just alias the to old v3_1 namespace, so very few things actually get fully duplicate implementations in multiple namespaces.

* Thus, things compiled against 3.1 will link just fine against the 3.2 library without recompilation, since the old symbols are still there.

* "My DCC reports a bug in OIIO 3.1 but we can't upgrade until next year" now can have the solution of "we've already fixed it in 3.2, we're not backporting, but it's safe to upgrade now -- you won't lose compatibility with any user plugins that expect 3.1 symbols."

* Every several years, like for 4.0, we can clean up the things that have been long deprecated in prior years (but still had working symbols).

I don't know that this scheme is the best or only way to do it. Maybe it will be a disaster. But I figure I need to try something, and if it works, out it will catch on. I think we won't really be able to assess its ultimate success until a few years from now when we're on 3.3 or 3.4 and can say if it's really still easily compatible with and upgradable from 3.1.

--

Larry Gritz

l...@larrygritz.com

[Brecht Van Lommel]

On Sat, Mar 29, 2025 at 12:54 AM Colin Doncaster <co...@peregrinelabs.com> wrote:

I don’t disagree that it would be good to cite some sort of minimum - but I think the bigger issue is that DCC’s aren’t keeping up with releases as quickly as the OpenUSD community likes.  It would be good to understand why that is before using the VFX reference platform as a means of enforcement?

I wonder if this comes down to the monolithic design, where it’s not just the scene composition USD component that DCC’s are building upon, but HDR and Imaging which adds more complexity to migration.

Isn't it the opposite? DCCs are shipping versions of OpenUSD that are newer compared to VFX platform libraries.

To get binary compatibility within one VFX platform year, DCCs would have to either use older OpenUSD versions or align their release schedules.

[Colin Doncaster]

That’s an interesting solution worth trying, not dissimilar to tr1 with the standard library.  I can see how this is more housekeeping when developing the libraries but as the scope is bleeding beyond the VFX industry I think it’s an effort well spent. 

Thank you for giving this a go Larry.  

As for OpenUSD, ideally if we have a version cited in the VFX reference platform that everyone is conforming to then unique namespaces should be needed allowing plugins etc. to be usable across DCC’s.  

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/B120A0CF-011A-4357-ABC6-C0120217B8E0%40larrygritz.com.

[Kimball Thurston]

In addition to Larry's comments, for OpenEXR, as of either the next release or the release after that depending on testing and not wanting to incur massive changes, it will be truly ABI stable and fully backwards compatible, so deserving of the up/down arrow and minimum going forward. This is a step farther than what OIIO is off to do, which is also a great step towards compatibility. But OIIO will continue to require similar libstdc++ / libc++ and ABI flags for C++ for a while but at least make it such that when a newer version is around, it won't brick every other app. But the VFX platform year provides that C++ library control for oiio, where operating systems don't pay attention to the vfx platform spec. A practical example where this matters: Unreal likes to use libc++, not libstdc++, but otherwise the linux version works well these days, so rather than requiring recompile, I would like the O.S. provided version, or other pre-compiled binary versions, to be more portable for EXR across a wider audience.

EXR is a simpler library to do so with, so do not take that as what everyone should choose, just wanted to point out the roadmap / goal. This was part of why we started with adding the C core to EXR, given widespread O.S. adoption of EXR and will continue expanding as we replace more of the C++ side of things which make it more difficult to be abi compatible. The API (and therefore ABI) will get to either only pod types, or fixed structs, and then inline pass through for things like std::strings and STL structures such that those can be whatever ABI / c++ std library provider, in addition to being able to provide allocators and such per-context, in whichever translation unit, and we don't care.

This is going to be more difficult for OpenUSD of course as it is that much larger than either EXR or even OIIO, but I think as we progress forward in time with string views, (md) spans, etc., that will also become more apparent / easier to provide generic, fast, safe functions that are more and more compatible. And maybe some sharding of USD might make sense in terms of abi stability, but that seems hard to point out at the moment.

With all that said, I VERY much appreciate and encourage the efforts that Foundry, Autodesk, SideFX, et al. are going through to provide "bring your own usd". This isn't the easiest path I am sure, but it makes providing in-house usd addons that much easier where we only have to compile delegates / sdf plugins / whatever for the one (our) version of USD internally per VFX platform year, and so non-dcc specific chunks of the pipeline can remain fully agnostic and not have yet another build variant - in fact, you kind of only have the few VFX platform years you're supporting. In case there are any doubters, we have already been able to provide a newer USD version to both katana (except hydra ... yet) and houdini than what was originally shipped with, although we did have to patch the python a bit in at least one case. And maya we've been doing that for a long while for USD export anyway.

tl;dr I am not sure yet whether we benefit from a hard-locked USD version / year, but think that Dhruv's approach of a minimum sounds plausible, especially knowing the experiments we're doing prepping towards 25.05/8 versions already and our desire to leverage the bring your own usd layers to be able to leverage those new features / capabilities. Longer term, might make sense to fix a version, but do not think I'd be happy to do so just yet.

best,

Kimball

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/B2AE37D7-3D8A-40DE-99B6-6567DE8BDA66%40peregrinelabs.com.