Loading GPv2 files was crashing after modifiers were removed in #125102.
The modifier type info structs were still used for some internal
purposes (`struct_name`, `free_data`, `foreach_ID_link`), but the info
was not registered any more.
Since we only need a small portion of the typeinfo and because GPv2
modifiers will never change, using simple functions with switch
statements makes more sense here than bringing back fully fledged
typeinfo struct registration.
Pull Request: https://projects.blender.org/blender/blender/pulls/125663
There was already code to handle active scene pointer for the window.
Simply replace it by a call to `wm_data_consistency_ensure`, which will
ensure that all potentially missing pointers in UI data get reset.
This adds a `geometry::smooth_curve_positions` function that
smoothes both bézier curves and all the other curve types.
Bézier curves are smoothed by joining the handle and control
points into a flat array, then using the 1D gaussian algorithm
and writing the resulting positions back into the left and right
handle positions as well as the control points. In general,
this works reasonably well and is similar to the results of the
other curve types.
Pull Request: https://projects.blender.org/blender/blender/pulls/125496
Previously, it was not possible to see detailed information about instances in
the spreadsheet. Only the attributes on the top level instances were shown. Now,
all nested instances can be inspected too.
Combined with #114910 this will make inspecting more complex geometry with the
spreadsheet much more feasible. It's also an important part of integrating
grease pencil into geometry nodes because it makes it more obvious how layers
are converted to curve instances.
The data-selection is split into two separate tree views now. One that selects
the geometry from the instance tree, and one that's used to select the geometry
component and domain within that geometry. We found that this works better than
combining both tree views into one (we tried that in #124186).
Pull Request: https://projects.blender.org/blender/blender/pulls/125293
This removes the legacy Grease Pencil modifiers from the code.
These should have already been inaccessible from the UI and hidden from
the user. The modifiers have been reimplemented for the new GPv3
data structure.
On top of the modifier code, some other related things have been
removed as well:
* Operators related to the legacy modifiers.
* Keymaps for the legacy modifier operators.
* Some bits of code that used modifier functions.
Some code has to be kept, because it is still used:
* The core line art code, which is used by the new line art modifier. It's
moved to `modifiers/lineart`.
* The DNA structs for the legacy modifiers. They are still needed for
conversion.
* A few kernel functions for the modifiers are kept (also for conversion).
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/125102
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
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
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.
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
Instead just compute the offsets as necessary. This avoids the need
to keep them in sync as the BMesh changes, though it requires passing
a few more arguments in the dynamic topology remeshing code.
This log is owned by SculptSession, it's a bit misleading
to store a pointer to it in the sculpt BVH tree, and having
multiple mutable pointers to objects should generally be
avoided anyway. Now just pass it to the remeshing function
which is the oinly place it was needed anyway.
Replace the `BKE_scene_cursor` functions with member functions
of the `View3DCursor` DNA struct. This makes using the cursor's
transform simpler, especially in newer C++ code.
Pull Request: https://projects.blender.org/blender/blender/pulls/124903
There were two issues:
* The target layer name was not copied over
* The thickness setting was being divided by two when it
resulted in thinner strokes.
Rename leftover references to action 'bindings' to 'slot':
- Two comments, and
- bunch of `bind_` variable prefixes, renamed to `slot_`.
No functional changes.
Add `#ifdef WITH_ANIM_BAKLAVA` to the blend file reading/writing code,
so that the Action layers & slots are ignored when Blender is built
without experimental features.
This ensures that any loaded Action is just treated as 'legacy' (which
is the only kind of Action non-experimental Blender should have to deal
with), which will also properly deal with the forward compatible data
written by !125065.
This fix was committed on the `blender-v4.2-release` branch as
1b7485f20892523942752f81239807b2eab0f00b.
Pull Request: https://projects.blender.org/blender/blender/pulls/125068
All image saving mechanisms in Blender ignores the color format for EXR
images, including Render Pipeline, Save Operator, and File Output nodes.
To fix this, we first allow EXR images to be BW for flexibility. Then we
adjust the EXR saving code to take into account the required number of
channels. This is only done for single layer EXR images. Multi-layer EXR
images correctly ignores the option.
Pull Request: https://projects.blender.org/blender/blender/pulls/124807
Though it results in more duplication currently, splitting these
could help to facilitate further performance improvements here
in the future, and it avoids passing a bunch of useless arguments
for the multires case.
These were mostly getting in the way of refactoring this code.
If the referenced problems actually happen, there would be
more obvious ways to observe the issues anyway.
This applies the same change as the previous commit to the bounds
of every BVH node. The bounds calculation can be changed to use
the standard functions from the regular BVH deformation.
In a simple test this makes building the sculpt BVH 64% faster.
I observed a change from 762ms to 464ms for a 1.9m vertex mesh.
This simplifies the BVH build process and potentially improves
its performance when parts of the geometry is hidden. The method
used to calculate whether a node is fully hidden is slightly different
too, vertex indices are used instead of triangle indices and a triangle
to face map.
Introduced in d527e3a6bd.
The change to update PBVH normals before destroying the PBVH to fix
shading on duplicate meshes issues had the unfortunate side effect of
causing crashes for multires due to a race condition. This commit
simply avoids performing this flushing for multires to allow for
further iteration in the future instead of reverting the offending
commit entirely.
Pull Request: https://projects.blender.org/blender/blender/pulls/125268
Part of #118145.
These days we aren't really benefiting from making PBVH an opaque type.
As we remove its responsibilities to focus it on being a BVH tree and look
to improve performance with data-oriented design, that will only become
more true.
There are some other future developments the current header structure
makes difficult:
- Storing selections of nodes with `IndexMask` for simpler iteration, etc.
- Specialization of node type for each PBVH type
- Reducing overhead of access to node data as nodes get smaller
- General C++ cleanliness and consistency
This PR moves `PBVH` to `blender::bke::pbvh::Tree` and moves `PBVHNode`
to `blender::bke::pbvh::Node`. Both are classes visible to elsewhere in Blender
but with private data fields.
The difficult part about the change is that we're in the middle of a transition
removing data from PBVH. Rather than making some data truly private I
chose to just give it the `_` suffix, since it will ideally be removed later.
Other things should be class methods or implemented as part of friend
classes. But the "fake" private status is much simpler for now and avoids
increasing the scope of this PR too much. Though that's a bit ugly, there's a
straightforward way to resolve these issues-- it just looks like the sort of
inconsistency you'd expect in the middle of a large refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/124919
In the case where the last layer is removed and all the drawings
have zero users, in the `remove_drawings_with_no_users` function
the `find_next_swap_index` lambda would return `false` on the
first call. Both `first_unused_drawing` and `last_used_drawing`
are `0` in this case. This meant that the `drawings_to_remove`
index mask would exclude the first drawing (because
`last_used_drawing` is the index of the first drawing) and not
remove it as it should.
To fix this, we check if `first_unused_drawing` is greater than zero.
If it is not, then we know all the drawings have to be removed.
Otherwise we only remove the drawings after
`last_used_drawing + 1`.
Pull Request: https://projects.blender.org/blender/blender/pulls/125318
This patch adds support for multi-pass compositing for EEVEE. This is
done by copying the passes used by the compositor node tree to the DRW
view data, which can then be accessed by the viewport compositor.
The viewport compositor will fallback to the viewport texture or an
invalid output of the passes were not initialized, this is currently the
case for any render engine that is not EEVEE.
A future optimization that we can do is eliminate the film pass copy
shaders and only copy the data that EEVEE rendered, which can be a
subset of the viewport for border rendering. This is not done at the
moment because not all engines support passes at the moment, so the
compositor expects full viewport passes.
Depends on: #123685, #123817, #123815.
Pull Request: https://projects.blender.org/blender/blender/pulls/123378
Regression from [0], drivers were tagged as being disabled with a flag
that was never cleared. Causing the label to be displayed for files
where the expressions were enabled and in use.
Resolve by clearing this flag on file load and when re-compiling
expressions - since an expressions block flag may be cleared if it
becomes a simple expression.
[0]: 1a8053939b
