Resolves custom attribute types for ints and booleans by ensuring
conversion mode is correct. Previously, the attribute declarations
were assumed to be linear. However, patch ensures the correct
attribute index is now fetched, ensuring the conversion mode
is correctly specified for non-linear attribute ID's.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/119569
If a bone was specified (but now missing), the driver would fallback to
using the object as a target (which can lead to unintended behavior).
So now check if a bone is specified, if it is missing, mark the driver
invalid. If no bone is specified at all, then use the armature object as
the target.
NOTE: `DTAR_FLAG_INVALID` is not granular enough to distinguish the
object and bone targets, so both will be marked in red in the UI (there
is already comments about it in code). If necessary, we could introduce
an additional DTAR_FLAG_BONE_INVALID and use that in a couple of places.
Pull Request: https://projects.blender.org/blender/blender/pulls/119533
A tone mapper designed specifically for PBR color accuracy, to get sRGB
colors in the output render that match as faithfully as possible the input
sRGB baseColor under gray-scale lighting. This is aimed toward product
photography use cases, where the scene is well-exposed and HDR color values
are mostly restricted to small specular highlights.
Fixes#118824: Proposal: add a view transform for Khronos PBR Neutral Tone Mapper
Co-authored-by: Emmett Lalish <elalish@google.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/118936
This makes it so GPv3 objects are rendered using the current grease pencil render engine.
A new `gpencil_next` engine was added at the beginning of the project, but it couldn't
be finished in time. This commit removes the `gpencil_next` engine as it is no longer
used. The current status of the new engine been pushed to the `gpencil-next` branch on
the `blender` repository.
Note: Onion skinning is not supported yet. This work will be done in a separate PR.
Fixes#115467 and #116347.
Pull Request: https://projects.blender.org/blender/blender/pulls/118664
The `IndexMask` data structure was designed to allow us to implement set
operations like `union`, `intersection` and `difference` efficiently
(2cfcb8b0b805401a0ffb252fd41750fadb0392ab). This patch adds an evaluator for
arbitrary expressions involving the mentioned operations. The evaluator makes
use of the design of the `IndexMask` data structure to be quite efficient.
In some common cases, the evaluator runs in constant time. So it's very fast
even if the mask contains many millions of indices. If possible the evaluator
works on entire segments at once instead of looking at the individual indices.
This results in a very low constant factor even if the evaluation time is
linear. If the evaluator has to look at the individual indices to be able to
perform the operation, it can make use of multi-threading.
The evaluation consists of the following steps:
1. A coarse evaluation that looks at entire segments at once.
2. All segments that couldn't be fully evaluated by the coarse evaluation are
evaluated exactly by looking at the actual indices. There are two evaluators
for this case. One that is based on `std::set_union` etc. The other one first
converts the index masks to bit spans, then does bit operations to evaluate
the expression, and then converts the bits back into indices. Depending on
the expression, one or the other can be more efficient.
3. Construct an index mask from the evaluated segments.
Showing the performance of the evaluator is kind of difficult because it highly
depends on the input data. Comparing the performance to something that does not
short-circuit when there are full ranges is meaningless, because one can
construct an example where the new evaluator is arbitrarily faster. I'm still
working on a case where performance can be compared to e.g. using
`std::set_union`. This comparison is only fair when the input data when
constructing a case where the new evaluator can't short-circuit.
One of the main remaining bottlenecks are the calls to `slice_content` on large
index masks. I think the impact of those can still be reduced.
We are not using this evaluator much yet, except through `IndexMask::complement`
calls. I intend to use it when I get to refactoring the field evaluator for
geometry nodes to optimize the evaluation of selections.
Pull Request: https://projects.blender.org/blender/blender/pulls/117805
Resolves render pass export for EEVEE Next on Metal.
Reads from texture views was previously utilising the
root texture rather than the view variant, resulting
in views into texture arrays being incorrectly sampled.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/119563
The buttons to sync and update individual repositories only work for
remote repositories. This PR just updates their poll functions to
disable them for local repos.
Pull Request: https://projects.blender.org/blender/blender/pulls/119568
Experimental flag for "Extensions Development Utilities" that can be
enabled separately from "Extensions". Note this PR does not enable the
use of this flag (coming later) as uses are in addons-contrib. This
flag is requested in #119521
Pull Request: https://projects.blender.org/blender/blender/pulls/119562
This affect all local lights (non-sun light).
We hide the artifact caused by different tracing results from
two adjacent projection. This is visible as the shading point
switches projections.
We fix this by randomizing which shadow map projection (face)
to trace. We do that by using the point at half the ray instead
of the shading point to choose the projection. This gives
a soft enough look proportional to the light shape.
This also has the benefit of being stupidly simple.
Pull Request: https://projects.blender.org/blender/blender/pulls/119555
This reverts commit c6497dd9f7632db2035b3c265000c22b8e1b56ed.
This wasn't working the way I expected, it seems the LIB_TAG_NEW isn't
set here. Better to address the fundamental issues anyway. Sorry for
the noise.
For small confirmations that appear at mouse position, change the
position slightly so that the mouse pointer is less likely to obscure
the confirm button text.
Pull Request: https://projects.blender.org/blender/blender/pulls/119536
When appending objects from an older file, versioning needs to run to add
an auto smooth modifier if necessary. However, this was running for all
objects rather than just the newly appended objects. It's quite wrong to
modify existing objects here, so add an explicit check for that. This could
improve performance as well, but skipping checks for objects when
the work is unnecessary.
The crash will hopefully be resolved by other improvements to the auto
smooth versioning (making it properly idempotent and running it again
should fix the problem with the hidden legacy flags still set). But I still think
this PR is worth committing, to be very explicit about only modifying new
objects in versioning code.
Pull Request: https://projects.blender.org/blender/blender/pulls/119467
which resulted in bias when self intersection is excluded in forward scattering.
Below is a comparison using principled BSDF with emission. NEE and MIS were much brighter.
Pull Request: https://projects.blender.org/blender/blender/pulls/119440
Ref: #118534
turns out `in_volume_segment` does need to be checked. If the ray origin
lies on the wrong side of the mesh light, part of the ray could still be
lit by the other side, so the sample should not be considered invalid.
Pull Request: https://projects.blender.org/blender/blender/pulls/119529
Previously I misunderstood the subsurf modifier's handling of custom
normals. The "use custom normals" check in 4.0 checked if there were
custom normals and whether the auto smooth flag was checked. I wrongly
changed that to check the mesh normals domain instead of whether there
was custom normals. In 4.1, auto smooth isn't required to use custom
normals, but that should be the only change here.
In this PR, that change is done for CPU and GPU subdivision, and for
the versioning which adds a modifier. The versioning now only puts the
new modifier before the subsurf modifier if it would have used the
custom normals interpolation in 4.0.
The last change causes two test failures which I also misunderstood
before. The previous results were arguably incorrect, because the
Cycles experimental adaptive subdivision ignored the auto smooth
angle, which was 5 degrees. It should have been 180 degrees.
I will modify those test files to remove auto smooth from the meshes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119485
When using mixed resolution rendering with an orthographic projection
the display was not correct. The reason was that the view boundaries
were decomposed from the winmat correctly, but when re-composing
the matrix it assumed to be in perspective.
This is fixed by composing an orthographic winmat when it was sourced
from a orthographic winmat.
Fixes#119514
Pull Request: https://projects.blender.org/blender/blender/pulls/119517
On some GPUs/drivers (seemingly nvidia) and screen sizes, VSE
vectorscope and sometimes waveform have "garbage" artifacts around
them.
Root cause unknown (driver bug?), for now similar fix as a while ago
in #112665: explicitly draw opaque background (with alpha=1), and then
use alpha blending for the scopes texture display on top of that.
Pull Request: https://projects.blender.org/blender/blender/pulls/119512
An alternative fix would be calling `update_on_change_` in the
attribute `try_create`function, but sticking with this more
conservative fix seems better for 4.1.
Pull Request: https://projects.blender.org/blender/blender/pulls/119515
This is a regression since d579ac2b3f
Ensure that the image buffers used by render passes have metadata at the
end of render, similarly to how stamping happens. This solves the reported
issue, and makes the metadata behave consistently, independent on how the
image buffer is accessed.
Thanks Philipp Oeser for investigation and pin-pointing the bad commit!
Pull Request: https://projects.blender.org/blender/blender/pulls/119503
Since 4a78d7dc4c9b blending is turned ON, but apparently the background
color is not receiving full alpha in this scenario.
Resolve by using immUniformThemeColorAlpha (with 1.0 alpha)
Pull Request: https://projects.blender.org/blender/blender/pulls/119504
