Reason is that `BKE_camera_view_frame_fit_to_scene` cannot handle grease
pencil data [it used to, that was once added in 80d0b68290 but lost in
the switch to GPv3 (see 5c57e24fea)].
So to resolve, add back support for grease pencil in
`BKE_camera_view_frame_fit_to_scene` which is similar to what we do for
getting the bounding box.
Pull Request: https://projects.blender.org/blender/blender/pulls/132733
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
* Clamp invalid per-face slot numbers to match rendering logic.
* When objects have no slots, ensure faces get assigned to an empty slot.
* Refactor code to avoid strong coupling between far away code.
Pull Request: https://projects.blender.org/blender/blender/pulls/132728
`GREASE_PENCIL_OT_layer_reorder` operator is not exposed in UI.
Alternative options exists for rearranging layers/groups: drag-drop and
`grease_pencil.layer_move()`.
As discussed previously in chat, remove the operator code.
Pull Request: https://projects.blender.org/blender/blender/pulls/132299
This patch redesigns the Glare node to improve the user experience. The
improvements are as follows.
Two new outputs were added, Glare and Highlights. The Glare output gives
the generated glare without the input, and is useful when the user wants
to adjust the glare before adding it to the image. The Highlights output
gives the areas that are considered highlights when computing the glare,
and is useful if the user wants to temporally check the highlights while
doing adjustments or wants to use those as a base for creating a custom
glare setup.
The Mix node option was removed and a new Strength single value input
was added to serve the same functionality. The Mix option had a range of
[-1, 1], where the [-1, 0] sub-range essentially controlled the strength
of the glare, 0 being full strength and -1 being zero strength. While
the [0, 1] range returned the generated glare with an attenuated version
of the image added, that is, it was useless except for the value of 1,
which returned the generate glare only.
Aside from being a very intuitive range, it also meant that the power of
glare can't be boosted beyond the full strength of, you guessed it, 0.
The newly added Strength input has a soft range of [0, 1] and can be
boosted beyond 1. If the users want the glare only, they can use the
newly provided Glare output.
The Size node option used for Bloom and Fog Glow was removed and a new
Size single value input was added. The Size node option had yet another
very intuitive range of [1, 9], and it was related exponentially to the
actual size of the Glare. For Bloom, the actual bloom size relative to
the image was 2^(Size-9), so a Size of 8 means the bloom covers half of
the image. For Fog Glow, the actual bloom size in pixels is 2^Size, so
the glare size is not relative to the image size and would thus change
as the image resolution change. Furthermore, the maximum possible glare
size was 512 pixels, and the user couldn't make fine adjustments to the
size.
The newly added Size input has a range [0, 1], where 1 means the glare
covers the entire image, 0.5 means it covers half the image, and so on.
That means it is consistent between Bloom and Fog Glow, it is relative
to the image size, it allows as large of a glare as possible, it is
continuous for Fog Glow, but not for Bloom because that requires an
algorithmic change that will be implemented separately.
The Threshold, Streaks, Streaks Angle, Iterations, Fade, and Color
Modulation node option was turned into a single value node input to
allow the option to be used in node groups.
---
Versioning was added to transfer node options into sockets, but it is
not all 1:1 versioning, since the old Size option was not relative to
the image size, so it depends on runtime information of the input size.
As a guess, we assume the render size in that case. Versioning the
[0, 1] range of the Mix option intentionally omits the attenuation of
the image input, because that is almost certainly not what the user
wants and was probably done thinking it controls the strength.
Glare code now sets the alpha channel to 1, that's because it was
already ignored in the mixing step, but now that we expose the Glare
output, we need to set it to 1. So this is not a functional change.
The get_glare_size() method was renamed for clarity since it now
conflicts with the newly added Size input.
---
This is a partial implementation of #124176 to address #131325. In
particular, it adjust existing functionality, it doesn't add any new
ones. Those will be added in separate patches.
Pull Request: https://projects.blender.org/blender/blender/pulls/132499
Consistently pass evaluated bake target objects to Cycles, instead
of using the original for this case. This way it can be matched with
evaluated objects being rendered.
Pull Request: https://projects.blender.org/blender/blender/pulls/132722
Selection shader changes the provoking vertex for edge selection.
Using a non default provoking vertex was not implemented in Vulkan
resulting in selecting a different edge then expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/132729
Depending on proxy size and scaling factor, the "does proxy cover
whole screen" code was producing wrong results, due to mismatched
resolutions it was working on: SeqRenderData at that point contains
proxy resolution (reduced), but SEQ_image_transform_final_quad_get
works at full resolution. The produced quad needs to be scaled down
to what the render context is operating at.
The `DeltaProjectionFunc` introduced in cbe2bb6755 was always using a
"worldspace" plane [which ignored the layer rotations for projections --
be it through actual layer transforms or object rotations].
So to resolve, use the appropriate axis of the (already available)
`layer_to_world` matrix.
Pull Request: https://projects.blender.org/blender/blender/pulls/132690
When the brush refactor project was in progress, the "Fake Neighbors"
feature used exclusively by the Pose brush was made more explicit.
However, the migration missed the usage of this data in the `flood_fill`
APIs.
This resulted in the option not affected unconnected topology islands
except when the Pose Origin Offset was non zero and using the Topology
mode of the brush.
To fix this, this commit updates the flood_fill APIs to take in the
pre-calculated fake neighbor data and use it when traversing connected
vertices and applying weights.
Pull Request: https://projects.blender.org/blender/blender/pulls/132610
With the brush asset project, the `Paint` `brush` and `eraser_brush`
properties were effectively turned into a convenient cache of the active
brush. A related operator, `paint.brush_set` was also removed in favor
of `brush.asset_activate`
While this is technically a breaking change to the API, it currently
seems better to align this property with expected usage & other recent
changes rather than allow users to set a property that may not behave as
expected.
There are two currently known side effects that setting this property
via the Python API has that the equivalent call to brush.asset_activate
does not:
* Changing this property via the console or script, peforming a stroke
and then undoing the stroke causes the active brush to change - this
directly contrasts with the normal experience of using the asset
shelf where brush changes are not affected by undo
* The asset shelf itself does not update the currently active brush
until a subsequent mouseover
Pull Request: https://projects.blender.org/blender/blender/pulls/131991
Before, it was only possible to clear the entire cache at once or to rely on
automatic clearing when it gets full. This patch adds the ability to remove
cached data based on a predicate function.
This is useful for #124369 for partially invalidating the cache for some files.
Pull Request: https://projects.blender.org/blender/blender/pulls/132605
The issue was that the propagation of referenced anonymous attributes treated
geometry outputs of the foreach zone as "normal". That means that every
anonymous attributes referenced by the input socket would also be referenced by
the output socket.
However, just like in the repeat zone, this so called "propagate relation" needs
some special behavior, because anonymous attributes references created inside a
zone have to remain inside that zone. Instead, the output node creates a new
anonymous attribute reference that is used outside of the zone.
Note, this is the same as #132560 but also implements the right-to-left pass,
whereas before only the left-to-right pass was implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/132607
There were two separate issues which have a very similar solution:
* When loading the .blend file, the `scene->rigid_body_world->group` collection
pointer has to be mapped to the actual address. However, that was not done
because `BKE_rigidbody_world_id_loop` was a stub when `WITH_BULLET` is off.
That resulted in the collection pointer having an invalid address.
* When closing the file, there was some issue because of incomplete code for
copying rigid body related stuff for the depsgraph and hence there was some
unexpectedly shared ownership which leads to a use-after-free. Here the fix is
to move the copy code out of a `#ifdef WITH_BULLET` block too.
Since none of the moved code actually needs bullet, it seems fine to move it.
The code should be exactly the same in the common case with `WITH_BULLET` is on.
Pull Request: https://projects.blender.org/blender/blender/pulls/132697
Papercut reported in #132293.
Allow explicitly disabling this behavior for a button, and do so for the
big preview asset shelf popup button. It gets more in the way than it's
useful in this case.
Mistak in 39f7c506b5.
The VBOs need to be allocated! And we can just use a single dummy
type as well, rather than using the type from the attribute request
which is meaningless in this case.
PR #129315 refactored polylines. The shaders now attaches the vertex
attributes as SSBOs. Adding a workaround for polyline shaders to
extract the correct vertex formats when called via Python.
Pull Request: https://projects.blender.org/blender/blender/pulls/132689
Confusing error messages are printed when requesting a clipped builtin
shader via Python that does not exist.
This PR will remove the confusion of the messaging:
- Replaced BLI_assert_unreachable with an assert as it is reachable
code.
- Adding clipped configuration for POLYLINE_UNIFORM_COLOR
Pull Request: https://projects.blender.org/blender/blender/pulls/132686
This renames the struct `Sequence` to `Strip`.
While the motivation for this partially comes from
the "Sequence Design" #131329, it seems like this
is a good refactor whether the design gets implemented
or not.
The `Sequence` represents what users see as strips in the
VSE. Many places in the code already refere to a `Sequence`
as "strip". It's the C-style "base class" of all strip types.
This also renames the python RNA type `bpy.types.Sequence`
to `bpy.types.Strip` which means that this technically breaks
the python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/132179
The max length of the RNA property `ActionSlot.identifier` was set
incorrectly. The setter code did manage the length properly, but the
getter was checking agains that incorrect max length, and rightfully
complained.
Pull Request: https://projects.blender.org/blender/blender/pulls/132691
This PR will add timeline semaphores to be required. It doesn't use
the timeline semaphores yet, but as multiple developments will
rely on it it is better to add the requirement.
Pull Request: https://projects.blender.org/blender/blender/pulls/132683
Framebuffers are getting freed in the GPUContext base class destructor. But
the framebuffer destructors use the MTL/VK/GLContext derived class, whose
destructor has already completed at this point. So these contexts are no
longer valid to use.
Now free the framebuffers earlier.
This caused ASAN warnings, it's not known to cause actual bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/132504
This code is now only used by annotations but was not updated.
Uses the right properties now and removes the layer mask
one which is not used by annotations.
Pull Request: https://projects.blender.org/blender/blender/pulls/132030
Move the `ID_TAG_ID_LINK_PLACEHOLDER` bit of `id->tag` to
`id->runtime.readfile_data->tags.is_id_link_placeholder`. It also
introduces the necessary stucts and allocation/freeing code.
Old code:
```cpp
if (id_tag & ID_TAG_ID_LINK_PLACEHOLDER) {
```
New code:
```cpp
if (readfile_id_runtime_tags(id).is_id_link_placeholder) {
```
where `readfile_id_runtime_tags(id)` is a getter for
`id->runtime.readfile_data->tags` that is null-safe for
`id->runtime.readfile_data`. The `readfile_data` is not allocated in
these cases:
1. When reading undo steps, because that doesn't have to deal with
versioning or linking (which are the sole purposes for this
struct).
2. When linking from another file (for example from the 'Link...'
operator). The just-linked IDs will have the `readfile_data`
struct, but already-loaded IDs will already have had those freed.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/132169
Design Task: #131695
Fix bone snapping failure by removing the Armature bounding box check.
That check would go over all the bones, compute the total bounding box,
just to avoid the remaining code (which goes over all the bones anyway).
Not sure why the code is causing these issues, but I'm guessing it's due
to getting the bounding box in the wrong space (could be a bug
introduced in 6212c3c374). Since this call doesn't look like it's an
actual optimization to me, I think it's better to remove it.
Pull Request: https://projects.blender.org/blender/blender/pulls/132602
