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.
Temporarily disable point cloud rendering in HIPRT to fix a performance
regression triggered by increased register preasure until
a better solution can be developed.
Pull Request: https://projects.blender.org/blender/blender/pulls/127738
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
The Vulkan backend has come a long way and it is time to spread his
wings a bit more. This change will make the vulkan backend available
in a regular release starting from 4.3.
Vulkan is still experimental and performance isn't there yet. But it
gives add-on developers already time to check if their add-ons work.
Main goal for the vulkan project is to get a better understanding which
platforms are supported.
- NVIDIA GTX900 and up should be supported using the official NVIDIA
drivers. This means that support for GTX700/800 is currently not
available. This is related to dynamic rendering.
- AMD Polaris and up are supported using the AMD drivers. When using
the open source drivers I believe the support level is around GCN2.
- Intel CPUs are supported from UHD (6th gen) on Linux. On windows
it requires features that are not available on all latest drivers and
a workaround should be added on our side.
- Intel GPUs are supported preferrable using the latest drivers on
Windows and Linux
Some render artifacts are showing when using EEVEE but the cause is
clear and would assume to solve them before the actual release.
Pull Request: https://projects.blender.org/blender/blender/pulls/127096
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.
This change makes it so that HIP-RT libraries are built as a part
of the rest of the dependencies.
The libraries are built and placed to the `lib-<platform>/hiprt`. They
are not currently used, but are needed to simplify transition of Cycles
to these new libraries.
The actual Cycles side is done in #121050
Pull Request: https://projects.blender.org/blender/blender/pulls/127719
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
b64bf66257 changed how brush based tools are defined. It was authored
before the vertex paint tools got added back for grease pencil v3, so
this additional change was missing.
