Yes, projects created with cmake -G Xcode create the datatoc and other binaries in a subdirectory named after the current inside bin.

Here some comparisons at higher sample counts, with hair and motion blur.
11_01_A.lighting.flamenco, 50% resolution, 1024 AA samples.

You need to be careful when looking at test posted in various forums - naturally, OIDN shows a big quality difference between with and without normal/albedo passes. The HDR option also makes a significant difference, when it's turned off it is much more aggressive at blurring bright areas.

• Fixed code style.
• Cleanup in denoiser compositing node.

OpenImageDenoise is adding about ~35MB to the binary, and the current version builds as shared library only (static library should be coming soon). We can debate whether adding 35MB for a single feature is worth it or not (or if we want to keep it as a compile time option that's off by default).

Is it just me or did this break builds with Xcode? Builds using make work fine for me, but when using Xcode projects, datatoc can't launch because it can't find libomp.dylib.

With the exception of the "ignore shaders" option, everything has moved to the host side now.

• Cycles: Moved most feature override code to host side to keep kernel code simple
• Cycles: Polygon smoothing feature override now properly updates in viewport
• Cycles: Moved feature overrides to Simplify subcategory

Fair enough, I’ll be rewriting this to be host side code then.

Yes, this is for troubleshooting. My impression was that the Debug panel is intended for developers, while this is intended for users to help them diagnose rendering artifacts by quickly disabling features. Moving this to the host side is possible the problem there would be though that most options would trigger shader recompilations and device updates, which can add delays in big scenes. When it is device code, it is fairly responsive and can be used with viewport rendering.

This is the documentation of the Arnold equivalent:
https://docs.arnoldrenderer.com/display/A5AFMUG/Feature+Overrides

We could debate whether this should be in the main tab of the Cycles options or moved to the View Layer/Override section.

I think this can be committed. There may be a few things where it can be extended (for example, it would be useful to group the scene_intersect calls by primary, diffuse, glossy, etc rays) and we could think of writing the output in a machine-readable format to allow for nice presentations (see https://rmanwiki.pixar.com/display/REN/Diagnostics for example), but the profiling data is already very useful as-is.

Ideally, we wouldn't need a custom FindEmbree.cmake and Embree's configuration file would point to the required libraries:
https://github.com/embree/embree/issues/209

Hey, I was working on something like that too :D

The normals produced by this code don't always have unit length.

Is it possible that this is missing a normalize() at the end? I'm seeng non-unit length normals being passed into the BSDFs now.
For example the classroom benchmark scene asserts with NaN pixels now.

• Fixed whitespace.

Unfortunately, I have no .blend file to demonstrate this bug, at least not one that I could legally share.

Just skimming the code, I can't claim I fully comprehend it yet. A few thoughts:

All BVHs are going to give identical results, unless they're broken. Likewise, the differences between separate implementations of a given ray/triangle intersector (Möller–Trumbore, Woop, ...) will also only differ in floating point rounding. As long as we're compiling with fast-math turned on, our results will not be bit-perfect across compilers anyway. Hair curves have small differences (caps, self-intersection epsilon), if we need perfection we could just implement the same intersection everywhere (Embree and DXR/OptiX allow for user defined geometry).

Please disregard the excessive changes in platform_win32.cmake - that must have been a merge gone wrong.