Sharing of the normals cache between copied meshes was missing from
89e3ba4e25, which under-represented the benefits of the
change. In a simple file where geometry nodes causes a re-evaluation
without changing the normals, this increased FPS from 2.6 to 14.
Recent and ongoing efforts have changed many properties to be stored
contiguously in memory, e.g. mesh attributes. This patch updates
rna_raw_access to make use of this and copy the entire contiguous block
of memory when the property is stored contiguously.
This is faster and scales much better with larger arrays.
Pull Request: https://projects.blender.org/blender/blender/pulls/116015
Part of overall "improve filtering situation" (#116980) task:
* Add Bicubic filtering option to strip Transform "Filter" setting.
Previously this option only existed in Transform Effect "Interpolation"
setting.
- With this addition, it feels like the transform effect could
possibly be marked as legacy/deprecated, since the regular Transform
that is on all strips can do everything that Transform Effect did?
* Speed up bicubic filtering (used now in VSE, but also in CPU Compositor,
image paint, etc.) by slightly simplifying the code and using some SIMD.
Upscaling 96x54 image to 3840x2160 resolution, using Bicubic filtering:
- Windows (VS2022, Ryzen 5950X): 35.5ms -> 15.1ms
- Mac (clang 15, M1 Max): 29.6ms -> 24.4ms
* Add gtest coverage for bicubic functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/117100
Fix an issue where, after deleting the active bone collection, the
incorrect bone collection became the active one.
The solution was to store the active bone collection index before
deletion, instead of after.
After the replacement of auto smooth with a modifier, sharp edges are
always used, so the "shade smooth", "shade flat", and "smooth by angle"
operators cleared the attribute. However, often users spend significant
time manually tagging edges sharp, and the operators make it too easy to
lose that data.
To keep the old behavior by default, add an option called "Keep Sharp
Edges". Though this can make the operators "ineffective" at their goal
of changing the way the meshes look, or result in redundant data stored
on the mesh, it's a much safer default, especially as users get used to
the new workflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/117069
Ensure attachment states and load/store configs don't get out of sync
with the framebuffer layout.
In theory, a Framebuffer could have empty attachments interleaved with
valid ones so checking just the attachments "length" is not enough.
What this does instead is to ensure that valid attachments have a valid
config and that null attachments either don't have a matching config or
have an IGNORE/DONT_CARE one.
Pull Request: https://projects.blender.org/blender/blender/pulls/117073
This is due to `BLI_findstring` returning wrong id from passed name.
Two IDs can have same name before making them unique so it can return
wrong id. To fix this, pass id argument instead of id_name to
`BLI_libblock_ensure_unique_name` and skip the use of `BLI_findstring`
Pull Request: https://projects.blender.org/blender/blender/pulls/116246
Caused by e968b4197b / 67e23b4b29
Since culprit commits, we are not running `MANTA::initGuiding` /
`fluid_alloc_guiding` if guiding is meant to be pulled from other
domains (it does work with effectors though). This is because atm. only
the `FLUID_DOMAIN_ACTIVE_GUIDE` flag sets `mUsingGuiding` to true
(activated in `update_obstacleflags`, so only for effectors).
So to fix this, we have to ensure that `MANTA::initGuiding` runs (also
if guiding is pulled from domains), but also make sure we dont run into
the crashes from T102257.
It seems that the real reason we were getting crashes in T102257 is that
67e23b4b29 made it so that resetting the cache (including a call to
`fluid_modifier_reset_ex`) in `fluid_modifier_processDomain` happens
**after** `FluidDomainSettings.active_fields` have been updated (this
happens in `update_flowsflags` & `update_obstacleflags`).
But `fluid_modifier_reset_ex` also resets
`FluidDomainSettings.active_fields`. If we then update pointers later in
`fluid_modifier_processDomain`, we never get anything in the guiding
related pointers for the new `mCurrentID` (specifically `mPhiGuideIn`
will be a nullptr). This is the real reason `initGuiding()` runs a
second time (it does once for `fluid_modifier_init` then again as a
consequence of the call to `manta_guiding`).
This patch proposes to move the resetting process from 67e23b4b29
**above** the refreshing of the `FluidDomainSettings.active_fields`,
this way these field stay intact, we do get the first run of
`initGuiding()` from `fluid_modifier_init`, manta pointers get updated
with intact fields afterwards (so we then get a valid `mPhiGuideIn`),
which then prevents the second run from `manta_guiding` to actually call
the python script again.
The fix from e968b4197b is then not needed and reverted in this patch.
This should be good for LTS I think.
Pull Request: https://projects.blender.org/blender/blender/pulls/117067
Generated copies of GLSL sources are kept in a std::string and
it was always accessed by a long living StringRefNull which lead
to potential read from unallocated memory as std::strings are
not null terminated.
Pull Request: https://projects.blender.org/blender/blender/pulls/117120
This commit tweaks some unit names:
- Remove `name_alt` for square mile "sq m" and cubic mile "cu m" as
they could easily be confused with meters.
- Correct plural forms for the ton units: rename "ton" to "tonne" for
the metric ton, and "tonnes" to "tons" for the imperial (short) ton.
Identifiers are unchanged.
- Swap `name_short` and `name_alt` for metric ton, hour, and second,
as `name_short` is used for UI display and should use the official
symbol. Keep the other form as `name_alt` for input.
- Use "t" and "tn" respectively as short names for the metric and
imperial (short) ton.
- Rename radian's short name "r" to "rad", keep it as alt name.
- Introduce alt names for km/h (kph), arcminutes (amin),
arcseconds (asec), for convenience.
References:
- https://en.wikipedia.org/wiki/Ton
- https://en.wikipedia.org/wiki/Tonne
Ref: !116762
- Move functions to C++ namespace
- Use two functions with simpler responsibilities instead
- Use C++ math functions
- Remove arguments structs left over from before C++ transition
- Return ray distance precalculation by value
Transition retiming keys move as if they are mirrored across a point.
It is possible to allow them to cross this point instead of limiting
transition duration.
This change itself doesn't really improve usability, but it is needed
for "Add transition and change its size" operator.
- Remove unlimited mip level.
- Make computation of sampling region simpler.
- Add correct mirroring of UV and border region.
- Fix crash when world probe is smaller than lightprobes.
The storage coordinate is left unchanged and is
kept as `ReflectionProbeAtlasCoordinate`.
A new structure `ReflectionProbeCoordinate`
contain scale and offset for efficient sampling
without integer math.
The `ReflectionProbeWriteCoordinate` is only used
during the octahedral map processing.
This also has the benefit to centralize the coordinate
changes to a single class.
Pull Request: https://projects.blender.org/blender/blender/pulls/117011
Allows specification of per-shader threadgroup memory tuning
to optimise performance through increase of GPU occupancy.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/115238
There's been feedback that placing them inside a Scope better aligns
with other DCCs and makes some aspects of tooling more consistent in the
ecosystem.
Note: it was not a spec violation to have the typeless def that we used
before.
Pull Request: https://projects.blender.org/blender/blender/pulls/116460
The foreach_get/foreach_set methods of bpy_prop_array get/set the entire
contents of the array, but they were checking that the length of the
input sequence was equal to the length of the current array dimension
rather than the total length of all dimensions of the array.
This would read/write memory after the end of the passed in sequence
when the property was a multidimensional array. Performing
`foreach_get` with a Python list with length matching the length of the
current dimension of a multidimensional array would crash a debug build
due to the trailing pad bytes of the temporarily allocated array being
overwritten.
This patch fixes `pyprop_array_foreach_getset` by changing the function
used to get the expected sequence size, to the RNA function that gets
the total length of the array across all its dimensions.
The tests have be updated to additionally test multidimensional array
properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/116457
It's pretty simple, but threading it, and making it write out whole
pixel at a time (instead of one byte at a time) still makes it faster.
4K resolution, five Color strips blended over each other, playback on
Windows/VS2022, Ryzen 5950X:
- Playback 9.2FPS -> 11.5FPS
- do_solid_color for one effect, median time 7.7ms -> 3.8ms
Additionally, the solid color on byte output was not doing float->byte
color rounding & clamping properly, and on float output it was writing
255.0 into alpha instead of 1.0. So fix that too.
Pull Request: https://projects.blender.org/blender/blender/pulls/117058
The viscosity panel was confusing for users because viscosity
is defined by the base and exponent properties in the Diffusion panel.
What this setting actually does is use a special solver algorithm that is designed for high viscosity liquids.
See 635694c0ff for details.
The below changes are designed to better represent this to the user.
- Move the "Viscosity" Panel to a sub panel of "Diffusion"
- Rename "Viscosity" to "High Viscosity Solver" to better represent what this property does
- Update `use_viscosity` tooltip to better explain that this uses a different solver algorithm.
Pull Request: https://projects.blender.org/blender/blender/pulls/116118
When autokeying a property with a driver, the code added
the keyframe into the drivers FCurve.
Judging by the code the intention was to be able to quickly
set up driven keys by modifying the driven value and have that
reflected in the driver curve.
However that idea was blocked by the fact that you can't actually
change the value of a property that is driven.
In addition to that it's quite unexpected and the result is hardly
communicated to the user.
The solution is to not insert keyframes to drivers using the
autokeying system.
Also Fixes#95866
This was discussed in the A&R module meeting
https://devtalk.blender.org/t/2024-01-11-animation-rigging-module-meeting/32888#patch-review-decision-time-5
and the consensus was the feature to set up driven keys would be great,
but since it's not working at all currently it's better to get rid of the bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/116927
In particular, while Object (un)linking was already tagged in relevant
BKE code, collection (un)linking was not in several cases.
This was (partially) done by user code, though almost never for the
whole hierarchy of parents.
Technically, the tag is done as part of
`collection_object_cache_free_parent_recursive`/`collection_object_cache_free`,
since currently clearing this cache is done everytime to collection
hierarchy or their content is modified.
It also removes `collection_tag_update_parent_recursive`, which was
already doing something similar, but was only called from code
adding/removing objects to collections, and was walking the same parent
hierarchy as `collection_object_cache_free_parent_recursive`.
This commit implements the decision made in #116601, to tag modified
data as close as possible from the code modifying it.
---------------------
This has an impact on deg tagging, which takes over twice as much cycles
with this commit compared to previous code when opening a Pets production
file with several liboverrides (`deggraph_id_tag_update_single_flag` goes
from less than 0.03% to over 0.06%).
The overhead remains extremely low though, and is totally unmeasurable in
global execution timing. Timing of the liboverride processing on opening
the production file also did not show any measurable differences.
Pull Request: https://projects.blender.org/blender/blender/pulls/116986
