Relying on the `TreeStoreElem.id` void pointer makes assumptions about
what code elsewhere sets to it (it's also misleading since it's actually
not an ID pointer), in this case we can easily avoid that.
`TreeElement.idcode` would be reused to store the sequence type. This is
risky if the field is assumed to actually contain a valid ID-code,
without further checks.
This was only accessed in one place, which I've refactored to a clean,
type-safe solution now.
For the root group, the parent is `nullptr` so calling `parent_group()`
would fail. This fixes the issue by adding a null check and returning
`nullptr` otherwise.
The view layer "base" element (the parent that the individual layers are
nested in) does not point to any data in its `directdata`, definitely
not to a view layer. Don't cast it to one, this can cause undefined
behavior when the pointer is not null.
Before this patch, the drawing code iterated the FCurve to see if there are any
curve interpolation types that can't easily be drawn. (Sinusoidal, Bounce, etc)
If it found one, it would fall back to evaluating the FCurve.
That meant in the worst case scenario it would iterate the whole FCurve
before even starting to draw.
This PR unifies the drawing logic for FCurves no matter their interpolation type.
If it encounters a key type that it can't draw, it falls back to samples, but only
for the current key.
To clarify that it renames `draw_fcurve_curve_bezts` to `draw_fcurve_curve_keys`
Curves with modifiers are still drawn with samples.
## Performance
Test setup: 6000f of dense data on 62 bones.
Only measuring the average draw time **per curve**.
All measurements were done at the same zoom level.
| - | before | after |
| - | - | - |
| only beziers | 28μs | 13μs |
| only elastic | 90μs | 60μs |
| mix (~1/2 of the view with elastic) | 110μs | 24μs |
The performance boost with "only elastic" can be explained by the fact that per key I can skip 1 call to `evaluate_fcurve`. That is because I always start at an existing keyframe so I can use its position.
Pull Request: https://projects.blender.org/blender/blender/pulls/110764
The fact that the guarded-allocated memory blocks are all linked to the
static `membase` listbase is enough for LSAN to not detect them as
leaks.
So this commit adds a new (private) callback to clear the memlist, which
is only used in the destructor of the `MemLeakDetector` class.
Many thanks to @Sergey for identifying the root issue here.
Pull Request: https://projects.blender.org/blender/blender/pulls/110995
The `OBJECT_OT_simulation_nodes_cache_delete` operator
would delete the parent bake directory. This could lead to catastrophic
loss of data if the user set their bake directory to a folder that
contains other files or folders.
This commit makes sure that only the "meta" and "bdata" folders get
deleted in the parent directory.
Pull Request: https://projects.blender.org/blender/blender/pulls/110999
This patch adds layer widgets in the grease pencil layer channels of the grease pencil dopesheet.
It adds RNA + getter function for the `use_onion_skinning` at layer level.
It also sets the offset of the channel, and the color of grease pencil data-block channels.
Pull Request: https://projects.blender.org/blender/blender/pulls/110991
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Implementation of the transform action for grease pencil frames, which enables translating and scaling grease pencil frames in the dopesheet.
This patch adds the following in the grease pencil API :
- `move_frames` to move a set of frames given a map of key transformations (with overwrite), and
- the structure `LayerTransformData` that stores in the layer runtime some useful data for the frames transformation.
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/110743
In RNA collections storing ID references, the name of the collection
item may not always be unique, when several IDs from different libraries
are present.
While rare, this situation can become deadly to liboverride, by causing
random but exponential liboverride hierarchies corruptions.
This has already been alleviated by using preferably both name and index
in items lookup (a05419f18b) and by reducing the risk of name collision
in general between liboverrides and their linked reference (b9becc47de).
This commit goes further, by ensuring that references to items of RNA
collections of IDs stored in liboverride operations become completely
unambiguous. This is achieved by storing an extra pointer to the item's
ID itself, when relevant.
Lookup then requires a complete match `name + ID` to be successful,
which is guaranteed to match at most a single item in the whole RNA
collection (since RNA collection of IDs do not allow duplicates, and
the ID pointer is always unique).
Note that this ID pointer is implemented as an `std::optional` one
(either directly in C++ code, or using an new liboverride operation `flag`
in DNA). This allows to smoothly transition from existing data to the
added ID pointer info (when needed), without needing any dedicated
versioning. This solution also preserves forward compatibility as much
as possible.
It may also provide marginal performances improvements in some cases, as
looking up for ID items in RNA collections will first check for the
ID pointer, which should be faster than a string comparision.
Implements #110421.
Pull Request: https://projects.blender.org/blender/blender/pulls/110773
The text used to be centered around a point left of the slider line
with the assumption that it displays a number from 0-1 and "%"
With the ability to set the unit name, this assumption is no longer true,
and if setting a long name (like "Frames" in #110540) the text overlaps the slider line
By right aligning the text on the left side of the slider, this overlap cannot happen anymore.
| Before | After |
| - | - |
|  |  |
|  |  |
|  |  |
Pull Request: https://projects.blender.org/blender/blender/pulls/110586
The new keyframe jumping code for the graph editor did not respect the NLA strip offset.
This patch fixes that by applying `ANIM_nla_mapping_apply_fcurve`
Technical side note: `FCurve *` lost its constness due to that
Pull Request: https://projects.blender.org/blender/blender/pulls/110790
Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag
resulted in over long lines & visual noise. Replace with a function that
takes multiple (cache_var flag) pairs to reduce duplication.
This updates the signature of `RNA_def_property_update_runtime`
which previously just has a `const void *` input. This made it difficult
to know what function signature is expected and also does not result
in compile errors when a wrong function is provided.
There is one case which required a different signature, so now there
is a separat function for that case.
The goal here is to reduce the number of files that need to be edited when
adding a new node. To register a node, one currently has to add a line to
`node_geometry_register.cc` and `node_geometry_register.hh` (for geometry
nodes). Those files can be generated automatically.
There is a new `NOD_REGISTER_NODE` macro that nodes can use to register
themselves. The macro is then discovered by `discover_nodes.py` that generates
code that calls all the registration functions. The script also works when the
register functions are in arbitrary namespaces. This allows simplifying the node
code as well.
In the past I tried a few times to get auto-registration working without resorting to
code generation, but that never ended up working. The general idea for that would
be to use non-trivial initialization for static variables. The issue always ends up
being that the linker just discards those variables, because they are unused and it
doesn't care if there are side effects in the initialization.
Related discussion regarding using Python for code generation:
https://devtalk.blender.org/t/code-generation-with-python/30558
Pull Request: https://projects.blender.org/blender/blender/pulls/110686
Bug identified in #110942.
In cases where the last corners of a polygon are out of context, the
`weld_iter_loop_of_poly_next` iterator skips these corners.
This means that some corners of the resulting mesh do not have the
value set, which can even result in infinite loops.
The solution was not simple. The iterator had to be practically redone
to not use the `loop_end` member (which caused the problem).
Fortunately the code is more simplified with this change.
The last supression rule (`leak:libasan*`) would match almost all
detected cases, since the first line is almost always something like
that:
#0 0x7f71040d85bf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
Not sure if that was already the case when this suppression rule was
added, or if things changed in newer versions of ASAN/LSAN...
This commit fixes the RNA path reported from the struct owned by the
Scene.display data. Paths generated for the View3D space remain
completely broken (but whole 'space' paths are broken anyway).
This was caused by the free unused data pass in the
init phase that would reset the clip data of the first
tilemap.
Uploading and checking for an invalid index fixes the
issue.
This is the next step towards AgX view transform project.
This is a sanitization pass over the existing color space names, as well as
addition of some new spaces. For example, the name Linear makes no sense when
there are a bunch of Linear spaces. An aliases are included for backwards
compatibility.
Some of the space descriptions and family tags are also updated., which also
involves in putting `False Color` to `inactive_colorspaces` instead of using
`family: display` filtering.
The spaces are now:
- Linear components of the display spaces
- Linear Rec.709
- Linear DCI-P3 D65
- Linear Rec.2020
- Linear ACES spaces
- ACES2065-1
- ACEScg (Changed from `Linear ACEScg` to `ACEScg` since ACEScg already
implied a linear transfer function, otherwise using `Linear AP1 ACES`
might make more sense. Same goes for ACES2065-1)
- Linear FilmLight E-Gamut
This is for AgX's LUT input encoding. It can potentially be useful for interop.
- Display spaces
- sRGB
- Display P3
- Rec.1886
- Rec.2020
- Filmic Components
- Filmic Log
- Filmic sRGB
- False Color
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110941
This patch includes keyframes for both the summary channel, and grease pencil data-block channels.
It also includes selection in these channels, in the same modes as the ones implemented for grease pencil keyframes.
Pull Request: https://projects.blender.org/blender/blender/pulls/110962
Make it so transform between color spaces which is a no-op does not
peroform any calculations.
This was initially found when working on #110941, but the issue can
be replicated easily by renaming "Linear" to "Linear Rec.709" and
adding alias as "Linear".
Doing so would result in a failure of the compositor_matte_test.
The reason for that is due to the image data-block still referring
to the "Linear" color space, the name-based comparison not detecting
that "Linear" and "Linear Rec.709" are the same spaces, and that the
cryptomatte requires bit-perfect floating point values.
Pull Request: https://projects.blender.org/blender/blender/pulls/110959
In edit mode, the "Select Random" operator selected the inverse.
For a probability of 1, no elements were selected and vice versa.
This was because the selection actually deselects elements, but used a
mask of elements that was not inverted.
The fix takes the complement of the mask of elements, so the deselection
now does the right thing.
Pull Request: https://projects.blender.org/blender/blender/pulls/110963
