To align better with the pixel and reduce the samples needed.
The paper was using gamma because the jacobian |d_gamma/d_h| approaches
infinity at the boundaries, but it seems that clamping at 0.999 is
enough for numerical stability.
In practice I did not notice a change in the noise level, but it
simplifies the range computation and renders faster due to reduced
sample amount.
Co-authored-by: Olivier Maury <omaury@meta.com>
Ref: !129616
Pull Request: https://projects.blender.org/blender/blender/pulls/134130
Check was misc-const-correctness, combined with readability-isolate-declaration
as suggested by the docs.
Temporarily clang-format "QualifierAlignment: Left" was used to get consistency
with the prevailing order of keywords.
Pull Request: https://projects.blender.org/blender/blender/pulls/132361
* Use .empty() and .data()
* Use nullptr instead of 0
* No else after return
* Simple class member initialization
* Add override for virtual methods
* Include C++ instead of C headers
* Remove some unused includes
* Use default constructors
* Always use braces
* Consistent names in definition and declaration
* Change typedef to using
Pull Request: https://projects.blender.org/blender/blender/pulls/132361
The original paper uses the single scattering albedo `sigma_s/sigma_t`
to pick a channel for sampling the scattering distance. However, this
only considers the situation where there is scattering inside the volume.
If some channel has an extinction coefficient of zero, the light passes
through without attenuation for that channel. We assign such channel
with a weight of 1 instead of 0 to make sure it can be sampled.
Pull Request: https://projects.blender.org/blender/blender/pulls/131741
The `ProjectionTransform` object has no trivial copy-assignment constructor.
This results in the following warning on `gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0`:
```
/.../blender-git/blender/intern/cycles/kernel/../util/projection.h: In function ‘ccl::ProjectionTransform ccl::projection_inverse(ProjectionTransform)’:
/.../blender-git/blender/intern/cycles/kernel/../util/projection.h:219:9: warning: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type ‘ccl::ProjectionTransform’ {aka ‘struct ccl::ProjectionTransform’} with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
219 | memcpy(&tfmR, R, sizeof(R));
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~
/.../blender-git/blender/intern/cycles/kernel/../util/projection.h:67:16: note: ‘ccl::ProjectionTransform’ {aka ‘struct ccl::ProjectionTransform’} declared here
67 | typedef struct ProjectionTransform {
| ^~~~~~~~~~~~~~~~~~~
```
To fix the warning, cast the pointer to `(void *)`.
Pull Request: https://projects.blender.org/blender/blender/pulls/130321
All the OSL matrix functions had been implemented using the
`Transform` utility of Cycles, but that's built around a 4x3 matrix,
when the OSL matrix functions are working with 4x4 matrices.
This resulted in them not producing results consistent with the
CPU implementation.
This fixes that by making use of the `ProjectionTransform` utility
of Cycles instead, because it's built around a 4x4 matrix. Since
matrix inversion is required, I had to make a few more utility
functions available on the GPU (except Metal, due to use of
references/pointers without specification) that were previously
CPU-only.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/110102
This probably should always have been the value used, really.
Now, instead of reporting `Qualcomm Technologies Inc`, it reports the more informative `Snapdragon(R) X Elite - X1E78100 - Qualcomm(R) Oryon(TM) CPU` on a Thinkpad T14s Gen6 device.
Pull Request: https://projects.blender.org/blender/blender/pulls/128808
- Deduplicate Fisheye projection code
- Replace spherical/cartesian conversions with shared helpers
- Replace transforms from/to local coordinate systems with shared helpers
The main type of repeated transform that's not covered here is `to/from_coords`, but with separate values for xy and z (e.g. BSDFs that already computed `dot(wi, N)` earlier, so they only need `dot(wi, X)` and `dot(wi, Y)` later). Could also be replaced, but it would feel weirdly specific for a helper function.
Pull Request: https://projects.blender.org/blender/blender/pulls/125999
Previously, Cycles only supported the Henyey-Greenstein phase function for volume scattering.
While HG is flexible and works for a wide range of effects, sometimes a more physically accurate
phase function may be needed for realism.
Therefore, this adds three new phase functions to the code:
Rayleigh: For particles with a size below the wavelength of light, mostly athmospheric scattering.
Fournier-Forand: For realistic underwater scattering.
Draine: Fairly specific on its own (mostly for interstellar dust), but useful for the next entry.
Mie: Approximates Mie scattering in water droplets using a mix of Draine and HG phase functions.
These phase functions can be combined using Mix nodes as usual.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/123532
`atan2(0, 0)` is undefined on many platforms. To ensure consistent
result across platforms, we return `0` in this case.
Note only the behavior of the shader node `Artan2` is changed here.
During shading, we might still produce `atan2(0, 0)` internally and
cause different results across platforms, but that usually happens with
single samples and is not obvious, plus checking this condition all the
time is costly. If later we find out it's indeed necessary to change all
the invocation of `atan2(0, 0)`, we could change the wrapper functions
in `metal/compat.h` and `mtl_shader_defines.msl`.
Pull Request: https://projects.blender.org/blender/blender/pulls/126951
Align Cycles SVM and EEVEE's rendering of the vector math node
in reflect mode with OSL when the normal vector is 0,0,0.
This is done by using safe_normalize rather than normalize on the
normal vector. Which also fixes a NaN in the reflect mode in this
specific configuration.
Pull Request: https://projects.blender.org/blender/blender/pulls/125688
The function direction_to_fisheye_lens_polynomial computes the inverse of
fisheye_lens_polynomial_to_direction.
Previously the function worked almost correctly if all parameters except k_0
and k_1 were zero (in that case it was correct except for flipping the x-axis).
I replaced the fixed-point iteration (?) by Newton's method and implemented a
test to make sure it works correctly with a wider range of parameter sets.
Pull Request: https://projects.blender.org/blender/blender/pulls/123737
