• Rebase with master/D11591.

This is what the Python OBJ exporter does to get the materials

I am not sure yet, I would hope that doing that on evaluated objects should give you the 'final' list of materials... But this needs to be investigated. Also need to check OBJ to understand why it's working there.

So what's the correct way to fetch materials now? The old way was to read ob.material_slots[n].material.

This looks good to me, as well, and works nicely in my quick test. Thank you, @Philipp Oeser (lichtwerk)!

@Michael Kowalski (makowalski) might also be interested to check here.

LGTM

The user expected behavior is that it would work like the file save window, and add the extension automatically

Thanks for the review, @Sybren A. Stüvel (sybren). I made the changes.

• USD import: rename material collision option.
• USD import: material collision code fixes.

• Adjust #include formatting, so that it's consistent with other Blender code and make format
• Remove unused bmain parameter
• Remove trailing whitespace

ps: please before sending in a patch, run make format to ensure it's formatted correctly.

Not using bmain is a good thing, but the warning could be removed too ;-)

blender/source/blender/io/usd/intern/usd_writer_volume.cc:91:74: warning: unused parameter ‘bmain’ [-Wunused-parameter]
   91 |                                                              const Main *bmain) const
      |                                                              ~~~~~~~~~~~~^~~~~

LGTM, found a few tiny things, see the inline notes.

Regarding last compilation fail - it turns out that since 22.03 USD version there has been a change to UsdVolFieldBase class inheritance (UsdGeomBoundable is no longer a parent). For whatever reason running make update wasn't updating my USD lib version, so I was sitting on 21.02 and couldn't see this error. Thanks for the heads up!

• Fixed compilation issue for USD 22.03 version related to removed extent attribute for volume fields.
• Updated D14193TestFiles.zip (in patch description) with new test.usda file reflecting the change mentioned in previous point.
• Improved if logic in USDVolumeWriter::resolve_vdb_file method.
• Added comment in USDHierarchyIterator::get_export_file_path method, further explaining what it does.

In D14792#397695, @Sybren A. Stüvel (sybren) wrote:

In D14792#397679, @Ray molenkamp (LazyDodo) wrote:

yeah but by that logic, we're using none of the imaging module right now, you want to disable the whole thing?

I'd like to see @Michael Kowalski (makowalski) chime in here and determine "is it useful to us and may we use it in the near future" lets not base it on if it's currently being used.

I've updated the description to read:

However, since [the Imaging] module was included for its support for converting primitive shapes (sphere, cube, etc.) to geometry, OSL is not necessary.

Earlier it read "..., it's not necessary", where it was ambiguous what "it" referred to. Support for USD primitives is a concrete use case.

In D14792#397679, @Ray molenkamp (LazyDodo) wrote:

yeah but by that logic, we're using none of the imaging module right now, you want to disable the whole thing?

I'd like to see @Michael Kowalski (makowalski) chime in here and determine "is it useful to us and may we use it in the near future" lets not base it on if it's currently being used.

In D14792#397679, @Ray molenkamp (LazyDodo) wrote:

yeah but by that logic, we're using none of the imaging module right now, you want to disable the whole thing?

I'd like to see @Michael Kowalski (makowalski) chime in here and determine "is it useful to us and may we use it in the near future" lets not base it on if it's currently being used.

When uploading a patch, please follow the guidelines on the wiki. That'll prevent the "Context not available" between modified chunks of code. No need to reupload this patch that way, but when updating it, please include more of the context (-U1000).

Your changes look good to me, @Piotr Makal (pmakal), and I like your solution of having the File References option in its own box in the UI.

• Renamed "Assets" to "File References" and moved this option to separate UI box. As shown in the figure below:

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.

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

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.