2023-06-14 16:52:36 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2011-2022 Blender Foundation
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: Apache-2.0 */
|
2020-02-02 13:09:18 +01:00
|
|
|
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "scene/light.h"
|
2020-02-02 13:09:18 +01:00
|
|
|
|
2025-02-21 21:37:48 +01:00
|
|
|
#include "DNA_light_types.h"
|
|
|
|
|
|
|
|
|
|
#include "IMB_colormanagement.hh"
|
|
|
|
|
|
2021-10-24 14:19:19 +02:00
|
|
|
#include "blender/sync.h"
|
|
|
|
|
#include "blender/util.h"
|
2025-02-24 23:44:14 +01:00
|
|
|
#include "scene/object.h"
|
2020-02-02 13:09:18 +01:00
|
|
|
|
|
|
|
|
CCL_NAMESPACE_BEGIN
|
|
|
|
|
|
2025-03-12 19:07:59 +01:00
|
|
|
void BlenderSync::sync_light(BObjectInfo &b_ob_info, Light *light)
|
2020-02-02 13:09:18 +01:00
|
|
|
{
|
2021-09-06 18:22:24 +02:00
|
|
|
BL::Light b_light(b_ob_info.object_data);
|
2020-02-02 13:09:18 +01:00
|
|
|
|
2023-05-26 13:03:54 +02:00
|
|
|
light->name = b_light.name().c_str();
|
|
|
|
|
|
2020-02-02 13:09:18 +01:00
|
|
|
/* type */
|
|
|
|
|
switch (b_light.type()) {
|
|
|
|
|
case BL::Light::type_POINT: {
|
|
|
|
|
BL::PointLight b_point_light(b_light);
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_size(b_point_light.shadow_soft_size());
|
|
|
|
|
light->set_light_type(LIGHT_POINT);
|
2024-02-07 19:07:11 +01:00
|
|
|
light->set_is_sphere(!b_point_light.use_soft_falloff());
|
2020-02-02 13:09:18 +01:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case BL::Light::type_SPOT: {
|
|
|
|
|
BL::SpotLight b_spot_light(b_light);
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_size(b_spot_light.shadow_soft_size());
|
|
|
|
|
light->set_light_type(LIGHT_SPOT);
|
|
|
|
|
light->set_spot_angle(b_spot_light.spot_size());
|
|
|
|
|
light->set_spot_smooth(b_spot_light.spot_blend());
|
2024-02-07 19:07:11 +01:00
|
|
|
light->set_is_sphere(!b_spot_light.use_soft_falloff());
|
2020-02-02 13:09:18 +01:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
/* Hemi were removed from 2.8 */
|
|
|
|
|
// case BL::Light::type_HEMI: {
|
|
|
|
|
// light->type = LIGHT_DISTANT;
|
|
|
|
|
// light->size = 0.0f;
|
|
|
|
|
// break;
|
|
|
|
|
// }
|
|
|
|
|
case BL::Light::type_SUN: {
|
|
|
|
|
BL::SunLight b_sun_light(b_light);
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_angle(b_sun_light.angle());
|
|
|
|
|
light->set_light_type(LIGHT_DISTANT);
|
2020-02-02 13:09:18 +01:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case BL::Light::type_AREA: {
|
|
|
|
|
BL::AreaLight b_area_light(b_light);
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_size(1.0f);
|
|
|
|
|
light->set_sizeu(b_area_light.size());
|
2021-04-01 05:35:56 +02:00
|
|
|
light->set_spread(b_area_light.spread());
|
2020-02-02 13:09:18 +01:00
|
|
|
switch (b_area_light.shape()) {
|
|
|
|
|
case BL::AreaLight::shape_SQUARE:
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_sizev(light->get_sizeu());
|
Cycles: improve sampling of ellipse area light with spread
**Problem**:
Area lights in Cycles have spread angle, in which case some part of the area light might be invisible to a shading point. The current implementation samples the whole area light, resulting some samples invisible and thus simply discarded. A technique is applied on rectangular light to sample a subset of the area light that is potentially visible (rB3f24cfb9582e1c826406301d37808df7ca6aa64c), however, ellipse (including disk) area lights remained untreated. The purpose of this patch is to apply a techniques to ellipse area light.
**Related Task**:
T87053
**Results**:
These are renderings before and after the patch:
|16spp|Disk light|Ellipse light|Square light (for reference, no changes)
|Before|{F13996789}|{F13996788}|{F13996822}
|After|{F13996759}|{F13996787}|{F13996852}
**Explanation**:
The visible region on an area light is found by drawing a cone from the shading point to the plane where the area light lies, with the aperture of the cone being the light spread.
{F13990078,height=200}
Ideally, we would like to draw samples only from the intersection of the area light and the projection of the cone onto the plane (forming a circle). However, the shape of the intersection is often irregular and thus hard to sample from directly.
{F13990104,height=200}
Instead, the current implementation draws samples from the bounding rectangle of the intersection. In this case, we still end up with some invalid samples outside of the circle, but already much less than sampling the original area light, and the bounding rectangle is easy to sample from.
{F13990125}
The above technique is only applied to rectangle area lights, ellipse area light still suffers from poor sampling. We could apply a similar technique to ellipse area lights, that is, find the
smallest regular shape (rectangle, circle, or ellipse) that covers the intersection (or maybe not the smallest but easy to compute).
For disk area light, we consider the relative position of both circles. Denoting `dist` as the distance between the centre of two circles, and `r1`, `r2` their radii. If `dist > r1 + r2`, the area light is completely invisible, we directly return `false`. If `dist < abs(r1 - r2)`, the smaller circle lies inside the larger one, and we sample whichever circle is smaller. Otherwise, the two circles intersect, we compute the bounding rectangle of the intersection, in which case `axis_u`, `len_u`, `axis_v`, `len_v` needs to be computed anew. Depending on the distance between the two circles, `len_v` is either the diameter of the smaller circle or the length of the common chord.
|{F13990211,height=195}|{F13990225,height=195}|{F13990274,height=195}|{F13990210,height=195}
|`dist > r1 + r2`|`dist < abs(r1 - r2)`|`dist^2 < abs(r1^2 - r2^2)`|`dist^2 > abs(r1^2 - r2^2)`
For ellipse area light, it's hard to find the smallest bounding shape of the intersection, therefore, we compute the bounding rectangle of the ellipse itself, then treat it as a rectangle light.
|{F13990386,height=195}|{F13990385,height=195}|{F13990387,height=195}
We also check the areas of the bounding rectangle of the intersection, the ellipse (disk) light, and the spread circle, then draw samples from the smallest shape of the three. For ellipse light, this also detects where one shape lies inside the other. I am not sure if we should add this measure to rectangle area light and sample from the spread circle when it has smaller area, as we seem to have a better sampling technique for rectangular (uniformly sample the solid angle). Maybe we could add [area-preserving parameterization for spherical
ellipse](https://arxiv.org/pdf/1805.09048.pdf) in the future.
**Limitation**:
At some point we switch from sampling the ellipse to sampling the rectangle, depending on the area of the both, and there seems to be a visible line (with |slope| =1) on the final rendering
which demonstrate at which point we switch between the two methods. We could see that the new sampling method clearly has lower variance near the boundaries, but close to that visible line,
the rectangle sampling method seems to have larger variance. I could not spot any bug in the implementation, and I am not sure if this happens because different sampling patterns for ellipse and rectangle are used.
|Before (256spp)|After (256spp)
|{F13996995}|{F13996998}
Differential Revision: https://developer.blender.org/D16694
2022-12-05 14:35:25 +01:00
|
|
|
light->set_ellipse(false);
|
2020-02-02 13:09:18 +01:00
|
|
|
break;
|
|
|
|
|
case BL::AreaLight::shape_RECTANGLE:
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_sizev(b_area_light.size_y());
|
Cycles: improve sampling of ellipse area light with spread
**Problem**:
Area lights in Cycles have spread angle, in which case some part of the area light might be invisible to a shading point. The current implementation samples the whole area light, resulting some samples invisible and thus simply discarded. A technique is applied on rectangular light to sample a subset of the area light that is potentially visible (rB3f24cfb9582e1c826406301d37808df7ca6aa64c), however, ellipse (including disk) area lights remained untreated. The purpose of this patch is to apply a techniques to ellipse area light.
**Related Task**:
T87053
**Results**:
These are renderings before and after the patch:
|16spp|Disk light|Ellipse light|Square light (for reference, no changes)
|Before|{F13996789}|{F13996788}|{F13996822}
|After|{F13996759}|{F13996787}|{F13996852}
**Explanation**:
The visible region on an area light is found by drawing a cone from the shading point to the plane where the area light lies, with the aperture of the cone being the light spread.
{F13990078,height=200}
Ideally, we would like to draw samples only from the intersection of the area light and the projection of the cone onto the plane (forming a circle). However, the shape of the intersection is often irregular and thus hard to sample from directly.
{F13990104,height=200}
Instead, the current implementation draws samples from the bounding rectangle of the intersection. In this case, we still end up with some invalid samples outside of the circle, but already much less than sampling the original area light, and the bounding rectangle is easy to sample from.
{F13990125}
The above technique is only applied to rectangle area lights, ellipse area light still suffers from poor sampling. We could apply a similar technique to ellipse area lights, that is, find the
smallest regular shape (rectangle, circle, or ellipse) that covers the intersection (or maybe not the smallest but easy to compute).
For disk area light, we consider the relative position of both circles. Denoting `dist` as the distance between the centre of two circles, and `r1`, `r2` their radii. If `dist > r1 + r2`, the area light is completely invisible, we directly return `false`. If `dist < abs(r1 - r2)`, the smaller circle lies inside the larger one, and we sample whichever circle is smaller. Otherwise, the two circles intersect, we compute the bounding rectangle of the intersection, in which case `axis_u`, `len_u`, `axis_v`, `len_v` needs to be computed anew. Depending on the distance between the two circles, `len_v` is either the diameter of the smaller circle or the length of the common chord.
|{F13990211,height=195}|{F13990225,height=195}|{F13990274,height=195}|{F13990210,height=195}
|`dist > r1 + r2`|`dist < abs(r1 - r2)`|`dist^2 < abs(r1^2 - r2^2)`|`dist^2 > abs(r1^2 - r2^2)`
For ellipse area light, it's hard to find the smallest bounding shape of the intersection, therefore, we compute the bounding rectangle of the ellipse itself, then treat it as a rectangle light.
|{F13990386,height=195}|{F13990385,height=195}|{F13990387,height=195}
We also check the areas of the bounding rectangle of the intersection, the ellipse (disk) light, and the spread circle, then draw samples from the smallest shape of the three. For ellipse light, this also detects where one shape lies inside the other. I am not sure if we should add this measure to rectangle area light and sample from the spread circle when it has smaller area, as we seem to have a better sampling technique for rectangular (uniformly sample the solid angle). Maybe we could add [area-preserving parameterization for spherical
ellipse](https://arxiv.org/pdf/1805.09048.pdf) in the future.
**Limitation**:
At some point we switch from sampling the ellipse to sampling the rectangle, depending on the area of the both, and there seems to be a visible line (with |slope| =1) on the final rendering
which demonstrate at which point we switch between the two methods. We could see that the new sampling method clearly has lower variance near the boundaries, but close to that visible line,
the rectangle sampling method seems to have larger variance. I could not spot any bug in the implementation, and I am not sure if this happens because different sampling patterns for ellipse and rectangle are used.
|Before (256spp)|After (256spp)
|{F13996995}|{F13996998}
Differential Revision: https://developer.blender.org/D16694
2022-12-05 14:35:25 +01:00
|
|
|
light->set_ellipse(false);
|
2020-02-02 13:09:18 +01:00
|
|
|
break;
|
|
|
|
|
case BL::AreaLight::shape_DISK:
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_sizev(light->get_sizeu());
|
Cycles: improve sampling of ellipse area light with spread
**Problem**:
Area lights in Cycles have spread angle, in which case some part of the area light might be invisible to a shading point. The current implementation samples the whole area light, resulting some samples invisible and thus simply discarded. A technique is applied on rectangular light to sample a subset of the area light that is potentially visible (rB3f24cfb9582e1c826406301d37808df7ca6aa64c), however, ellipse (including disk) area lights remained untreated. The purpose of this patch is to apply a techniques to ellipse area light.
**Related Task**:
T87053
**Results**:
These are renderings before and after the patch:
|16spp|Disk light|Ellipse light|Square light (for reference, no changes)
|Before|{F13996789}|{F13996788}|{F13996822}
|After|{F13996759}|{F13996787}|{F13996852}
**Explanation**:
The visible region on an area light is found by drawing a cone from the shading point to the plane where the area light lies, with the aperture of the cone being the light spread.
{F13990078,height=200}
Ideally, we would like to draw samples only from the intersection of the area light and the projection of the cone onto the plane (forming a circle). However, the shape of the intersection is often irregular and thus hard to sample from directly.
{F13990104,height=200}
Instead, the current implementation draws samples from the bounding rectangle of the intersection. In this case, we still end up with some invalid samples outside of the circle, but already much less than sampling the original area light, and the bounding rectangle is easy to sample from.
{F13990125}
The above technique is only applied to rectangle area lights, ellipse area light still suffers from poor sampling. We could apply a similar technique to ellipse area lights, that is, find the
smallest regular shape (rectangle, circle, or ellipse) that covers the intersection (or maybe not the smallest but easy to compute).
For disk area light, we consider the relative position of both circles. Denoting `dist` as the distance between the centre of two circles, and `r1`, `r2` their radii. If `dist > r1 + r2`, the area light is completely invisible, we directly return `false`. If `dist < abs(r1 - r2)`, the smaller circle lies inside the larger one, and we sample whichever circle is smaller. Otherwise, the two circles intersect, we compute the bounding rectangle of the intersection, in which case `axis_u`, `len_u`, `axis_v`, `len_v` needs to be computed anew. Depending on the distance between the two circles, `len_v` is either the diameter of the smaller circle or the length of the common chord.
|{F13990211,height=195}|{F13990225,height=195}|{F13990274,height=195}|{F13990210,height=195}
|`dist > r1 + r2`|`dist < abs(r1 - r2)`|`dist^2 < abs(r1^2 - r2^2)`|`dist^2 > abs(r1^2 - r2^2)`
For ellipse area light, it's hard to find the smallest bounding shape of the intersection, therefore, we compute the bounding rectangle of the ellipse itself, then treat it as a rectangle light.
|{F13990386,height=195}|{F13990385,height=195}|{F13990387,height=195}
We also check the areas of the bounding rectangle of the intersection, the ellipse (disk) light, and the spread circle, then draw samples from the smallest shape of the three. For ellipse light, this also detects where one shape lies inside the other. I am not sure if we should add this measure to rectangle area light and sample from the spread circle when it has smaller area, as we seem to have a better sampling technique for rectangular (uniformly sample the solid angle). Maybe we could add [area-preserving parameterization for spherical
ellipse](https://arxiv.org/pdf/1805.09048.pdf) in the future.
**Limitation**:
At some point we switch from sampling the ellipse to sampling the rectangle, depending on the area of the both, and there seems to be a visible line (with |slope| =1) on the final rendering
which demonstrate at which point we switch between the two methods. We could see that the new sampling method clearly has lower variance near the boundaries, but close to that visible line,
the rectangle sampling method seems to have larger variance. I could not spot any bug in the implementation, and I am not sure if this happens because different sampling patterns for ellipse and rectangle are used.
|Before (256spp)|After (256spp)
|{F13996995}|{F13996998}
Differential Revision: https://developer.blender.org/D16694
2022-12-05 14:35:25 +01:00
|
|
|
light->set_ellipse(true);
|
2020-02-02 13:09:18 +01:00
|
|
|
break;
|
|
|
|
|
case BL::AreaLight::shape_ELLIPSE:
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_sizev(b_area_light.size_y());
|
Cycles: improve sampling of ellipse area light with spread
**Problem**:
Area lights in Cycles have spread angle, in which case some part of the area light might be invisible to a shading point. The current implementation samples the whole area light, resulting some samples invisible and thus simply discarded. A technique is applied on rectangular light to sample a subset of the area light that is potentially visible (rB3f24cfb9582e1c826406301d37808df7ca6aa64c), however, ellipse (including disk) area lights remained untreated. The purpose of this patch is to apply a techniques to ellipse area light.
**Related Task**:
T87053
**Results**:
These are renderings before and after the patch:
|16spp|Disk light|Ellipse light|Square light (for reference, no changes)
|Before|{F13996789}|{F13996788}|{F13996822}
|After|{F13996759}|{F13996787}|{F13996852}
**Explanation**:
The visible region on an area light is found by drawing a cone from the shading point to the plane where the area light lies, with the aperture of the cone being the light spread.
{F13990078,height=200}
Ideally, we would like to draw samples only from the intersection of the area light and the projection of the cone onto the plane (forming a circle). However, the shape of the intersection is often irregular and thus hard to sample from directly.
{F13990104,height=200}
Instead, the current implementation draws samples from the bounding rectangle of the intersection. In this case, we still end up with some invalid samples outside of the circle, but already much less than sampling the original area light, and the bounding rectangle is easy to sample from.
{F13990125}
The above technique is only applied to rectangle area lights, ellipse area light still suffers from poor sampling. We could apply a similar technique to ellipse area lights, that is, find the
smallest regular shape (rectangle, circle, or ellipse) that covers the intersection (or maybe not the smallest but easy to compute).
For disk area light, we consider the relative position of both circles. Denoting `dist` as the distance between the centre of two circles, and `r1`, `r2` their radii. If `dist > r1 + r2`, the area light is completely invisible, we directly return `false`. If `dist < abs(r1 - r2)`, the smaller circle lies inside the larger one, and we sample whichever circle is smaller. Otherwise, the two circles intersect, we compute the bounding rectangle of the intersection, in which case `axis_u`, `len_u`, `axis_v`, `len_v` needs to be computed anew. Depending on the distance between the two circles, `len_v` is either the diameter of the smaller circle or the length of the common chord.
|{F13990211,height=195}|{F13990225,height=195}|{F13990274,height=195}|{F13990210,height=195}
|`dist > r1 + r2`|`dist < abs(r1 - r2)`|`dist^2 < abs(r1^2 - r2^2)`|`dist^2 > abs(r1^2 - r2^2)`
For ellipse area light, it's hard to find the smallest bounding shape of the intersection, therefore, we compute the bounding rectangle of the ellipse itself, then treat it as a rectangle light.
|{F13990386,height=195}|{F13990385,height=195}|{F13990387,height=195}
We also check the areas of the bounding rectangle of the intersection, the ellipse (disk) light, and the spread circle, then draw samples from the smallest shape of the three. For ellipse light, this also detects where one shape lies inside the other. I am not sure if we should add this measure to rectangle area light and sample from the spread circle when it has smaller area, as we seem to have a better sampling technique for rectangular (uniformly sample the solid angle). Maybe we could add [area-preserving parameterization for spherical
ellipse](https://arxiv.org/pdf/1805.09048.pdf) in the future.
**Limitation**:
At some point we switch from sampling the ellipse to sampling the rectangle, depending on the area of the both, and there seems to be a visible line (with |slope| =1) on the final rendering
which demonstrate at which point we switch between the two methods. We could see that the new sampling method clearly has lower variance near the boundaries, but close to that visible line,
the rectangle sampling method seems to have larger variance. I could not spot any bug in the implementation, and I am not sure if this happens because different sampling patterns for ellipse and rectangle are used.
|Before (256spp)|After (256spp)
|{F13996995}|{F13996998}
Differential Revision: https://developer.blender.org/D16694
2022-12-05 14:35:25 +01:00
|
|
|
light->set_ellipse(true);
|
2020-02-02 13:09:18 +01:00
|
|
|
break;
|
|
|
|
|
}
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_light_type(LIGHT_AREA);
|
2020-02-02 13:09:18 +01:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-21 21:37:48 +01:00
|
|
|
/* Color and strength. */
|
|
|
|
|
float3 light_color = get_float3(b_light.color());
|
|
|
|
|
if (b_light.use_temperature()) {
|
|
|
|
|
light_color *= get_float3(b_light.temperature_color());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const float3 strength = light_color * BL::PointLight(b_light).energy() *
|
|
|
|
|
exp2f(b_light.exposure());
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_strength(strength);
|
2020-02-02 13:09:18 +01:00
|
|
|
|
2025-02-21 21:37:48 +01:00
|
|
|
/* normalize */
|
|
|
|
|
light->set_normalize(b_light.normalize());
|
|
|
|
|
|
2020-02-02 13:09:18 +01:00
|
|
|
/* shadow */
|
|
|
|
|
PointerRNA clight = RNA_pointer_get(&b_light.ptr, "cycles");
|
2024-05-15 22:00:55 +02:00
|
|
|
light->set_cast_shadow(b_light.use_shadow());
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_use_mis(get_boolean(clight, "use_multiple_importance_sampling"));
|
2020-02-02 13:09:18 +01:00
|
|
|
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
/* caustics light */
|
|
|
|
|
light->set_use_caustics(get_boolean(clight, "is_caustics_light"));
|
|
|
|
|
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_max_bounces(get_int(clight, "max_bounces"));
|
2020-02-02 13:09:18 +01:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (light->get_light_type() == LIGHT_AREA) {
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_is_portal(get_boolean(clight, "is_portal"));
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
|
|
|
|
else {
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_is_portal(false);
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2020-02-02 13:09:18 +01:00
|
|
|
|
2023-09-17 09:01:48 +10:00
|
|
|
if (light->get_is_portal()) {
|
2025-02-24 23:44:14 +01:00
|
|
|
world_use_portal = true;
|
2023-09-17 09:01:48 +10:00
|
|
|
}
|
2020-02-02 13:09:18 +01:00
|
|
|
|
|
|
|
|
/* tag */
|
|
|
|
|
light->tag_update(scene);
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-24 23:44:14 +01:00
|
|
|
void BlenderSync::sync_background_light(BL::SpaceView3D &b_v3d)
|
2020-02-02 13:09:18 +01:00
|
|
|
{
|
2024-02-09 12:16:16 +01:00
|
|
|
BL::World b_world = view_layer.world_override ? view_layer.world_override : b_scene.world();
|
2020-02-02 13:09:18 +01:00
|
|
|
|
|
|
|
|
if (b_world) {
|
|
|
|
|
PointerRNA cworld = RNA_pointer_get(&b_world.ptr, "cycles");
|
|
|
|
|
|
|
|
|
|
enum SamplingMethod { SAMPLING_NONE = 0, SAMPLING_AUTOMATIC, SAMPLING_MANUAL, SAMPLING_NUM };
|
2024-12-29 17:32:00 +01:00
|
|
|
const int sampling_method = get_enum(
|
|
|
|
|
cworld, "sampling_method", SAMPLING_NUM, SAMPLING_AUTOMATIC);
|
|
|
|
|
const bool sample_as_light = (sampling_method != SAMPLING_NONE);
|
2020-02-02 13:09:18 +01:00
|
|
|
|
2025-02-24 23:44:14 +01:00
|
|
|
if (sample_as_light || world_use_portal) {
|
|
|
|
|
/* Create object. */
|
|
|
|
|
Object *object;
|
|
|
|
|
const ObjectKey object_key(b_world, nullptr, b_world, false);
|
|
|
|
|
bool update = object_map.add_or_update(&object, b_world, b_world, object_key);
|
2025-03-05 16:27:49 +01:00
|
|
|
if (update) {
|
|
|
|
|
/* Lights should be shadow catchers by default. */
|
|
|
|
|
object->set_is_shadow_catcher(true);
|
|
|
|
|
}
|
2025-02-24 23:44:14 +01:00
|
|
|
|
|
|
|
|
/* Create geometry. */
|
|
|
|
|
const GeometryKey geom_key{b_world.ptr.data, Geometry::LIGHT};
|
|
|
|
|
Geometry *geom = geometry_map.find(geom_key);
|
|
|
|
|
if (geom) {
|
|
|
|
|
update |= geometry_map.update(geom, b_world);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
geom = scene->create_node<Light>();
|
|
|
|
|
geometry_map.add(geom_key, geom);
|
|
|
|
|
object->set_geometry(geom);
|
|
|
|
|
update = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (update || world_recalc || b_world.ptr.data != world_map) {
|
|
|
|
|
/* Initialize light geometry. */
|
|
|
|
|
Light *light = static_cast<Light *>(geom);
|
2020-02-02 13:09:18 +01:00
|
|
|
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_light_type(LIGHT_BACKGROUND);
|
2020-02-02 13:09:18 +01:00
|
|
|
if (sampling_method == SAMPLING_MANUAL) {
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_map_resolution(get_int(cworld, "sample_map_resolution"));
|
2020-02-02 13:09:18 +01:00
|
|
|
}
|
|
|
|
|
else {
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_map_resolution(0);
|
2020-02-02 13:09:18 +01:00
|
|
|
}
|
2025-02-24 23:44:14 +01:00
|
|
|
array<Node *> used_shaders;
|
|
|
|
|
used_shaders.push_back_slow(scene->default_background);
|
|
|
|
|
light->set_used_shaders(used_shaders);
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_use_mis(sample_as_light);
|
|
|
|
|
light->set_max_bounces(get_int(cworld, "max_bounces"));
|
2020-02-02 13:09:18 +01:00
|
|
|
|
|
|
|
|
/* force enable light again when world is resynced */
|
2020-11-04 11:17:38 +01:00
|
|
|
light->set_is_enabled(true);
|
2020-02-02 13:09:18 +01:00
|
|
|
|
Cycles: approximate shadow caustics using manifold next event estimation
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
2022-04-01 15:44:24 +02:00
|
|
|
/* caustic light */
|
|
|
|
|
light->set_use_caustics(get_boolean(cworld, "is_caustics_light"));
|
|
|
|
|
|
2020-02-02 13:09:18 +01:00
|
|
|
light->tag_update(scene);
|
2025-02-24 23:44:14 +01:00
|
|
|
geometry_map.set_recalc(b_world);
|
2020-02-02 13:09:18 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
world_map = b_world.ptr.data;
|
|
|
|
|
world_recalc = false;
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
viewport_parameters = BlenderViewportParameters(b_v3d, use_developer_ui);
|
2020-02-02 13:09:18 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
CCL_NAMESPACE_END
|