area light with zero spread was introduced in bf18032977. Such paths can
only be sampled with NEE, so MIS should not be used.
This fixes the discrepancy when Direct Light Sampling is set to MIS or NEE.
Pull Request: #118584
if emission sampling is not set, we do not use MIS weight when sampling
from the BSDF, but we were still drawing samples from the light,
resulting in double contribution.
Pull Request: https://projects.blender.org/blender/blender/pulls/118534
This `operator new` added in ecc3e78d787cce8a3f202e7de26575e2d47baea2
are only called if the alignment is greater than `__STDCPP_DEFAULT_NEW_ALIGNMENT__`.
This is generally 8 or 16 depending on the platform. `MEM_mallocN` does
guarantee 16 byte alignment currently (in fact it's usually not 16 byte aligned
because of `MemHead`). Now `MEM_mallocN_aligned` is used with the default
alignment, even if we don't know that the type does not require it.
An alternative would be to pass the alignment to `MEM_CXX_CLASS_ALLOC_FUNCS`,
but that would be more intrusive.
Pull Request: https://projects.blender.org/blender/blender/pulls/118568
Register the last held key when activating a window
(not only modifiers keys) under Wayland.
This resolves a bug where holding the D-key and clicking on a window
wouldn't activate grease pencil drawing.
Previously, the alignment of structs that use `MEM_CXX_CLASS_ALLOC_FUNCS`
were not taken into account when doing the allocation. This can cause some data
to be mis-aligned and leads to crashes when cpu instructions or code expect the
data to be aligned.
The fix is to provide an overload of `operator new` that accepts the alignment as parameter.
More info: https://en.cppreference.com/w/cpp/language/new (search for `align_val_t`).
Pull Request: https://projects.blender.org/blender/blender/pulls/118526
My misreading of the Microsoft BITMAPV5HEADER specification causes a
shift of three pixels when transferring between applications using this
format. This does not occur when moving within or between Blender
instances. This PR just removes the incorrect 12-byte offset. Note
that many applications prefer PNG transfers over DibV5 so testing this
might be non-obvious.
Pull Request: https://projects.blender.org/blender/blender/pulls/118417
The size of the string in bytes happened to match the the pointer size
on 64bit systems, nevertheless the logic was wrong would would fail on
32bit systems. Also use a character to search the string instead of a
single character string.
These are now included in the OSL shared libraries, so no reason to
link against it.
The CMake code for WITH_LLVM remains in case it is useful in the future,
but is not enabled by any Blender feature now.
Pull Request: https://projects.blender.org/blender/blender/pulls/118229
Turns out we were not building OSL with OptiX enabled anymore.
Also check now if the OSL builds has OptiX support and if not
disable it in Cycles.
Building OSL with support for this (still) does not require
either the OptiX SDK or CUDA, it only needs LLVM.
Pull Request: https://projects.blender.org/blender/blender/pulls/118234
Currently the multi-input sockets are not exposed to the custom nodes
Python API. This makes some features cumbersome to implement if one
wants a node to process an arbitrary number of inputs.
One workaround is to make inputs duplicate themselves when a link is
created, but a proper multi-input would be easier to use for both
add-on developers and users.
This commit exposes a new `use_multi_input` boolean parameter when
creating a new node socket. This makes it possible to declare a
multi-input, while still leaving the existing `is_multi_input`
property read-only so that existing nodes cannot be made unstable.
The parameter is optional so existing scripts stay compatible. It also
raises an error when used on output sockets, since it makes no sense
for those to be multi-input.
The Custom Node Tree Python template was updated to reflect this
change by making one of the inputs of the custom node multi-input.
Pull Request: https://projects.blender.org/blender/blender/pulls/114474
This commit updates all defines, compiler flags and cleans up some code for unused CPU capabilities.
There should be no functional change, unless it's run on a CPU that supports sse41 but not sse42. It will fallback to the SSE2 kernel in this case.
In preparation for the new SSE4.2 minimum in Blender 4.2.
Pull Request: https://projects.blender.org/blender/blender/pulls/118043
This feature is useful for many production scenarios as it allows for the
creation of separate render passes with specific worlds. This would help
workflows that require different skies or other backgrounds for compositing.
Ref #117919
Pull Request: https://projects.blender.org/blender/blender/pulls/117920
Merge duplicated motion blur settings between Cycles and EEVEE,
and move them to `RenderData`/`scene.render`:
* `scene.cycles.motion_blur_position` -> `scene.render.motion_blur_position`
* `scene.eevee.use_motion_blur` -> `scene.render.user_motion_blur`
* `scene.eevee.motion_blur_position` -> `scene.render.motion_blur_position`
* `scene.eevee.motion_blur_shutter` -> `scene.render.motion_blur_shutter`
On the C/C++ side, this also renames `RenderData::blurfac` to
`RenderData::motion_blur_shutter`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117913
This isn't necessary and has been removed from macOS & X11,
Wayland never did this.
Besides removing the offset GetTickCount() has been replaced by
GetTickCount64 to prevent 32bit rollover when high resolution timers
aren't supported.
Ref !117618
Add new "Soft Falloff" option on point and spot light that uses
the old light behavior from Blender versions before 4.0. Blend
files saved with those older versions will use the option.
This option is enabled by default on new lights.
Fix#114241
Co-authored-by: Weizhen Huang <weizhen@blender.org>
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/117832
