This patch ports the GPU Vector Blur node to the CPU, which is in turn
ported from EEVEE. This is a breaking change since it produces different
motion blur results that are more similar to EEVEE's motion blur.
Further, the Curved, Minimum, and Maximum options were removed on the
user level since they are not used in the new implementation.
There are no significant changes to the code, except in the max velocity
computation as well as the velocity dilation passes. The GPU code uses
atomic indirection buffers, while the CPU runs single threaded for the
dilation pass, since it is a fast pass anyways. However, we impose
artificial constraints on the precision of the dilation process for
compatibility with the atomic implementation.
There are still tiny differences between CPU and GPU that I haven't been
able to solve, but I shall solve them in a later patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/120135
This patch unifies the Defocus node between the CPU and GPU compositors.
Both nodes now use a variable sized bokeh kernel which is always odd
sized for a center pixel guarantee. Further the CPU implementation now
properly handles half pixel offsets when doing interpolation, and always
sets the threshold to zero similar to the GPU implementation.
This patch unifies the CPU and GPU implementation for the Bokeh Image
node. The bokeh is now evaluated at the center of pixels and allows
different sizes for the output kernel.
it is not clear from which point the `cos_theta_u` should be computed in
volume segment, so the original implementation was mixing the closest point
and the point where the minimal angle is formed.
Use the closest point on segment as a conservative measure.
Pull Request: https://projects.blender.org/blender/blender/pulls/119965
The Sun Beams node is off by half a pixel. That's because we add a half
pixel offset to the initial coordinates, but then sample the texture
with the half pixel. To fix thus, use the texture_bilinear_extend
utility to sample the image, which takes care of the half pixel offset.
The GPU compositor Chroma Key node differs from the reference
implementation. This is caused by a typo, where the acceptance angle was
halved after computing tangent instead of before computing it.
The Lens Distortion node is off by half a pixel because their normalized
coordinates were at the pixel corners as opposed to their centers, where
this patch changes the behavior to the latter.
The Plane Track and Corner Pin nodes are off by half a pixel because
their mask is computed at the pixel corners as opposed to their center,
where this patch changes the behavior to the latter.
The Directional Blur node is off by half a pixel because it transforms
the pixels at their corner as opposed to their center, where this patch
changes the behavior to the latter.
The Movie Distort node is off by half a pixel because it evaluates the
distortion at the corner of pixels as opposed to their center, where
this patch changes the behavior to the latter.
The curve variations were used during development of the GeometrySet
changes.
The lights and point instancer coverage would have helped uncover bugs
earlier. Bugs that eventually had to be fixed in 4.1. Better late than
never.
The one downside is that the light tests is actually a round-trip test,
which is normally fine to do, except it technically does an export
during the import test.
Pull Request: https://projects.blender.org/blender/blender/pulls/119858
The same random number was used when sampling from the volume segment
and from the direct scattering position, causing correlation issues with
light tree.
To solve this problem, we ensure the same light is picked for
volume segment/direct scattering, equiangular/distance sampling by
sampling the light tree only once in volume segment. From the direct
scattering position in volume, we sample a position on the picked light
as usual. If sampling from the light tree fails, we continue with
indirect scattering.
For unbiased MIS weight for forward sampling, we retrieve the `P`, `D`
and `t` used in volume segment for traversing the light tree.
The main changes are:
1. `light_tree_sample()` and `light_distribution_sample()` now only pick
lights. Sampling a position on light is done separately via
`light_sample()`.
2. `light_tree_sample()` is now only called only once from volume
segment. For direct lighting we call `light_sample()`.
3. `light_tree_pdf()` now has a template `<in_volume_segment>`.
4. A new field `emitter_id` is added to struct `LightSample`, which just
stores the picked emitter index.
5. Additional field `previous_dt = ray->tmax - ray->tmin` is added to
`state->ray`, because we need this quantity for computing the pdf.
6. Distant/Background lights are also picked by light tree in volume
segment now, because we have no way to pick them afterwards. The direct
sample event for these lights will be handled by
`VOLUME_SAMPLE_DISTANCE`.
7. Original paper suggests to use the maximal importance, this results
in very poor sampling probability for distant and point lights therefore
excessive noise. We have a minimal importance for surface to balance, we
could do the same for volume but I do not want to spend much time on
this now. Just doing `min_importance = 0.0f` seems to do the job
okayish. This way we still won't sample the light with zero
`max_importance`.
The current solution might perform worse with distance sampling, because
the light tree measure is biased towards equiangular sampling. However,
it is difficult to perform MIS between equiangular and distance sampling
if different lights are picked for each method. This is something we can
look into in the future if proved to be a serious regression.
Pull Request: https://projects.blender.org/blender/blender/pulls/119389
By restricting the sample range along the ray to the valid segment.
Supports
**Mesh Light**
- [x] restrict the ray segment to the side with MIS
**Area Light**
- [x] when the spread is zero, find the intersection of the ray and the bounding box/cylinder of the rectangle/ellipse area light beam
- [x] when the spread is non-zero, find the intersection of the ray and the minimal enclosing cone of the area light beam
*note the result is also unbiased when we just consider the cone from the sampled point in volume segment. Far away from the light source it's less noisy than the current solution, but near the light source it's much noisier. We have to restrict the sample region on the area light to the part that lits the ray then, I haven't tried yet to see if it would be less noisy.*
**Point Light**
- [x] the complete ray segment should be valid.
**Spot Light**
- [x] intersect the ray with the spot light cone
- [x] support non-zero radius
Pull Request: https://projects.blender.org/blender/blender/pulls/119438
The code to compute differentials mixed up the camera-space locations
of the raster coordinate and the camera itself, which caused the dP
differential to be set even when the ray origin is always the same.
This commit fixes that, reorganizes the code so that the Px/Py are
no longer used for both values to avoid future confusion, and skips
some unnecessary calculations stereo rendering isn't being used.
Previously I misunderstood the subsurf modifier's handling of custom
normals. The "use custom normals" check in 4.0 checked if there were
custom normals and whether the auto smooth flag was checked. I wrongly
changed that to check the mesh normals domain instead of whether there
was custom normals. In 4.1, auto smooth isn't required to use custom
normals, but that should be the only change here.
In this PR, that change is done for CPU and GPU subdivision, and for
the versioning which adds a modifier. The versioning now only puts the
new modifier before the subsurf modifier if it would have used the
custom normals interpolation in 4.0.
The last change causes two test failures which I also misunderstood
before. The previous results were arguably incorrect, because the
Cycles experimental adaptive subdivision ignored the auto smooth
angle, which was 5 degrees. It should have been 180 degrees.
I will modify those test files to remove auto smooth from the meshes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119485
This patch unifies the anti-aliasing of plane deforms between the CPU
and GPU compositors. The CPU used a multi-sample approach, where the
mask was computed 8 times with a jitter, then averaged to get smooth
edges. The GPU relied on the anisotropic filtering with zero boundaries
to smooth the edges.
Furthermore, the CPU implementation ignored the anti-aliasing for the
deformed image and also relied anisotropic filtering like the GPU, so
its outputs were different.
To unify both implementation, we use the existing SMAA anti-aliasing
algorithm instead, and use the anti-aliased mask for the image output as
well. This affects both the Corner Pin and Plane Deform nodes.
A consequence of this change for the Plane Deform node is that motion
blur will appear to have less samples, that's because it was sampled
8-times more in the previous implementation. But users can just increase
the samples in the node to account for that.
Pull Request: https://projects.blender.org/blender/blender/pulls/118853
This patch unifies the variable size blur between the CPU and GPU
compositor. The difference is due to how weights are computed and used.
The CPU computed a nested array of weights for every possible size, that
is, from size 1 to the base size. Then, it assumed the kernel was
separable and reconstructed a 2D kernel by selecting two 1D weights
array and multiplying them for every pixel of the blur window.
The GPU on the other hand computes a single quadrant of the 2D weights
kernel and sampled it directly in the blur window. We favor the GPU
implementation since it makes no assumptions about the separability of
the weights kernel and since the CPU has no performance advantage even
with the assumption in place.
Pull Request: https://projects.blender.org/blender/blender/pulls/118834
Currently, the CPU compositor smoothes its input size in variable size
mode. It is unclear why this is the case, but it seems the logic is that
sharp transitions in the size input are undesirable. Alternatively, this
is similar to the morphological blurring step in the Defocus node. But
it does not use standard weights and it is not morphological in nature
at all.
This patch removes the smoothing step and uses the original size
provided by the user. Looking at resources online, it seems users almost
always expect the size inputs to be used directly, so there is no reason
for force smooth their inputs.
Pull Request: https://projects.blender.org/blender/blender/pulls/118757
Often when the reference linked data is significantly modified, a lot of
'ghost' linked data remain referenced by liboverrides, even after
resync. This is due to the fact that missing data is ignored (skipped)
during resync process, to avoid potential destruction of data in case
the linked data is actually missing.
However, after all resync has been done, we can consider that missing
linked references and their liboverrides can be safely deleted, if the
later are not user-edited or hierarchy roots.
Nested panels are not supported currently, and this parameter serves no
actual purposes. Only the root panel supports adding child panels and it
is not user-accessible (adding the root panel is done using a nullptr
for the parent).
Pull Request: https://projects.blender.org/blender/blender/pulls/118792
area light with zero spread was introduced in bf18032977. Such paths can
only be sampled with NEE, so MIS should not be used.
This fixes the discrepancy when Direct Light Sampling is set to MIS or NEE.
Pull Request: #118584
for a camera ray, compute the actual range of the hair width that the
current pixel covers, and only integrate that subset, to prevent a
ribbon-like appearance in close-up looks.
When the hair covers less than one pixel on the screen or when the ray
is not camera ray, the model works the same as before.
Pull Request: https://projects.blender.org/blender/blender/pulls/116094
area light with zero spread was introduced in bf18032977. Such paths can
only be sampled with NEE, so MIS should not be used.
This fixes the discrepancy when Direct Light Sampling is set to MIS or NEE.
Pull Request: https://projects.blender.org/blender/blender/pulls/118584
