Overall, this commit reworks the component layering in the Principled BSDF
in order to ensure that energy is preserved and conserved.
This includes:
- Implementing support for the OSL `layer()` function
- Implementing albedo estimation for some of the closures for layering purposes
- The specular layer that the Principled BSDF uses has a proper tabulated
albedo lookup, the others are still approximations
- Removing the custom "Principled Diffuse" and replacing it with the classic
lambertian Diffuse, since the layering logic takes care of energy now
- Making the merallic component independent of the IOR
Note that this changes the look of the Principled BSDF noticeably in some
cases, but that's needed, since the cases where it looks different are the
ones that strongly violate energy conservation (mostly grazing reflections
with strong Specular).
Pull Request: https://projects.blender.org/blender/blender/pulls/110864
Instead of storing the backtrace in all memory blocks, and trying to get
meaningful info out of this list of pointers when printing leaked ones,
just use `__asan_describe_address` when ASAN is enabled.
This also work on Windows, in addition to linux and (presumably) OSX,
but does require to build with ASAN enabled.
The previous code was not working very well anymore, for some reason the
call to `backtrace_symbols` seems to fail to give any meaningful
information nowadays on most of Blender code. And it was only
implemented for linux and OSX.
Based on an idea from @LazyDodo, many thanks!
Pull Request: https://projects.blender.org/blender/blender/pulls/111006
The fact that the guarded-allocated memory blocks are all linked to the
static `membase` listbase is enough for LSAN to not detect them as
leaks.
So this commit adds a new (private) callback to clear the memlist, which
is only used in the destructor of the `MemLeakDetector` class.
Many thanks to @Sergey for identifying the root issue here.
Pull Request: https://projects.blender.org/blender/blender/pulls/110995
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag
resulted in over long lines & visual noise. Replace with a function that
takes multiple (cache_var flag) pairs to reduce duplication.
Make it so transform between color spaces which is a no-op does not
peroform any calculations.
This was initially found when working on #110941, but the issue can
be replicated easily by renaming "Linear" to "Linear Rec.709" and
adding alias as "Linear".
Doing so would result in a failure of the compositor_matte_test.
The reason for that is due to the image data-block still referring
to the "Linear" color space, the name-based comparison not detecting
that "Linear" and "Linear Rec.709" are the same spaces, and that the
cryptomatte requires bit-perfect floating point values.
Pull Request: https://projects.blender.org/blender/blender/pulls/110959
Add a High Dynamic Range option in the Color Management > Display panel.
This enables display of extended color ranges above 1.0 for the 3D
viewport, image editor and render previews.
This requires a monitor that can display HDR colors, and a view
transform designed for HDR output. The Standard view transform works,
but Filmic does not as it was designed to bring values into the 0..1
range for SDR displays.
This patch is limited to allowing the display to visualize extended
colors, but does not include future looking work to better integrate HDR
into the full workflow.
It is implemented by rendering to high bit-depth texture formats for
the user interface, and uncapping the color range in color management.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/105662
This add the possibility to define different
viewports inside a single framebuffer and
let the vertex shader decide which viewport
to render to.
This only contain the GL and VK implementation.
The Vulkan implementation works but still
has a validation error related to shader features
and extension. The test passes nonetheless.
Pull Request: https://projects.blender.org/blender/blender/pulls/110923
Both the `Math` node and the `Vector Math` currently only explicitly
support modulo using truncated division which is oftentimes not the
type of modulo desired as it behaves differently for negative numbers
and positive numbers.
Floored Modulo can be created by either using the `Wrap` operation or
a combination of multiple `Math` nodes. However both methods obfuscate
the actual intend of the artist and the math operation that is actually
used.
This patch adds modulo using floored division to the scalar `Math` node,
explicitly stating the intended math operation and renames the already
existing `"Modulo"` operation to `"Truncated Modulo"` to avoid confusion.
Only the ui name is changed, so this should not break compatibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/110728
The current core was only detecting sRGB transform when it is defined
as sRGB->Linear using srgb.spi1d. If it is defined as an inverse of
Linear->sRGB using srgb_inv.spi1d, or as an analytical formula using
ExponentWithLinearTransform then the code did not detect the color
as sRGB on anything by Apple Silicon platform.
The naming of the checks could be improved to make it more clear that
the check is only used to allow lossless access to 8bit sRGB textures.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110889
This pull request covers up a subtle difference between the CPU and GPU
when rendering with a light tree. Specifically a case where the user
has a sun light with a small angle.
The difference was caused by the dot() function being different between
CPU and GPU backends, with the GPU showing more meaningful
floating-point precision losses when working with small suns.
Pull Request: https://projects.blender.org/blender/blender/pulls/110307
The issue was an out-of-bounds read access when checking whether
the world volume emission needs to be accumulated.
Solution is to check for this case. Done in the generic place, so
that the shade_volume kernel is more readable and no branching
added there, and there is no impact on scenes without the light
linking.
Assume that the world emissive volume belongs to the default light
linking group, as there is no way to link it explicitly to anything.
Pull Request: https://projects.blender.org/blender/blender/pulls/110733
This replaces the Sheen model used in the Principled BSDF with the
model from #108869 that is already used in the Sheen BSDF now.
The three notable differences are:
- At full intensity (Sheen = 1.0), the new model is significantly
stronger than the old one. For existing files, the intensity is
adjusted to keep the overall look similar.
- The Sheen Tint input is now a color input, instead of the
previous blend factor between white and the base color.
- There is now a Sheen roughness control, which can be used to
tweak the look between velvet-like and dust-like.
Pull Request: https://projects.blender.org/blender/blender/pulls/109949
MSVC_VER 1937 included 17.7 preview 1 and 2 that didn't support the flag
while developers may be using these versions already because of the
issues with 17.6. We now check for preview 3 specifically.
Starting with MSVC 17.7 preview 3, /jumptablerdata is available and
allows to ensure switch tables don't get mixed with the code, helping on
performance when there is contention in a large switch statement, such
as in svm.h.
Pull Request: https://projects.blender.org/blender/blender/pulls/110470
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
<algorithm> header include is missing from some sycl headers, this will
be fixed upstream with https://github.com/intel/llvm/pull/10424,
meanwhile, we work around it by including it directly.
