There were two issues here preventing the proper display of the IES
files in question.
The primary one was that these lights are actually vertical. Their
profiles actually point upwards from 90deg to 180deg but our parser was
trying hard to adjust it to start at 0deg incorrectly.
Lastly, the files in question ended with the parser in the `eof`
state - they are "missing" the final carriage return that other IES
files tend to have but other viewers don't seem to mind. Change the
`eof` check instead for a better one that will indicate if any parsing
errors occurred along the way.
Pull Request: https://projects.blender.org/blender/blender/pulls/107320
MSVC can't optimize it out and even keeps an external call to CRT
function rintf: https://godbolt.org/z/Ex9vjf8vj
It does translate to a real speedup on windows on some scenes, here are the ratios I had on my 13900K:
classroom 101.53%
junkshop 100.71%
monster 100.76%
attic 107.98%
bistro 113.00%
Pull Request: https://projects.blender.org/blender/blender/pulls/107371
Since the version v1.5.0 of sse2neon the functionality for denormals
flushing is implemented in the library. This commit makes it so the
_MM_SET_FLUSH_ZERO_MODE and _MM_SET_DENORMALS_ZERO_MODE are used from
the ss2neon if available.
This solves macro re-definition when a newer sse2neon is used.
The change is implemented in a way that both current and new sse2neon
are supported.
Updated Embree 4 library with GPU support is required for it to be
compiled - compatiblity with Embree 3 and Embree 4 without GPU support
is maintained.
Enabling hardware raytracing is an opt-in user setting for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/106266
Use raw Blender structs and mesh data rather than using the RNA API.
There isn't any benefit from using the RNA when Cycles is compiled
with Blender anyway, and a profile showed that the majority of time
was spent in Blender RNA API functions.
This gives a significant improvement in performance when ingesting
meshes. Here are some tests of the runtime of the `create_mesh`
function (in seconds):
| | Before | After |
| ------------------------- | ------ | ----- |
| Grid | 0.66 | 0.11 |
| Many realized cubes | 2.60 | 0.48 |
| Large curve to mesh setup | 4.18 | 1.14 |
Also change to resizing the arrays and filling them by index rather
than appending. This makes the parallel aspect of the logic clearer,
and makes the loops easier to parallelize in the future, and makes
it easier to have a performance benefit when an attribute like
`sharp_face` doesn't exist.
Pull Request: https://projects.blender.org/blender/blender/pulls/106275
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
This commit replaces the current Glass approach, where Glass is a virtual closure
that gets replaced with a Glossy and a Refractive closure, with a combined
closure that handles Fresnel after sampling the microfacet. That way, the Fresnel
term is more accurate since it accounts for the microfacet normal, not the
shading normal.
Also updates the BSDF sampling to use a 3D sampler now, since we need two
dimensions to pick the microfacet normal and then a third dimension to pick
reflection/refraction. This can also be used to get rid of the LCG in the
Principled Hair BSDF, which means we can remove it altogether once MultiGGX is
gone.
Also, "sharp" is now supported as a microfacet distribution in OSL, and 2
is supported as the "refract" argument to microfacet() in order to get glass.
To improve mesh upload speeds and reduce the size of the scene data which allows larger scenes to be rendered.
The meshes in Cycles are currently stored as flattened meshes, where each triangle is stored as a set of 3 vertices. Unflattening writes out the vertices in a list according to the index buffer. This uses a lot of memory and for current hardware does not provide a noticeable benefit. This change unflattens the mesh by directly using the meshes vertex and index buffers directly and skips the unflattening. This change allows for larger scenes and also a reduction in the sizes of the meshes. Further it results in a decrease the amount of time it takes to upload the data to a GPU. This is especially important for when multiple GPUs are used in a single machine.
Pull Request #105173
This patch adds two new kernels: SORT_BUCKET_PASS and SORT_WRITE_PASS. These replace PREFIX_SUM and SORTED_PATHS_ARRAY on supported devices (currently implemented on Metal, but will be trivial to enable on the other backends). The new kernels exploit sort partitioning (see D15331) by sorting each partition separately using local atomics. This can give an overall render speedup of 2-3% depending on architecture. As before, we fall back to the original non-partitioned sorting when the shader count is "too high".
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D16909
Cycles ignores the size of spot lights, therefore the illuminated area doesn't match the gizmo. This patch resolves this discrepancy.
| Before (Cycles) | After (Cycles) | Eevee
|{F14200605}|{F14200595}|{F14200600}|
This is done by scaling the ray direction by the size of the cone. The implementation of `spot_light_attenuation()` in `spot.h` matches `spot_attenuation()` in `lights_lib.glsl`.
**Test file**:
{F14200728}
Differential Revision: https://developer.blender.org/D17129
Based on "Sampling the GGX Distribution of Visible Normals" by Eric Heitz
(https://jcgt.org/published/0007/04/01/).
Also, this removes the lambdaI computation from the Beckmann sampling code and
just recomputes it below. We already need to recompute for two other cases
(GGX and clearcoat), so this makes the code more consistent.
In terms of performance, I don't expect a notable impact since the earlier
computation also was non-trivial, and while it probably was slightly more
accurate, I'd argue that being consistent between evaluation and sampling is
more important than absolute numerical accuracy anyways.
Differential Revision: https://developer.blender.org/D17100
While keeping SSE2, SSE4.1 and AVX2. This does not affect hardware support, it
only slightly reduces performance for some older CPUs.
To reduce maintenance cost and improve compile times.
Differential Revision: https://developer.blender.org/D16978
The code that computes and inverts the shutter CDF had some issues that caused
the result to be asymmetric, this tweaks it to be more robust and produce
symmetric outputs for symmetric inputs.
This adds a new mirror image extension type for shaders and
geometry nodes (next to the existing repeat, extend and clip
options).
See D16432 for a more detailed explanation of `wrap_mirror`.
This also adds a new sampler flag `GPU_SAMPLER_MIRROR_REPEAT`.
It acts as a modifier to `GPU_SAMPLER_REPEAT`, so any `REPEAT`
flag must be set for the `MIRROR` flag to have an effect.
Differential Revision: https://developer.blender.org/D16432
Compiling Cycles in Visual Studio 2022 yields the error:
C4146: unary minus operator applied to unsigned type, result still unsigned
Replacing it with explicit two's complement achieves the same result as signed
negation but avoids the error.
Differential Revision: https://developer.blender.org/D16616
It is not really used from any of the sources, including the
standalone app. Since we are moving to a more backend-independent
drawing it makes sense to remove header which was specific to
how Blender integrates Cycles into viewport.
There is probably some cleanup in CMake files is possible, but
there is some inter-dependency with USD.
Differential Revision: https://developer.blender.org/D16681
This patch adapts D14754 for the Metal backend. Kernels of the same type are already organised into subdirectories which simplifies type matching.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D16469
This patch generalizes the OSL support in Cycles to include GPU
device types and adds an implementation for that in the OptiX
device. There are some caveats still, including simplified texturing
due to lack of OIIO on the GPU and a few missing OSL intrinsics.
Note that this is incomplete and missing an update to the OSL
library before being enabled! The implementation is already
committed now to simplify further development.
Maniphest Tasks: T101222
Differential Revision: https://developer.blender.org/D15902
The distinction existed for legacy reasons, to easily port of Embree
intersection code without affecting the main vector types. However we are now
using SIMD for these types as well, so no good reason to keep the distinction.
Also more consistently pass these vector types by value in inline functions.
Previously it was partially changed for functions used by Metal to avoid having
to add address space qualifiers, simple to do it everywhere.
Also removes function declarations for vector math headers, serves no real
purpose.
Differential Revision: https://developer.blender.org/D16146
The new Xcode declares the `sprintf()` function deprecated and
suggests to sue `snprintf()` as a safer alternative.
This change actually moves away from any formatted printing and
uses inlined byte-to-hex-string conversion which is also safe
and is (unmesurably) faster.
Differential Revision: https://developer.blender.org/D16378
This fixes a 15% performance regression silently introduced by
79ab76e156 that aligned the compact
float3 on 16 bytes for oneAPI.
Current change is minimalist, there are further cleanup opportunities
such as removing packed_float3 definition for oneAPI but for some
reason, it cuts the recovered speedup in half, so we're starting with
this small fix for now.
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D16340
This was a floating point precision issue - or, to be more precise,
an issue with how Cycles split floats into the integer and fractional
parts for Perlin noise.
For coordinates below -2^24, the integer could be wrong, leading to
the fractional part being outside of 0-1 range, which breaks all sorts
of other things. 2^24 sounds like a lot, but due to how the detail
octaves work, it's not that hard to reach when combined with a large
scale.
Since this code is originally based on OSL, I checked if they changed
it in the meantime, and sure enough, there's a fix for it:
https://github.com/OpenImageIO/oiio/commit/5c9dc68391e9
So, this basically just ports over that change to Cycles.
The original code mentions being faster, but as pointed out in the
linked commit, the performance impact is actually irrelevant.
I also checked in a simple scene with eight Noise textures at
detail 15 (with >90% of render time being spent on the noise), and
the render time went from 13.06sec to 13.05sec. So, yeah, no issue.
This adds path guiding features into Cycles by integrating Intel's Open Path
Guiding Library. It can be enabled in the Sampling > Path Guiding panel in the
render properties.
This feature helps reduce noise in scenes where finding a path to light is
difficult for regular path tracing.
The current implementation supports guiding directional sampling decisions on
surfaces, when the material contains a least one diffuse component, and in
volumes with isotropic and anisotropic Henyey-Greenstein phase functions.
On surfaces, the guided sampling decision is proportional to the product of
the incident radiance and the normal-oriented cosine lobe and in volumes it
is proportional to the product of the incident radiance and the phase function.
The incident radiance field of a scene is learned and updated during rendering
after each per-frame rendering iteration/progression.
At the moment, path guiding is only supported by the CPU backend. Support for
GPU backends will be added in future versions of OpenPGL.
Ref T92571
Differential Revision: https://developer.blender.org/D15286
