- 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
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Translation of the UI is currently split into 3 preferences:
interface, tooltips, and new data. The distinction between interface
and tooltips is currently unclear as tooltips also include a lot of
messages not displayed in the actual tooltips on mouse hover.
These include reports to the Info Editor, information in editor
headers and footers, and statuses in panels.
In order to limit the use of `TIP_()` to actual tooltips, this commit
introduces a new preference for this extra information: "Reports".
New translation macros are introduced: `RPT_()` and `CTX_RPT_()`, as
well as their equivalent for the Python API, `pgettext_rpt_()`, to be
imported as `rpt_()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
This patch implements the Vector Blur node for the Realtime Compositor.
The implementation is a direct and mostly identical port of the EEVEE
motion blur implementation with the necessary adjustments to make it
work with the compositor.
The exposed parameters in the node does not match those exposed in
EEVEE, so only the parameters shared between both are currently
implemented. In the future, we should make a decision to either unify
both, or just consider them independent implementations, with the
possibility of sharing the full or part of the code.
Further, it would also make sense to port the implementation to the CPU
compositor, since the new implementation is higher in quality while also
being faster.
The default value of the node shutter setting was changed to 0.25 to
approximately match the default settings of EEVEE and Cycles, since in
their default settings, they evaluate the previous and next frames at
plus and minus 0.25.
Pull Request: https://projects.blender.org/blender/blender/pulls/116977
The ruler code would add new (GP) ID and link it to current scene outside
of any depsgraph tagging and/or undo step writing.
Now always add this 'util' GP data earlier, in a context where there is a clear
undo step written. Also fixes the missing tagging and relations updates.
Pull Request: https://projects.blender.org/blender/blender/pulls/116751
