Initial LOD proposal

[meshula]

Description of Proposal

This proposal defines an API schema for managing Level of Detail (LOD) in USD stages. The LOD API enables creators and renderers to efficiently switch between different detail levels of assets based on configurable criteria like distance, screen size, or explicit selection. This approach allows optimizing rendering performance while maintaining visual quality where needed.

This proposal is a modernization of the original Ubisoft LoD proposal which is included in the proposal as supporting documentation. Many thanks to the original authors for that work.

This proposal is preliminary, for community discussion and requirements gathering, and not expected to land in its present form. Please use this PR as a place to collate discussion and feedback. It would be great to learn of alternative approaches, modern LoD systems, how LoD works in your engine, and so on.

[
Link to Rendered Proposal
](https://github.com/PixarAnimationStudios/OpenUSD-proposals/tree/lod/proposals/level-of-detail)

Contributing

• I agree to and accept the Supplemental Terms.

[dgovil]

I've been trying to just poke at a few parts of this and had a few questions and thoughts

• How could we do paired LOD? E.g if you have crowds, you might have mesh+skeleton+material that change together versus independently.

• I keep coming back to variants being an expression of LODs. I know we've discussed the problems with that approach, and I agree currently that it's an issue. But I wonder if OpenUSD added a concept of "variant views", it could simplify things?

In my head a "variant view" would be letting me take a stage and construct a view of the stage with a different variant activated, without changing the primary view of the stage. That would effectively let a runtime pull out all the types of variants without changing the primary viewed variant.

[spiffmon]

In my head a "variant view" would be letting me take a stage and construct a view of the stage with a different variant activated, without changing the primary view of the stage. That would effectively let a runtime pull out all the types of variants without changing the primary viewed variant.

I wouldn't want to hang this proposal on a change like that. It's conceptually very appealing, but opens the door on a lot of complexity, performance issues, and potential correctness issues (e.g. there'd be no way for the stage to monitor changes to non-selected variants, so no way to inform clients).

[dgovil]

Fair. I’m curious how we might do LOD bundles (material+mesh+skel or other arbitrary things). It’s not something we need right now but just looking at the general usage patterns for real time uses, I think it will inevitably come up. Though it also doesn’t need to block this proposal since I guess you could create an additive change that allows expressing that when the need arises.

…

On Wed, Aug 13, 2025 at 10:44 AM F. Sebastian (spiff) Grassia < ***@***.***> wrote: *spiffmon* left a comment (PixarAnimationStudios/OpenUSD-proposals#81) <#81 (comment)> In my head a "variant view" would be letting me take a stage and construct a view of the stage with a different variant activated, without changing the primary view of the stage. That would effectively let a runtime pull out all the types of variants without changing the primary viewed variant. I wouldn't want to hang this proposal on a change like that. It's conceptually very appealing, but opens the door on a lot of complexity, performance issues, and potential correctness issues (e.g. there'd be no way for the stage to monitor changes to non-selected variants, so no way to inform clients). — Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB4XUWFTH7ZXLZ4CAECF433NN2N7AVCNFSM6AAAAAB4ECDUD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOBUHA3DSMBSGA> . You are receiving this because you commented.Message ID: ***@***.***>

[meshula]

The proposal has been updated to reflect feedback to date, and now includes a definition of Heterogeneous Hierarchical Level of Detail.

How could we do paired LOD? E.g if you have crowds, you might have mesh+skeleton+material that change together versus independently.

@dgovil The proposal has been updated to concretely cover that case.

[MishDivy]

Thanks for the proposal!

Initial Questions / Thoughts

• I'm not sure what the official guidance is regarding indirectly inheriting from APISchemaBase.
  In my experience, usdGenSchema throws an error when trying to define an API schema that extends another concrete API schema. See the relevant code in usdGenSchema.
  Since indirect inheritance from APISchemaBase is used extensively in this proposal, it might be worth a clarification here.

• In some OpenUSD applications, prim count is a major performance factor. A pattern I’ve seen is collapsing parts of a model-kind transform/mesh hierarchy into a single mesh prim (with subsets) and storing that as a separate variant. This isn’t ideal, but it yields a composed stage with fewer prims at runtime while other variants preserve the verbose hierarchy. In this case, the level of detail type (levelType) relates to prim count rather than geometric, material, or physics differences. I am wondering how would this proposal work with this kind of optimization?

[michaelybecker]

(late to the party, apologies if this has already been discussed to death elsewhere!)

This proposal is incredibly exciting - it represents such a quantum leap for OpenUSD in real-time contexts!

The architecture at large makes a lot of sense. I am curious about one design choice - expressed in a several parts of the schema - specifically, the choice of including heuristic data and encapsulating specific agency that strikes me as traditionally belonging to the application-domain rather than the "LoD subject" (for lack of a better term).

By their very nature, LoD heuristics seem (to me, at least) incredibly situational and context specific, especially considering the fact LoDs are primarily motivated by performance considerations highly contingent on bespoke hardware platforms and (perhaps to lesser extents) renderer architectures, OSs, game engines etc.

So I find myself wondering whether attributes such as screen size thresholds, distance thresholds and even transition ranges - in fact, the very question of which criteria to employ when switching LoDs (encapsulated in the perhaps-misnamed distance - a more appropriate token type might be criteria or heuristic?) - might be out of the scope of the LoD domain itself, since (in true Gödelian form) the bearer never has enough situational context to make intelligent choices about switching LoDs. As a case in point, I'm fairly certain the current state of the art overwhelmingly points to the rendering context (e.g the game engine, DCC or web framework) rather than the asset being the locale of such decision making, and for good reason.

Graver than the metaphysics of responsibility domains are the practical aspects of committing to the "mess of implementation" in a spec. LoDs themselves are a wonderful value-add that is usage-agnostic and, their inclusion enables capturing oodles of creative intent that would otherwise be delegated either to downstream humans or to automated last-mile processes.
But shipping something so implementation-sensitive as heuristics opens up a context-bound can of worms; for example, how can I meaningfully instruct an asset to "switch to LoD 1 when 5 units away" during the authoring stage, when I know some engines will interpret the concept of "distance units" as meters while others as centimeters? How can I make informed FPS-based switching decisions when the same asset is designed to run on a phone, a smart fridge and a threadripper? At the bare minimum, this greatly increases the implementation overhead when accommodating this data in any given platform, and imposes technical choices that may be foreign to how it "prefers" to reason about LoDs.

In short, I perceive these heuristics as potentially kneecapping the very flexibility LoDs can offer, by baking in their predetermined, inflexible usage recipes at source. In practice, I suspect you'll end up having to accommodate differing heuristics in every platform (that are also directly informed by the platform's own API and way of doing business) which - in my mind, at least - directly contradicts the notion of having those be a part of the "platonic ideal" of the asset.

(Hope my two cents aren't too feather-ruffling, I'm such a fan of this proposal overall!)

[meshula]

I'm traveling so will answer in detail later.

@MishDivy Good example, we should be able to accommodate that classic optimization.

@michaelybecker Those are well reasoned points, and indeed we don't want to be in the business of maintaining every possible LOD heuristic for every possible engine and application. USD files serve more than the purpose of interchange however, so it makes sense to be clear about which elements are meant to be interchangeable. Another purpose for a USD file is reify specific data, so the proposal should be clear about where heuristics are encoded, how they relate to the overall LOD scheme, and rather than specifying an unending zoo of heuristics the proposal should instead lay out how you might store information for your application coherently. As such the proposal will need a pass to clarify the required elements versus example solutions. I'll raise your Gödel with a Hegel and say that that revision should sublate the original proposal and your contradictions ;)

Thanks for the feedback.

[tcauchois]

Small rebuttal/complication to @michaelybecker. I agree that LOD selection is fundamentally application/use-case driven. However, putting my VFX hat on for a moment, in VFX we don't care about swapping stuff in and out dynamically to keep frame time down; we're applying some automatic LOD to (usually) degrade materials or save memory on objects that don't get a ton of pixels. But we care a great deal about reproducibility; and the LOD pipelines may be configured by batch processes, anyway. So while encoding LOD selection in the file might not make sense for all/many use cases, it is a pathway that's useful to support.

Not sure how to square that with interchange, though. Within a pipeline I'd want to keep using the pipeline-provided LOD, but it wouldn't make sense for other contexts. I wonder if there's a better way to capture intent here?

[michaelybecker]

thanks, @tcauchois , that's very helpful context, and the "helpful optional pathway" angle makes a lot of sense.

[spiffmon]

Not sure how to square that with interchange, though. Within a pipeline I'd want to keep using the pipeline-provided LOD, but it wouldn't make sense for other contexts. I wonder if there's a better way to capture intent here?

One way to make this clearer might be to cast LOD-selection as a multi-apply schema, so pipelines, when appropriate, apply a site/pipeline/dcc specific instance of the schema, and independently, inform Hydra/the-renderer which instance (if any) of that schema to consult?

[meshula]

I addressed the general concern of interoperability vs domain specific storage of useful data by adding a systemDomain field to the heuristic, and throughout annotated doc strings to indicate which fields are meant to be consistently named as an advisory hint to interoperability while emphasizing that for the purposes of interoperability the heuristics are not intended to be anything more than hints to an importing application. I also removed the lod selection index as it's position in the rel array is sufficient and the index was redundant.

As @MishDivy pointed out, api schemas can only derive from APISchemaBase; it would be nice to have a way to easily detect that a heuristic API is a heuristic API. It's probably sufficient that the name end in HeuristicAPI.

The idea of a multi-apply schema to encode domain specific LOD selection is interesting, however I haven't applied it yet.

[meshula]

Proposal updated with most recent feedback taken into account.

[meshula]

The schema definition has been updated to reflect most recent feedback.

[dgovil]

So just some feedback items:

• I think the API names are a little too generic. ConfigurationAPI and LevelAPI aren’t clear by themselves and would preclude anyone else having something called configuration api. Which I can see people wanting that in the future for other domains too

• same with selectionMode and targetFramerate, unless that gets namespaced when applied?

• I think we’re still missing how to tell USD not to render a specific hierarchy until it’s activated by an LOD. The example scene I think would have people rendering the city hierarchy in its entirety.

But from a “what needs to be defined” perspective I think it makes sense.

[meshula]

after you run it through genSchema, it comes out like UsdLodConfigurationAPI and UsdLodLevelAPI, but I suspect you are looking for something else when you say they aren't clear. Open to suggestions, I'm coming up dry.

These are multi-apply schemas so they become namespaced in the usual way, yes.

As to rendering a specific hierarchy, when you select a particular level, that "level" may contain a hierarchy. You could set up a sub-hierarchy within the city, the schema is intentionally hierarchical. Presumably you would set up some kind of heuristic to prune the city; the example doesn't set that up. But you might divide the city into blocks, and set up a frustum heuristic as an example so that only blocks within the six bounding planes of the frustum are traversed, as an example. There's no frustum heuristic proposed, however the mechanism is meant to make it simple enough to declare one.

[dgovil]

The GenSchema name would just be the C++ API but I mean what would be serialized in the USD file. It wouldn't have the prefix applied so would preclude any other api in any other schema being called ConfigurationAPI.

For pruning, I feel like that's something we should be solving along side this proposal. Leaving it up to heuristics and how a renderer or endpoint may load the scene feels like it would be fragile and lead to lots of divergence in behaviour

[spiffmon]

The schema declaration can be configured to preserve just the "Lod" part of the prefix for the schema name/identifier, while still allowing the C++ classes to have the full "UsdLod" prefix, as we do for the schemas in UsdRender.

[dgovil]

Yeah I think that would be preferable. That way it's LODConfigurationAPI which feels much nicer in the file.