mottosso
commented
6 years ago From Alan over at the chat.
Just to clarify some common misunderstandings about USD and Walter:
- Walter provides a nice way of encapsulating materials as-is, designating material assignments dynamically via regex formulas and define render attribute overrides (also dynamically) from a DCC (Maya, Katana, Houdini) into what becomes internally a USD "stage".
- That means you create a Walter standin (or equivalent) in any of the supported DCCs, set your base layer with your asset geo, assign your materials, attributes and overrides, export them as separate files via the Walter Python API. In another (potentially different) DCC you can then load your base layer and additional layers that you exported just then, and all the shading will follow perfectly as-is. Need stuff to move? Add your animated Alembic geometry after your base geo layer.
- Exporting everything as separate files means you can consider versioning materials separate from shading attributes separate from their assignments, which is neat.
- Feature-wise, Walter is very lookdev-focused, but you can also benefit from the standin as a fast in-DCC USD/Alembic viewer that supports both Hydra (GL) and Intel's Embree (pure CPU realtime raytracer), so handling enormous scenes is much easier on Maya's viewport.
- A Walter standin can load any Alembic or USD file, not just those made by Walter exports. Everything gets ingested by USD internally and becomes part of the one common "stage".
- It's not just a viewport viewer, but also a rendertime procedural (Arnold only right now), so time-to-first-pixel is much lower as MtoA/Maya/KtoA/Katana/HtoA/Houdini do not actually export any big meshes or materials, just a bit of metadata, and Arnold opens the USD stage directly at render time.
- Walter layers get sandwiched into one common stage, which means you can use it to join different sets of data, for example base geometry abc, animated geometry abc, materials, assignments, overrides and transform overrides, one after another.
- Each Walter layer has a "visible" and "renderable" toggles, so you can for example view a low-res layer, but render a mega-hi-res layer instead when the render hits (though you probably wouldn't have to since it's so fast to load high res geo thanks to Pixar's Hydra! :)
- 1 standin/procedural = 1 USD stage, so you will theoretically get better performance in large complex USD scenes if using one standin to display everything than using multiple standins. That said, thinking in terms of 1 standin = 1 asset is perfectly valid also and honestly it's how we're doing it at Rodeo FX right now. Plus you can export the layers and then load all the layers into one standin after, so you're never really restricted if you go 1 standin = 1 asset at first.
- Hydra is usually the better viewer up to a certain threshold of insane detail (usually when your GPU memory can't take it anymore) after which the Embree mode -- which is a fast (not super pretty, but very very fast) raytracer -- may be marginally slower than Hydra, but its slowness concerns with the resolution of your viewport rather than the complexity of what is being rendered. We've noticed it does a better job at handling city-scale assets than Hydra.
- Each standin can be told to use Hydra or Embree, and you can mix them! It's totally fine!
- Not only is it totally fine, but both do correct depth-sorting with regards to other geometry in the DCC, so if you move a true Maya sphere in front of a standin, it will be occluded properly. (AFAIK ours is the only USD plugin handling this.)
- No Windows build as we don't use it at the studio, but there's no technological reason why it shouldn't be possible and we will actively support anyone who wants to make the effort of trying to compile it and/or contributes some Windows builds. (If you get stuck, make us a Github issue.)
- Renderer-wise we only support Arnold as it's what we use at the studio, but architecturally-speaking, the project is sufficiently abstracted that adding support for another renderer would not be a big deal for someone familiar with C++ and that renderer in question.
Is this a good fit for Avalon?