Blender would crash when trying to move/duplicate, etc. some keyframes.
This was because the `convert_type_get` function in the transform code
would return the wrong transform type `TransConvertType_GreasePencil`
instead of `TransConvertType_Action`.
The fix makes sure that we only return the
`TransConvertType_GreasePencil` in the 3d viewport.
When the object was transformed, the eraser would no longer work.
This was because the transformation of the positions to screen space
did not take the transforms into account.
This fix adds the transforms to the erasing operation.
This issue happend when a geometry nodes modifier wouldn't output grease
pencil geometry. In this case, we write an emtpy grease pencil
data-block to the evaluated `geometry_set`. But we don't update the
`eval_frame` that indicates on what frame the grease pencil data-block
was evaluated on.
The fix makes sure we update the `eval_frame` even if the output is
empty.
Additionally, there was a missing return in the
`get_evaluated_grease_pencil_drawing_deformation` function that lead
to an empty `deformation.positions` span.
The fix makes sure we return the correct deformation with the correct
positions.
Don't log wm.operator operator properties when no properties
are stored/loaded, this was noisy, especially for the
INFO_OT_reports_display_update operator when runs from a timer.
When retrieving a color attribute to paint it, the layer data needs to
be unshared so that it doesn't modify data from separate meshes.
In the past I think we've unknowingly avoided this problem by porting
code to the new attribute API. I've been refactoring `PBVH` and
`SculptSession` to make that possible (removing the long-lived
layer pointers in the two structs). But that wouldn't fit as a bug fix.
In the meantime, make sure the color attribute data is un-shared
and separate "for read" and "for write" versions of the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/114119
A curve with only two points shouldn't be considered cyclic. Otherwise
a duplicate edge is added between the points. This fixes the utility
that calculates the segment count to account for this and adjusts
other code to account for that as necessary. Curves now evaluate
correctly to a single evaluated segment in this case (in the case of
Bezier and NURBS curves, it depends on the resolution though).
Co-authored-by: Dalai Felinto <dalai@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114095
The PBVH is given the evaluated positions from the end of the modifier
stack, but then updates normals from the original mesh based on those
positions. This causes a feedback loop, even when in vertex paint mode.
As mentioned in a comment, calculating these normals and duplicating
the arrays is quite wasteful. But it's necessary since the PBVH always
assumes we are interested in modifying the positions, and also always
retrieves the normals from the original mesh too. Those things would
be good to untangle at some point too, but for now this change is small
and helps to clarify the situation as well.
Caused by: b339e3937d
Pull Request: https://projects.blender.org/blender/blender/pulls/114118
`EdgeHash` was replaced by `VectorSet`, but the changes in the data
structure hid some other changes, causing incorrect indices to be used.
Instead use `Map` and explicitly build the indices similar to how they
were counted in a separate loop before.
Caused by: 425b871607
When using Voronoi shader nodes on legacy Intel platforms (HD4400) Blender would crash
due to a driver bug. The bug is related to generating the `fractal_voronoi_x_fx` functions.
It doesn't effect all drivers, but mainly from vendors that don't allow installing the official
intel drivers.
We have tried several approaches including using unique function names and unroll only the
function of the body. But none worked on the failing platform.
In the future we could solve this by including our own GLSL compiler, but that is still very
experimental and requires a lot of testing.#113938
Pull Request: https://projects.blender.org/blender/blender/pulls/113834
The goal is to make it possible to have more or less reliable way
to perform performance comparisons of changes in algorithms used
in dynamic topology.
This change allows to run Blender with the following arguments:
blender --log "sculpt.detail,pbvh.bmesh" --log-level 2
and see timing of dynamic topology flood-fill operation, as well as
individual timings of edge subdivision/collapsing.
Pull Request: https://projects.blender.org/blender/blender/pulls/114099
Regression from [0] where the key-map was attempting to load preferences
for key-map items for add-on operators which were not yet defined.
Resolve by postponing keymap updating until after loading add-ons.
[0]: 6de294a191
The main goal of this patch is to turn `node.inputs[...]` and `node.outputs[...]` into
the main way to lookup sockets on a node. Currently, it's used for that sometimes,
but often it is not, because it does not work in all cases. More specifically, it does
not work when a node has multiple sockets with the same name but different
identifiers, which is relatively common.
This patch proposes to make the string lookup more convenient, more useful and
less prone to breaking after changes in Blender.
This is achieved by changing how the lookup works:
* First, it tries to find an available socket with an identifier that matches the given
key. This is checked first, it makes sure that every socket can be accessed by its
identifier. The identifier matching is currently disabled in some nodes where we
want to change identifiers soonish.
* If that didn't work, it tries to find an available socket with a matching name. This
is often convenient because it generally matches what can be seen in the UI.
Furthermore, it's also necessary to avoid breakage with old usages of this lookup
function.
* If both options above didn't work, it checks whether the given key matches any
socket name/identifier that the node used to have in the past, but has been
renamed for whatever reason. This mainly exists to avoid breaking scripts by certain
kinds of changes in the future. This is not included in this patch.
Note, previously, string lookup would also find unavailable sockets. This is disabled
now, because the way we handle unavailable sockets internally is likely to change.
Therefor, any use of unavailable sockets might break (unavailable != hidden). For
the time being, it's still possible to find unavailable sockets by iterating over all sockets.
This change has a small chance to break existing scripts because the behavior
changes for some inputs in some nodes. However, for the cases where the function
is used in practice, I don't really expect any breakage.
This patch also allows us to give a better answer to reports like #113106.
Pull Request: https://projects.blender.org/blender/blender/pulls/113984
Due to missing logic reflection probe updates where not always
performed. There were multiple artifacts:
* Lookdev Worlds where Black Until the Scene world was rendered.
Issue was that the lookdev world didn't initialized its atlas
coordinates.
* Lookdev world should only retrigger reflection probe update when
material is compiled
* When world is updated, reflection probes should be updated; this
might require a redraw when reflection probe draw passes aren't
updated this sample.
Pull Request: https://projects.blender.org/blender/blender/pulls/114064
No functional changes.
Changing old C code to C++ by returning a `Vector` from `ANIM_setting_get_rna_values`.
This reduces the argument count for that function and simplifies the code.
Pull Request: https://projects.blender.org/blender/blender/pulls/113931
It's possible to encounter a true 1-channel image if it's coming
directly from, say, a float-value AOV or similar.
This was not accounted for and would cause issues when saving the image
out to a 3 or 4 channel format (wrong values) or when saving out to
another 1 channel format (unnecessary usage of luminance weight values).
Pull Request: https://projects.blender.org/blender/blender/pulls/111577
Last key is drawn on the right edge of the strip, but that is end of
the frame, which it should be bound to. Because of this, drawing code
and operators must consider, that this key is always displaced.
This was not done in 86a0d0015a and caused issues like #113755 that was
fixed incorrectly.
Own mistake in d47ceb53f8
The old calls to `BLI_array_staticdeclare` were deceptive. Because no
appends were done after declaration, to actually use the array, the
variables remained null. Effectively `nullptr` was always being passed
in here.
Pull Request: https://projects.blender.org/blender/blender/pulls/114049
The issue was that a node was supposed to propagate an anonymous
attribute that is only created further to the right in the tree. This does not
during inferencing, where uses of fields can only come to the right of its
creation. Note, all fields coming out of the repeat input/output node are
new field sources during inferencing.
Now, only field sources that are passed from the outside into the repeat zone
can be propagated from the repeat output to the repeat input node.
Solving this also showed another issue where anonymous attributes are
not properly propagated through a repeat zone where there is no link between
the repeat input and output node. In such cases, data is still propagated between
those two nodes when the number of iterations is zero.
The way we handled activation of view item buttons (which are placed
underneath other buttons) would leave that button in an active state,
giving it priority on the next event handler run. Instead we want to
cleanly exit the button after activation, so that the overlapped chevron
icon can be recognized as hovered again.
Also limit this to mouse press events, since otherwise the tree view
item would toggle the collapsed state on both the press and the release
event.
This should fix one of the remaining crashes while drawing.
The issue was that we would try to write to an out-of-bounds
memory location.
This fixes the issue and also cleans up the code a bit more,
adding more comments and using better names.
The drawing plane was at the world origin not the object origin.
This still needs to use the correct drawing plane in the future,
but it's a good step in the right direction.
