When strokes from to different layers get joined together, if one layer
had the `resolution` attribute and the other did not. The new
`resolution` attribute would be left with uninitialized values and then
a crash would happen.
This fixes this by filling all attributes that didn't exist with their
default value.
This also ensures that when strokes are removed, the drawing is
tagged as dirty.
Pull Request: https://projects.blender.org/blender/blender/pulls/147948
This is an alternative to ba0f73d076. I'm not exactly sure why that on
didn't work yet. Seems like there is some hidden state somewhere, not sure.
Now this fix is more similar to what is done in `curves_blend_write`.
Pull Request: https://projects.blender.org/blender/blender/pulls/148267
While more of a theoritical issue currently, this change is a
pre-requisite to support properly compo nodes duplication in 'linked
copy' case (see !148210).
Also add a basic unittest for this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/148222
BLI code for enums that are meant to be used as "bit flags" defined
an ENUM_OPERATORS macro in BLI_utildefines.h. This cleans up things
related to said macro:
- Move it out into a separate BLI_enum_flags.hh header, instead of
"random bag of things" that is the current place,
- Update it to no longer need manual indication of highest individual
bit value. This originally was added in a31a87f89 (2020 Oct), in
order to silence some UBSan warnings that were coming
from GPU related structures (looking at current GPU code, I don't
think this is happening anymore). However, that caused actual
user-visible bugs due to incorrectly specified max. enum bit value,
and today 14% of all usages have incorrect highest individual
bit value spelled out.
- I have reviewed all usages of operator ~ and none of them are
used for directly producing a DNA-serialized value; all the
usages are for masking out other bits for which the new ~
behavior that just flips all bits is fine.
- Make the macro define flag_is_set() function to ease check of bits
that are set in C++ enum class cases; update existing cases to use
that instead of three other ways that were used.
Pull Request: https://projects.blender.org/blender/blender/pulls/148230
The recently introduced size, strength, and jitter pressure curves
affect most paint code. This exposed further odd behavior inside
`paint_brush_update` where the size pressure curve was being evaluated
even if the brush's size did not vary with pressure.
To fix this issue, this commit clarifies a few comments and updates the
code flow such that cached input values and evaluated pressure values
are used more consistently.
Pull Request: https://projects.blender.org/blender/blender/pulls/148077
Rewrite the "mesh is valid" and "validate mesh" functions to be more
agnostic of the custom data storage system, align with the changes to
topology storage in the last 5 years, be much clearer overall, more
reusable.
Each check is implemented as a separate pass over the remaining
valid geometry in the mesh, producing an IndexMask of the invalid
elements it finds. At the cost of some extra iteration over mesh elements,
this should make each requirement clearer and make it easier to
optimize and reuse each check if needed.
The code is roughly twice as fast as it was before. I measured 92ms
instead of 200ms for a 1 million vertex cube on a Ryzen 7950X.
There's a bit of low hanging fruit for further optimization too.
There are now automated tests just for the validation code as well.
For now they are very basic but they could be extended in the future.
Some non-obvious points:
- The new face offsets storage (replacing `MPoly`) upholds more
invariants by itself. Previously faces could easily overlap or leave
corners unreferenced. That doesn't really happen anymore, but
bad offset values are a more "global" problem.
- The validation code for the old "MFace" storage was removed. It is
just rebuilt when it's needed at runtime anyway, so there isn't much
point in validating it.
- The versioning code for 2.90.1 was calling the mesh validation code
to fix an issue where the extrude manifold tool could generate bad faces.
Unfortunately keeping that would mean being unable to remove the old
code, so now there's a warning to open and save the file in a previous
version instead.
- One of the main goals of the new code is better const correctness, and
working better with implicit sharing. The code now only requests mutable
copies of the mesh data if it has to change.
Part of #122398
Pull Request: https://projects.blender.org/blender/blender/pulls/148063
The issue was that the data-blocks of two different undo steps were detected to
be identical, even if the attributes changed. That's because even if the
implicitly-shared data was different, they were turned into the same pointer by
cadb3fe5c5 on write.
This patch makes it so that for undo steps, implicitly shared data does not use
the pointer stability feature (in a sense, implicit-sharing itself provides
pointer stability for undo steps already).
The main tricky aspect is that we need to know if a pointer is implicitly shared
in `writestruct_at_address_nr` and oftentimes that's called before the
corresponding shared data is actually written with `BLO_write_shared`. The
solution is to enforce that the blend-write code has to know what pointers are
implicitly-shared before they are written the first time. The simplest way to
ensure that is to call `BLO_write_shared` first. However, that's not always
possible, especially when the pointer is directly embedded in an ID. Therefore,
there is a new `BLO_write_shared_tag` function that can be used in such cases.
The undo performance for the file in #141262 is still fixed with this change.
Pull Request: https://projects.blender.org/blender/blender/pulls/148144
`socket.socket_typeinfo()` can be nullptr when reading blend files that
contains custom socket types that are not registered yet. This fix
prevents crashing when this happenes (but the socket will stay
unregistered).
Pull Request: https://projects.blender.org/blender/blender/pulls/148103
Instead of reordering edges to be able to map them with hash sets, new
edges order (since 157e7e0351) is kept as-is in order to not
touch edge attributes. In early return in case of correct mesh this new
ordering was missed. This was found in file from #147694.
Pull Request: https://projects.blender.org/blender/blender/pulls/147872
Forgot that the Armature's bones list only contain root bones...
Fix the versioning code.
Also adding a 'recovery' extra versioning step for files that may have
already been opened and re-saved in Blender 5.0 (though this step is
not 100% handling all cases, in case some script or add-on already
created some system properties in a bone in 5.0, the existing user
properties from 4.5 and before won't be copied over anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/148125
Fix playhead snapping to seconds, when the frame rate is less than 0.5
FPS.
This makes it possible to snap to fractions of frames, to support setups
with multiple seconds per frame. Of course this only has any effect
(apart from not crashing) when sub-frames are enabled.
I've also added unit tests, and verified that the values are the same
from before this refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/148074
Regression in [0] caused printing integers to crash.
While this function isn't widely used it could crash logging
key-map items.
Also add tests for IDP_reprN.
Ref !148109
[0]: 92cf9dd2f2
While uncommon, brush initialization does happen in some addon
workflows. Prior changes to use custom pressure curves in more places
did not initialize the `CurveMapping` struct correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/147840
Currently, the scene strip preview uses the existing dependency
graph built for that scene. This was not a big issue before
the sequencer scene was introduced, because the user would have
to create two main Blender windows to run into problems.
Now with the sequencer scene, it's possible to look at the scene
of a scene strip within the same window.
When the user is editing the scene (e.g. moving an animated object)
any open sequencer preview will cause the edits to be flushed.
This can e.g. result in visual jumping of animated objects, and more.
This PR attempts to fix the issue in a straightforward way: Use
a separate dependency graph for rendering the sequencer preview.
While this fixes the immediate issues, there are some consequences:
* The memory usage of the scene dependency graph _can_ roughly
double (since there are now likely two instances of the same
dependency graph). Because of implicit sharing, unmodified data
will not be copied. But for example modifiers on meshes would
currently create two copies of the evaluated data in the two
dependency graphs.
* Creating the dependency graph can be costly, which will cause the
first frame that the scene has to render to be slower.
Note: The current code changes some properties of the original scene
like the frame, subframe etc. before rendering and then restores
the original state. In theory, this part of the code can be removed,
but may be a bit too risky for just a fix. This should be improved
at a later stage.
Also resolves#146769, #139501.
Pull Request: https://projects.blender.org/blender/blender/pulls/147457
This speeds up drawing of the UI of the Geometry Nodes modifier, especially for
very large node trees like in the files from #146949.
A couple previous commits and #147883 speed up the inferencing significantly
already. However, there is a certain limit to how fast this can be on large
complex node trees. While there is some more optimization potential, this patch
implements a cache on the Geometry Nodes modifier level. This means that as long
as the inputs and the node tree stays the same, the inferencing only has to
happen once, instead of on every redraw.
The main difficulty with this cache is that we don't have a good way to
invalidate it eagerly when any of the modifier inputs changes. That can
hopefully become simpler with #138117. For now, we have to check all input
values on redraw to check if anything has changed compared to the last redraw
and recompute the cache if there is any change.
Pull Request: https://projects.blender.org/blender/blender/pulls/147930
Split the "Interpolation Line" theme property into three for each
interpolation mode, and use them accordingly. In the current theme
refactor, almost all theme properties of the dope sheet are getting
either removed (unused), or moved (shared). This decluttering opens up
the possibility to allow more theming, and let artists read the Dope
Sheet better.
## Avoiding Confusion
There's two "Bézier" interpolation types:
- Called "Bézier" in the interpolation type menu, and
- Called "Bézier" in the code, for the types that are labeled as
**"Easing" and "Dynamic"** in the interpolation type menu.
Since this commit is about the interpolation lines, which are **not**
drawn for the former, **this PR only covers Constant, Linear, and the
latter form of Bézier interpolation types.**
Pull Request: https://projects.blender.org/blender/blender/pulls/144255
I think the special handling for string input node, added in #139478,
was broken by #146033. The early check for src_value (`if (!src_value)`)
caused the string-specific logic to be skipped. This PR moves the
string-specific handling before the src_value check.
Pull Request: https://projects.blender.org/blender/blender/pulls/147697
This list can be used as a source of truth for what needs to be
supported in CustomData vs. AttributeStorage for some ongoing work.
These comments just make it a bit more useful.
