Yes, projects created with cmake -G Xcode create the datatoc and other binaries in a subdirectory named after the current inside bin.
Sat, Feb 9
Fri, Feb 8
Wed, Feb 6
Here some comparisons at higher sample counts, with hair and motion blur.
11_01_A.lighting.flamenco, 50% resolution, 1024 AA samples.
Tue, Feb 5
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.
Mon, Feb 4
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).
Wed, Jan 30
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.
Tue, Jan 29
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
Fri, Jan 25
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:
We could debate whether this should be in the main tab of the Cycles options or moved to the View Layer/Override section.
Jan 18 2019
Jan 14 2019
Jan 11 2019
Jan 7 2019
Dec 5 2018
Nov 28 2018
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.
Nov 23 2018
Nov 15 2018
Ideally, we wouldn't need a custom FindEmbree.cmake and Embree's configuration file would point to the required libraries:
Nov 14 2018
Nov 8 2018
Hey, I was working on something like that too :D
Nov 7 2018
Nov 6 2018
Oct 30 2018
Oct 29 2018
Oct 28 2018
Oct 19 2018
Oct 16 2018
Oct 15 2018
Oct 12 2018
Oct 5 2018
Sep 27 2018
Sep 26 2018
Sep 24 2018
Sep 21 2018
Sep 18 2018
The normals produced by this code don't always have unit length.
Sep 17 2018
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.
Sep 15 2018
Sep 14 2018
- 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:
Sep 10 2018
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.