Geometry LODs - Best practices

Community USD
1

Hi,

What is best practice for handling geometry LODs? Are the any best practice?

Currently we have them published in our pipeline to all go into the same “model.usd” publish, e.g like this:

model_defaultVariant

  • lod0_GRP
  • lod1_GRP
  • lod2_GRP

Where the above is all one .usd file. We then write this “model.usd” into a modelPkg.usda and create a variant set on the top prim called “LOD”, where we set the visibility on/off on the LODs.

Would it be better to have the individual LODs published as their own .usd file and then payloaded into a “model.usda” file as well as setting the visibility?

Thanks in advance

2

Hi @kskovbo

How do you envision artists interactive with them ? Do they manually switch LODs ? And do you think each LOD has its own Material or do they use the same (maybe via bindingcollections for v arious shaders) ?
Are you also looking for something that render-delegates (or any other scene plugin) could automatically switch to based on some camera metrics ?

Cheers,
Paolo

3

If the answer to @paoloemilioselva 's second question is that it is for artists and/or scene-optimization scripts to “manually” select LOD’s (which is what we do for the most part), then you do not want to use visibility to disable the non-selected LOD’s, as Storm and possibly other Hydra renderers pre-load invisible geometry to facilitate fast interactive “re-vising”. So you’ll always pay for processing the highest LOD whether you are drawing it or not. Instead of setting visibility, I’d suggest doing prim.SetActive(False) in the variants in which it is not present.

In our Maya modeling pipeline, when LOD’s are explicitly authored, we put all the geometry into one file and deactivate it appropriately, as you are doing. We have a Houdini-based “standin generation” process for props and crowds that merges and simplifies meshes, and those LOD’s get authored into a separate file that gets referenced in, inside the specific variant that selects it.

4

Hi,

The primary concern is memory optimization at render times. We want a camera based auto-lod system for our renderer (Renderman) to take advantage of. We are currently using Houdini Solaris for the render setup. We also want the artist to be able to manually select the LODs (for example background scattering, just set it all to the lowest LOD).

Currently with the “visibility” on/off as Sebastian mentions, I have the suspicion that Renderman loads in all the LOD’s geometry into memory, regardless of the visibility setting. We will try with “setActive” state instead.

@spiff - As per your last sentence, it does sound like ultimately what gets sent to the renderer is a model file which have each of the LODs in its own .usd file and then referenced into a .usda file, is that correct?

cheers

5

Hey Klaus,

are you intending to use the provided hdPrman delegate and its functionalities or are you writing your own Renderman delegate ? It seems you want that, while also have the artists to pick a specific LOD.

If I can suggest a few things: auto-lods (sending all LODs and letting the renderer to pick the right one) for offline renders(pathtracers) is in most cases not really good memory wise (nowadays), and you might just ensure you have one LOD (the best for all copies/instances of that same element) and use instancing as much as possible.
So, having a system that analyses your scene before sending it to Hydra (before writing the usd file that will actually be rendered) is probably the best approach today, and this means that VariantSets are going to be a good solution, so that you can choose which variant to render for specific shots/cameras.

Cheers

6

Hi,

I am also looking at geometric lod’s for our pipeline. Currently we have a way of expressing the construction of variant sets/variants which is dynamically built and the user can then publish a sublayer that overrides the default variant choice in their shot for rendering. I’m curious if there is an penalty for doing it this way - i.e expressing the variant sets on the prims in this manner? This would be part of a “prop” sublayer which is part of a larger root layer stack.

@spiff is your comment about visibility and set active valid if variant sets are expressed this way? I thought (and very well could be wrong) - that only the selected variant is loaded/composed under the anchor (in my case /prop/shapes/geo)? Or is the pixar approach mentioned not even using variant sets for lods? Is there a benefit to not using variant sets in a LOD workflow?

def Xform "prop" (
    kind = "assembly"
)
{
    def Xform "shapes" (
        kind = "assembly"
    )
    {
        def Xform "geo" (
            kind = "assembly"
            variants = {
                string shape = "cube"
            }
            prepend variantSets = "shape"
        )
        {
            variantSet "shape" = {
                "cube" (
                    variants = {
                        string geo_vis = "low"
                    }
                    prepend variantSets = "geo_vis"
                ) {
                    variantSet "geo_vis" = {
                        "high" (
                            prepend payload = @cube/usdCache/default/v001/assembly.usda@
                        ) {
 
                        }
                        "low" (
                            prepend payload = @cube/usdCache/default/v001/assembly.usda@
                        ) {
 
                        }
                    }
 
                }
                "sphere" (
                    variants = {
                        string geo_vis = "low"
                    }
                    prepend variantSets = "geo_vis"
                ) {
                    variantSet "geo_vis" = {
                        "high" (
                            prepend payload = @sphere/usdCache/default/v007/assembly.usda@
                        ) {
 
                        }
                        "low" (
                            prepend payload = @sphere/usdCache/default/v007/assembly.usda@
                        ) {
 
                        }
                    }
 
                }
            }
        }
    }
}
7

Hi @patricknagle , your use of variantSets is perfectly in keeping with what @paoloemilioselva and I were advocating, and there is no penalty I can think of associated with how you are constructing things. We have a similar layer in our shots that makes lod variant selections and potentially prunes geometry not visible to camera.

In our traditional modeling pipeline, one Maya file held all of the geometry for all modeling and lod variations of a prop model, with a “visibility set”-based workflow for managing them. Our model build would then put all the geo in one USD file, but then create modeling and lod variantSet (nested as you have them) that deactivates all the geo that should not be present for each combination of selections. Not the way to go… just a way :slight_smile: As I mentioned earlier we now have other workflows where lod’s would live in separate files and referenced/payloaded in as you have.