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
|
|
|
|
2024-12-26 17:53:56 +01:00
|
|
|
#pragma once
|
2017-03-23 12:47:27 +01:00
|
|
|
|
2024-12-26 17:53:56 +01:00
|
|
|
#include "util/math_float2.h"
|
|
|
|
|
#include "util/math_float3.h"
|
|
|
|
|
#include "util/math_float4.h"
|
|
|
|
|
|
2017-03-23 12:47:27 +01:00
|
|
|
CCL_NAMESPACE_BEGIN
|
|
|
|
|
|
|
|
|
|
/* Ray Intersection */
|
|
|
|
|
|
2025-01-01 18:15:54 +01:00
|
|
|
ccl_device bool ray_sphere_intersect(const float3 ray_P,
|
|
|
|
|
const float3 ray_D,
|
|
|
|
|
const float ray_tmin,
|
|
|
|
|
const float ray_tmax,
|
|
|
|
|
const float3 sphere_P,
|
|
|
|
|
const 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;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-01 18:15:54 +01:00
|
|
|
ccl_device bool ray_aligned_disk_intersect(const float3 ray_P,
|
|
|
|
|
const float3 ray_D,
|
|
|
|
|
const float ray_tmin,
|
|
|
|
|
const float ray_tmax,
|
|
|
|
|
const float3 disk_P,
|
|
|
|
|
const 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. */
|
2024-12-29 17:32:00 +01:00
|
|
|
const 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;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-01 18:15:54 +01:00
|
|
|
ccl_device bool ray_disk_intersect(const float3 ray_P,
|
|
|
|
|
const float3 ray_D,
|
|
|
|
|
const float ray_tmin,
|
|
|
|
|
const float ray_tmax,
|
|
|
|
|
const float3 disk_P,
|
|
|
|
|
const float3 disk_N,
|
|
|
|
|
const float disk_radius,
|
2021-11-24 14:04:34 +01:00
|
|
|
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
|
|
|
|
|
{
|
2024-12-29 17:32:00 +01:00
|
|
|
const float t = dp / cos_angle;
|
2021-11-24 14:04:34 +01:00
|
|
|
if (t < 0.f) { /* Ray points away from the light. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2024-12-29 17:32:00 +01:00
|
|
|
const float3 P = ray_P + t * ray_D;
|
|
|
|
|
const 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. */
|
2025-02-04 18:59:24 +01:00
|
|
|
ccl_device_forceinline float ray_triangle_reciprocal(const float x)
|
2022-07-18 21:07:06 +02:00
|
|
|
{
|
|
|
|
|
#ifdef __KERNEL_NEON__
|
|
|
|
|
/* Move scalar to vector register and do rcp. */
|
2024-03-06 15:44:46 +01:00
|
|
|
__m128 a = {0};
|
|
|
|
|
a = vsetq_lane_f32(x, a, 0);
|
2025-02-04 18:59:24 +01:00
|
|
|
float32x4_t rt_rcp = vrecpeq_f32(a);
|
|
|
|
|
rt_rcp = vmulq_f32(vrecpsq_f32(a, rt_rcp), rt_rcp);
|
|
|
|
|
rt_rcp = vmulq_f32(vrecpsq_f32(a, rt_rcp), rt_rcp);
|
|
|
|
|
return vgetq_lane_f32(rt_rcp, 0);
|
2022-07-18 21:07:06 +02:00
|
|
|
#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-09 17:25:58 +01:00
|
|
|
#if defined(__KERNEL_SSE42__) && 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-09 17:25:58 +01:00
|
|
|
#if defined(__KERNEL_SSE42__) && 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
|
|
|
|
2025-02-04 18:59:24 +01:00
|
|
|
const float rcp_uvw = (fabsf(UVW) < 1e-18f) ? 0.0f : ray_triangle_reciprocal(UVW);
|
2022-07-18 21:07:06 +02:00
|
|
|
*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.
|
|
|
|
|
*/
|
2025-01-01 18:15:54 +01:00
|
|
|
ccl_device bool ray_quad_intersect(const float3 ray_P,
|
|
|
|
|
const float3 ray_D,
|
|
|
|
|
const float ray_tmin,
|
|
|
|
|
const float ray_tmax,
|
|
|
|
|
const float3 quad_P,
|
|
|
|
|
const float3 inv_quad_u,
|
|
|
|
|
const float3 inv_quad_v,
|
|
|
|
|
const 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. */
|
2024-12-29 17:32:00 +01:00
|
|
|
const 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. */
|
2024-12-26 17:53:56 +01:00
|
|
|
if (isect_P != nullptr) {
|
2017-03-23 12:53:45 +01:00
|
|
|
*isect_P = hit;
|
2024-12-26 17:53:56 +01:00
|
|
|
}
|
|
|
|
|
if (isect_t != nullptr) {
|
2017-03-23 12:53:45 +01:00
|
|
|
*isect_t = t;
|
2024-12-26 17:53:56 +01:00
|
|
|
}
|
2022-08-01 16:07:10 +02:00
|
|
|
|
|
|
|
|
/* NOTE: Return barycentric coordinates in the same notation as Embree and OptiX. */
|
2024-12-26 17:53:56 +01:00
|
|
|
if (isect_u != nullptr) {
|
2022-08-01 16:07:10 +02:00
|
|
|
*isect_u = v + 0.5f;
|
2024-12-26 17:53:56 +01:00
|
|
|
}
|
|
|
|
|
if (isect_v != nullptr) {
|
2022-08-01 16:07:10 +02:00
|
|
|
*isect_v = -u - v;
|
2024-12-26 17:53:56 +01:00
|
|
|
}
|
2022-08-01 16:07:10 +02:00
|
|
|
|
2017-03-23 12:47:27 +01:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-25 13:02:02 +01:00
|
|
|
/* Find the ray segment that lies in the same side as the normal `N` of the plane.
|
|
|
|
|
* `P` is the vector pointing from any point on the plane to the ray origin. */
|
|
|
|
|
ccl_device bool ray_plane_intersect(const float3 N,
|
|
|
|
|
const float3 P,
|
|
|
|
|
const float3 ray_D,
|
2024-11-12 12:06:09 +01:00
|
|
|
ccl_private Interval<float> *t_range)
|
2024-03-25 13:02:02 +01:00
|
|
|
{
|
|
|
|
|
const float DN = dot(ray_D, N);
|
|
|
|
|
|
|
|
|
|
/* Distance from P to the plane. */
|
|
|
|
|
const float t = -dot(P, N) / DN;
|
|
|
|
|
|
|
|
|
|
/* Limit the range to the positive side. */
|
|
|
|
|
if (DN > 0.0f) {
|
2024-11-12 12:06:09 +01:00
|
|
|
t_range->min = fmaxf(t_range->min, t);
|
2024-03-25 13:02:02 +01:00
|
|
|
}
|
|
|
|
|
else {
|
2024-11-12 12:06:09 +01:00
|
|
|
t_range->max = fminf(t_range->max, t);
|
2024-03-25 13:02:02 +01:00
|
|
|
}
|
|
|
|
|
|
2024-11-12 12:06:09 +01:00
|
|
|
return !t_range->is_empty();
|
2024-03-25 13:02:02 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Find the ray segment inside an axis-aligned bounding box. */
|
|
|
|
|
ccl_device bool ray_aabb_intersect(const float3 bbox_min,
|
|
|
|
|
const float3 bbox_max,
|
|
|
|
|
const float3 ray_P,
|
|
|
|
|
const float3 ray_D,
|
2024-11-12 12:06:09 +01:00
|
|
|
ccl_private Interval<float> *t_range)
|
2024-03-25 13:02:02 +01:00
|
|
|
{
|
2025-02-04 18:59:24 +01:00
|
|
|
const float3 inv_ray_D = reciprocal(ray_D);
|
2024-03-25 13:02:02 +01:00
|
|
|
|
|
|
|
|
/* Absolute distances to lower and upper box coordinates; */
|
|
|
|
|
const float3 t_lower = (bbox_min - ray_P) * inv_ray_D;
|
|
|
|
|
const float3 t_upper = (bbox_max - ray_P) * inv_ray_D;
|
|
|
|
|
|
|
|
|
|
/* The four t-intervals (for x-/y-/z-slabs, and ray p(t)). */
|
2024-12-19 09:41:55 +01:00
|
|
|
const float4 tmins = make_float4(min(t_lower, t_upper), t_range->min);
|
|
|
|
|
const float4 tmaxes = make_float4(max(t_lower, t_upper), t_range->max);
|
2024-03-25 13:02:02 +01:00
|
|
|
|
|
|
|
|
/* Max of mins and min of maxes. */
|
|
|
|
|
const float tmin = reduce_max(tmins);
|
|
|
|
|
const float tmax = reduce_min(tmaxes);
|
|
|
|
|
|
2024-11-12 12:06:09 +01:00
|
|
|
*t_range = {tmin, tmax};
|
2024-03-25 13:02:02 +01:00
|
|
|
|
2024-11-12 12:06:09 +01:00
|
|
|
return !t_range->is_empty();
|
2024-03-25 13:02:02 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Find the segment of a ray defined by P + D * t that lies inside a cylinder defined by
|
|
|
|
|
* (x / len_u)^2 + (y / len_v)^2 = 1. */
|
|
|
|
|
ccl_device_inline bool ray_infinite_cylinder_intersect(const float3 P,
|
|
|
|
|
const float3 D,
|
|
|
|
|
const float len_u,
|
|
|
|
|
const float len_v,
|
2024-11-12 12:06:09 +01:00
|
|
|
ccl_private Interval<float> *t_range)
|
2024-03-25 13:02:02 +01:00
|
|
|
{
|
|
|
|
|
/* Convert to a 2D problem. */
|
|
|
|
|
const float2 inv_len = 1.0f / make_float2(len_u, len_v);
|
2024-12-19 09:41:55 +01:00
|
|
|
float2 P_proj = make_float2(P) * inv_len;
|
|
|
|
|
const float2 D_proj = make_float2(D) * inv_len;
|
2024-03-25 13:02:02 +01:00
|
|
|
|
|
|
|
|
/* Solve quadratic equation a*t^2 + 2b*t + c = 0. */
|
|
|
|
|
const float a = dot(D_proj, D_proj);
|
|
|
|
|
float b = dot(P_proj, D_proj);
|
|
|
|
|
|
|
|
|
|
/* Move ray origin closer to the cylinder to prevent precision issue when the ray is far away. */
|
|
|
|
|
const float t_mid = -b / a;
|
|
|
|
|
P_proj += D_proj * t_mid;
|
|
|
|
|
|
|
|
|
|
/* Recompute b from the shifted origin. */
|
|
|
|
|
b = dot(P_proj, D_proj);
|
|
|
|
|
const float c = dot(P_proj, P_proj) - 1.0f;
|
|
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
float tmin;
|
|
|
|
|
float tmax;
|
2024-03-25 13:02:02 +01:00
|
|
|
const bool valid = solve_quadratic(a, 2.0f * b, c, tmin, tmax);
|
|
|
|
|
|
2024-11-12 12:06:09 +01:00
|
|
|
*t_range = intervals_intersection(*t_range, {tmin + t_mid, tmax + t_mid});
|
|
|
|
|
|
|
|
|
|
return valid && !t_range->is_empty();
|
2024-03-25 13:02:02 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* *
|
|
|
|
|
* Find the ray segment inside a single-sided cone.
|
|
|
|
|
*
|
|
|
|
|
* \param axis: a unit-length direction around which the cone has a circular symmetry
|
|
|
|
|
* \param P: the vector pointing from the cone apex to the ray origin
|
|
|
|
|
* \param D: the direction of the ray, does not need to have unit-length
|
|
|
|
|
* \param cos_angle_sq: `sqr(cos(half_aperture_of_the_cone))`
|
2024-11-12 12:06:09 +01:00
|
|
|
* \param t_range: the ray segment that lies inside the cone
|
2024-03-25 13:02:02 +01:00
|
|
|
* \return whether the intersection exists and is in the provided range
|
|
|
|
|
*
|
|
|
|
|
* See https://www.geometrictools.com/Documentation/IntersectionLineCone.pdf for illustration
|
|
|
|
|
*/
|
|
|
|
|
ccl_device_inline bool ray_cone_intersect(const float3 axis,
|
|
|
|
|
const float3 P,
|
|
|
|
|
float3 D,
|
|
|
|
|
const float cos_angle_sq,
|
2024-11-12 12:06:09 +01:00
|
|
|
ccl_private Interval<float> *t_range)
|
2024-03-25 13:02:02 +01:00
|
|
|
{
|
|
|
|
|
if (cos_angle_sq < 1e-4f) {
|
|
|
|
|
/* The cone is nearly a plane. */
|
|
|
|
|
return ray_plane_intersect(axis, P, D, t_range);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const float inv_len = inversesqrtf(len_squared(D));
|
|
|
|
|
D *= inv_len;
|
|
|
|
|
|
|
|
|
|
const float AD = dot(axis, D);
|
|
|
|
|
const float AP = dot(axis, P);
|
|
|
|
|
|
|
|
|
|
const float a = sqr(AD) - cos_angle_sq;
|
|
|
|
|
const float b = 2.0f * (AD * AP - cos_angle_sq * dot(D, P));
|
|
|
|
|
const float c = sqr(AP) - cos_angle_sq * dot(P, P);
|
|
|
|
|
|
2024-12-29 17:32:00 +01:00
|
|
|
float tmin = 0.0f;
|
|
|
|
|
float tmax = FLT_MAX;
|
2024-03-25 13:02:02 +01:00
|
|
|
bool valid = solve_quadratic(a, b, c, tmin, tmax);
|
|
|
|
|
|
|
|
|
|
/* Check if the intersections are in the same hemisphere as the cone. */
|
|
|
|
|
const bool tmin_valid = AP + tmin * AD > 0.0f;
|
|
|
|
|
const bool tmax_valid = AP + tmax * AD > 0.0f;
|
|
|
|
|
|
|
|
|
|
valid &= (tmin_valid || tmax_valid);
|
|
|
|
|
|
|
|
|
|
if (!tmax_valid) {
|
|
|
|
|
tmax = tmin;
|
|
|
|
|
tmin = 0.0f;
|
|
|
|
|
}
|
|
|
|
|
else if (!tmin_valid) {
|
|
|
|
|
tmin = tmax;
|
|
|
|
|
tmax = FLT_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
2024-11-12 12:06:09 +01:00
|
|
|
*t_range = intervals_intersection(*t_range, {tmin * inv_len, tmax * inv_len});
|
|
|
|
|
|
|
|
|
|
return valid && !t_range->is_empty();
|
2024-03-25 13:02:02 +01:00
|
|
|
}
|
|
|
|
|
|
2017-03-23 12:47:27 +01:00
|
|
|
CCL_NAMESPACE_END
|