Previously with adaptive subdivision this happened to work with the N
attribute, but that was not meant to be undisplaced. This adds a new
undisplaced_N attribute specifically for this purpose.
For backwards compatibility in Blender 4.5, this also keeps N undisplaced.
But that will be changed in 5.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/142090
This commit renames the GHOST Metal graphic context class and related
files / references from `GHOST_ContextCGL` to `GHOST_ContextMTL`. When
the Metal backend was first introduced, this context file contained
both the old OpenGL context (CGL, for macOS Core OpenGL API), and the
newer Metal context. Since #110185 all CGL related code was removed
from the class, making it Metal only, and thus rendering the old class
name outdated and potentially misleading. In addition to the rename,
unused OpenGL related forward declarations and old TODOs were also
removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/142519
Currently MetalRT renders always use extended limits, which is needed to correctly render scenes where the max primitive count can exceed 2^28 or the instance count can exceed 2^24. This patch adopts Metal best practices of only enabling this flag if it is needed.
This PR is similar to #133364, but there are some notable differences:
1) The old PR made an overly optimistic assumption that all the relevant visibility bits could be squeezed into 8 bits. This new PR adopts the same approach that Optix takes of using 8 bits as a primary HW filter, and checking the full 32 bit mask inside the SW intersection handler.
~~2) I moved the scene scanning check from Scene into MetalDevice. This avoids platform specific details leaking into platform agnostic areas.~~
~~3) In live viewport mode, we always use extended limits in case we tip over the threshold.~~
_EDIT:_
2) The limits are scanned in `Scene::update_kernel_features`, and given to the device by a new `set_bvh_limits` method which returns true if the BVH and kernels need to be reloaded.
Pull Request: https://projects.blender.org/blender/blender/pulls/142401
When `delta` is significantly larger than the difference between `tmin`
and `tmax`, the precision of `theta_a` and `theta_b` reduces, resulting
in banding artefacts.
For equiangular sampling, we use uniform sampling to fix this case.
For light tree, we use the equality
atan(a) + atan(b) = atan2(a + b, 1 - a*b).
Pull Request: https://projects.blender.org/blender/blender/pulls/142845
Use Principled BSDF instead of Diffuse BSDF. This is a breaking change but
likely does not affect many scenes significantly. It adds some specularity
when an object does not have a a material assigned.
Fix#142538
Pull Request: https://projects.blender.org/blender/blender/pulls/142703
This PR allows blender to be compiled with OpenXR, but without
OpenGL support.
For investigating a bug we needed to compile Blender without
OpenGL (`WITH_OPENGL_BACKEND=OFF`) but it would fail to
compile OpenXR (`WITH_XR_OPENXR=ON`). This PR tweakes
the preprocess directives to compile the openxr graphics
binding without OpenGL.
Co-authored-by: Jonas Holzman <jonas@holzman.fr>
Pull Request: https://projects.blender.org/blender/blender/pulls/141668
The code of the "oneapi_load_kernels" function before this modification
was loading kernels and compiling them, if needed, for all devices in
the associated GPU context. This makes sense for one GPU execution
scenario, as well as for execution scenario of multi identical GPU,
but in cases where Blender users have several different GPUs in
render, the previous implementation would compile all kernels
for all devices for each device, unnecessarily doing the same
work multiple times. Because of this, I am changing the
implementation so that now compilation happens only for the used
device per used device, ensuring that no unnecessary work is done.
No render performance changes are expected.
This improves the existing scene specialisation mechanism by replacing "kernel_data.kernel_features" with a function constant. It doesn't cause any additional compilation requests, but allows the backend compiler to eliminate more dead code. An additional compiler hint is provided for dead-stripping "volume_stack_enter_exit" which results in slightly faster rendering of non-volumetric scenes.
Pull Request: https://projects.blender.org/blender/blender/pulls/142235
- Cursors in wayland are expected to use pre-multiplied alpha.
Note that cursor generators create straight alpha,
pre multiplier in the wayland backend.
- Invert cursor colors on Wayland since dark cursors are often default,
this could use dark theme settings in the future.
Support showing vector cursors at the appropriate size based on each
monitors DPI.
This solves incorrectly sized cursors with Hi-DPI outputs as well as
supporting outputs with different DPI's.
Instead of passing pixel data, pass an object that can generate cursors,
GHOST/Wayland can then ensure the correct size is used based on the
display the cursor is shown on.
While may sound overly complicated it actually simplifies displaying
cursors on Wayland, especially for multiple monitors at different DPI's.
Showing cursors at higher or lower resolutions than the monitor's DPI
also behaves differently on GNOME & Plasma, resulting in situations
where the cursor would show larger/smaller than expected.
Details:
- Take advantage of the recently added SVG cursors & BLF time cursor
!140990 & !141367.
- Setting bitmap cursors via GHOST_SetCustomCursorShape is now a no-op
for Wayland since it's no longer used. This was supported in an
earlier version of this PR and could be restored if needed.
- While fractional scaling works it relies on the compositor downscaling
the cursors. Ideally they would be rendered at the target size but
this isn't a priority as the difference isn't noticeable.
Ref !141597
When having a checkbox and a value both in one row together with an
animation decorator it is questionable whether the decorator should act
on animating the checkbox or the corresponding value.
We had similar cases before (e.g. 7c04ef210e)
In this case as well, one would think it is more desirable to animate
the actual Temperature **value** (instead of the checkbox), so this is
what this PR does.
Pull Request: https://projects.blender.org/blender/blender/pulls/142192
Cycles automatically tries to decide if the camera ray should be a
surface or a volume + surface camera ray by checking to see if the
scene contains a volumetric material, and if it does, is it near
where the camera rays are expected to spawn. This step is done
during scene intialization.
With the OSL camera, it is impratical to predict where the
camera rays will spawn during scene intialization, which makes it
impratical to predict if the OSL camera ray will spawn near a
volumetric object. So this commit marks all OSL cameras as
"inside a volume", leading to the spawning of volume + surface camera
rays for OSL cameras while the scene contains a volumetric material.
This leads to increased render times ranging between 1% - 5% in scenes
that use a OSL camera, has a volumetric object in it, and the
volumetric object is far away from the camera. Every other scene should
see no performance impact.
Testing was done on a AMD Ryzen 9 5950X and a NVIDIA GeForce RTX 4090.
Pull Request: https://projects.blender.org/blender/blender/pulls/142036
This is not an actual solution, it falls back to a perspective camera instead
of crashing. Note full_rastertocamera exists specifically for computing raster
size for adaptive subdivision, and changing it should not affect anything else.
Pull Request: https://projects.blender.org/blender/blender/pulls/141905
These changes introduce modifications to the SYCL queue creation
in OneapiDevice::create_queue. In case several DPC++ devices are
detected by Blender and exposed through it, we are now creating
a new SYCL context for each device, which allows us to prevent
execution failures due to some known issues in the DPC++ runtime
regarding multi GPU support. As this would have some small
performance impact, few percents, it is only applied to
multi GPU configurations, while the behavior for a single
GPU configuration remains the same.
Pull Request: https://projects.blender.org/blender/blender/pulls/141834
