The original names were `...update_position()`, but no update in
position is performed in these functions, rather, the entries in
`LightSample` are updated. Also make clear that the functions are used
by MNEE.
Windows file associations using ProgID, needed because of the launcher.
This fixes "pin to taskbar" and Recent Documents lists, allow per-
version jump lists and an "Open with" list with multiple versions.
Pull Request: https://projects.blender.org/blender/blender/pulls/107013
This patch fixes an undefined behaviour where we were trying to use linked functions with binary archives. This isn't supported yet. At best this will fail silently, but this is not guaranteed in future. To fix this we simply disable binary archives if any linked functions are involved. The impact of this is that the `SHADE_SURFACE_RAYTRACE` and `SHADE_SURFACE_MNEE` kernels will fall back to the file system cache when MetalRT is enabled. The file system cache will occasionally be purged due to factors beyond Blender's control.
Pull Request: https://projects.blender.org/blender/blender/pulls/108176
In previous implementation the first available render surface was
selected. For NVIDIA platform this was the correct one, but for
AMD and Intel GPUs this was incorrect. This PR goes over all the
available render surfaces and selects a compatible one.
For now when no compatible render surface is found it will still select
the first available one. With the expectation that the screen is drawn
incorrectly and users would report a bug so we can investigate.
Pull Request: https://projects.blender.org/blender/blender/pulls/108169
Covers the macro ARRAY_SIZE() and STRNCPY.
The problem this change is aimed to solve it to provide cross-platform
compiler-independent safe way pf ensuring that the functions are used
correctly.
The type safety was only ensured for GCC and only for C. The C++
language and Clang compiler would not have detected issues of passing
bare pointer to neither of those macros.
Now the STRNCPY() will only accept a bounded array as the destination
argument, on any compiler.
The ARRAY_SIZE as well, but there are a bit more complications to it
in terms of transparency of the change.
In one place the ARRAY_SIZE was used on float3 type. This worked in the
old code because the type implements subscript operator, and the type
consists of 3 floats. One would argue this is somewhat hidden/implicit
behavior, which better be avoided. So an in-lined value of 3 is used now
there.
Another place is the ARRAY_SIZE used to define a bounded array of the
size which matches bounded array which is a member of a struct. While
the ARRAY_SIZE provides proper size in this case, the compiler does not
believe that the value is known at compile time and errors out with a
message that construction of variable-size arrays is not supported.
Solved by converting the field to std::array<> and adding dedicated
utility to get size of std::array at compile time. There might be a
better way of achieving the same result, or maybe the approach is
fine and just need to find a better place for such utility.
Surely, more macro from the BLI_string.h can be covered with the C++
inlined functions, but need to start somewhere.
There are also quite some changes to ensure the C linkage is not
enforced by code which includes the headers.
Pull Request: https://projects.blender.org/blender/blender/pulls/108041
Only Embree CPU BVH was built in the multi-device case. However, one
Embree GPU BVH is needed per GPU, so we now reuse the same logic as in
the other backends.
Pull Request: https://projects.blender.org/blender/blender/pulls/107992
Hardware Raytracing wasn't properly disabled or enabled in the
subdevices of the multi-device.
This construct:
foreach ( DeviceInfo &info,
(device.multi_devices.size() != 0 ?
device.multi_devices : vector<DeviceInfo>({device}))
)
was a nice trap - it was giving a copy to iterate on.
Pull Request: https://projects.blender.org/blender/blender/pulls/107989
xdg_surface_ack_configure must run once the events have been handled
which is not the case configure runs from the event handling thread.
In practice this could lead to glitches resizing windows, although some
flickering on startup remains on KDE which would be good to resolve.
Exiting with multiple overlapping windows (a file selector for e.g.)
reliably crashes.
Closing the windows on exit caused the the keyboard enter handler to be
called with a NULL window surface (wl_surface).
While this doesn't look to be documented anywhere, SDL's code-comments
note this happens when windows have just been closed.
GTK also check surfaces for NULL.
Used to be https://archive.blender.org/developer/D17123.
Internally these are already using the same code path anyways, there's no point in maintaining two distinct nodes.
The obvious approach would be to add Anisotropy controls to the Glossy BSDF node and remove the Anisotropic BSDF node. However, that would break forward compability, since older Blender versions don't know how to handle the Anisotropy input on the Glossy BSDF node.
Therefore, this commit technically removes the Glossy BSDF node, uses versioning to replace them with an Anisotropic BSDF node, and renames that node to "Glossy BSDF".
That way, when you open a new file in an older version, all the nodes show up as Anisotropic BSDF nodes and render correctly.
This is a bit ugly internally since we need to preserve the old `idname` which now no longer matches the UI name, but that's not too bad.
Also removes the "Sharp" distribution option and replaces it with GGX, sets Roughness to zero and disconnects any input to the Roughness socket.
Pull Request: https://projects.blender.org/blender/blender/pulls/104445
The goal is to make it more explicit and centralized operation to
assign and steal buffer data, with proper ownership tracking.
The buffers and ownership flags are wrapped into their dedicated
structures now.
There should be no functional changes currently, it is a preparation
for allowing implicit sharing of the ImBuf buffers. Additionally, in
the future it is possible to more buffer-specific information (such
as color space) next to the buffer data itself. It is also possible
to clean up the allocation flags (IB_rect, ...) to give them more
clear naming and not have stored in the ImBuf->flags as they are only
needed for allocation.
The most dangerous part of this change is the change of byte buffer
data from `int*` to `uint8_t*`. In a lot of cases the byte buffer was
cast to `uchar*`, so those casts are now gone. But some code is
operating on `int*` so now there are casts in there. In practice this
should be fine, since we only support 64bit platforms, so allocations
are aligned. The real things to watch out for here is the fact that
allocation and offsetting from the byte buffer now need an explicit 4
channel multiplier.
Once everything is C++ it will be possible to simplify public
functions even further.
Pull Request: https://projects.blender.org/blender/blender/pulls/107609
Only make libdecor a hard-requirement for using Wayland in gnome-shell
when X11 is available, as it's possible to disable Xwayland.
This also fixes window-borders not being used in gnome-shell when
WITH_GHOST_X11 is off.
Now it's possible to test Blender under gnome without libdecor by
uninstalling libdecor & running with DISPLAY environment variable
set to an empty string - useful for troubleshooting issues which
could be caused by libdecor.
NanoVDB headers have unused code using "double" type, which is not supported on Arc GPUs.
Recent DPC++ changes enforced runtime verifications:
7663dc201d
which prevents execution when such type has been present even if unused.
This is a solution to avoid double to be compiled at all, similar as how it is done for Metal.
