Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
The previous formula for adjusting Coat Tint intensity resulted
in strong tints and sudden colour changes when using a low coat weight.
This commit fixes these issues by mixing between a white tint (no tint)
and the chosen tint based on the Coat Weight.
Pull Request: https://projects.blender.org/blender/blender/pulls/113468
Tested with IBUS on GNOME 45.
Added a capabilities flag to GHOST since support for IME works on
Wayland but not on X11, so runtime detection is needed.
The increased amount of BSDF code from Principled BSDF v2 and the
microfacet BSDF led to a big performance regression on Metal and AMD.
We have not been able to find a good workaround for all scenes.
This change disables the Principled Hair BSDF code when it is not used
in the scene. This makes common benchmark scenes faster, but
performance is still bad in scenes that do use it.
Ref #112596
Pull Request: https://projects.blender.org/blender/blender/pulls/113904
This was a regression after the sphere light changes, where the normal
now is the normal along the geometry of the light and no longer suitable
for the IES texture direction.
This not only fixes point lights with non-zero radius, but makes the IES
texture direction work consistently across light types and meshes,
always rotated by the object transform.
The USE_LIBDECOR_FRACTIONAL_SCALE_HACK worked on my system but made
window size issues worse in older versions of GNOME, see: #109194.
Replace the hack with logic to set the window size using frational
scaling information from the output.
When fractional scaling is used, window sizes from LIBDECOR are still
divided by the window-decorations internal buffer scale which doesn't
match the GHOST window (always 1 in the case of fractional scale).
Also resolve glitches caused by recalculating the window size when
no size change was intended. In this case reuse LIBDECOR's internal
size so there are never any changes (caused by rounding for e.g.).
When the window manager set the window size, there were no checks
the size is a multiple of the buffer scale (a requirement for Wayland).
This meant setting the window size could exit Blender without warning
if an invalid window size was set.
When fractional scaling was used with libdecor the window decorations
would not match the window size on startup, drawing small and on top
of Blender's window.
While there are still glitches with fractional-scaling & libdecor
(which doesn't support fractional scaling),
see #109194 this at least resolves one of the worst issues.
When a new window is created the final buffer scale isn't known
so setting the buffer scale assuming the final state was just a guess
and only had the minor advantage of preventing rounding the window size
on startup.
Removing this to resolve a bug with LIBDECOR & fractional scaling
relating to #109194 (will commit separately).
When running Blender inside renderdoc an extension can be used to print
from any shader stage to the console. This is useful during developing,
but not so during running/triaging. For now we remove the extension to
not confuse by incorrect error messages.
Pull Request: https://projects.blender.org/blender/blender/pulls/113654
This PR adds workarounds for platforms that don't support `shaderOutputLayer`
or `shaderOutputViewportIndex`. Some NVIDIA laptop GPUs and ARM GPUs don't
have those device features.
The workaround uses the same approach as OpenGL. A geometry shader is injected
to emulate the feature.
For testing the workarounds they have also been connected to the
`--debug-gpu-force-workarounds` command line argument.
Fixes#113475 by implementing #113529
Pull Request: https://projects.blender.org/blender/blender/pulls/113605
Windows mouse warping bounds margin needs to be different when not
GHOST_kGrabHide, or else the visible wrapping occurs within the
area at an odd location. Making it 2, like it used to be.
