98c92b9033 disabled refreshing for the redo popup, since that requires
passing an operator pointer to the UI to holding on to it while the popup is
visible. Usually operators are short lived and shouldn't be held by the UI, to
avoid dangling pointer accesses. In this case it's fine though, because the
operator will be kept alive in the window manager.
Partially reverts 98c92b9033, and adds a comment to note this special case.
Fixes: #126521, #127561
Pull Request: https://projects.blender.org/blender/blender/pulls/127795
std::sort() requires a strict weak ordering, i.e. `x < x` must be false. Therefore `id_order_compare(ID *a, ID *b)` must return false for `a.name == b.name`
Pull Request: https://projects.blender.org/blender/blender/pulls/127794
This is due to memory allocation mismatch. `MEM_dupallocN` is used on
cpp style `ButsTextureUser` pointer. Now fixed by using `MEM_new`. Also
pass `uiButArgNFree/Copy` callback fn arguments to avoid the use of
default arguments which are C style.
Pull Request: https://projects.blender.org/blender/blender/pulls/127690
Blender codebase had two ways to convert half (FP16) to float (FP32):
- BLI_math_bits.h half_to_float. Out of 64k possible half values, it converts
4096 of them incorrectly. Mostly denormals and NaNs, which is perhaps not too
relevant. But more importantly, it converts half zero to float 0.000030517578
which does not sound ideal.
- Functions in Vulkan vk_data_conversion.hh. This one converts 2046 possible
half values incorrectly.
Function to convert float (FP32) to half (FP16) was in Vulkan
vk_data_conversion.hh, and it got a bunch of possible inputs wrong. I guess it
did not do proper "round to nearest even" that CPU/GPU hardware does.
This PR:
- Adds BLI_math_half.hh with float_to_half and half_to_float functions.
- Documentation and test coverage.
- When compiling on ARM NEON, use hardware VCVT instructions.
- Removes the incorrect half_to_float from BLI_math_bits.h and replaces single
usage of it in View3D color picking to use the new function.
- Changes Vulkan FP32<->FP16 conversion code to use the new functions, to fix
correctness issues (makes eevee_next_bsdf_vulkan test pass). This makes it
faster too.
Pull Request: https://projects.blender.org/blender/blender/pulls/127708
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.
