Match function and declaration names, picking names based on
consistency with related code & clarity.
Also changes for old conventions, missed in previous cleanups:
- name -> filepath
- tname -> newname
- maxlen -> maxncpy
When including Python on the tooltips they are meant to be shown using
a monospaced font. This is the case in two of the four places that
python is shown, but not in the other two which include Tool tooltips.
This PR makes them all consistent.
Pull Request: https://projects.blender.org/blender/blender/pulls/125521
Fixes an issue where the original material of the node tree wasn't
connected to the right sockets in most situations after applying
EEVEE-Next shadow mode versioning.
Pull Request: https://projects.blender.org/blender/blender/pulls/125438
This adds the `curve_offsets` collection property.
The curve offsets can be used to get the points that belong
to a curve. They are the offset indices of the first point of
each curve. The first offset is always zero and the last offset
is the total number of points in the drawing.
This adds two new python functions:
* `curves.remove_curves(indices=None)`
* `curves.resize_curves(sizes, indices=None)`
By default, `remove_curves` will remove all curves. If `indices`
are provided, only the curves with the given indices are removed.
The indices have to be in ascending order and mustn't repeat.
The `resize_curves`function will change the number of points
for each curve. If no indices are provided, there must be as
many elements in `sizes` as the number of curves there is.
Otherwise, there must be one element in `sizes` per element
in `indices`. The `sizes` are the new size for a given curve.
If the new size for a curve is smaller, then the curve is
trimmed from the end. If the new size for a curve is greater,
then the end values will be default initialized.
Pull Request: https://projects.blender.org/blender/blender/pulls/125502
This removes the terminal periods automatically added to the end of
tooltip items. The current desire is to only end in period if there
are multiple sentences - so if there is one in the middle of the
description. This also converts our uses of lists to use space and
bullet, rather than just bullet or asterisks.
Pull Request: https://projects.blender.org/blender/blender/pulls/125460
The viewport compositor slows down complex scenes even if it has very
simple setups. That's because it internally computes previews which
involves a fair bit of CPU computation, however, those previews are
actually never written to the original tree, so previewers weren't
really visible so it is effectively redundantly computations.
To fix this, we double down on disabling previews for the viewport
compositor and avoid any redundant computations in that case.
Introduced with d527e3a6bd.
Cached values are tagged as dirty during the update step, this can cause
conflicts where we attempt to then flush then changes into the PBVH but
have not yet updated the mesh pointers and reinitialized them.
This commit forcibly initializes the underlying data to prevent such
cases from happening when flushing to the PBVH.
Pull Request: https://projects.blender.org/blender/blender/pulls/125396
This is a PR that is built on top of #122094 (thanks to @SietseB
for the initial work).
Adds the following properties and functions:
* `layer.frames`,
* `layer.frames.new(frame_number)`
* `layer.frames.remove(frame_number)`
* `layer.frames.copy(from, to)`
* `frame = layer.get_frame_at(frame_number)`
* `frame.drawing`
* `frame.frame_number`
* `frame.select`: the selection state of the keyframe in the dope sheet
* `frame.keyframe_type`
* `drawing = frame.drawing`
* `drawing.type` (`DRAWING`/`REFERENCE`)
* `drawing.user_count`: The number of keyframes that use this drawing
* `drawing.attributes`: attribute read/write access to the drawing data
To be able to access attributes on drawings, a new
`AttributeOwnerType::GreasePencilDrawing` is added.
The API in `BKE_attributes.h` is updated to handle this type.
In `rna_attributes.cc`, there is a new
`rna_def_attribute_group_grease_pencil_drawing` that defines the
attribute group. For this to work, it also defines its own rna
callback functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/124787
Rather than a manually managed union, use `std::variant` which is
generally safer. E.g. an invalid access will now throw an exception
instead of causing undefined behavior (which may or may not crash, or
cause a data corruption). Code is also simplified this way.
Pull Request: https://projects.blender.org/blender/blender/pulls/125494
This patch implements all baking operators for LineArt for GPv3.
The old baking operators are renamed with `_legacy_` to
distinguishing both when calling the operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/125079
While the python API for the legacy Grease Pencil object can be fully
deprecated, annotations still make use of the `bGPdata` DNA and
therefore need their own python API.
This removes `RNA_def_gpencil` entirely, but replaces parts of it
in `RNA_def_annotations` to make sure that annotations keep
working as before. Note that this is only a very small subset of the
legacy Grease Pencil API.
Technically, this "removes" python API functionality from annotations
because they are full Grease Pencil IDs, but the idea is to make them
simpler and encourage users to use Grease Pencil objects instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/125097
Use "asset storage" instead of just "storage", because there are other
members acting as storage (e.g. holding all catalog data), while this is
asset specific.
This was just rather useless level of abstraction. I heard from other
devs that these helper classes caused confusion, so better to avoid
this.
Now the asset representation has all the needed bits to create its full
path, blend-file path and asset library relative path. In fact only the
asset library relative path needs to be stored to make all this
available, since the asset representation already stores a reference to
the asset library owning it, so the paths can be recreated easily.
Missed after 'Set Snap Base' commit.
Just like in 3D View, UV editing can also benefit from selecting
multiple snap target elements.
The C++ code was already done, it was only necessary to edit the
interface.
Pull Request: https://projects.blender.org/blender/blender/pulls/124986
Though it amounts to the same thing for trivially destructible types,
conceptually `reinitialize` destructs old values before resizing. This
isn't necessary, and in the cases where it was used for a vector of
vectors (like vertex neighbor index storage), it could be slower.
I measured a few percent performance improvement for the smooth brush.
Also change some dynamically resized Arrays to vectors to make
use of amortized growth.
No functional changes intended.
The function `clear_keyframe` had more arguments than needed:
* The `bAction *` was always a nullptr
* the unused parameter `eInsertKeyFlags` was removed
* the rna path and the array index were merged with the `RNAPath` struct
Pull Request: https://projects.blender.org/blender/blender/pulls/125487
No functional changes intended.
This simplifies the arguments for the `delete_keyframe` function.
The `bAction *` was always a `nullptr` so I just removed it.
The rna path char array and the array index were merged into the `RNAPath` struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/125479
This was just a useless level of abstraction, where the asset library
would have functions with the same name, just to pass the call on to the
asset storage. Now asset library stores and manages the asset
representations itself directly.
This should simplify the asset system a bit. I heard from other devs
that these kind of helper classes caused confusion for them.
Blendfile uses the 'old (memory) address' of its data as 'uid' in the
blendfile. There should only be one block written for a given address
and a same ID (each ID define its own 'virtual address space').
This commit checks that this condition is met at wrtite time (except for
undo steps, for performances reasons).
Tooling part of the investigations on #125001.
Mostly to allow leak-free early exiting from functions generating the
tooltip data, otherwise cleanups have to be duplicated. But using smart
pointers is good practice in general. Also use references instead of
pointers, to indicate that null is not an expected value.
This adds initial support for transforming bezier handles.
In some cases, the pivot is not correct, e.g. when scaling or rotating
one left or right handle. This will be added in a separate PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/123110
The "radius" mode shows circles for the radius in which new lines are
formed. However, all circles currently remain visible when a point is
found in the circumference. This patch removes circles once they add
a line.
Followup fix for #125229.
Pull Request: https://projects.blender.org/blender/blender/pulls/125475
When writing a layered Action to disk, take the F-Curves from the
first keyframe strip and write that as `action.curves` as well. This
will make older Blender versions see those curves and load them
properly.
Only the curves for the first slot are written this way. This means
that any legacy Action that was converted to a layered Action will be
loaded again properly by older Blender versions. Of course this is
limited to a single layer, single strip, and single slot -- once the
newer features are used, older versions of Blender will not be able to
see this extra data.
When an Action contains multiple slots, so with animation for multiple
distinct objects, the forward compatibility becomes a bit iffy. Older
versions of Blender will just see a legacy Action, with its legacy
semantics, and thus all objects that use that Action will receive the
exact same animation data. I don't think there's a way around this.
(_Unless we start breaking up Actions into an Action per slot, alter
the assignments, and then store metadata so that modern Blenders can
reassemble them. I do not think this is a good idea._)
Ref: #124714
Pull Request: https://projects.blender.org/blender/blender/pulls/125065
As well as takes text color transparency into account. That is, text
"shadow" now virtually casts shadow of however the text itself + outline
looks like. The result is blurred, and extra shadow color tint and
transparency is applied.
Performance testing: seems to be slightly faster than before in my tests.
Probably because the shadow "image" that is now blurred only contains
one byte per pixel (the transparency), instead of full uchar4 per pixel
(with only the "transparency" being blurred).
I have extended sequencer render tests to better cover various text
outline/shadow/box combinations.
Pull Request: https://projects.blender.org/blender/blender/pulls/125445
Grease Pencil objects are not visible when using the viewport
compositor. That's because since the introduction of multi-pass
compositing, the compositor now access the combined pass written by
EEVEE, which does not include GP.
To fix this, we skip writing the EEVEE combined pass, then read the
viewport texture for the combined pass as a special case, which should
include GP.
The reported issue was that Texture Mask mapping behaves wrong (wrong
coordinates -- seemed as if it was always using `Tiled` mapping), but
the issue actually spawns to more brush features (the coordinates were
wrong not only for mask mapping but for the actual texture mapping, too,
next to randomness and offsets/angles being ignored, jitter was also not
working at all).
On the code side, for the reported issue, we can observe that
`BKE_brush_sample_masktex` relies on `UnifiedPaintSettings`
`mask_tex_mouse` to be set. Other stuff mentioned above also ends up in
`UnifiedPaintSettings`.
In regular painting (has its own modal), this gets updated in
`paint_brush_stroke_add_step` by calling `paint_brush_update` before
adding another step. This is not called when doing painting from python
(here the modal handling happens in py, usually
`bpy.ops.paint.image_paint`is executed immediately for each mousemove).
Jitter is also doing stuff in `paint_brush_stroke_add_step` -- equally
ignored from above py workflow.
So to resolve, now make sure we are calling the necessary stuff in
`paint_exec` as well.
NOTE: There was a similar case in
9aa20a0979, where we could simply move
part of the necessary code from `paint_brush_update` to
`paint_stroke_new`
NOTE: `Rake` is still ignored, depends on previous positions, cannot be
supported
Pull Request: https://projects.blender.org/blender/blender/pulls/124582
