The `FILE_PT_operator` panel used in the file browser does not correctly
allow the new UI layout panels to be drawn correctly.
The layout panels depend on drawing the background so that different
colors can denote each panel section. In the case of `FILE_PT_operator`,
this background drawing is skipped entirely leading to a situation where
there's no panel delineation at all.
Forcing the background to be drawn leads to a second problem where
the "typical" panel colors are not used in this part of the file
browser. We need to match the surrounding area otherwise a much
lighter shade of gray will be used and look out of place.
The fix is to extend the processing for PANEL_TYPE_NO_HEADER to account
for both of the above situations.
Pull Request: https://projects.blender.org/blender/blender/pulls/118231
This patch adds support for canceling compositor evaluations for the
realtime compositor. Only the canceling of the Denoise operation is
supported for now. That's because inter-operation canceling is not
feasible since all work will have been submitted to the GPU driver
before the user is able to cancel. So some kind of blocking operations
would need to used to actually allow canceling, which is not something
we are going to investigate as part of this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117725
Previously only dropping file-paths was supported by the WM logic,
even though GHOST supported strings.
This is used for dropping a text selection as well as URL's
(on X11 & Wayland).
Add WM_DRAG_STRING, created from GHOST's GHOST_kDragnDropTypeString.
If hooks are not unregistered Blender will report a leak on exit.
Store the hooks as unique_ptrs to remove manual memory management and
encapsulate the previous global list inside a function. These changes
ensure that everything is cleaned up on termination.
Also makes a small change to the hook documentation for a missing
`import` statement.
Pull Request: https://projects.blender.org/blender/blender/pulls/118294
This adds group ids to the `Sample Nearest Surface` node. This allows e.g. finding
the closest point on a specific mesh island.
Three new sockets are added:
* `Group ID`: Is evaluated on the face domain and splits the input mesh into multiple
parts, each with its own id.
* `Sample Group ID`: Determines in which group the closest nearest surface is detected.
* `Is Valid`: Outputs true if a nearest surface was found, it's false if the group is empty.
Pull Request: https://projects.blender.org/blender/blender/pulls/118150
Use IDTypeInfo data as much as possible, to avoid too many functions
`switch`ing over all ID type values.
Now only `BKE_idtype_idcode_to_index` and `BKE_idtype_idfilter_to_index`
do that, all others are using one of the above to retrieve the valid
IDTypeInfo and return data from it.
Also tweaked some namings to make them more consistent.
No behavioral changes expected here.
This data was 'hidden' away in a util in
`lib_query.cc`, which made it hard to discover and keep up-to-date.
However, as shown by e.g. #108407, critical low-level features in ID
management code, such as remapping, now rely on this information being
valid.
Also simplify `BKE_library_id_can_use_filter_id` and
`BKE_library_id_can_use_idtype` to make them more generic, relying on
IDTypeInfo to retrieve IDtype-specific info.
No behavioral changes expected here.
Own d38824bc02 mistakenly added the 'FILTER_ID_KE' to the list IDTypes
usable by Lights (`ID_LA`) instead of Lattices (`ID_LT`)...
Note that this did not cause any additional issue, but only missed part
of the expected fix.
Now that attributes use implicit sharing, copying CurvesGeometry
is relatively cheap, and the complexity of this function isn't worth
the remaining optimization of avoiding user count updates.
When using proportional editing in the Graph Editor or the Dope Sheet,
the GUI displays a circle suggesting that the influence is limited in x and y.
In reality those editors only look at the x-axis to determine which keys to influence.
This PR fixes that by adding a new drawing function for those editors that
draws 2 lines to indicate a range.
In theory this can be a feature in other 2D editors in the future.
I assume the VSE would benefit from this as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/118196
These reports were embedded in the window manager DNA,
but they were always cleared when reading it from files. It's clearer
to just not store the reports in files at all. I also moved the reports
initialization and freeing to the constructor and destructor of the
runtime class.
This is the only place `ReportList` was embedded in DNA, so
after this we can move that to use C++ features if we want.
Pull Request: https://projects.blender.org/blender/blender/pulls/118329
This PR disables the `SCULPT_OT_sample_color` and `SCULPT_OT_set_pivot_position` operators and the following actions that correspond to them when attempting to operate on invisible objects:
* Set Pivot
* Sample Color
| Set Pivot | Sample Color |
| --- | --- |
|  |  |
### Limitations
* All of the operators invoked by a menu option do not indicate to the user that they are currently invalid or will not operate due to the mesh being invisible, potentially leading to a confusing user experience.
Addresses part of #112371
Pull Request: https://projects.blender.org/blender/blender/pulls/118306
This PR disables the `SCULPT_OT_face_sets_init`, `SCULPT_OT_face_sets_create`, `SCULPT_OT_face_sets_edit`, `SCULPT_OT_face_sets_randomize_colors`, `SCULPT_OT_face_set_change_visibility`, `SCULPT_OT_face_set_box_gesture`, and `SCULPT_OT_face_set_lasso_gesture` operators and the following actions that correspond to them when attempting to operate on invisible objects:
* Face Set From Masked
* Face Set from Visible
* Face Set from Edit Mode Selection
* Initialize Face Sets
* Grow Face Set
* Shrink Face Set
* Randomize Colors
* Toggle Visibility
* Hide Active Face SEt
* Box Face Set
* Lasso Face Set
| Init | Create | Edit |
| --- | --- | --- |
|  |  |  |
| Randomize Colors | Visibility | Gestures |
| --- | --- | --- |
|  |  |  |
### Limitations
* All of the operators invoked by a menu option do not indicate to the user that they are currently invalid or will not operate due to the mesh being invisible, potentially leading to a confusing user experience.
Addresses part of #112371
Pull Request: https://projects.blender.org/blender/blender/pulls/118228
This PR disables the `SCULPT_OT_mesh_filter`, `SCULPT_OT_cloth_filter`, and `SCULPT_OT_color_filter` operators and the following actions that correspond to them when attempting to operate on invisible objects:
* Mesh Filter
* Color FIlter
* Cloth Filter
| Mesh & Cloth | Color |
| ---- | --- |
|  |  |
Addresses part of #112371
Pull Request: https://projects.blender.org/blender/blender/pulls/118172
This PR disables the `SCULPT_OT_mask_init`, `SCULPT_OT_mask_filter`, `SCULPT_OT_mask_by_color`, and `SCULPT_OT_mask_from_cavity` operators and the following actions that correspond to them when attempting to operate on invisible objects:
* Random Mesh
* Per Vertex
* Per Face Set
* Per Loose Part
* Smooth Mask
* Sharpen Mask
* Grow Mask
* Shrink Mask
* Increase Contrast
* Decrease Contrast
* Mask By Color
* Mask From Cavity
| Init | Filter | By Color | From Cavity |
| ---- | --- | --- | --- |
|  |  |  | 
### Limitations
* All of the operators invoked by a menu option do not indicate to the user that they are currently invalid or will not operate due to the mesh being invisible, potentially leading to a confusing user experience.
Addresses part of #112371
Pull Request: https://projects.blender.org/blender/blender/pulls/118173
The compositor assumes the entire viewport as its compositing space even
in camera view. The current design decision was to limit the compositing
space by the camera region only if the camera passepartout is opaque,
that is, areas outside of the camera are not visible.
This patch changes that behavior to always limit the compositing space
by the camera region. The downside is that areas outside of the camera
will be left uncomposited.
This is useful to match viewport compositing to final render compositing
in terms of maintaining the same space, but not necessarily the same
resolution. However, this still has the limitation that space will be
different when the camera region intersects the viewport, since we only
composite their intersection in that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/118241
In some/many cases, an `ImBuf` is allocated, and all the pixels are
immediately filled by some code. Doing the memory clear within allocation
is just memory traffic for no good reason.
Add a flag to skip initialization of ImBuf pixels (IB_uninitialized_pixels)
and use that in some parts of VSE effects/rendering/cache/scopes, as well
as image loading code.
Rendering out VSE movie, on Windows/VS2022/Ryzen5950X:
- Sprite Fright: 443sec -> 414sec (takes 93% of previous time)
- Gold previs: 367sec -> 325sec (takes 88% of prev time)
Pull Request: https://projects.blender.org/blender/blender/pulls/118321
The GPU compositor does not take the border region into consideration,
which means it reads more than it should, leading to corruption. Fix
this by taking the border region into account when computing render
width and height.
