I ran into this issue a while ago too, where the vertex iteration
macro didn't process all of the vertices. I didn't figure it out yet,
but it makes more sense in the context of the surrounding code
to specialize this anyway.
The issue was that the clamping to the bounds happened before the rounding to the increment step.
In the reported case this led to a divide by 0 error.
The fix is to do the increment first, then the clamp to bounds.
This was reported by Raymond Luc on #117287
Pull Request: https://projects.blender.org/blender/blender/pulls/119367
Unfortunately the only versioning code that can "properly" add data-
blocks is not run when linking or appending (`do_versions_after_setup`
has details). The versioning has to be done manually for this case.
Fortunately that is simple since the versioning function already just
operators on a main database.
This could happen if objects were hidden after going to editmode and
knife was used on them.
In that case, raycasting would (rightfully) fail, but there is a
fallback in place using the back-buffer selection method (in which the
hidden object is still present). So a face would be found, but this
makes all following code confusing/wrong since we are working with
coordinates / faces under the assumption there would be a valid/
corresponding object to it in `KnifeTool_OpData` > `objects` -- which is
not the case...
So to resolve, just check if the object is visible before calling
`EDBM_face_find_nearest` in knife code.
Alternativeliy, we could also add a check for Base viewport visibility
to all the bmesh `find_nearest` functions (a bit hesitant though since i
am not sure this would be desired in all cases)
Pull Request: https://projects.blender.org/blender/blender/pulls/119383
Fix of error introduced in c31718649d. Attribute names will
be freed on domain resizing. This mean, ref-names which is attribute
ids is will be invalid. To avoid this, make sure names will be gathered
only after resize. To avoid unnecessary topology map computation before
mesh resize, check if attributes on required domain exists, instead
of gathering them and check if span is not empty.
Pull Request: https://projects.blender.org/blender/blender/pulls/119242
With some data-type conversions we can do a best-effort conversion of
UI data like default values and min and max to the new data type.
This can help to make Python scripts simpler and to avoid bugs like
#105965.
Pull Request: https://projects.blender.org/blender/blender/pulls/106161
Added a null check for RE_GetRenderLayer() which could possibly return
null and then stored in `render_layer`, in order to prevent members of
`render_layer` being accessed in RE_pass_find_by_name(), and thus solved
the segmentation fault.
Pull Request: https://projects.blender.org/blender/blender/pulls/119200
The core of the issue was that `sculpt_flag` was used by three different enums (`eGP_Sculpt_Flag`, `eGP_Sculpt_Mode_Flag`, and `eBrushFlags`). This resulted in the flag getting overriden because `ENUM_OPERATORS` expected the maximum value of `eGP_Sculpt_Flag` to be `(1 << 3)` which it wasn't.
The `sculpt_flag` was exposed through python as `"direction"`.
In the UI this meant that it was effectively used as `brush.direction`. This fix replaces `brush.gpencil_settings.direction` with `brush.direction`.
It also makes sure `sculpt_flag` is only ever used with values from `eGP_Sculpt_Flag`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119373
This commit adds the `SCULPT_OT_hide_show_lasso_gesture` and the
corresponding Lasso Hide tool.
* Exposes the selection type for both the lasso and box hide tools
as a option in the header
* Adds functionality into `sculpt_gesture.cc` for handling lasso
selections with the `Outside` selection type
For `SelectionType::Outside`, the current implementation opts to not
do any filtering on the PBVH node level due to cases where the node
is mostly covered by a single gesture.
Addresses one of the tools in #80390
Pull Request: https://projects.blender.org/blender/blender/pulls/119140
The regression happened because object instances were turned into normal geometry
instances which don't have object-level visibility settings. Long term, this may not be
something we can support, but it's also not something we should break unnecessarily
and accidentally.
Pull Request: https://projects.blender.org/blender/blender/pulls/119370
I think the issue is that the run-node-group operator overwrites the data stored in the
`Mesh` while mesh edit mode operations typically only change the `BMEditMesh`. It
seems like that causes issues because the mesh edit mode undo stack does not
keep track of changes to the `Mesh`. When hitting undo, Blender assumes that the
`Mesh` stored in the object has not changed and therefore it does not have to be
read from the undo step again.
The preliminary fix implemented here is to just not change the `Mesh` but only the
`BMEditMesh` like any other edit mode operator. This seems to solve the issue.
I haven't quite figured out yet how to tell the undo system that the `Mesh` has to be
loaded from the undo step when undoing out of mesh edit mode. Doing that might
provide a better solution.
Pull Request: https://projects.blender.org/blender/blender/pulls/119015
The function didn't return early in case the domain was empty.
The fix makes sure we return an empty `MutableSpan` in this case
(add doesn't try to create a new custom data layer).
Adds copy and paste images functionality to and from the image editor
in Linux/Wayland clipboard.
Currently the only format supported is PNG.
Ref: !119117
