Files
test2/intern/cycles/kernel/light/sample.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

543 lines
19 KiB
C
Raw Normal View History

/* SPDX-FileCopyrightText: 2011-2022 Blender Foundation
*
* SPDX-License-Identifier: Apache-2.0 */
#pragma once
#include "kernel/integrator/path_state.h"
#include "kernel/integrator/surface_shader.h"
#include "kernel/light/distribution.h"
#include "kernel/light/light.h"
#ifdef __LIGHT_TREE__
# include "kernel/light/tree.h"
#endif
#include "kernel/sample/mapping.h"
#include "kernel/sample/mis.h"
CCL_NAMESPACE_BEGIN
/* Evaluate shader on light. */
ccl_device_noinline_cpu Spectrum
light_sample_shader_eval(KernelGlobals kg,
IntegratorState state,
Cycles: Kernel address space changes for MSL This is the first of a sequence of changes to support compiling Cycles kernels as MSL (Metal Shading Language) in preparation for a Metal GPU device implementation. MSL requires that all pointer types be declared with explicit address space attributes (device, thread, etc...). There is already precedent for this with Cycles' address space macros (ccl_global, ccl_private, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness. The vast majority of deltas in this patch fall into one of two cases: - Ensuring ccl_private is specified for thread-local pointer types - Ensuring ccl_global is specified for device-wide pointer types Additionally, the ccl_addr_space qualifier can be removed. Prior to Cycles X, ccl_addr_space was used as a context-dependent address space qualifier, but now it is either redundant (e.g. in struct typedefs), or can be replaced by ccl_global in the case of pointer types. Associated function variants (e.g. lcg_step_float_addrspace) are also redundant. In cases where address space qualifiers are chained with "const", this patch places the address space qualifier first. The rationale for this is that the choice of address space is likely to have the greater impact on runtime performance and overall architecture. The final part of this patch is the addition of a metal/compat.h header. This is partially complete and will be extended in future patches, paving the way for the full Metal implementation. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D12864
2021-10-14 13:53:40 +01:00
ccl_private ShaderData *ccl_restrict emission_sd,
ccl_private LightSample *ccl_restrict ls,
float time)
{
/* setup shading at emitter */
Spectrum eval = zero_spectrum();
if (surface_shader_constant_emission(kg, ls->shader, &eval)) {
if ((ls->prim != PRIM_NONE) && dot(ls->Ng, ls->D) > 0.0f) {
ls->Ng = -ls->Ng;
}
}
else {
/* Setup shader data and call surface_shader_eval once, better
* for GPU coherence and compile times. */
PROFILING_INIT_FOR_SHADER(kg, PROFILING_SHADE_LIGHT_SETUP);
if (ls->type == LIGHT_BACKGROUND) {
shader_setup_from_background(kg, emission_sd, ls->P, ls->D, time);
}
else {
shader_setup_from_sample(kg,
emission_sd,
ls->P,
ls->Ng,
-ls->D,
ls->shader,
ls->object,
ls->prim,
ls->u,
ls->v,
ls->t,
time,
false,
ls->lamp);
ls->Ng = emission_sd->Ng;
}
PROFILING_SHADER(emission_sd->object, emission_sd->shader);
PROFILING_EVENT(PROFILING_SHADE_LIGHT_EVAL);
/* No proper path flag, we're evaluating this for all closures. that's
* weak but we'd have to do multiple evaluations otherwise. */
surface_shader_eval<KERNEL_FEATURE_NODE_MASK_SURFACE_LIGHT>(
kg, state, emission_sd, NULL, PATH_RAY_EMISSION);
/* Evaluate closures. */
if (ls->type == LIGHT_BACKGROUND) {
eval = surface_shader_background(emission_sd);
}
else {
eval = surface_shader_emission(emission_sd);
}
}
eval *= ls->eval_fac;
if (ls->lamp != LAMP_NONE) {
ccl_global const KernelLight *klight = &kernel_data_fetch(lights, ls->lamp);
eval *= rgb_to_spectrum(
make_float3(klight->strength[0], klight->strength[1], klight->strength[2]));
}
return eval;
}
/* Early path termination of shadow rays. */
ccl_device_inline bool light_sample_terminate(KernelGlobals kg,
Cycles: Kernel address space changes for MSL This is the first of a sequence of changes to support compiling Cycles kernels as MSL (Metal Shading Language) in preparation for a Metal GPU device implementation. MSL requires that all pointer types be declared with explicit address space attributes (device, thread, etc...). There is already precedent for this with Cycles' address space macros (ccl_global, ccl_private, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness. The vast majority of deltas in this patch fall into one of two cases: - Ensuring ccl_private is specified for thread-local pointer types - Ensuring ccl_global is specified for device-wide pointer types Additionally, the ccl_addr_space qualifier can be removed. Prior to Cycles X, ccl_addr_space was used as a context-dependent address space qualifier, but now it is either redundant (e.g. in struct typedefs), or can be replaced by ccl_global in the case of pointer types. Associated function variants (e.g. lcg_step_float_addrspace) are also redundant. In cases where address space qualifiers are chained with "const", this patch places the address space qualifier first. The rationale for this is that the choice of address space is likely to have the greater impact on runtime performance and overall architecture. The final part of this patch is the addition of a metal/compat.h header. This is partially complete and will be extended in future patches, paving the way for the full Metal implementation. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D12864
2021-10-14 13:53:40 +01:00
ccl_private BsdfEval *ccl_restrict eval,
const float rand_terminate)
{
if (bsdf_eval_is_zero(eval)) {
return true;
}
2015-05-09 19:34:30 +05:00
if (kernel_data.integrator.light_inv_rr_threshold > 0.0f) {
float probability = reduce_max(fabs(bsdf_eval_sum(eval))) *
kernel_data.integrator.light_inv_rr_threshold;
if (probability < 1.0f) {
if (rand_terminate >= probability) {
return true;
}
bsdf_eval_mul(eval, 1.0f / probability);
}
}
return false;
}
/* This function should be used to compute a modified ray start position for
* rays leaving from a surface. The algorithm slightly distorts flat surface
* of a triangle. Surface is lifted by amount h along normal n in the incident
* point. */
ccl_device_inline float3 shadow_ray_smooth_surface_offset(
KernelGlobals kg, ccl_private const ShaderData *ccl_restrict sd, float3 Ng)
{
float3 V[3], N[3];
if (sd->type == PRIMITIVE_MOTION_TRIANGLE) {
motion_triangle_vertices_and_normals(kg, sd->object, sd->prim, sd->time, V, N);
}
else {
kernel_assert(sd->type == PRIMITIVE_TRIANGLE);
triangle_vertices_and_normals(kg, sd->prim, V, N);
}
const float u = 1.0f - sd->u - sd->v;
const float v = sd->u;
const float w = sd->v;
float3 P = V[0] * u + V[1] * v + V[2] * w; /* Local space */
float3 n = N[0] * u + N[1] * v + N[2] * w; /* We get away without normalization */
if (!(sd->object_flag & SD_OBJECT_TRANSFORM_APPLIED)) {
object_dir_transform(kg, sd, &n); /* Normal x scale, to world space */
}
/* Parabolic approximation */
float a = dot(N[2] - N[0], V[0] - V[2]);
float b = dot(N[2] - N[1], V[1] - V[2]);
float c = dot(N[1] - N[0], V[1] - V[0]);
float h = a * u * (u - 1) + (a + b + c) * u * v + b * v * (v - 1);
/* Check flipped normals */
if (dot(n, Ng) > 0) {
/* Local linear envelope */
float h0 = max(max(dot(V[1] - V[0], N[0]), dot(V[2] - V[0], N[0])), 0.0f);
float h1 = max(max(dot(V[0] - V[1], N[1]), dot(V[2] - V[1], N[1])), 0.0f);
float h2 = max(max(dot(V[0] - V[2], N[2]), dot(V[1] - V[2], N[2])), 0.0f);
h0 = max(dot(V[0] - P, N[0]) + h0, 0.0f);
h1 = max(dot(V[1] - P, N[1]) + h1, 0.0f);
h2 = max(dot(V[2] - P, N[2]) + h2, 0.0f);
h = max(min(min(h0, h1), h2), h * 0.5f);
}
else {
float h0 = max(max(dot(V[0] - V[1], N[0]), dot(V[0] - V[2], N[0])), 0.0f);
float h1 = max(max(dot(V[1] - V[0], N[1]), dot(V[1] - V[2], N[1])), 0.0f);
float h2 = max(max(dot(V[2] - V[0], N[2]), dot(V[2] - V[1], N[2])), 0.0f);
h0 = max(dot(P - V[0], N[0]) + h0, 0.0f);
h1 = max(dot(P - V[1], N[1]) + h1, 0.0f);
h2 = max(dot(P - V[2], N[2]) + h2, 0.0f);
h = min(-min(min(h0, h1), h2), h * 0.5f);
}
return n * h;
}
/* Ray offset to avoid shadow terminator artifact. */
ccl_device_inline float3 shadow_ray_offset(KernelGlobals kg,
Cycles: Kernel address space changes for MSL This is the first of a sequence of changes to support compiling Cycles kernels as MSL (Metal Shading Language) in preparation for a Metal GPU device implementation. MSL requires that all pointer types be declared with explicit address space attributes (device, thread, etc...). There is already precedent for this with Cycles' address space macros (ccl_global, ccl_private, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness. The vast majority of deltas in this patch fall into one of two cases: - Ensuring ccl_private is specified for thread-local pointer types - Ensuring ccl_global is specified for device-wide pointer types Additionally, the ccl_addr_space qualifier can be removed. Prior to Cycles X, ccl_addr_space was used as a context-dependent address space qualifier, but now it is either redundant (e.g. in struct typedefs), or can be replaced by ccl_global in the case of pointer types. Associated function variants (e.g. lcg_step_float_addrspace) are also redundant. In cases where address space qualifiers are chained with "const", this patch places the address space qualifier first. The rationale for this is that the choice of address space is likely to have the greater impact on runtime performance and overall architecture. The final part of this patch is the addition of a metal/compat.h header. This is partially complete and will be extended in future patches, paving the way for the full Metal implementation. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D12864
2021-10-14 13:53:40 +01:00
ccl_private const ShaderData *ccl_restrict sd,
float3 L,
ccl_private bool *r_skip_self)
{
float3 P = sd->P;
if ((sd->type & PRIMITIVE_TRIANGLE) && (sd->shader & SHADER_SMOOTH_NORMAL)) {
const float offset_cutoff =
kernel_data_fetch(objects, sd->object).shadow_terminator_geometry_offset;
/* Do ray offset (heavy stuff) only for close to be terminated triangles:
* offset_cutoff = 0.1f means that 10-20% of rays will be affected. Also
* make a smooth transition near the threshold. */
if (offset_cutoff > 0.0f) {
float NL = dot(sd->N, L);
const bool transmit = (NL < 0.0f);
if (NL < 0) {
NL = -NL;
}
const float3 Ng = (transmit ? -sd->Ng : sd->Ng);
const float NgL = dot(Ng, L);
const float offset_amount = (NL < offset_cutoff) ?
clamp(2.0f - (NgL + NL) / offset_cutoff, 0.0f, 1.0f) :
clamp(1.0f - NgL / offset_cutoff, 0.0f, 1.0f);
if (offset_amount > 0.0f) {
P += shadow_ray_smooth_surface_offset(kg, sd, Ng) * offset_amount;
/* Only skip self intersections if light direction and geometric normal point in the same
* direction, otherwise we're meant to hit this surface. */
*r_skip_self = (NgL > 0.0f);
}
}
}
return P;
}
Cycles: Kernel address space changes for MSL This is the first of a sequence of changes to support compiling Cycles kernels as MSL (Metal Shading Language) in preparation for a Metal GPU device implementation. MSL requires that all pointer types be declared with explicit address space attributes (device, thread, etc...). There is already precedent for this with Cycles' address space macros (ccl_global, ccl_private, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness. The vast majority of deltas in this patch fall into one of two cases: - Ensuring ccl_private is specified for thread-local pointer types - Ensuring ccl_global is specified for device-wide pointer types Additionally, the ccl_addr_space qualifier can be removed. Prior to Cycles X, ccl_addr_space was used as a context-dependent address space qualifier, but now it is either redundant (e.g. in struct typedefs), or can be replaced by ccl_global in the case of pointer types. Associated function variants (e.g. lcg_step_float_addrspace) are also redundant. In cases where address space qualifiers are chained with "const", this patch places the address space qualifier first. The rationale for this is that the choice of address space is likely to have the greater impact on runtime performance and overall architecture. The final part of this patch is the addition of a metal/compat.h header. This is partially complete and will be extended in future patches, paving the way for the full Metal implementation. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D12864
2021-10-14 13:53:40 +01:00
ccl_device_inline void shadow_ray_setup(ccl_private const ShaderData *ccl_restrict sd,
ccl_private const LightSample *ccl_restrict ls,
const float3 P,
ccl_private Ray *ray,
const bool skip_self)
{
if (ls->shader & SHADER_CAST_SHADOW) {
/* setup ray */
ray->P = P;
ray->tmin = 0.0f;
if (ls->t == FLT_MAX) {
/* distant light */
ray->D = ls->D;
ray->tmax = ls->t;
}
else {
/* other lights, avoid self-intersection */
ray->D = ls->P - P;
ray->D = normalize_len(ray->D, &ray->tmax);
}
}
else {
/* signal to not cast shadow ray */
ray->P = zero_float3();
ray->D = zero_float3();
ray->tmax = 0.0f;
}
ray->dP = differential_make_compact(sd->dP);
ray->dD = differential_zero_compact();
ray->time = sd->time;
/* Fill in intersection surface and light details. */
ray->self.object = (skip_self) ? sd->object : OBJECT_NONE;
ray->self.prim = (skip_self) ? sd->prim : PRIM_NONE;
ray->self.light_object = ls->object;
ray->self.light_prim = ls->prim;
ray->self.light = ls->lamp;
}
/* Create shadow ray towards light sample. */
Cycles: Kernel address space changes for MSL This is the first of a sequence of changes to support compiling Cycles kernels as MSL (Metal Shading Language) in preparation for a Metal GPU device implementation. MSL requires that all pointer types be declared with explicit address space attributes (device, thread, etc...). There is already precedent for this with Cycles' address space macros (ccl_global, ccl_private, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness. The vast majority of deltas in this patch fall into one of two cases: - Ensuring ccl_private is specified for thread-local pointer types - Ensuring ccl_global is specified for device-wide pointer types Additionally, the ccl_addr_space qualifier can be removed. Prior to Cycles X, ccl_addr_space was used as a context-dependent address space qualifier, but now it is either redundant (e.g. in struct typedefs), or can be replaced by ccl_global in the case of pointer types. Associated function variants (e.g. lcg_step_float_addrspace) are also redundant. In cases where address space qualifiers are chained with "const", this patch places the address space qualifier first. The rationale for this is that the choice of address space is likely to have the greater impact on runtime performance and overall architecture. The final part of this patch is the addition of a metal/compat.h header. This is partially complete and will be extended in future patches, paving the way for the full Metal implementation. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D12864
2021-10-14 13:53:40 +01:00
ccl_device_inline void light_sample_to_surface_shadow_ray(
KernelGlobals kg,
Cycles: Kernel address space changes for MSL This is the first of a sequence of changes to support compiling Cycles kernels as MSL (Metal Shading Language) in preparation for a Metal GPU device implementation. MSL requires that all pointer types be declared with explicit address space attributes (device, thread, etc...). There is already precedent for this with Cycles' address space macros (ccl_global, ccl_private, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness. The vast majority of deltas in this patch fall into one of two cases: - Ensuring ccl_private is specified for thread-local pointer types - Ensuring ccl_global is specified for device-wide pointer types Additionally, the ccl_addr_space qualifier can be removed. Prior to Cycles X, ccl_addr_space was used as a context-dependent address space qualifier, but now it is either redundant (e.g. in struct typedefs), or can be replaced by ccl_global in the case of pointer types. Associated function variants (e.g. lcg_step_float_addrspace) are also redundant. In cases where address space qualifiers are chained with "const", this patch places the address space qualifier first. The rationale for this is that the choice of address space is likely to have the greater impact on runtime performance and overall architecture. The final part of this patch is the addition of a metal/compat.h header. This is partially complete and will be extended in future patches, paving the way for the full Metal implementation. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D12864
2021-10-14 13:53:40 +01:00
ccl_private const ShaderData *ccl_restrict sd,
ccl_private const LightSample *ccl_restrict ls,
ccl_private Ray *ray)
{
bool skip_self = true;
const float3 P = shadow_ray_offset(kg, sd, ls->D, &skip_self);
shadow_ray_setup(sd, ls, P, ray, skip_self);
}
/* Create shadow ray towards light sample. */
Cycles: Kernel address space changes for MSL This is the first of a sequence of changes to support compiling Cycles kernels as MSL (Metal Shading Language) in preparation for a Metal GPU device implementation. MSL requires that all pointer types be declared with explicit address space attributes (device, thread, etc...). There is already precedent for this with Cycles' address space macros (ccl_global, ccl_private, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness. The vast majority of deltas in this patch fall into one of two cases: - Ensuring ccl_private is specified for thread-local pointer types - Ensuring ccl_global is specified for device-wide pointer types Additionally, the ccl_addr_space qualifier can be removed. Prior to Cycles X, ccl_addr_space was used as a context-dependent address space qualifier, but now it is either redundant (e.g. in struct typedefs), or can be replaced by ccl_global in the case of pointer types. Associated function variants (e.g. lcg_step_float_addrspace) are also redundant. In cases where address space qualifiers are chained with "const", this patch places the address space qualifier first. The rationale for this is that the choice of address space is likely to have the greater impact on runtime performance and overall architecture. The final part of this patch is the addition of a metal/compat.h header. This is partially complete and will be extended in future patches, paving the way for the full Metal implementation. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D12864
2021-10-14 13:53:40 +01:00
ccl_device_inline void light_sample_to_volume_shadow_ray(
KernelGlobals kg,
Cycles: Kernel address space changes for MSL This is the first of a sequence of changes to support compiling Cycles kernels as MSL (Metal Shading Language) in preparation for a Metal GPU device implementation. MSL requires that all pointer types be declared with explicit address space attributes (device, thread, etc...). There is already precedent for this with Cycles' address space macros (ccl_global, ccl_private, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness. The vast majority of deltas in this patch fall into one of two cases: - Ensuring ccl_private is specified for thread-local pointer types - Ensuring ccl_global is specified for device-wide pointer types Additionally, the ccl_addr_space qualifier can be removed. Prior to Cycles X, ccl_addr_space was used as a context-dependent address space qualifier, but now it is either redundant (e.g. in struct typedefs), or can be replaced by ccl_global in the case of pointer types. Associated function variants (e.g. lcg_step_float_addrspace) are also redundant. In cases where address space qualifiers are chained with "const", this patch places the address space qualifier first. The rationale for this is that the choice of address space is likely to have the greater impact on runtime performance and overall architecture. The final part of this patch is the addition of a metal/compat.h header. This is partially complete and will be extended in future patches, paving the way for the full Metal implementation. Ref T92212 Reviewed By: brecht Maniphest Tasks: T92212 Differential Revision: https://developer.blender.org/D12864
2021-10-14 13:53:40 +01:00
ccl_private const ShaderData *ccl_restrict sd,
ccl_private const LightSample *ccl_restrict ls,
const float3 P,
ccl_private Ray *ray)
{
shadow_ray_setup(sd, ls, P, ray, false);
}
/* Multiple importance sampling weights. */
ccl_device_inline float light_sample_mis_weight_forward(KernelGlobals kg,
const float forward_pdf,
const float nee_pdf)
{
#ifdef WITH_CYCLES_DEBUG
if (kernel_data.integrator.direct_light_sampling_type == DIRECT_LIGHT_SAMPLING_FORWARD) {
return 1.0f;
}
else if (kernel_data.integrator.direct_light_sampling_type == DIRECT_LIGHT_SAMPLING_NEE) {
return 0.0f;
}
else
#endif
return power_heuristic(forward_pdf, nee_pdf);
}
ccl_device_inline float light_sample_mis_weight_nee(KernelGlobals kg,
const float nee_pdf,
const float forward_pdf)
{
#ifdef WITH_CYCLES_DEBUG
if (kernel_data.integrator.direct_light_sampling_type == DIRECT_LIGHT_SAMPLING_FORWARD) {
/* Return 0.0f to only account for the contribution in forward path tracing, unless when the
* light can not be forward sampled, in which case return 1.0f so it converges to the same
* result. */
return (forward_pdf == 0.0f);
}
else if (kernel_data.integrator.direct_light_sampling_type == DIRECT_LIGHT_SAMPLING_NEE) {
return 1.0f;
}
else
#endif
return power_heuristic(nee_pdf, forward_pdf);
}
/* Next event estimation sampling.
*
* Sample a position on a light in the scene, from a position on a surface or
* from a volume segment.
*
* Uses either a flat distribution or light tree. */
ccl_device_inline bool light_sample_from_volume_segment(KernelGlobals kg,
const float3 rand,
const float time,
const float3 P,
const float3 D,
const float t,
const int object_receiver,
const int bounce,
const uint32_t path_flag,
ccl_private LightSample *ls)
{
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
const int shader_flags = SD_BSDF_HAS_TRANSMISSION;
#ifdef __LIGHT_TREE__
if (kernel_data.integrator.use_light_tree) {
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
if (!light_tree_sample<true>(kg, rand.z, P, D, t, object_receiver, shader_flags, ls)) {
return false;
}
}
else
#endif
{
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
if (!light_distribution_sample(kg, rand.z, ls)) {
return false;
}
}
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
/* Sample position on the selected light. */
return light_sample<true>(
kg, rand, time, P, D, object_receiver, shader_flags, bounce, path_flag, ls);
}
ccl_device bool light_sample_from_position(KernelGlobals kg,
const float3 rand,
const float time,
const float3 P,
const float3 N,
const int object_receiver,
const int shader_flags,
const int bounce,
const uint32_t path_flag,
ccl_private LightSample *ls)
{
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
/* Randomly select a light. */
#ifdef __LIGHT_TREE__
if (kernel_data.integrator.use_light_tree) {
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
if (!light_tree_sample<false>(kg, rand.z, P, N, 0.0f, object_receiver, shader_flags, ls)) {
return false;
}
}
else
#endif
{
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
if (!light_distribution_sample(kg, rand.z, ls)) {
return false;
}
}
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
/* Sample position on the selected light. */
return light_sample<false>(
kg, rand, time, P, N, object_receiver, shader_flags, bounce, path_flag, ls);
}
/* Update light sample with new shading point position for MNEE. The position on the light is fixed
* except for directional light. */
ccl_device_forceinline void light_sample_update(KernelGlobals kg,
ccl_private LightSample *ls,
Cycles/EEVEE: change point light to double-sided sphere light for energy preservation and better compatibility with other renderes. Ref: #108505 Point light now behaves the same as a spherical mesh light with the same overall energy (scaling from emission strength to power is \(4\pi^2R^2\)). # Cycles ## Comparison | Mesh Light | This patch | Previous behavior | | -------- | -------- | -------- | | ![mesh_1024](attachments/2900954c-57f8-49c2-b6f3-8fb559b820ac) | ![sphere_1024](attachments/148241ca-9350-48b6-be04-3933e015424c) | ![point_1024](attachments/d9b19d54-2b00-4986-ba8c-c4b28f687f09) | The behavior stays the same when `radius = 0`. | This patch | Previous behavior | | -------- | -------- | | ![sphere_64](attachments/aa05d59a-146a-4f69-b257-5d09a7f41d4e) | ![point_64](attachments/69a743be-bc15-454b-92d8-af02f4e8ab07) | No obvious performance change observed. ## Sampling When shading point lies outside the sphere, sample the spanned solid angle uniformly. When shading point lies inside the sphere, sample spherical direction uniformly when inside volume or the surface is transmissive, otherwise sample cosine-weighted upper hemisphere. ## Light Tree When shading point lies outside the sphere, treat as a disk light spanning the same solid angle. When shading point lies inside the sphere, it behaves like a background light, with estimated outgoing radiance \[L_o=\int f_aL_i\cos\theta_i\mathrm{d}\omega_i=\int f_a\frac{E}{\pi r^2}\cos\theta_i\mathrm{d}\omega_i\approx f_a \frac{E}{r^2}\], with \(f_a\) being the BSDF and \(E\) `measure.energy` in `light_tree.cpp`. The importance calculation for `LIGHT_POINT` is \[L_o=f_a E\cos\theta_i\frac{\cos\theta}{d^2}\]. Consider `min_importance = 0` because maximal incidence angle is \(\pi\), we could substitute \(d^2\) with \(\frac{r^2}{2}\) so the averaged outgoing radiance is \(f_a \frac{E}{r^2}\). This only holds for non-transmissive surface, but should be fine to use in volume. # EEVEE When shading point lies outside the sphere, the sphere light is equivalent to a disk light spanning the same solid angle. The sine of the new half-angle is the tangent of the previous half-angle. When shading point lies inside the sphere, integrating over the cosine-weighted hemisphere gives 1.0. ## Comparison with Cycles The plane is diffuse, the blue sphere has specular component. | Before | |After || |---|--|--|--| |Cycles|EEVEE|Cycles|EEVEE| |![](attachments/5824c494-0645-461a-b193-d74e02f353b8)|![](attachments/d2e85b53-3c2a-4a9f-a3b2-6e11c6083ce0)|![](attachments/a8dcdd8b-c13c-4fdc-808c-2563624549be)|![](attachments/8c3618ef-1ab4-4210-9535-c85e873f1e45)| Pull Request: https://projects.blender.org/blender/blender/pulls/108506
2023-06-20 12:23:05 +02:00
const float3 P,
const float3 N,
const uint32_t path_flag)
{
const ccl_global KernelLight *klight = &kernel_data_fetch(lights, ls->lamp);
if (ls->type == LIGHT_POINT) {
Cycles/EEVEE: change point light to double-sided sphere light for energy preservation and better compatibility with other renderes. Ref: #108505 Point light now behaves the same as a spherical mesh light with the same overall energy (scaling from emission strength to power is \(4\pi^2R^2\)). # Cycles ## Comparison | Mesh Light | This patch | Previous behavior | | -------- | -------- | -------- | | ![mesh_1024](attachments/2900954c-57f8-49c2-b6f3-8fb559b820ac) | ![sphere_1024](attachments/148241ca-9350-48b6-be04-3933e015424c) | ![point_1024](attachments/d9b19d54-2b00-4986-ba8c-c4b28f687f09) | The behavior stays the same when `radius = 0`. | This patch | Previous behavior | | -------- | -------- | | ![sphere_64](attachments/aa05d59a-146a-4f69-b257-5d09a7f41d4e) | ![point_64](attachments/69a743be-bc15-454b-92d8-af02f4e8ab07) | No obvious performance change observed. ## Sampling When shading point lies outside the sphere, sample the spanned solid angle uniformly. When shading point lies inside the sphere, sample spherical direction uniformly when inside volume or the surface is transmissive, otherwise sample cosine-weighted upper hemisphere. ## Light Tree When shading point lies outside the sphere, treat as a disk light spanning the same solid angle. When shading point lies inside the sphere, it behaves like a background light, with estimated outgoing radiance \[L_o=\int f_aL_i\cos\theta_i\mathrm{d}\omega_i=\int f_a\frac{E}{\pi r^2}\cos\theta_i\mathrm{d}\omega_i\approx f_a \frac{E}{r^2}\], with \(f_a\) being the BSDF and \(E\) `measure.energy` in `light_tree.cpp`. The importance calculation for `LIGHT_POINT` is \[L_o=f_a E\cos\theta_i\frac{\cos\theta}{d^2}\]. Consider `min_importance = 0` because maximal incidence angle is \(\pi\), we could substitute \(d^2\) with \(\frac{r^2}{2}\) so the averaged outgoing radiance is \(f_a \frac{E}{r^2}\). This only holds for non-transmissive surface, but should be fine to use in volume. # EEVEE When shading point lies outside the sphere, the sphere light is equivalent to a disk light spanning the same solid angle. The sine of the new half-angle is the tangent of the previous half-angle. When shading point lies inside the sphere, integrating over the cosine-weighted hemisphere gives 1.0. ## Comparison with Cycles The plane is diffuse, the blue sphere has specular component. | Before | |After || |---|--|--|--| |Cycles|EEVEE|Cycles|EEVEE| |![](attachments/5824c494-0645-461a-b193-d74e02f353b8)|![](attachments/d2e85b53-3c2a-4a9f-a3b2-6e11c6083ce0)|![](attachments/a8dcdd8b-c13c-4fdc-808c-2563624549be)|![](attachments/8c3618ef-1ab4-4210-9535-c85e873f1e45)| Pull Request: https://projects.blender.org/blender/blender/pulls/108506
2023-06-20 12:23:05 +02:00
point_light_mnee_sample_update(klight, ls, P, N, path_flag);
}
else if (ls->type == LIGHT_SPOT) {
Cycles: replace spot light disk sampling with sphere sampling The spotlight is now treated as a sphere instead of a view-aligned disk. The implementation remains almost identical to that of a point light, except for the spotlight attenuation and spot blend. There is no attenuation inside the sphere. Ref #108505 Other changes include: ## Sampling Instead of sampling the disk area, the new implementation samples either the cone of the visible portion on the sphere or the spread cone, based on which cone has a smaller solid angle. This reduces noise when the spotlight has a large radius and a small spread angle. | Before | After | | -- | -- | |![spot_size_before.png](/attachments/04ea864a-6bf9-40fe-b11b-61c838ae70cf)|![spot_size_after.png](/attachments/7077eaf9-b7a8-41b1-a8b6-aabf1eadb4f4) ## Texture Spot light can now project texture using UV coordinates. <video src="/attachments/6db989d2-7a3c-4b41-9340-f5690d48c4fb" title="spot_light_texture.mp4" controls></video> ## Normalization Previously, the normalization factor for the spotlight was \(\pi r^2\), the area of a disk. This factor has been adjusted to \(4\pi r^2\) to account for the surface area of a sphere. This change also affects point light since they share the same kernel type. ## Versioning Some pipeline uses the `Normal` socket of the Texture Coordinate node for projection, because `ls->Ng` was set to the incoming direction at the current shading point. Now that `ls->Ng` corresponds to the normal direction of a point on the sphere (except when the radius is zero), we replace these nodes with a combination of the Geometry shader node and the Vector Transform node, which gives the same result as before. ![versioning.png](/attachments/5bbfcacc-26c5-4f7f-8360-c42bcd851f68) Example file see https://archive.blender.org/developer/T93676 Pull Request: https://projects.blender.org/blender/blender/pulls/109329
2023-07-07 17:15:18 +02:00
spot_light_mnee_sample_update(klight, ls, P, N, path_flag);
}
else if (ls->type == LIGHT_AREA) {
area_light_mnee_sample_update(klight, ls, P);
}
else {
/* Keep previous values. */
}
/* Re-apply already computed selection pdf. */
ls->pdf *= ls->pdf_selection;
}
/* Forward sampling.
*
* Multiple importance sampling weights for hitting surface, light or background
* through indirect light ray.
*
* The BSDF or phase pdf from the previous bounce was stored in mis_ray_pdf and
* is used for balancing with the light sampling pdf. */
ccl_device_inline float light_sample_mis_weight_forward_surface(KernelGlobals kg,
IntegratorState state,
const uint32_t path_flag,
const ccl_private ShaderData *sd)
{
bool has_mis = !(path_flag & PATH_RAY_MIS_SKIP) &&
(sd->flag & ((sd->flag & SD_BACKFACING) ? SD_MIS_BACK : SD_MIS_FRONT));
#ifdef __HAIR__
has_mis &= (sd->type & PRIMITIVE_TRIANGLE);
#endif
if (!has_mis) {
return 1.0f;
}
const float bsdf_pdf = INTEGRATOR_STATE(state, path, mis_ray_pdf);
const float t = sd->ray_length;
float pdf = triangle_light_pdf(kg, sd, t);
/* Light selection pdf. */
#ifdef __LIGHT_TREE__
if (kernel_data.integrator.use_light_tree) {
float3 ray_P = INTEGRATOR_STATE(state, ray, P);
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
const float dt = INTEGRATOR_STATE(state, ray, previous_dt);
const float3 N = INTEGRATOR_STATE(state, path, mis_origin_n);
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
uint lookup_offset = kernel_data_fetch(object_lookup_offset, sd->object);
uint prim_offset = kernel_data_fetch(object_prim_offset, sd->object);
uint triangle = kernel_data_fetch(triangle_to_tree, sd->prim - prim_offset + lookup_offset);
pdf *= light_tree_pdf(
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
kg, ray_P, N, dt, path_flag, sd->object, triangle, light_link_receiver_forward(kg, state));
}
else
#endif
{
/* Handled in triangle_light_pdf for efficiency. */
}
return light_sample_mis_weight_forward(kg, bsdf_pdf, pdf);
}
ccl_device_inline float light_sample_mis_weight_forward_lamp(KernelGlobals kg,
IntegratorState state,
const uint32_t path_flag,
const ccl_private LightSample *ls,
const float3 P)
{
if (path_flag & PATH_RAY_MIS_SKIP) {
return 1.0f;
}
const float mis_ray_pdf = INTEGRATOR_STATE(state, path, mis_ray_pdf);
float pdf = ls->pdf;
/* Light selection pdf. */
#ifdef __LIGHT_TREE__
if (kernel_data.integrator.use_light_tree) {
const float3 N = INTEGRATOR_STATE(state, path, mis_origin_n);
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
const float dt = INTEGRATOR_STATE(state, ray, previous_dt);
pdf *= light_tree_pdf(kg,
P,
N,
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
dt,
path_flag,
0,
kernel_data_fetch(light_to_tree, ls->lamp),
light_link_receiver_forward(kg, state));
}
else
#endif
{
pdf *= light_distribution_pdf_lamp(kg);
}
return light_sample_mis_weight_forward(kg, mis_ray_pdf, pdf);
}
ccl_device_inline float light_sample_mis_weight_forward_distant(KernelGlobals kg,
IntegratorState state,
const uint32_t path_flag,
const ccl_private LightSample *ls)
{
const float3 ray_P = INTEGRATOR_STATE(state, ray, P);
return light_sample_mis_weight_forward_lamp(kg, state, path_flag, ls, ray_P);
}
ccl_device_inline float light_sample_mis_weight_forward_background(KernelGlobals kg,
IntegratorState state,
const uint32_t path_flag)
{
/* Check if background light exists or if we should skip PDF. */
if (!kernel_data.background.use_mis || (path_flag & PATH_RAY_MIS_SKIP)) {
return 1.0f;
}
const float3 ray_P = INTEGRATOR_STATE(state, ray, P);
const float3 ray_D = INTEGRATOR_STATE(state, ray, D);
const float mis_ray_pdf = INTEGRATOR_STATE(state, path, mis_ray_pdf);
float pdf = background_light_pdf(kg, ray_P, ray_D);
/* Light selection pdf. */
#ifdef __LIGHT_TREE__
if (kernel_data.integrator.use_light_tree) {
const float3 N = INTEGRATOR_STATE(state, path, mis_origin_n);
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
const float dt = INTEGRATOR_STATE(state, ray, previous_dt);
uint light = kernel_data_fetch(light_to_tree, kernel_data.background.light_index);
pdf *= light_tree_pdf(
Fix #114634: correlated samples in volume when using equiangular sampling and light tree 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
2024-03-25 18:50:52 +01:00
kg, ray_P, N, dt, path_flag, 0, light, light_link_receiver_forward(kg, state));
}
else
#endif
{
pdf *= light_distribution_pdf_lamp(kg);
}
return light_sample_mis_weight_forward(kg, mis_ray_pdf, pdf);
}
CCL_NAMESPACE_END