The order key-maps are stored changed in [0], causing the mouse button
shortcut to be shown instead of the "G" key.
[0]: d7558a243c6b3b48669d7c084ff0cfbbc5324e6a
Sort the incoming Alembic objects by name before processing them. This
mirrors what is already done in USD to partially side-step Blender's
quadratic behavior when checking object names.
The file contained in issue #118839 contains over 365000 individual
objects. This change allows loading to be ~4x faster; from 2.2 hours
down to 28 minutes.
Additionally, change the progress bar to report in finer-grained steps
to better indicate that progress is still being made.
Pull Request: https://projects.blender.org/blender/blender/pulls/118869
Note that this still isn't entirely thread safe since the catalogs of
the asset libraries may still be edited in various ways while building
the all asset library. But at least this avoids a data race when
assigning the catalog service once done building it.
Some of these members are not expected to change throughout the lifetime
of the class instances, so make them constant and only set them via the
constructor. Making them immutable this way helps making clear which
data needs extra attention for thread safety.
This adds implicit sharing support for the `MemFile` undo-step. This decreases memory
usage and increases performance.
Implicit sharing allows the undo system to take (shared) ownership of some data.
Previously, the data would always be serialized and compared to the previous undo-step.
So this turns an O(n) operation into O(1) (in terms of memory usage and time).
Read/write code that wants to make use of this has to use the new `BLO_read_shared`
and `BLO_write_shared` functions respectively. Those either make use of implicit-sharing
internally or do the "full" read/write based on a passed-in function. It seems possible to
use the same API in the future to store shared data to .blend files.
Improvements:
* Much faster undo step creation in many cases by avoiding the majority data copies
and equality checks. This fixes#98574. I found undo step creation and undo step
decoding to be 2-5 times faster in some demo files from the blender website and in
some production files from the Heist project.
* Reduced memory usage when there is large data in `bmain`. For example, when
loading the same highly subdivided mesh that I used in #106228 the memory usage
is 1.03 GB now (compared to 1.62 GB in `main` currently). The main remaining copy
of the data now is done by rendering code.
* Some significant performance improvements were also measured for the new grease
pencil type (#105540).
There is one main downside of using implicit-sharing as implemented here: `MemFile`
undo steps can't be written as .blend files anymore. This has a few consequences:
* Auto-save becomes slower (up to 3x), because it can't just save the previous undo step
anymore and does a normal save instead. This has been discussed in more detail here:
https://devtalk.blender.org/t/remove-support-for-saving-memfile-undo-steps-as-blend-files-proposal/33544
It would be nice to work towards asynchronous auto-save to alleviate this problem.
Some previous work has been done to reduce the impact of this change in 41b10424c7e0
and f0f304e240. This has been committed separately in efb511a76d98a.
* Writing `quit.blend` has to do a normal file save now. So it's a bit slower too, but it's
less of a problem in practice.
* The `USE_WRITE_CRASH_BLEND` functionality does not work anymore. It doesn't seem
to be used by anyone (removed in e90f5d03c4a382)
There are also benefits to not writing `MemFile` from undo steps to disk. It allows us to
more safely do undo-specific optimizations without risking corrupted .blend files. This
is especially useful when we want to preserve forward compatibility in some cases.
This requires converting data before writing the .blend files, but this conversion is not
necessary for undo steps. Trying to implement this kind of optimization in the past has
often lead to bugs (e.g. 43b37fbc93).
Another new problem is that it is harder to know the size of each undo step. Currently, a
heuristic is used to approximate the memory usage, but better solutions could be found
if necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106903
These shouldn't need to be accessed from outside the asset system
itself, so they should not be exposed with its API. Move them to an own
asset system private headers. This is a further step towards making
asset system classes more encapuslated, so behavior and data flow can be
controlled better (which helps addressing threat safety issues).
Personally I've found it quite confusing to work on higher level issues
of the asset catalog system, because I got lost in the multiple classes.
Hopefully separating them more clearly helps with that too.
Making the member private (or at least protected) makes threat safety
more tangible, and we don't need to expose locking in the API. Generally
we need to make data more encapsulated, so we can make edits more
controlled and threat safe.
Asset libraries also always have a catalog-service, so it can accessed
by reference, rather than pointer that would have to be null-checked.
In many modes, Blender uses the `MemFile` undo step, which serializes all DNA
data in RAM almost as if writing a .blend file. For auto-save, Blender used to
write the last `MemFile` undo step to disk because that was faster serializing
all of DNA again. Furthermore, saving the `quit.blend` file when closing Blender
also used this.
This functionality is now removed in preparate for supporting implicit sharing
in the undo system (#106903). Auto-save and saving the quit.blend file now use
regular file saving.
The removal of this feature and its implications have also been discussed here:
https://devtalk.blender.org/t/remove-support-for-saving-memfile-undo-steps-as-blend-files-proposal/33544
This was a debug feature for developers that allowed writing the last MemFile
undo step as a .blend file when Blender crashed. This was rarely/never used
nowadays and is now removed.
This is in preparation for #106903 which removes support for writing `MemFile`
undo steps as .blend files.
Alternative to #118820 and #118815.
The current optimization to skip work when the offsets are zero
or the positions are the original positions is error prone and overly
specific. Such optimizations should be applied to field evaluation
and attribute capturing in general.
This PR significantly simplifies the set position node to compose
fields with the addition function instead of implementing it directly
in the node. Then the position is saved to the geometry with the
generic utility for capturing attributes on geometry.
The most significant lost optimization is for when the positions are
original and the offset is zero. That could still be added back here
directly if we wanted. Or it could be done later in a more general
way that would also help in other places.
Pull Request: https://projects.blender.org/blender/blender/pulls/118857
This implements a new internal data structure for reverse uv sampling.
Being better than the previous one was not particularly hard, because it
was never really optimized and used a very simple approach. I found the
new implementation to be about 10-20x faster in my tests. Simon was
able to reproduce an comparable speedups in production files.
The speed-up is mainly achieved by a better memory layout and better
multi-threading during construction. The lookup performance is mostly the
same as before.
Like the old data structure, the new one also splits the uv space into
uniformly sized cells. The size of the cells is based on the number of
triangles. Then it sorts all triangles into the rows that they touch. Finally,
it creates a flat array for each row that contains the triangle indices
contained in each cell.
There are still ways to optimize this further, but for now this is a good
improvement already.
Pull Request: https://projects.blender.org/blender/blender/pulls/118772
When using the area light gizmo in the 3d viewport to resize the
area light, the changes where only made visible when EEVEE-Next would
rerender. EEVEE and Cycles did refresh accordingly.
The reason is that EEVEE and Cycles uses a more general approach of
detecting changes. EEVEE-Next listens to exact changes made in the
dependency graph.
This change fixes this by tagging the lamp without any flags similar
to what RNA does. EEVEE and Cycles don't need the general flag for
correct working.
Pull Request: https://projects.blender.org/blender/blender/pulls/118888
Add percentage closer filtering to shadowmap sampling and a
`shadow_filter_radius` property to lights to control it.
Notes:
* This adds PCF to `eevee_shadow_tracing_lib`, but not to
`eevee_shadow_lib`, which is used by volumes (not required) and
thickness.
* PCF is computed based on the LOD0 size. This assumes that higher
LODs are only used when the shadowmap resolution is actually good
enough to match the render resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/118220
Tiles tagged for update in eevee_shadow_tag_update_comp can be
untagged in eevee_shadow_tilemap_init_comp, since those tiles
might be tagged as rendered.
Regression from 9e015f703c
The `std::all_of` function wasn't used correcty.
Also, the last value of `dst_offsets` was always 0
(because the offsets were still counts at this point)
so the fix also makes sure the last value
is never included in the check.
HIP fails to allocate textures, typically when they are too large.
This commit lets the user know what might be causing the issue
rather than providing a confusing internal error message.
Pull Request: https://projects.blender.org/blender/blender/pulls/118239
Auto-save currently only really works in modes that use the `MemFile` undo step,
that excludes things like mesh edit and sculpt mode. Previously, Blender would
attempt to auto-save in those modes, but it would only save the last state from
before the mode was entered, which is useless when staying in the mode for longer.
This problem is *not* fixed here. However, the code now explicitly skips auto-saving
in order to avoid unnecessary short freezes in these modes when Blender auto-saves.
Furthermore, the auto-save will now happen when changing modes.
This reduces the impact of save-time-regressions with #106903.
Pull Request: https://projects.blender.org/blender/blender/pulls/118892
This splits the core part of `resample_to_uniform` into it's own function, so that it doesn't depend on field evaluation.
From there, new versions of `resample_to_count`, `resample_to_length`, and `resample_to_evaluated` are provided.
Pull Request: https://projects.blender.org/blender/blender/pulls/118551
This patch unifies the anti-aliasing of plane deforms between the CPU
and GPU compositors. The CPU used a multi-sample approach, where the
mask was computed 8 times with a jitter, then averaged to get smooth
edges. The GPU relied on the anisotropic filtering with zero boundaries
to smooth the edges.
Furthermore, the CPU implementation ignored the anti-aliasing for the
deformed image and also relied anisotropic filtering like the GPU, so
its outputs were different.
To unify both implementation, we use the existing SMAA anti-aliasing
algorithm instead, and use the anti-aliased mask for the image output as
well. This affects both the Corner Pin and Plane Deform nodes.
A consequence of this change for the Plane Deform node is that motion
blur will appear to have less samples, that's because it was sampled
8-times more in the previous implementation. But users can just increase
the samples in the node to account for that.
Pull Request: https://projects.blender.org/blender/blender/pulls/118853
Affects the catalog tree found in the catalog selector popup in the
asset shelf.
Looks like this added the padding for indented items without children
twice, which was misleading (because it would look like items were
nested deeper than siblings with children). I think it was added twice
since 2e02c0c515, which changed how tree view indentation is done.
- Skip leading forward slashes when setting the temp directory.
- Add a utility function to set the temporary directory
which is used for the user preferences & environment variables.
This issue was raised by #95411 where "//" resolves to "/",
then asserts when passed to Blender's file-system functions.
However the crash referenced in this report looks to be caused
by Collada failing to write to the temporary directory which
can be handled separately.
Ref !118872
This patch unifies the variable size blur between the CPU and GPU
compositor. The difference is due to how weights are computed and used.
The CPU computed a nested array of weights for every possible size, that
is, from size 1 to the base size. Then, it assumed the kernel was
separable and reconstructed a 2D kernel by selecting two 1D weights
array and multiplying them for every pixel of the blur window.
The GPU on the other hand computes a single quadrant of the 2D weights
kernel and sampled it directly in the blur window. We favor the GPU
implementation since it makes no assumptions about the separability of
the weights kernel and since the CPU has no performance advantage even
with the assumption in place.
Pull Request: https://projects.blender.org/blender/blender/pulls/118834
Currently, the CPU compositor smoothes its input size in variable size
mode. It is unclear why this is the case, but it seems the logic is that
sharp transitions in the size input are undesirable. Alternatively, this
is similar to the morphological blurring step in the Defocus node. But
it does not use standard weights and it is not morphological in nature
at all.
This patch removes the smoothing step and uses the original size
provided by the user. Looking at resources online, it seems users almost
always expect the size inputs to be used directly, so there is no reason
for force smooth their inputs.
Pull Request: https://projects.blender.org/blender/blender/pulls/118757
