Currently all nodes pushed in a single undo step are expected to have
the same type. Storing the undo type in the undo step itself rather than
duplicating it in every node makes it easier to move some "entire mesh"
data out of the undo nodes and into the undo step, with the goal of
making undo nodes smaller and simpler.
Pushing multiple nodes at the same time helps to reduce the amount
of time spent waiting for threads to unlock while they manipulate the
nodes map, and equalizes the amount of work per thread, since we
can iterate over just the nodes that need data stored. I observed a
2.6% speedup in the benchmark file from #118145 (0.59s to 0.57s).
Instead of counting the size of undo steps as they're being built,
add up the size of all undo nodes as a final step when the undo step
is finished. This is faster because it avoids incrementing the same
size variable from many threads (which also wasn't threadsafe).
I measured a 4% performance improvement in the brush benchmark
file from #118145 (from 0.61s to 0.59s).
Instead of locking for the whole time the undo data is being stored,
only lock while the step's per-node undo node map is being accessed.
This is fine because each PBVH node is only processed by a single thread.
Changing the node vector to not store anything until the undo step is
finalized makes this process a bit simpler because we don't have to build
both the map and the vector at the same time.
Overall this improved the performance of the sculpt brush benchmark
from #118145 by 12%, from 0.68s to 0.61s.
By itself this change doesn't look great since it's mixing up the
responsibilities of different functions. However, it's preferred
since we want to separate geometry undo state and per-node
undo state further in the future. Eventually geometry undo state
should be stored in `StepData` instead.
Sometimes undo data is stored per PBVH node, and sometimes the entire
geometry is stored. Currently these go through the same `undo::push_node`
function, which is confusing and limits improvements we can make to the
pushing of per-node undo data.
In file_browse_invoke, if the path is blank we attempt to use
BKE_appdir_folder_default_or_root to get the user's normal document
root. However we are not ensuring that the directory path has a
trailing slash, which can result in it being misinterpreted as a file
path instead, separating out the last path part. This PR only adds a
call to BLI_path_slash_ensure.
Pull Request: https://projects.blender.org/blender/blender/pulls/123504
This was caused by some pixels having no good neighbors
to get the irradiance from. The weighted sum would
have huge precision issues and the values would blow-out.
Adding an epsilon weight tailored to the report file
to fix this issue.
Fix#123488
The icon for missing media/data-block would be too close to the edges.
Decrease the size so it matches the size of the label and aligns with
the text baseline.
Update the batch specializations compilation to allow using it in an
async way.
The implementation has 2 main limitations:
- Only one batch at a time can be processed, extra batches will be
added to a queue.
- Binding a specialization variant that is still being compiled will fail.
Pull Request: https://projects.blender.org/blender/blender/pulls/123015
With the recent change for labels to be black when not active/selected,
the hardcoded colors of missing media/data-blocks make it hard to read.
- Use a lighter color just like muted strips.
- Makes active/selected muted strips draw labels in full opacity, for consistency.
- Make muted strips a little less gray (50% instead of 80%)
Pull Request: https://projects.blender.org/blender/blender/pulls/123494
There is some special code in the Object's freeing which did
special checks for SubdivCCG based on the evaluated mesh state.
If the depsgraph is destroyed prior to the evaluated object it
makes object to access freed components of ID node.
The fix makes it so the evaluated ID is freed prior to freeing
components.
Moving after extrude looks weird when selecting a Bezier point with both
handles and extruding it. This happens because old handles are selected
as well as new ones. Patch takes `".selection_handle_left"` and
`".selection_handle_right"` attributes into account.
Pull Request: https://projects.blender.org/blender/blender/pulls/121340
Blender would crash if it tried to convert a grease pencil
data-block with strokes that used the editcurve.
This was because of a wrong assertion that assumed
to work with a poly curve.
The fix moves the assertion to the correct place where
we handle the poly curves.
From the user perspective, the transform tools in editmode and
sculptmode look like the same tools, the equal behavior could be
expected.
So now set vertices on the mirror axis (check with the same epsilon as
editmode transform) while transforming, replicating what
`mesh_transdata_mirror_apply` does.
Pull Request: https://projects.blender.org/blender/blender/pulls/123428
While the evaluated result is not well defined, we expect Blender to not crash
when there are dependency cycles.
The evaluation of one object often takes the evaluated geometry of another
object into account. This works fine if the other object is already fully
evaluated. However, if there is a dependency cycle, the other object may not be
evaluated already. Currently, we have no way to check for this and were mostly
just relying on luck that the other objects geometry is in some valid state
(even if it's not the fully evaluated geometry).
This patch adds the ability to explicitly check if an objects geometry is fully
evaluated already, so that it can be accessed by other objects. If there are not
dependency cycles, this should always be true. If not, it may be false
sometimes, and in this case the other objects geometry should be ignored. The
same also applies to the object transforms and the geometry of a collection.
For that, new functions are added in `DEG_depsgraph_query.hh`. Those should be
used whenever accessing another objects or collections object during depsgraph
evaluation. More similar functions may be added in the future.
```
bool DEG_object_geometry_is_evaluated(const Object &object);
bool DEG_object_transform_is_evaluated(const Object &object);
bool DEG_collection_geometry_is_evaluated(const Collection &collection);
```
To determine if the these components are fully evaluated, a reference to the
corresponding depsgraph is needed. A possible solution to that is to pass the
depsgraph through the call stack to these functions. While possible, there are a
couple of annoyances. For one, the parameter would need to be added in many new
places. I don't have an exact number, but it's like 50 or so. Another
complication is that under some circumstances, multiple depsgraphs may have to
be passed around, for example when evaluating node tools (also see
`GeoNodesOperatorDepsgraphs`).
To simplify the patch and other code in the future, a different route is taken
where the depsgraph pointer is added to `ID_Runtime`, making it readily
accessible similar to the `ID.orig_id`. The depsgraph pointer is set in the same
place where the `orig_id` is set.
As a nice side benefit, this also improves the situation in simple cases like
having two cubes with a boolean modifier and they union each other.
Pull Request: https://projects.blender.org/blender/blender/pulls/123444
During the strips redesign it was tested to go with drop shadows but
in practice and based on user feedback it looks better without.
- Remove drop shadow.
- Use white text for active/selected strips, black for unselected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123487
EEVEE stores light probes using octahedral mapping. Compared to the previous
cubemap storage octahedral has less pixels. The 64x64 is becoming useless
and can be removed. This PR also enables generating light probe maps upto 4k.
Some issues were found: the offset of the sphere inside the atlas
was always set to mipmap level 0 offset. This was hidden because of the texture
wrapping. Also the offset was substracted from the local texture
coordinate when calculating the direction of the pixel. Might be that due
to the incorrect offset (mipmap level 0), the latter issue was never detected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123074
EEVEE stores light probes using octahedral mapping. Compared to the previous
cubemap storage octahedral has less pixels. The 64x64 is becoming useless
and can be removed. This PR also enables generating light probe maps upto 4k.
Some issues were found: the offset of the sphere inside the atlas
was always set to mipmap level 0 offset. This was hidden because of the texture
wrapping. Also the offset was substracted from the local texture
coordinate when calculating the direction of the pixel. Might be that due
to the incorrect offset (mipmap level 0), the latter issue was never detected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123074
Add support for VK_EXT_dynamic_rendering_unused_attachments. Although
this is required, it needs to be registered optional for now due to
lacking support when using renderdoc.
Pull Request: https://projects.blender.org/blender/blender/pulls/123483
Due to incorrect logic any multi viewport setup could be cleaned
when dynamic rendering begins. This patch moves the clearing
of the viewport/scissor setup when binding.
This issue fixes shadow rendering in EEVEE.
Pull Request: https://projects.blender.org/blender/blender/pulls/123484
Store library filepath so we can find the right datablock.
Tested to work with the brush assets project branch, as this
currently does not affect anything in main.
Pull Request: https://projects.blender.org/blender/blender/pulls/123449
`VK_EXT_shader_stencil_export` isn't supported by NVIDIA devices.
This extension was recently added to support EEVEE PBR layer selection.
This PR makes this extension optional and selects the work around
when not supported by the physical device.
Fixes#114385
Pull Request: https://projects.blender.org/blender/blender/pulls/123470
