When the opaque layer was populated with only emissive
material, no raytracing was used for it and no feedback
buffer was needed. Thus, the refraction layer had nothing
to raytrace against.
This fixes it by forcing the use of feedback buffer in this
corner case.
Pull Request: https://projects.blender.org/blender/blender/pulls/127771
Part of #118145.
Doing so removes the last usages of some dependent code as well, namely
the `SCULPT_VERTEX_NEIGHBORS_ITER` macro and the `PBVHVertRef` version
of the `flood_fill` algorithms. The now dead & unused code, as well as
their related helper functions, structs, and defines have been removed.
Additionally, a helper `vert_face_set_get` method for multires has been
added to be consistent with the other provided APIs
Pull Request: https://projects.blender.org/blender/blender/pulls/127781
`U.runtime.is_dirty` is not tagged dirty when some animation preferences
are changed. To fix this, pass `rna_userdef_update` updated function
which will tag preference dirty with the help of `USERDEF_TAG_DIRTY`
macro.
Pull Request: https://projects.blender.org/blender/blender/pulls/127754
This is a variation of the modal "Interpolate" operator, where a series
of keyframes is generated according in stead of a single keyframe.
The behavior should be the same as the GPv2 operator.
Much of the code is shared between the "Interpolate" and "Interpolate
Sequence" operators now (utility functions section at the top).
Pull Request: https://projects.blender.org/blender/blender/pulls/127709
In an effort to improve code documentation, reduce the number of
commonly needed arguments, and avoid repeating work for each
BVH node, combine position data and shape key data arrays to a
temporary struct used during brush deformation.
I'm generally wary of adding such object-oriented abstractions to
the code, but I think this one will hold up, and I find things easier to
understand after the change. It reduces overhead too, since the
evaluated position attribute and shape key data aren't retrieved
potentially thousands of times.
Pull Request: https://projects.blender.org/blender/blender/pulls/127725
* 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
