2023-06-14 16:52:36 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2011-2022 Blender Foundation
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: Apache-2.0 */
|
2017-03-23 12:47:27 +01:00
|
|
|
|
|
|
|
|
#ifndef __UTIL_MATH_INTERSECT_H__
|
|
|
|
|
#define __UTIL_MATH_INTERSECT_H__
|
|
|
|
|
|
|
|
|
|
CCL_NAMESPACE_BEGIN
|
|
|
|
|
|
|
|
|
|
/* Ray Intersection */
|
|
|
|
|
|
|
|
|
|
ccl_device bool ray_sphere_intersect(float3 ray_P,
|
2017-03-23 12:53:45 +01:00
|
|
|
float3 ray_D,
|
2022-07-13 16:54:53 +02:00
|
|
|
float ray_tmin,
|
|
|
|
|
float ray_tmax,
|
2017-03-23 12:53:45 +01:00
|
|
|
float3 sphere_P,
|
|
|
|
|
float sphere_radius,
|
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 float3 *isect_P,
|
|
|
|
|
ccl_private float *isect_t)
|
2017-03-23 12:47:27 +01:00
|
|
|
{
|
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 |
| -------- | -------- | -------- |
|  |  |  |
The behavior stays the same when `radius = 0`.
| This patch | Previous behavior |
| -------- | -------- |
|  |  |
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|
|||||
Pull Request: https://projects.blender.org/blender/blender/pulls/108506
2023-06-20 12:23:05 +02:00
|
|
|
const float3 d_vec = sphere_P - ray_P;
|
|
|
|
|
const float r_sq = sphere_radius * sphere_radius;
|
|
|
|
|
const float d_sq = dot(d_vec, d_vec);
|
|
|
|
|
const float d_cos_theta = dot(d_vec, ray_D);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
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 |
| -------- | -------- | -------- |
|  |  |  |
The behavior stays the same when `radius = 0`.
| This patch | Previous behavior |
| -------- | -------- |
|  |  |
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|
|||||
Pull Request: https://projects.blender.org/blender/blender/pulls/108506
2023-06-20 12:23:05 +02:00
|
|
|
if (d_sq > r_sq && d_cos_theta < 0.0f) {
|
|
|
|
|
/* Ray origin outside sphere and points away from sphere. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-06 16:16:34 +02:00
|
|
|
const float d_sin_theta_sq = len_squared(d_vec - d_cos_theta * ray_D);
|
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 |
| -------- | -------- | -------- |
|  |  |  |
The behavior stays the same when `radius = 0`.
| This patch | Previous behavior |
| -------- | -------- |
|  |  |
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|
|||||
Pull Request: https://projects.blender.org/blender/blender/pulls/108506
2023-06-20 12:23:05 +02:00
|
|
|
|
|
|
|
|
if (d_sin_theta_sq > r_sq) {
|
|
|
|
|
/* Closest point on ray outside sphere. */
|
|
|
|
|
return false;
|
2017-03-23 12:47:27 +01:00
|
|
|
}
|
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 |
| -------- | -------- | -------- |
|  |  |  |
The behavior stays the same when `radius = 0`.
| This patch | Previous behavior |
| -------- | -------- |
|  |  |
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|
|||||
Pull Request: https://projects.blender.org/blender/blender/pulls/108506
2023-06-20 12:23:05 +02:00
|
|
|
|
|
|
|
|
/* Law of cosines. */
|
|
|
|
|
const float t = d_cos_theta - copysignf(sqrtf(r_sq - d_sin_theta_sq), d_sq - r_sq);
|
|
|
|
|
|
|
|
|
|
if (t > ray_tmin && t < ray_tmax) {
|
|
|
|
|
*isect_t = t;
|
|
|
|
|
*isect_P = ray_P + ray_D * t;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-23 12:47:27 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ccl_device bool ray_aligned_disk_intersect(float3 ray_P,
|
2017-03-23 12:53:45 +01:00
|
|
|
float3 ray_D,
|
2022-07-13 16:54:53 +02:00
|
|
|
float ray_tmin,
|
|
|
|
|
float ray_tmax,
|
2017-03-23 12:53:45 +01:00
|
|
|
float3 disk_P,
|
|
|
|
|
float disk_radius,
|
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 float3 *isect_P,
|
|
|
|
|
ccl_private float *isect_t)
|
2017-03-23 12:47:27 +01:00
|
|
|
{
|
2017-03-23 12:53:45 +01:00
|
|
|
/* Aligned disk normal. */
|
2017-03-23 12:47:27 +01:00
|
|
|
float disk_t;
|
2017-03-23 12:53:45 +01:00
|
|
|
const float3 disk_N = normalize_len(ray_P - disk_P, &disk_t);
|
|
|
|
|
const float div = dot(ray_D, disk_N);
|
|
|
|
|
if (UNLIKELY(div == 0.0f)) {
|
2017-03-23 12:47:27 +01:00
|
|
|
return false;
|
2017-03-23 12:53:45 +01:00
|
|
|
}
|
|
|
|
|
/* Compute t to intersection point. */
|
|
|
|
|
const float t = -disk_t / div;
|
2022-07-13 16:54:53 +02:00
|
|
|
if (!(t > ray_tmin && t < ray_tmax)) {
|
2017-03-23 12:47:27 +01:00
|
|
|
return false;
|
2017-03-23 12:53:45 +01:00
|
|
|
}
|
|
|
|
|
/* Test if within radius. */
|
2017-03-23 12:47:27 +01:00
|
|
|
float3 P = ray_P + ray_D * t;
|
2017-03-23 12:53:45 +01:00
|
|
|
if (len_squared(P - disk_P) > disk_radius * disk_radius) {
|
2017-03-23 12:47:27 +01:00
|
|
|
return false;
|
2017-03-23 12:53:45 +01:00
|
|
|
}
|
2017-03-23 12:47:27 +01:00
|
|
|
*isect_P = P;
|
|
|
|
|
*isect_t = t;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-24 14:04:34 +01:00
|
|
|
ccl_device bool ray_disk_intersect(float3 ray_P,
|
|
|
|
|
float3 ray_D,
|
2022-07-13 16:54:53 +02:00
|
|
|
float ray_tmin,
|
|
|
|
|
float ray_tmax,
|
2021-11-24 14:04:34 +01:00
|
|
|
float3 disk_P,
|
|
|
|
|
float3 disk_N,
|
|
|
|
|
float disk_radius,
|
|
|
|
|
ccl_private float3 *isect_P,
|
|
|
|
|
ccl_private float *isect_t)
|
|
|
|
|
{
|
|
|
|
|
const float3 vp = ray_P - disk_P;
|
|
|
|
|
const float dp = dot(vp, disk_N);
|
|
|
|
|
const float cos_angle = dot(disk_N, -ray_D);
|
|
|
|
|
if (dp * cos_angle > 0.f) // front of light
|
|
|
|
|
{
|
|
|
|
|
float t = dp / cos_angle;
|
|
|
|
|
if (t < 0.f) { /* Ray points away from the light. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
float3 P = ray_P + t * ray_D;
|
|
|
|
|
float3 T = P - disk_P;
|
2022-07-13 16:54:53 +02:00
|
|
|
|
|
|
|
|
if (dot(T, T) < sqr(disk_radius) && (t > ray_tmin && t < ray_tmax)) {
|
2021-11-24 14:04:34 +01:00
|
|
|
*isect_P = ray_P + t * ray_D;
|
|
|
|
|
*isect_t = t;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2022-07-18 21:07:06 +02:00
|
|
|
/* Custom rcp, cross and dot implementations that match Embree bit for bit. */
|
|
|
|
|
ccl_device_forceinline float ray_triangle_rcp(const float x)
|
|
|
|
|
{
|
|
|
|
|
#ifdef __KERNEL_NEON__
|
|
|
|
|
/* Move scalar to vector register and do rcp. */
|
|
|
|
|
__m128 a;
|
|
|
|
|
a[0] = x;
|
|
|
|
|
float32x4_t reciprocal = vrecpeq_f32(a);
|
|
|
|
|
reciprocal = vmulq_f32(vrecpsq_f32(a, reciprocal), reciprocal);
|
|
|
|
|
reciprocal = vmulq_f32(vrecpsq_f32(a, reciprocal), reciprocal);
|
|
|
|
|
return reciprocal[0];
|
|
|
|
|
#elif defined(__KERNEL_SSE__)
|
|
|
|
|
const __m128 a = _mm_set_ss(x);
|
|
|
|
|
const __m128 r = _mm_rcp_ss(a);
|
|
|
|
|
|
|
|
|
|
# ifdef __KERNEL_AVX2_
|
|
|
|
|
return _mm_cvtss_f32(_mm_mul_ss(r, _mm_fnmadd_ss(r, a, _mm_set_ss(2.0f))));
|
|
|
|
|
# else
|
|
|
|
|
return _mm_cvtss_f32(_mm_mul_ss(r, _mm_sub_ss(_mm_set_ss(2.0f), _mm_mul_ss(r, a))));
|
|
|
|
|
# endif
|
|
|
|
|
#else
|
|
|
|
|
return 1.0f / x;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ccl_device_inline float ray_triangle_dot(const float3 a, const float3 b)
|
|
|
|
|
{
|
2024-02-19 15:54:48 +01:00
|
|
|
#if defined(__KERNEL_SSE41__) && defined(__KERNEL_SSE__)
|
2022-11-01 15:16:55 +01:00
|
|
|
return madd(make_float4(a.x),
|
|
|
|
|
make_float4(b.x),
|
|
|
|
|
madd(make_float4(a.y), make_float4(b.y), make_float4(a.z) * make_float4(b.z)))[0];
|
2022-07-18 21:07:06 +02:00
|
|
|
#else
|
|
|
|
|
return a.x * b.x + a.y * b.y + a.z * b.z;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ccl_device_inline float3 ray_triangle_cross(const float3 a, const float3 b)
|
|
|
|
|
{
|
2024-02-19 15:54:48 +01:00
|
|
|
#if defined(__KERNEL_SSE41__) && defined(__KERNEL_SSE__)
|
2022-11-01 15:16:55 +01:00
|
|
|
return make_float3(
|
|
|
|
|
msub(make_float4(a.y), make_float4(b.z), make_float4(a.z) * make_float4(b.y))[0],
|
|
|
|
|
msub(make_float4(a.z), make_float4(b.x), make_float4(a.x) * make_float4(b.z))[0],
|
|
|
|
|
msub(make_float4(a.x), make_float4(b.y), make_float4(a.y) * make_float4(b.x))[0]);
|
2022-07-18 21:07:06 +02:00
|
|
|
#else
|
|
|
|
|
return make_float3(a.y * b.z - a.z * b.y, a.z * b.x - a.x * b.z, a.x * b.y - a.y * b.x);
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
2022-07-21 15:49:00 +02:00
|
|
|
ccl_device_forceinline bool ray_triangle_intersect(const float3 ray_P,
|
|
|
|
|
const float3 ray_D,
|
|
|
|
|
const float ray_tmin,
|
|
|
|
|
const float ray_tmax,
|
2017-03-23 17:15:54 +01:00
|
|
|
const float3 tri_a,
|
|
|
|
|
const float3 tri_b,
|
|
|
|
|
const float3 tri_c,
|
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 float *isect_u,
|
|
|
|
|
ccl_private float *isect_v,
|
|
|
|
|
ccl_private float *isect_t)
|
2017-03-23 13:30:18 +01:00
|
|
|
{
|
2022-07-21 15:49:00 +02:00
|
|
|
/* This implementation matches the Plücker coordinates triangle intersection
|
|
|
|
|
* in Embree. */
|
2017-03-23 13:30:18 +01:00
|
|
|
|
2017-03-27 17:06:37 +02:00
|
|
|
/* Calculate vertices relative to ray origin. */
|
2022-07-26 16:07:50 +02:00
|
|
|
const float3 v0 = tri_a - ray_P;
|
|
|
|
|
const float3 v1 = tri_b - ray_P;
|
|
|
|
|
const float3 v2 = tri_c - ray_P;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-03-27 17:06:37 +02:00
|
|
|
/* Calculate triangle edges. */
|
|
|
|
|
const float3 e0 = v2 - v0;
|
|
|
|
|
const float3 e1 = v0 - v1;
|
|
|
|
|
const float3 e2 = v1 - v2;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-03-27 17:06:37 +02:00
|
|
|
/* Perform edge tests. */
|
2022-07-18 21:07:06 +02:00
|
|
|
const float U = ray_triangle_dot(ray_triangle_cross(e0, v2 + v0), ray_D);
|
|
|
|
|
const float V = ray_triangle_dot(ray_triangle_cross(e1, v0 + v1), ray_D);
|
|
|
|
|
const float W = ray_triangle_dot(ray_triangle_cross(e2, v1 + v2), ray_D);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-07-26 16:07:50 +02:00
|
|
|
const float UVW = U + V + W;
|
|
|
|
|
const float eps = FLT_EPSILON * fabsf(UVW);
|
2017-03-27 17:06:37 +02:00
|
|
|
const float minUVW = min(U, min(V, W));
|
|
|
|
|
const float maxUVW = max(U, max(V, W));
|
|
|
|
|
|
2022-07-21 15:49:00 +02:00
|
|
|
if (!(minUVW >= -eps || maxUVW <= eps)) {
|
2017-03-23 13:30:18 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
2017-11-29 02:02:17 +01:00
|
|
|
|
2017-03-27 17:06:37 +02:00
|
|
|
/* Calculate geometry normal and denominator. */
|
2022-07-18 21:07:06 +02:00
|
|
|
const float3 Ng1 = ray_triangle_cross(e1, e0);
|
2017-03-27 17:06:37 +02:00
|
|
|
const float3 Ng = Ng1 + Ng1;
|
2022-07-21 15:49:00 +02:00
|
|
|
const float den = dot(Ng, ray_D);
|
2017-03-27 17:06:37 +02:00
|
|
|
/* Avoid division by 0. */
|
|
|
|
|
if (UNLIKELY(den == 0.0f)) {
|
2017-03-23 13:30:18 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-03-27 17:06:37 +02:00
|
|
|
/* Perform depth test. */
|
2022-07-21 15:49:00 +02:00
|
|
|
const float T = dot(v0, Ng);
|
2022-07-13 16:54:53 +02:00
|
|
|
const float t = T / den;
|
|
|
|
|
if (!(t >= ray_tmin && t <= ray_tmax)) {
|
2017-03-23 13:30:18 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-07-18 21:07:06 +02:00
|
|
|
const float rcp_uvw = (fabsf(UVW) < 1e-18f) ? 0.0f : ray_triangle_rcp(UVW);
|
|
|
|
|
*isect_u = min(U * rcp_uvw, 1.0f);
|
|
|
|
|
*isect_v = min(V * rcp_uvw, 1.0f);
|
2022-07-13 16:54:53 +02:00
|
|
|
*isect_t = t;
|
2017-03-23 13:30:18 +01:00
|
|
|
return true;
|
2017-03-27 17:06:37 +02:00
|
|
|
}
|
2017-03-23 13:01:42 +01:00
|
|
|
|
2022-07-18 21:07:06 +02:00
|
|
|
ccl_device_forceinline bool ray_triangle_intersect_self(const float3 ray_P,
|
|
|
|
|
const float3 ray_D,
|
2023-05-08 19:11:11 +02:00
|
|
|
const float3 verts[3])
|
2022-07-18 21:07:06 +02:00
|
|
|
{
|
|
|
|
|
/* Matches logic in ray_triangle_intersect, self intersection test to validate
|
|
|
|
|
* if a ray is going to hit self or might incorrectly hit a neighboring triangle. */
|
|
|
|
|
|
|
|
|
|
/* Calculate vertices relative to ray origin. */
|
2023-05-08 19:11:11 +02:00
|
|
|
const float3 v0 = verts[0] - ray_P;
|
|
|
|
|
const float3 v1 = verts[1] - ray_P;
|
|
|
|
|
const float3 v2 = verts[2] - ray_P;
|
2022-07-18 21:07:06 +02:00
|
|
|
|
|
|
|
|
/* Calculate triangle edges. */
|
|
|
|
|
const float3 e0 = v2 - v0;
|
|
|
|
|
const float3 e1 = v0 - v1;
|
|
|
|
|
const float3 e2 = v1 - v2;
|
|
|
|
|
|
|
|
|
|
/* Perform edge tests. */
|
|
|
|
|
const float U = ray_triangle_dot(ray_triangle_cross(v2 + v0, e0), ray_D);
|
|
|
|
|
const float V = ray_triangle_dot(ray_triangle_cross(v0 + v1, e1), ray_D);
|
|
|
|
|
const float W = ray_triangle_dot(ray_triangle_cross(v1 + v2, e2), ray_D);
|
|
|
|
|
|
|
|
|
|
const float eps = FLT_EPSILON * fabsf(U + V + W);
|
|
|
|
|
const float minUVW = min(U, min(V, W));
|
|
|
|
|
const float maxUVW = max(U, max(V, W));
|
|
|
|
|
|
|
|
|
|
/* Note the extended epsilon compared to ray_triangle_intersect, to account
|
|
|
|
|
* for intersections with neighboring triangles that have an epsilon. */
|
|
|
|
|
return (minUVW >= eps || maxUVW <= -eps);
|
|
|
|
|
}
|
|
|
|
|
|
Cycles/Eevee: Implement disk and ellipse shapes for area lamps
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
2018-05-24 03:50:16 +02:00
|
|
|
/* Tests for an intersection between a ray and a quad defined by
|
|
|
|
|
* its midpoint, normal and sides.
|
|
|
|
|
* If ellipse is true, hits outside the ellipse that's enclosed by the
|
|
|
|
|
* quad are rejected.
|
|
|
|
|
*/
|
2017-03-23 12:53:45 +01:00
|
|
|
ccl_device bool ray_quad_intersect(float3 ray_P,
|
|
|
|
|
float3 ray_D,
|
2022-07-13 16:54:53 +02:00
|
|
|
float ray_tmin,
|
|
|
|
|
float ray_tmax,
|
2017-03-23 12:53:45 +01:00
|
|
|
float3 quad_P,
|
2022-12-02 15:21:57 +01:00
|
|
|
float3 inv_quad_u,
|
|
|
|
|
float3 inv_quad_v,
|
2017-03-23 12:53:45 +01:00
|
|
|
float3 quad_n,
|
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 float3 *isect_P,
|
|
|
|
|
ccl_private float *isect_t,
|
|
|
|
|
ccl_private float *isect_u,
|
|
|
|
|
ccl_private float *isect_v,
|
Cycles/Eevee: Implement disk and ellipse shapes for area lamps
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
2018-05-24 03:50:16 +02:00
|
|
|
bool ellipse)
|
2017-03-23 12:47:27 +01:00
|
|
|
{
|
2017-03-23 12:53:45 +01:00
|
|
|
/* Perform intersection test. */
|
2017-03-23 12:47:27 +01:00
|
|
|
float t = -(dot(ray_P, quad_n) - dot(quad_P, quad_n)) / dot(ray_D, quad_n);
|
2022-07-13 16:54:53 +02:00
|
|
|
if (!(t > ray_tmin && t < ray_tmax)) {
|
2017-03-23 12:47:27 +01:00
|
|
|
return false;
|
2017-03-23 12:53:45 +01:00
|
|
|
}
|
|
|
|
|
const float3 hit = ray_P + t * ray_D;
|
|
|
|
|
const float3 inplane = hit - quad_P;
|
2022-12-02 15:21:57 +01:00
|
|
|
const float u = dot(inplane, inv_quad_u);
|
Cycles/Eevee: Implement disk and ellipse shapes for area lamps
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
2018-05-24 03:50:16 +02:00
|
|
|
if (u < -0.5f || u > 0.5f) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2022-12-02 15:21:57 +01:00
|
|
|
const float v = dot(inplane, inv_quad_v);
|
Cycles/Eevee: Implement disk and ellipse shapes for area lamps
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
2018-05-24 03:50:16 +02:00
|
|
|
if (v < -0.5f || v > 0.5f) {
|
2017-03-23 12:47:27 +01:00
|
|
|
return false;
|
2017-03-23 12:53:45 +01:00
|
|
|
}
|
Cycles/Eevee: Implement disk and ellipse shapes for area lamps
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
2018-05-24 03:50:16 +02:00
|
|
|
if (ellipse && (u * u + v * v > 0.25f)) {
|
2017-03-23 12:47:27 +01:00
|
|
|
return false;
|
2017-03-23 12:53:45 +01:00
|
|
|
}
|
|
|
|
|
/* Store the result. */
|
|
|
|
|
/* TODO(sergey): Check whether we can avoid some checks here. */
|
|
|
|
|
if (isect_P != NULL)
|
|
|
|
|
*isect_P = hit;
|
|
|
|
|
if (isect_t != NULL)
|
|
|
|
|
*isect_t = t;
|
2022-08-01 16:07:10 +02:00
|
|
|
|
|
|
|
|
/* NOTE: Return barycentric coordinates in the same notation as Embree and OptiX. */
|
Cycles/Eevee: Implement disk and ellipse shapes for area lamps
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
2018-05-24 03:50:16 +02:00
|
|
|
if (isect_u != NULL)
|
2022-08-01 16:07:10 +02:00
|
|
|
*isect_u = v + 0.5f;
|
Cycles/Eevee: Implement disk and ellipse shapes for area lamps
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
2018-05-24 03:50:16 +02:00
|
|
|
if (isect_v != NULL)
|
2022-08-01 16:07:10 +02:00
|
|
|
*isect_v = -u - v;
|
|
|
|
|
|
2017-03-23 12:47:27 +01:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
CCL_NAMESPACE_END
|
|
|
|
|
|
|
|
|
|
#endif /* __UTIL_MATH_INTERSECT_H__ */
|