Every call to BM_faces_join and BM_faces_join_pair has been adjusted to
provide the new face pointer, and a BLI_assert_msg has been added so
that doubles are now consistently identified and flagged as a problem.
BM_faces_join is now also capable of automatically reusing a double
when it is found. This new behavior is currently unused at this point.
Future patch-sets will begin to use it, allowing simplification of
calling functions.
Ref: !137406
Remove long-deprecated constraints that will likely never be
implemented in this form.
- Rigid Body Joint Constraint was removed in 2.80, but some references
remained in the code. Versioning code was written that tried to
remove them on load, but since constraint initialization code sets
the type to CONSTRAINT_TYPE_NULL before versioning gets a chance,
the versioning code ended up never running. This has all been
removed.
- Python/Script Constraint never worked since 2.50 and showed an error
message in the UI panel.
These constraints now load as 'null' constraint, as seems to be
(looking at the code) the way that Blender currently deals with
removed constraint types. These still show up in the outliner and
python API, but have no UI panel. Removing such constraints completely
will be left for another time, as it is beyond the scope of removing
these two specific constraint types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136672
Some paths in Blender support the `//` prefix for blend-file relative
paths however this is not communicated anywhere.
Support declaring this with a new flag which can be applied to filepath
& dirpath typed properties.
This is used to:
- Show red-alert when "//" are used in paths which don't support a relative prefix.
- Show a warning in the tooltip that the relative suffix is used when unsupported.
- Python warns if this prefix is ever used in an assignment or
function argument.
Resolves#133456.
Ref !137060
Part of #82877
When drawing specialized cursors for the different paint modes via the
`wmPaintCursor` draw callback, tablet tilt direction is unavailable to
use to customize the drawing for the user.
To enable this functionality, this commit adds the `x_tilt` and `y_tilt`
data read while processing MOUSEMOVE events to the `eventstate` variable
so it can be used by consuming functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/137189
This is getting in the way of making the
GPUShader API more threadsafe.
This getter already doesn't work for vulkan
and Metal, and has very limited usage.
Keeping the python function to avoid errors
and display a deprecation warning.
Pull Request: https://projects.blender.org/blender/blender/pulls/136983
When debugging with gdb in vscode, the stuff I print when executing a script in
the text editor does not show up in the terminal. It does work when I flush
explicitly though using `print(..., flush=True)`. This is quite annoying.
The solution is to always flush `stdout` and `stderr` automatically when running
a script. This is done using the CPython API, as just using
`fflush(stdout/stderr)` did not solve the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136632
In Geometry Nodes a geometry is represented by a `GeometrySet`. This is a
container that can contain one geometry of each of the supported types (mesh,
curves, volume, grease pencil, pointcloud, instances). It's possible for a
`GeometrySet` to contain e.g. a mesh and a point cloud.
This patch creates a Python wrapper for the built-in `GeometrySet`. For now,
it's main purpose is to consume the complete evaluated geometry of an object
without having to go through complex hoops via `depsgraph.object_instances`. It
also also allows retrieving instances that have been created with legacy
instancing systems such as dupli-verts or particles.
In the future, the `GeometrySet` API could also be used for more kinds of
geometry processing from Python, similar to how we use `GeometrySet` internally
as generic geometry storage.
Since we can't really have constness guarantees in Python currently, it's
enforced that the `GeometrySet` wrapper always has its own copy of each geometry
type (so e.g. it does not share a `Mesh` data-block pointer with any other place
in Blender). Without the copy, changes to the mesh in the geometry set would
also affect the evaluated geometry that Blender sees. The copy has a small cost,
but typically the overhead should be low, because attributes and other run-time
data can still be shared. This should be entirely thread-safe, assuming that no
code modifies implicitly shared data, which is forbidden. For historic reasons
there are still cases like #132423 where this assumption does not hold in all
cases. Those cases should be fixed. To my knowledge, this patch does not
introduce any new such issues or makes existing issues worse.
Pull Request: https://projects.blender.org/blender/blender/pulls/135318
While using constructors in Operator classes is _really_ not
recommended, BPY code was a bit too eager to overwrite existing errors
with its own generic messages.
Now only generate these exceptions if there is no other exception
already set.
- Manually check over all direct calls to operator callbacks
ensuring the result isn't assigned to an int.
- OPERATOR_RETVAL_CHECK() now fails unless a wmOperatorStatus is used.
- Check the return values of direct calls to callbacks.
- Remove invalid check for the return value of rna_operator_check_cb.
- Use the variable name `retval` as it's most widely used.
- Move the assignment of `retval` out of the `if` statement in
sculpt/paint operators because it prevents assigning the result
`const` variable.
Add support for using BLF to draw into an ImBuf image buffer.
Once the imbuf context has been set, draw calls for that font_id will draw into the image.
This works by binding an imbuf to BLF which is then used as the target when drawing.
```
with blf.bind_imbuf(font_id, imbuf):
blf.draw_buffer(font_id, text)
```
See the example in the Python API documentation for reference.
The following BLF API's have been added to support a Python context manager.
- `BLF_buffer_state_push`.
- `BLF_buffer_state_pop`
- `BLF_buffer_state_free`
Ref !135772
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135852
