On its own this change is just noise and not really worth it. The point
is to make a future diff for #122398 smaller and more legible. Also it's
semantically more consistent with the way we usually handle early
returns: the "special case" comes first, then the expected normal path
continues un-indented.
This PR updated the drawing of the playhead so that it better supports
time stretching, which separates the top from the line. This draws the
shadows as separate pieces and draws the line higher.
Pull Request: https://projects.blender.org/blender/blender/pulls/147658
We have icons that represent specific individual collections. like
Icon_Outliner_Collection for a default (uncolored) collection, and
Icon_Collection_color_x for ones with colors. For "collections" as a
general thing though we have icon_group. Sometimes we confuse the two,
for example the list of tabs to show in Properties uses a different
icon than the actual category icon. This PR fixes the complaint by
using the correct icon for each of these purposes.
Pull Request: https://projects.blender.org/blender/blender/pulls/147652
With #126307 the default collection color (not set to a specific one),
set in Icon Colors / Collection, is always white. This PR restores the
correct behavior of following the theme color (an error in the SVG
source). And does so immediately (change in property_update).
Pull Request: https://projects.blender.org/blender/blender/pulls/147651
Now every function node except for "Sample UV Surface" supports
both list and grid outputs. Any grid or list input means the output also
has that type (combinations of grids and lists aren't supported).
However note that some nodes also have inputs that are always fields
evaluated on the target geometry.
There is still plenty of room for optimization. For grids and lists, all
the outputs will be computed, and every function node is evaluated
completely separately. It would be better to build a network similar to
fields and evaluate it lazily (when topology doesn't change anyway).
Pull Request: https://projects.blender.org/blender/blender/pulls/147312
The fix in this case is to properly use the stored builtin attribute defaults
when capturing the field on the mesh. I extracted that to a function so
the code would read better with early returns.
Pull Request: https://projects.blender.org/blender/blender/pulls/147646
The geometry was copied later on when it was modified because there was still a
reference to it in the modifier. Since this uses implicit sharing, if there is
more than one reference, the data has to be copied before it can be modified.
Pull Request: https://projects.blender.org/blender/blender/pulls/147644
Code executing in parallelized context should never attempt to resync
viewlayers, this is just not safe.
So instead, explicitly call `BKE_main_view_layers_synced_ensure` and
forbid further updates before entering the multi-threaded part of
`BKE_lib_override_library_main_operations_create`.
This should make issues like #147565 less likely to happen in the
future.
`BKE_view_layer_synced_ensure` would report success and clear the 'out
of sync' flag of the viewlayer, even if the call to `BKE_layer_collection_sync`
could not actually perform the resync (e.g. because resync is forbidden
by one or more calls to `BKE_layer_collection_resync_forbid`).
While logically fairly bad, this issue did not seem to have any
practical consequences. So would rather not backport this to the 5.0 beta
branch.
This fix also reveals at least one place where the usage of
`BKE_view_layer_synced_ensure` and related is muddy and not ideal: the
Scene's `foreach_id' code. This is patched as best as possible in this
commit, but is something that will have to be properly fixed at some
point most likely.
Also add some documentation to this API - although the whole thing needs
a real reafctor at some point still, name-wise and organization-wise.
Pull Request: https://projects.blender.org/blender/blender/pulls/147635
Currently UV maps and tangents are referenced by custom data layer index
by the mesh extraction system that decides what attributes are needed on
the GPU for rendering. This system is closely tied to CustomData, and
adds a limit on 8 total UV maps on the mesh (crucially different than
a limit on the supported UV map count for rendering).
The process of detecting which attributes to upload is also directly
tied to CustomData. In particular, `mesh_cd_calc_used_gpu_layers` is
quite complicated.
This commit reimplements that function, and references used UV maps
and UV tangents by name rather than by index. The process is now mostly
separated from `CustomData`, which is important as Mesh moves to
`AttributeStorage` instead.
Overall I noticed this introduces some overhead (a few percent cost to
playback in some extreme cases). `DRW_MeshCDMask` is bigger than before
(it was just an integer), and the attribute API currently has some
overhead that can be removed when it's backed by `AttributeStorage`.
The change still feels worth it to me, given other opportunities for
optimization in this area.
Ref #122398
Pull Request: https://projects.blender.org/blender/blender/pulls/141467
When rendering in the main window and changing the active scene,
RE_FreeUnusedGPUResources can free the resources of an active Render,
since no wmWindow references the Scene anymore.
Active Render instances always reference their Scene, so we check those
directly instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/147553
Support loops at the GLSL level instead of relying on
NOD_shader_nodes_inline.
This improves compilation and runtime performance, avoids causing
recompilations on iteration count changes, and allows supporting
dynamic iteration counts.
(EEVEE-only)
Pull Request: https://projects.blender.org/blender/blender/pulls/145269
Split the result mesh generation to work into two loops. The first loop
builds topology maps used for propagating attribute values, and the next
loop mixes attribute values with those maps. This has a few benefits:
The propagation can be done in parallel, and the topology mapping code
can get simpler. Also, we reduce the overhead that comes with iterating
over all attributes for every single element. Overall I didn't measure
a large performance difference though, because the new code has the
downside of needing to allocate two more arrays.
There is a small difference of a propagated byte color (250 vs. 251) in
the geometry nodes test due to a subtle difference in the mixing
implementation.
Part of #122398.
Pull Request: https://projects.blender.org/blender/blender/pulls/147367
Make the logic in the image editor drawing robust against configuration
when the image editor has flag "show render result from sequencer scene"
and the sequencer scene being nullptr.
It could happen when user configures image editor is such way and then
removes the sequencer scene.
Or, it could also happen when the image editor has the flag set, which
was exactly the cause of the originally reported issue. So this change
also clears the flag which was expected to be cleared. It could affect
some current files saved in the past day, but since the render operator
sets it based on the way the scene is rendered it is not too bad.
Caused by 76c03744a8
Pull Request: https://projects.blender.org/blender/blender/pulls/147630
Previously items in the "Group" list would usually show up first because
their menu path is shorter. Now, adjust their search weight so they show
up lower than the corresponding asset. That this is just a heuristic,
because we don't have a good way to directly deduplicate groups
that are just packed assets in the add menu currently.
Pull Request: https://projects.blender.org/blender/blender/pulls/147629
This avoid putting too much work in only one thread for building very long surfel lists.
Instead of insertion sort, we use a prefix sum where all surfel scan the whole ray
list to know their position. Only the coplanar surfel patching is dispatched as
one thread per list.
This is currently a bruteforce approach and could be optimized further.
On top of this, we add a heuristic to scale the amount of work from the baking
depending on the scene complexity. Complex scene will have more overhead but
will remain responsive during baking, while simple scene will be faster to bake.
This avoids hitting TDR in most cases.
The update refresh is now limited to 1 per second to avoid the readback overhead.
Fix#142988
Pull Request: https://projects.blender.org/blender/blender/pulls/146848
This is the 'safe and simple' aspect of the fix: prevent `node_warnings`
RNA property of the Node modifier to be overridable.
Its access is 100% not thread safe currently - and it makes no sense to
have this reuntime data overridable anyway!
Another side of the issue will be fixed in a separate commit, for main
only, as it affects quite deeply the behavior of viewlayer resync, and
fixes some unrelated logical issues in the current code.
The UI property was changed 7b97bc48d8
to a negative boolean but the boolean conversion inside EEVEE was
not inverted.
This mean that since 4.2, the default behavior for Lightprobe
volume has been broken / inverted.
To make an existing scene bake the same as before, all material
needs to have their `BackFace Culling > Light Probe Volume` options
inverted. This is done automatically through the versioning code.
The only test cases broken are the ones using default materials which
do not have their property turned off.
Release Notes should contains the compatibility breakage.
Pull Request: https://projects.blender.org/blender/blender/pulls/147218
This new version of the graphics compiler improves performance
for the majority of supported Intel devices and adds support
for upcoming Intel hardware. Such an upgrade also requires
an increase in the minimal supported driver version on Windows,
which is why these changes are combined together with
the ocloc upgrade.
Previously set minimal version 101.6557 was increased to 101.8132.
Pull Request: https://projects.blender.org/blender/blender/pulls/147460
