I am having difficulties to wrap my head around the drawMode system.
My goal is to have a card representation for our assets. The assets can be composed of different parts, so ideally the drawMode and the cards should be defined on the asset root.
I consider the simplified (non-default) drawModes only useful for a viewport representation. By default, I’d not want them to be considered when rendering offline.
All this seems to be contradictory. For a viewport-only setup of the drawMode, I would need a separate prim where I can define the proxy purpose. But the real usefulness for something like card display is when the entire asset (on the asset root) is represented on the card (and not one card for each part of the asset that might just overlay one other).
Can anybody tell me if I just misunderstand the concept or give an example of how the drawMode is intended to be used efficiently ?
Thanks !
Happy to provide some guidance @mreinhard. Sometimes similar features have different development histories and predecessors. That’s the case with “model cards” and “purpose” even though they are both related to viewport optimization.
As you suggest, the most useful form of cards is where they replace an entire asset. The GeomModelAPI generally applies this to component model roots. A separate proxy prim isn’t required.
I couldn’t find anything in the documentation about whether or not the cards are guaranteed to be ignored during final render passes, but in practice that’s what I’d expect. usdrecord offers a --disableDrawMode option USD Toolset — Universal Scene Description 26.08 documentation. This global toggle suggests that it may be renderer specific but that your final rendering pipeline could be setup to ignore it.
Moving discussion to Hydra category for a more definitive answer on whether “Draw Mode” is active by default for non-Storm renderers. The H1 ImagingEngine clearly enables DrawModes by default, but I can’t tell for H2, and there’s a comment in drawModeSceneIndex.h that indicates it may only work properly in Storm, currently.
It is up to the app to configure draw mode evaluation in UsdImaging. usdrecord and usdview both enable it by default. I am not aware of renderer-specific behavior here.
For our studio’s batch rendering we use --disableDrawMode to ensure that we always render with full scene fidelity. We use “–purposes default,render” for the same reason. These are pragmatic defaults for now, but we can imagine people asking for finer-grained controls down the line.
I had seen the flag in usdrecord and can well imagine that this is useful if a studio owns the whole rendering pipeline (which broadly speaking we don’t).
Relying on a global behavior switch like that has also consequences for all the ‘hybrid’ workflows which I think are still quite common. It means that all “conversion” steps will need to expose this switch (“editAsMayaData”, “UsdToKatana”, conversion to surfaces in Houdini, Blender and Unreal USD import, Nuke’s ScanlineRenderer2 workflows), and to my knowledge none of these actually does that at the moment.