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
This gives users the ability to control the size of tooltip text
separately from other text styles. This is an accessibility issue
in that users with low vision can choose to make these larger than
the working text.
Pull Request: https://projects.blender.org/blender/blender/pulls/125147
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.
Originally added in ed9c0464ba.
`last_visited_vertex` was never assigned to inside the flood fill loop,
therefore the following conditional to check if it had been set would
always be false, meaning that `forms_loop` was always false.
Pull Request: https://projects.blender.org/blender/blender/pulls/125344
Part of #118145
Both int indices and PBVVertRef objects are used in multiple places
throughout the sculpt_boundary.cc code. This commit removes the
external-facing PBVHVertRef in favor of the int index to make further
refactoring of the methods that use this data easier.
Pull Request: https://projects.blender.org/blender/blender/pulls/125274
Currently, the SculptBounary struct initializes and stores an array of
distances from the original boundary vert. However, this data is only
actually stored and calculated for boundary vertices, every other vertex
is initialized to 0.0f.
Pull Request: https://projects.blender.org/blender/blender/pulls/125278
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
When holding CTRL using the draw tool to erase, the size of the cursor
was using the size of the eraser brush. This is not the expected behavior
when using the eraser from the draw tool. It should respect the size
of the brush used by the draw tool instead.
This fixes the issue by computing the right size when the eraser operation
is invoked. The size is then stored in a runtime field, so that the cursor
rendering callback can use the cached size.
Pull Request: https://projects.blender.org/blender/blender/pulls/125225
This adds two new nodes:
* `Grease Pencil to Curves`: Converts each grease pencil layer into an instance
that contains curves.
* `Curves to Grease Pencil`: Converts top-level curve instances into grease
pencil layers.
This opens up many new opportunities:
* Use grease pencil as input to other procedural systems that don't necessarily
output grease pencil.
* Generate grease pencil from scratch using geometry nodes.
* Temporarily convert grease pencil data to curves to use more powerful features
for curves processing.
Some data on layers are not attributes yet unfortunately, so there is some
special case handling for the `opacity` attribute. This was previously discussed
at the geometry nodes workshop:
https://devtalk.blender.org/t/2024-05-13-geometry-nodes-workshop-notes/34760#grease-pencil-14
Pull Request: https://projects.blender.org/blender/blender/pulls/124279
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
