Quick Q n A
Placeholder answers until I get time to flesh this out more:
Just use it. If you've read this far, you'll be thinking the same questions that everyone else does. "Ok, how do I import my geometry? Do I import my materials first or last? Do I need the proxy stuff? How can I templatize all this? WON'T SOMEONE TELL ME WHAT TO DO??'
The Component Builder is a great template to start with. Put it down, it makes a little network of nodes to structure your USD nicely. Dive into the geometry node, pull in your geometry, connect it to the clearly labelled output. Dive into the material node, make your material. The network will auto assign the material, name your geo nicely, and get you going.
If you don't like the setup, thats fine, its designed to be modular and adjustable, but best to just use it first as is until you get comfortable with hacking USD yourself.
It should just work, but probably won't. Put down a cache node, should fix things.
Why? Lops attempts to leverage USD as a rib/ifd/ass replacement as much as possible. Most (all?) of these render geo formats will treat that render cache as an instantaneous snapshot of time, like taking a photo with a super high shutter speed. By default there's no sense of motion, everything is frozen.
To do geometry motion blur, most render formats then have to store multiple time samples. Lops and USD is the same. The cache lop in its default mode will make the next frame (or previous frame, or whatever interval you want) be stored in the usd file, so the renderer can access it. It makes sense from a tech standpoint, but is unintuitive for most users. Expect this to be silently turned on by default under the hood if you enable motion blur on a karma lop.
You're a lighter, you load in a huge USD for a shot, then add lights, assign materials, modify visibility. You want those changes you've made stored in their own USD file, and want to ensure that no big heavy geometry gets accidentally stored twice or baked and stuffed in your lighting file.
A layer break lop enables this workflow. Put this node in before your changes, this forces Lops to say 'right, anything downstream of here will be compartmentalised into its own layer, so when you save, all these new things and modifiers will be saved into a clean seperate usd file'.
more on materials (geo subsets, multiple materials for a geo, collect node)
Maya let you assign materials per face, but was never really happy with it. It's possible in Lops too, with similar caveats.
The preferred way to work is to just split your model, and assign materials to each section. So if you have a car mesh, make sure the parts have different @path attribues, when pulled into lops they'll appear as seperate prims, you can assign them appropriately.
Of course that doesn't always work, say you have a character mesh with different materials for body and head. If you plan to subdiv the model, you'll get a seam.
To fix this, you can have Lops import the mesh sections with GeomSubSets. In the Scene Graph Tree you'll see extra sections under the mesh prim, which allow you to assign materials. They sometimes cause issues with different renderers, but mostly work.
The collect node allows you to support multiple renderers with different material networks. Say you want a USDPreviewSurface fallback for everyone, a karma material, a redshift material. Create them all in a material library, connect their final results to a collect node. When you swap delegates, lops will appropriately swap materials for you.
When Apple decided to support USD, they wanted a single file representation that could be easily shared, viewed on iOS devices. Their simple answer was to collect up all the textures used by a model, bake down all the seperate USD files into a single one, and zip it up. That's what a USDZ file is.
Pro's are that you get a single file, and you can open it on you iphone. Cons are that other apps and dcc's support it to various degrees. Lops can read them, write them, but won't let you modify in place (ie you can't load a usdz file in lops, change it, then write it back to the same usdz). They can sometimes be picky about paths to textures, and especially image types (only png is supported). Materials really have to be USDPreviewSurface only, and a few other gotchas I can't remember off the top of my head. Still, if you're working with iOS in any way, its handy to be able to author these directly in Lops.
fancier merge operations; graft vs merge vs reference vs stage manager
- Merge - Layers will stack, no complex composition is done
- Graft - Try and combine inputs into a single layer. If you have large layers, this can be an expensive operation, save this for atomic edits
- Reference - The preferred method of pulling in stuff from disc, combining layers. It's very strict in how it creates the output, how naming works, somtimes the messier graft can be the more versatile approach
- Stage manager - will use references under the hood if you load things from disk, and will do expensive recomposition as you move structures and rename things, but thats the cost of full freeform edits.
time varying malarky
Basically blue is good, green is bad. Look in the scene graph details (and also keep an eye on the time badge per node), really think carefully about what is causing cooks per frame. Lops and USD lets you get very atomic about what will be saved in the final usd file as values per frame vs just static, so you might say P is time varying while displayColor is static. This can be controlled by the sopimport options, especially what are treated as 'default values' (ie they don't change in time). But also be aware the Lops and USD can lull you into a false sense of security; when you move the timeline it triggers a cook, so even though you might have attributes marked as static, you're essentially get a fresh 'static' bake on every frame, which is now what you want. Careful now!
usd configure node in sops (eg fix packed handling)
Example coming in later, but you can set how sops attributes will appear in lops by using a sops usd configure node. Handy way to ensure clean inputs.
sopimport vs sceneimport, pros and cons
Sopimport is good for fast atomic level control of how work comes into lops, but won't bring in materials or cameras.
Sceneimport can pull in everything (objects, materials, lights, cameras), but lacks low level control. Sometimes you need both.
rendering! karma lops, usd husk stuff
Still getting my head around this stuff (to my shame I've mainly been using Lops for layout and realtime focused output, not final pixel rendering), but its definitely getting easier.
Keeping it simple, the Karma lop is pretty good, can setup most of the bits and pieces you want. The Lop node will create extra nodes in your Scene Graph to store these render proprties, and if you swap the viewport delegate to Karma, you'll see these changes.
To actually render frames on disk, there's a couple of options; you could do it 'live' from within lops, but that's inefficient. You're consuming an interactive license, locking up your machine, not ideal.
Better is to use Husk. Husk is sidefx's command line usd renderer, which interestingly doesn't consume a license at all. Ultimately under the hood it runs a command line that looks like 'husk myrender.usd', it will fire up the correct Hydra delegate, read the settings stored in the file, render out the framerange you want.
The way we're using this is via tops. We'll use lops to setup the scene, and write out a usd file to disk. Then in tops we use a USD Render node, which is a wrapper for husk, to render your usd in a seperate process.