Paths

Table of Contentst

WIP: USD cycles procedural
Needs ReviewPublic
Actions

Authored by Charles Flèche (charlesf) on Apr 4 2022, 1:32 AM.

Details

Reviewers

Summary

This patch is a first step toward a USD Cycles procedural node. While the current approach of rendering an USD in Cycles through an Hydra plugin is neat, it does require the Hydra layer, while a procedural would allow a more direct integration. This procedural is by no mean complete and is marked WIP to start a discussion / link to what has been decided, get comments, make baby steps toward a potentially mergeable patch and define what minimal feature set should be implemented before this patch is considered mergable.

An XML scene can link to an USD:

<cycles>

<camera width="1920" height="1080" />

<transform translate="90 125 -600" scale="1 1 1" rotate="0 0 1 0">
  <camera type="perspective" />
</transform>

<background>
  <background name="bg" strength="2.0" color="0.2, 0.2, 0.2" />
  <connect from="bg background" to="output surface" />
</background>

<usd filepath="/home/charles/opt/USD-samples/Kitchen_set/Kitchen_set.usd" />

</cycles>

Currently only non-animated, non-shaded, triangulized (no suddiv) meshes are supported as one Object / Geometry per USD mesh, and nothing is cached.

The build could largely be improved:

cmake's WITH_BLENDER is relied on to install the datafiles/usd folder where the USD plugin lives. It is then currently impossible to build cycles standalone without blender.
the functions to find the datafiles/usd folder are in blender, not cycles. As such there is a temporary, somewhat hardcoded way to register the USD plugins.

Diff Detail

Repository

rB Blender

Branch

cycles-usd-procedural (branched from master)

Build Status

Buildable 21438
Build 21438: arc lint + arc unit

Event Timeline

Charles Flèche (charlesf) requested review of this revision.Apr 4 2022, 1:32 AM

Charles Flèche (charlesf) created this revision.

Harbormaster completed remote builds in B21437: Diff 50055.Apr 4 2022, 1:32 AM

Charles Flèche (charlesf) edited the summary of this revision. (Show Details)Apr 4 2022, 1:37 AM

Charles Flèche (charlesf) added projects: Cycles, Render & Cycles, USD.

Revert usd.cmake to upstream version

Harbormaster completed remote builds in B21438: Diff 50056.Apr 4 2022, 1:41 AM

Charles Flèche (charlesf) edited the summary of this revision. (Show Details)Apr 4 2022, 1:46 AM

Charles Flèche (charlesf) mentioned this in D14538: Add nullptr check in case a mesh has no shader.Apr 4 2022, 1:55 AM

I would really want to avoid code duplication with the Hydra implementation, since it's effectively converting the same data structures. Otherwise it's more work to maintain, and we end up with bugs where a Hydra viewport shows one thing and a background render shows something else.

Is there no way to reuse that code for a procedural also?

Also one thing I've been considering is, could we drop our custom XML format completely in favor of USD?

I don't know what your intended use case is for the USD procedural, but if it's rendering USD files in Cycles standalone, then being able to render a .usd file directly would solve the same problem. A USD procedural can still be useful in e.g. the Blender viewport, to mix a Blender data with USD data.

It's doable, I have a prototype lying around that needs some clean up. It instantiates the Cycles Hydra render delegate (with an existing Cycles session: https://developer.blender.org/diffusion/B/browse/master/intern/cycles/hydra/render_delegate.h$17), loads the USD stage and pushes it into the render delegate to sync. That takes care of setting up the Cycles scene and can then render as usual.
Does require a USD build with Hydra though of course, so if we want to make building the Cycles standalone with USD support using the precompiled libraries only possible, would need to update the precompiled USD to also include the Hydra component.

In D14537#390293, @Patrick Mours (pmoursnv) wrote:

Does require a USD build with Hydra though of course, so if we want to make building the Cycles standalone with USD support using the precompiled libraries only possible, would need to update the precompiled USD to also include the Hydra component.

The 3.2 lib update will enable the imaging components for USD which I think hydra is part of?

intern/cycles/app/CMakeLists.txt

Setting interface link options for an executable is somewhat strange and unlikely to work, you most likely need something like this:

set_property(TARGET cycles APPEND_STRING PROPERTY LINK_FLAGS_DEBUG " /WHOLEARCHIVE:${USD_DEBUG_LIB}")
set_property(TARGET cycles APPEND_STRING PROPERTY LINK_FLAGS_RELEASE " /WHOLEARCHIVE:${USD_RELEASE_LIB}")
set_property(TARGET cycles APPEND_STRING PROPERTY LINK_FLAGS_RELWITHDEBINFO " /WHOLEARCHIVE:${USD_RELEASE_LIB}")
set_property(TARGET cycles APPEND_STRING PROPERTY LINK_FLAGS_MINSIZEREL " /WHOLEARCHIVE:${USD_RELEASE_LIB}")

I think the Hydra dependency would be worth it for not having duplicated implementations.

HEYPictures (HEYPictures) awarded a token.Apr 4 2022, 6:51 PM

I would really want to avoid code duplication with the Hydra implementation

Makes total sense. I haven't taken a look at the hydra implementation yet, that's definitely my next step.

I don't know what your intended use case is for the USD procedural, but if it's rendering USD files in Cycles standalone, then being able to render a .usd file directly would solve the same problem.

Rendering USD files in Cycles standalone is the intended use case: some DCC / script generates USD stages that are then rendered on a farm by executing cycles standalone.

By render a .usd file directly I suppose you mean usdrecord --renderer cycles kitchen.usd ? If that's the case, yes, we could definitely use usdrecord and the cycles's hydra plugin. But it needs a python environment for usdrecord and build of USD that requires Hydra. With a a procedural those wouldn't be needed and would simplify the rendering environment on the farm.

Also one thing I've been considering is, could we drop our custom XML format completely in favor of USD?

Probably, eventually. USD is still a big dependency, so I'm not sure what the plan for cycles would be. Even though, if that patch was accepted, I was considering making the XML scene format a procedural and the cycles standalone to create an empty scene and add a procedural (ABC / USD / XML) depending of the type of the input file. That cycles would still be able to render XML, but could also render USD directly (and this will make it easier to add other file format like glTF if needed).

But dependency size consideration apart, USD really seems like a solid candidate a cycles scene description format.

In D14537#391034, @Charles Flèche (charlesf) wrote:

By render a .usd file directly I suppose you mean usdrecord --renderer cycles kitchen.usd ? If that's the case, yes, we could definitely use usdrecord and the cycles's hydra plugin. But it needs a python environment for usdrecord and build of USD that requires Hydra. With a a procedural those wouldn't be needed and would simplify the rendering environment on the farm.

For convenience I think we'd want to have a cycles binary that still works more or less as it does now, but using the render delegate under the hood and accepting .usd files.

I have not looked at how hard that would be to implement though.

I implemented direct rendering of USD files with the cycles executable in rC1a5f4932b481: Add USD as a file format for Cycles standalone rendering. The implementation itself ended up relatively straightforward.

This could be adapted for procedurals with some work.

That's great. I suppose that makes this diff redundant. Should I just close it ?

You can close it if you want. It would still be good to add a USD procedural at some point, but the implementation would be quite different than this patch.