Information regarding proxies in VtValue

As I continue navigating through the intricacies of USD’s codebase, I’ve now reached the complex terrain of VtValue and its associated type handling mechanisms, particularly in vt/types.h and related files.

I’ve encountered the term ‘proxy’ and find myself somewhat at sea about its exact meaning and application within USD. From what I gather, USD accommodates a range of common types under VT_VALUE_TYPES, and a comment in the code clearly states None of the VT_VALUE_TYPES are value proxies. However, the concept of proxies themselves remains nebulous to me. Are they some form of wrappers, or do they serve a different purpose?

I’m reaching out in the hope that one of the USD gurus (and congratulations on the sci-tech award :star_struck: :partying_face:, by the way, Alex and all the others! It’s a honor to get answers from you guys) might shed some light on this subject. Could you please explain what proxies are in the context of USD, how they are utilized, and what specific roles they fulfill?

Thank you for your assistance. -ms

Hi @msaintourens , not sure what your goals are, but if they are understanding and possibly replicating necessary USD features/behaviors, you can very safely ignore VtValue “proxies”. The lowest levels of OpenUSD (including the majority of pxr/base) precede the USD project by (in some cases) more than a dozen years. The value proxy feature was made in support of a Presto scene description feature that we would now like to deprecate when we are able, and the proxy feature (specifically, only the “erased” proxy is used in the Presto codebase) allows a layer to be loaded containing types that are defined only in deferred-load plugins, without immediately loading the plugins. But there’s a pretty heavy performance cost (the comments in traits.h refer to threading concerns), and the feature got used for really only one (but used in many schemas) datatype, enums (which in USD we use token-valued attributes for, insead).

Since Presto literally is built on top of USD, we need to keep the feature around for now, though we probably should document it as a “legacy” feature, and for these reasons we don’t provide examples of how to use it.

You’ll find the term “proxy” used in other places in the USD code base to refer to different things, including the UsdGeom concept of prim purpose, but UsdGeom is a long ways up from Vt and Sdf :grinning:

Thank you, Sebastian, for your help. I was tasked to look into the USD code to grasp its fundamental workings for future application. While navigating through the few samples and looking at the doc offers some insight, I need to look at the code to comprehend its internal mechanisms (at least I have a hard to time to do this any other way).

I guess that the forthcoming OpenUSD specs could provide me with some answers, yet I must start this work now. It appears that, apart from the core team at Pixar and a select few from companies like Animal Logic, Nvidia, and Apple who have been involved with USD if I get it well, not many have an in-depth understanding of the codebase. As I become more familiar with it, I hope I can also help others in the future, much like how you’re assisting me now, which I really appreciate.

Your explanation about proxies was helpful and, honestly, it’s a relief to know that I can safely ignore them.