Blender Git Commits

Blender Git "temp-cycles-denoising" branch commits.

Page: 15 / 17

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.
By: Miika HämäläinenLast update: Nov-07-2014 14:18MiikaHweb | 2003-2021