July 8, 2016, 01:39 (GMT) |
Cycles: Once again fix MSVC building Apparently, MSVC doesn't like enum values being larger than 32 bit. So, for now the enum entries are just #define'd instead. |
July 7, 2016, 18:12 (GMT) |
Cycles: Add additional debugging output containing the estimated rMSE reduction per sample |
July 7, 2016, 18:12 (GMT) |
Cycles: Fix 2-parameter least-squares helper function |
July 7, 2016, 18:10 (GMT) |
Cycles: Fix artifacts in lower-left tile when denoising on the CPU |
July 6, 2016, 22:50 (GMT) |
Cycles: Add experimental alternative SVD-threshold norm based on power iteration One of the first steps of the algorithm is to apply a truncated SVD to a matrix formed by the features in order to reduce the dimensionality of the problem and decorrelate dimensions. The truncation threshold, according to the paper, is defined by twice the spectral norm of the matrix that is formed like the first one, but from the variances of the features. The reference implementation doesn't compute the spectral norm, but instead computes the Frobenius norm and multiplies it with sqrt(Rank)/2. That makes sense since it's guaranteed that the Frobenius norm lies somewhere between the one and sqrt(Rank) times the spectral norm. However, it's still an approximation. Therefore, in this commit I've tried to directly compute the spectral norm since the runtime performance is currently mainly limited by the per-pixel loops, so a small constant increase shouldn't matter too much. In order to compute it, the code just constructs the Gramian matrix of the variance matrix and computes the square root of its largest eigenvalue, which is found via power iteration. I haven't tested the code too much yet, but it seems that the improvement is quite negligible and not really worth the effort. Still, it might be interesting to tweak it further. |
July 6, 2016, 19:25 (GMT) |
Merge remote-tracking branch 'origin/master' into soc-2016-cycles_denoising |
July 6, 2016, 19:25 (GMT) |
Cycles: Fix denoising artifacts caused by Emission closures |
July 6, 2016, 19:24 (GMT) |
Cycles: Fix denoising debug passes with CUDA |
July 6, 2016, 02:24 (GMT) |
Cycles: Implement Postprocessing callback This commit finally uses all the work from the earlier commits to implement the postprocess callback, which triggers a denoising pass on the current RenderResult. Note that this does not work on GPUs yet - they can be used for rendering, but the Device setting has to be switched to CPU rendering before using the postprocess button. One other remaining problem is that the Image editor view isn't updated automatically, you have to switch to another pass/layer and back to see the change. Also, the feature should eventually be implemeted as a Job to get a progress bar and a responding UI during denoising. |
July 6, 2016, 02:19 (GMT) |
Cycles: Add denoise-only mode the the Session This mode just creates the Device, generates tiles and runs the denoising kernel on each tile. Compared to the regular mode of operation, a lot is missing: No interactivity, no scene syncing, no progressive rendering etc. However, these features aren't needed for the denoise-after-render feature, and so this mode saves a lot of code when calling it from the bindings. Internally, it uses one single large buffer to hold the image, instead of a small buffer per tile. That requires some changes to the TileManager and is also the reason for the earlier region-of-interest commit. |
July 6, 2016, 02:14 (GMT) |
Cycles: Implement RenderResult -> RenderBuffers import This commit adds a function that takes an existing RenderResult and copies the passes to newly created RenderBuffers. That will later be used to copy the rendered image back for post-processing denoising. |
July 6, 2016, 02:09 (GMT) |
Cycles: Explicitly pass region of interest to RenderBuffers when exporting pixels to Blender By itself, that change is pretty useless, but it's important for the upcoming denoise-after-render support. |
July 6, 2016, 01:35 (GMT) |
Render API: Fix bugs regarding pass handling when Cycles debugging is enabled The probem here was that regular passes are stored as (signed) integers. Therefore, the pass with bit 31 set (the Cycles debug pass) is stored as -1. On its own, that's fine - however, when that pass type is implicitly cast to uint64_t in a function call, the compiler apparently first sign-extends it and then reinterprets it as unsigned, so the result is 0xffffffff80000000 instead of only bit 31. To get around that issue, the type is now explicitly cast to a unsigned int32 first and then implicitly extended to uint64_t. |
July 6, 2016, 01:32 (GMT) |
Cycles: Add additional debugging info to the denoiser |
July 4, 2016, 13:52 (GMT) |
Cycles: Fix border rendering with denoising enabled The code assumed that the rendered image starts at (0, 0), which is of course wrong for border rendering. |
July 4, 2016, 13:51 (GMT) |
Fix compilation on MSVC with 64-bit bitmasks in the Pass flag Apparently MSVC doesn't like the (1UL << x) syntax, so now 1 is explicitly cast to a 64-bit integer before shifting. |
July 3, 2016, 22:15 (GMT) |
Merge remote-tracking branch 'origin/master' into soc-2016-cycles_denoising Conflicts: intern/cycles/kernel/kernel_path.h intern/cycles/kernel/kernel_path_branched.h intern/cycles/kernel/kernel_types.h intern/cycles/render/buffers.cpp intern/cycles/render/buffers.h intern/cycles/render/film.cpp intern/cycles/render/film.h intern/cycles/render/integrator.cpp source/blender/render/intern/source/render_result.c |
June 24, 2016, 21:58 (GMT) |
Cycles: Add the two new headers to CMake |
June 21, 2016, 17:27 (GMT) |
Cycles: Implement Postprocessing API This commit implements the Postprocessing API in the Cycles Python bindings and the poll function in the actual Cycles code. The actual postprocessing doesn't do any processing yet. |
June 21, 2016, 17:23 (GMT) |
Render API/Image Editor: Add postprocessing operator that calls the render engine when executed This commit adds a general operator for postprocessing render results in the Image editor. To do so, the render API is extended by two functions: - can_postprocess checks whether the current render result can be postprocessed by the engine. For the denoiser, this will check whether the required passes have been rendered. - postprocess is executed when the user runs the operator. For the denoiser, this will do the actual denoising. |
|