* Move grab brush preview method to `grab.cc`
* Use `enum class` where possible
* Use `const` where possible
* Use C++ math libraries where possible
* float3 instead of float *
* numeric limits & constexpr instead of macros
* Clarify naming of some variables
* Add doxygen sections
Pull Request: https://projects.blender.org/blender/blender/pulls/127743
Also return a pointer from `Layer::duplicate_with_shallow_strip_copies()`
rather than a reference, since it doesn't maintain ownership of the
returned item.
Transforming the layers instead of points is way more efficient and usually has
the same effect visually. Therefore, it is the better standard behavior.
The main problem with this right now is that layer transforms are stored
as separate location/rotation/scale, so shearing is not supported. This will have
to be solved separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/127757
This updates the layered action data model to store strip data differently. Specifically:
- `Strip` is now just a single, POD type that only stores the data common to all
strips, such as start/end frames.
- The data that might be of a completely different nature between strips (e.g.
keyframe data vs modifier data) is now stored in arrays on the action itself.
- `Strip`s indicate their type with an enum, and specify their data with an
index into the array on the action that stores data for that type.
This approach requires a little more data juggling, but has the advantage of
making `Strip`s themselves super simple POD types, and also opening the door to
trivial strip instancing later on: instances are just strips that point at the
same data.
The intention is that the RNA API remains the same: from RNA's perspective there
is no data storage separate from the strips, and a strip's data is presented as
fields and methods directly on the strip itself. Different strip types will be
presented as different subtypes of `ActionStrip`, each with their own fields and
methods specific to their underlying data's type. However, this PR doesn't
implement that sub-typing, leaving it for a future PR. It does, however, put the
fields and methods of the one strip type we have so far directly on the strip,
which avoids changing the APIs we have so far.
This PR implements the bulk of this new approach, and everything should be
functional and working correctly. However, there are two TODO items left over
that will be implemented in forthcoming PRs:
- Type refinement in the RNA api. This PR actually removes the existing type
refinement code that was implemented in terms of the inheritance tree of the
actual C++ types, and this will need to be reimplemented in terms of the new
data model. The RNA API still works without the type refinement since there
are only keyframe strips right now, but it will be needed in preparation for
more strip types down the road.
- Strip data deletion. This PR only deletes data from the strip data arrays when
the whole action is deleted, and otherwise just accumulates strip data as more
and more strips are added, never removing the data when the corresponding
strips get removed. That's fine in the short term, especially since we only
support single strips right now. But it does need to be implemented in
preparation for proper layered actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/126559
Code would try to use a random ID as a legacy curve one, without any
check on the actual ID type. When trying to open
`tests/data/io_tests/blend_big_endian/2.30/dolphin.blend` recently added
to our collection of regression tests, this ended up 'converting' a
shapekey into a legacy curve ID, leading to invalid memory access
detected by ASAN.
Fix a null pointer access in the slider drawing code. Determining the
width of the property label used `std::string::c_str()`, which on a
calloc'ed `std::string` returns `nullptr`.
The fix was to use `MEM_new()` instead of `MEM_callocN()` to allocate
the struct that contains the `std::string`.
Pull Request: https://projects.blender.org/blender/blender/pulls/127760
The Build Modifier was not copying the ID pointer to the object.
This resulted in the object field being empty when loading a GPv2
file.
The fix makes sure the ID pointer is copied.
The build modifier did not walk the ID link of the object in the settings.
This meant that the pointer was just pointing to random memory after
loading a file that had this object set.
The fix makes sure this ID link is handled in `foreach_ID_link`.
Refactor the slot assignment & related properties to use as much generic
code as possible. This'll make it much easier to add Action+Slot
properties to other data-blocks in the future (currently just planned
for the Action Constraint).
Pull Request: https://projects.blender.org/blender/blender/pulls/127720
This reverts commit 0a0551cf26.
This commit broke building on linux with mold. It seems to never
generate the necessary file when something other than the `blender`
binary is the first thing being built.
Support manipulating symbols_unix.map using symbols_unix.map.cmake
script.
Currently this removes symbols that generate noisy warnings with the
mold linker.
Looks like ffmpeg AVFrame width/height/format for the deinterlaced frame
was never initialized. That was not a problem until starting with 4.1
the colorspace conversion and upside down flip was started to be
multi-threaded, which accessed the frame width/height.
Also, the memory storage for the deinterlaced frame was never freed
either; fix that too.
Pull Request: https://projects.blender.org/blender/blender/pulls/127689
These accessors are non-trivial and shouldn't be called
again and again. That's besides the fact that it's inefficient
to re-access data on every iteration of a hot loop.
Part of #118145.
* Removes usages of PBVHVertRef and flood_fill:execute for specific
versions per PBVH type
* Adds stub method for BMesh face set retrieval to make future
implementation easier.
Pull Request: https://projects.blender.org/blender/blender/pulls/127666
In the `blender::animrig` namespace, add two new functions
`generic_assign_action()` and `generic_assign_action_slot()`. These are
now used as basis for (un)assigning Actions and Action slots, both
directly on the ID and for NLA strips.
The method `Action::assign_id()` has been removed, in favour of free
functions for (un)assigning Actions and slots.
This is almost a non-functional change. The only thing that's different
is when both an Action and a slot should get assigned in one go.
Old behaviour: the slot would be inspected, and if not suitable for the
animated ID, the entire operation would be aborted. In other words, any
previously-assigned Action would still be assigned, making this an
atomic operation.
New behaviour: assigning an Action + a slot is no longer atomic. First
the new Action is assigned (which uses the automatic slot selection
based on the name). If after this the given slot cannot be assigned, the
new Action + the auto-selected slot are still kept.
This makes the Action & slot assignment more uniform in behaviour, where
"assign this Action + this slot" as one operation behaves the same as
two sequential operations "assign this Action" + "assign this slot". If
it turns out to be confusing, we can always improve things.
The return code for slot assignment is now more explicit (enum instead
of boolean), so that the caller can decide what to do in case of which
error (like unassigning the slot if the automatic behaviour is
unwanted).
Pull Request: https://projects.blender.org/blender/blender/pulls/127712
These buffers are bound as texture buffers and will have
their backend object created whether or not the subsequent
drawcall is emited.
Ensuring a minimum size fixes the issue.
ShaderC compiler was cached on the Vulkan backend. The compiler itself
is light-weight and doesn't require any caching. This PR removes the
cached instance from the backend.
Pull Request: https://projects.blender.org/blender/blender/pulls/127693
This uses the path that metal was using.
This doesn't seems to create any difference in render
tests. This simplify the backend code and avoid
specific path for metal.
Idea suggested by Kevin Chuang
Pull Request: https://projects.blender.org/blender/blender/pulls/127687
Parallel shader compilation introduced `GPU_shader_cache_dir_clear_old`.
The implementation was specific to OpenGL and could not be overwritten
by other backends. This PR improves the implementation so the backend
can have its own implementation.
This is needed for upcoming changes to the Vulkan backend where we
want to use similar mechanisms to speed up shader compilation and caching.
Pull Request: https://projects.blender.org/blender/blender/pulls/127680
Majority of math operations on VecBase<> were implemented by calling into an
indexing operator, sometimes coupled with unroll<Size> template.
When compiler optimizations are off (e.g. Debug build), or when asserts are on
(e.g. usual "developer" setup), this resulted in codegen that is very
sub-optimal. Especially if these vector types are used a lot, e.g. when
scaling down a screenshot for saving as a thumbnail into the blend file.
Address that by explicit code paths for 4,3,2 dimensional vectors, that
avoids both the unroll<> template and indexing operator. To avoid repeated long
typo-prone code, do that with C preprocessor :( -- however all of the
preprocessor innards are in a separate file BLI_math_vector_unroll.hh so they
do not get into the way much.
Scaling down a screenshot to the blend file thumbnail, while saving the blend
file, on my machine: (4K screen resolution, Ryzen 5950X, VS2022 build), which
involves two calls to IMB_scale which uses float4 for pixel operations:
- Release with asserts off (what ships to users): no change at 9.4ms
- Release with asserts on ("developer" setup): 38.1ms -> 9.4ms
- Debug: 226ms -> 64ms
- Debug w/ ASAN: 314ms -> 78ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127577
Part of blender/blender!125449.
Since brush assets were merged, the brush asset selector and some other brush
UIs wouldn't show up for the primitive tools. This is addressed now. The
primitive tools use the same brush as the brush tool, although only the draw
brushes will work properly. !125449 addresses this so the primitive tools
remember their own draw brush, separate from the brush tool.
Turns out that these primitive tools were never tagged as using brushes by
setting the `data_block` member (or setting the `'USE_BRUSHES'` option since
b64bf66257). The UI was just hardcoded to display things like the brush selector
for primitive tools. So as far as the tool system knew, these tools did not use
brushes.
Tagging the tools properly exposed some issues that are addressed here (see PR
for details).
Pull Request: https://projects.blender.org/blender/blender/pulls/127204
The previous way of considering tools with the `data_block` member set
as using brushes was rather unclear/confusing, but also a bit outdated
with the brush assets changes. Since then most sculpt/paint modes use a
unified brush tool, there was no tool for every brush type (aka brush
tool) anymore. So now the `data_block` member was just set dynamically to
match the active brush type which is otherwise irrelevant to the tool
system now.
Further, this will become important to bring back some of the tools that
use brushes in grease pencil draw mode, see #116337. For that we want to
keep the unified brush tool, but still allow other tools that only use a
specific brush type. So marking a tool as using brushes should be done
separately from indicating a specific brush type.
Removing/replacing the `data_block` member should happen separately
still, pending further developments (e.g. see #125449).
Pull Request: https://projects.blender.org/blender/blender/pulls/125911
Previously, we only measured the execution time of built-in nodes. To get
execution times of node groups, the time of each nested node was accumulated.
This can lead to very bad accuracy when multiple nodes are evaluated at the same
time.
With this patch, we measure the time spend in each compute context more directly
instead of relying on accumulating many small measurements. This also opens up
some potential optimization opportunities, because we can skip measuring the
time for contexts that we don't care about. However, that is not implemented
yet.
The time shown in the UI can still be misleading when many things are going on
at the same time, but it should at least be more accurate in more situations
now.
Pull Request: https://projects.blender.org/blender/blender/pulls/127658
It was possible for a Grease Pencil object to have a material
with no Grease Pencil settings. This can lead to crashes in many
places because it's often assumed that the material has
these settings.
The fix makes sure that `BKE_object_material_get` returns
a Grease Pencil material when called on a Grease Pencil
object. If the Grease Pencil settings don't exist,
it returns `nullptr`.
In the future, it should be possible to have these materials
and code that reads from the settings should fall back to
the default material.
Pull Request: https://projects.blender.org/blender/blender/pulls/127570
Saving files could take ~3-4 seconds on debug builds because of new
imbuf scaling logic.
Even though debug performance usually isn't much of a consideration,
it gets in the way of development.
Since thumbnails don't require the same accuracy as the sequencer or
compositor, use a faster scaling method that uses a box-filter clamped
to integer bounds & integer math.
In practice the difference between the resulting thumbnails isn't
noticeable in my tests.
For debug build with ASAN this gives a ~25x speedup,
for release builds it gives a ~1.4x speedup which is to be
expected with a more approximate scaling method.
Avoid a division by zero when the Action constraint has the same value
for its 'min' and 'max' parameters.
When `min` and `max` are equal, the code will now choose either `min`
(when `target value` ≤ `min`) or max (`target value` > `max`).
Pull Request: https://projects.blender.org/blender/blender/pulls/127583
