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
The PROP_RAW_BOOLEAN raw type exists, but was only used as a fallback in
bpy_rna.cc#foreach_getset to help construct an input RawArray for
PROP_BOOLEAN properties without raw access.
Using the PROP_RAW_BOOLEAN raw type for PROP_BOOLEAN properties where
possible will make it so that almost all PROP_BOOLEAN properties are
considered compatible with bool buffers in bpy_rna.cc#foreach_getset,
which should simplify efficient access to bool properties of collection
items with bpy_rna.cc#foreach_getset.
Only about 50 PROP_BOOLEAN properties have raw access because most
either don't use #RNA_def_property_boolean_sdna or use a bitmask, which
disables raw access. Even fewer of these properties belong to a
StructRNA used by a collection property with raw access.
PROP_BOOLEAN properties with raw access, but which use a type larger
than a single byte are rarer still, and will remain using their existing
raw type because they cannot have raw access as bool.
Pull Request: https://projects.blender.org/blender/blender/pulls/116673
In the end it was a dummy mistake in own 94e6ab6d71 refactor, which
broke the 'restore on undo' case for ID pointers when the old and new
pointers remain exactly the same.
Many thanks to Campbell (@ideasman42) for investigating and identifying
the actual issue.
Can be convenient to do this from python (e.g. afaict, these preferences
are not used from Application Templates userpref.blend, but could now at
least be configured via the template script __init__.py)
Pull Request: https://projects.blender.org/blender/blender/pulls/116381
Reason is that `.handle_free` and `.handle_sel_free` are never really
defined as RGBA defaults in `U_theme_default` `.space_image` (nor
`.space_clip` and `.space_graph` ) with full alpha (as opposed to the
other handle types).
If we read these with `immUniformThemeColor` then we are ending up with
with zero alpha.
So in the Image Editor or Movie Clip Editor, we only see the grey
"Outline" (if the mask display is set to this - which is by default),
the handles themselves are in visible, making it look like those were
always drawn in grey and the Preference would have no effect.
We also dont really have a preference color defined for free handles
(they are set to black).
So there are two possible solutions:
- [1] come up with a good color, define as RGBA default in
`U_theme_default` and overwrite user Preferences in `do_versions_theme`
(with a version bump)
- [2] read existing Preferences with `immUniformThemeColor3` (instead of
`immUniformThemeColor`) to work around the alpha problem
This patch uses the second (and less disruptive) solution.
Pull Request: https://projects.blender.org/blender/blender/pulls/116898
No functional changes.
Clean up the code by:
* renaming variable `ks` to `keyingset`
* renaming variable `ksi` to `keyingset_info`
* renaming variable `ksp` to `keyingset_path`
* moving variables closer to where they are used
* making variables const if possible
* use `LISTBASE_FOREACH_MUTABLE` where applicable
* Fix comment style
* Remove comments that provide no extra information
Pull Request: https://projects.blender.org/blender/blender/pulls/117062
This PR adds support for specialization constants for the OpenGL
backend. The minimum OpenGL version we are targetting doesn't
have native support for specialization constants. We simulate this
by keeping track of shader programs for each set of specialization
constants that are being used.
Specialization constants can be used to reduce shader complexity
and improve performance as less registry and/or spilling is done.
This requires the ability to recompile GLShaders. In order to do this
we need to keep track of the sources that are used when the shader
was compiled. For static sources we only store references
(`GLSource::source_ref`), for dynamically generated sources we keep
a copy of the source (`GLSource::source`).
When recompiling the shader GLSL source-code is generated for the
constants stored in `Shader::constants`. When compiling the previous
GLSource that contains specialization constants is then replaced
by the new version.
Pull Request: https://projects.blender.org/blender/blender/pulls/116926
