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.

Some more updates, addressing Sergey's comments.

• Cycles: Code styling
• Merge branch 'cycles_cryptomatte' of github.com:skwerner/blender into cycles_cryptomatte

• Cycles: Code styling

• Cycles: Addressed Sergey's cryptomatte omments.
• Cycles: Fixed OpenCL build

• Fixed indentation.

• Cycles: Fixed typos in Crytpomatte code.

• Cycles: More Cryptomatte code review changes.
• Cycles: Skip calls to CPU kernel coverage buffer when accurate cryptomatte layers are turned off.

I support this.

I'm seeing CUDA renders on macOS giving wrong results starting with rBd611cf923358 (determined via git bisect, MBP Retina, 15-inch, Late 2013, GeForce GT 750M, Xcode 9.2, CUDA 9.2). The code in rBd611cf923358 looks innocent to me, may be that commit just exposed a compiler bug on macOS?

• Cycles: A little refactor of the cryptomatte ID pass writting to reduce #ifdef clutter
• Cycles: Removed PathState::matte_weight, using throughput instead for Cryptomatte

Addressed some of Sergey's comment.s

• Merge branch 'master' of git.blender.org:blender into cycles_cryptomatte
• Merge branch 'master' of git.blender.org:blender into cycles_cryptomatte
• Cycles: Implemented full sorting for Cryptomatte layers for all possible renderign devices.
• Cycles: Refactoring to remove duplicate Cyryptomatte id pass code.
• Cycles: Addressed some of Sergey's comments on D3538
• Cycles: Stochastic cryptomatte writing now adds coverage to last ID when it runs out of slots.

Without resorting to dynamic memory allocations inside the kernel or grossly over allocating memory, there will always be a chance of randomly skipped data.

• Cycles: Compile fixes for OpenCL kernel.

I think I found a way to write id passes using atomics.

• Cycles: Cryptomatte writing now uses atomics on GPUs to avoid race conditions.
• Cycles: Code style, fixed typos moving murmurhash to its own cpp file.

• Reverted an accidental change.

• Compositor: Fixed Cryptomatte string handling.
• Compositor: Applied Brecht's UI improvements to Cryptomatte node
• Compositor: Fixed broken add/remove in Cryptomatte node.
• Compositor: Raised default number of Crypto inputs to three, as recommended by the Cryptomatte specification.

• Compositor: Cryptomatte node now uses a dynamic string for matte ids, no more 1024 character limit.

Cryptomatte output for Cycles is now in D3538

• Cycles: Addressed Lukas' comments for Cryptomatte output.