Prefetching happens on a background thread by design, and so it was not loading
any fonts and using the default monospace font.
Address this by making all font usage within VSE use "unique" BLF font objects,
and protecting concurrent access to them or their state within VSE itself:
- SeqFontMap structure to hold a mutex, file path -> font ID map (for file
based fonts), name -> font ID map (for datablock fonts).
- seq_load_font_file, seq_load_font_mem, seq_unload_font that use the above
instead of calling into BLF directly.
- Text effect rendering part guards with a mutex, so that font render state and
glyph cache does not get trashed.
- SeqFontMap is global instead of some Scene-specific runtime data (e.g.
scene->ed), because right now there's a hard max limit of total number of
fonts (64), and if each copy of the VSE data would start to load their own
unique fonts, that limit could get easily reached.
- BLF font loading/unloading code is now thread safe. The rest of BLF drawing
is still not!
If at some point in the future BLF font usage becomes thread safe, and font
drawing becomes "stateless", this whole machinery can be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/130542
The "is edit mode" checks in the draw module have been simplified
to just check the object mode. We need to be a bit more careful to
avoid retrieving the original mesh from a non-mesh object.
This commit improves the "get pre-modified mesh" function with
better comments and checks that reflect the relatively recent cases
where the original and evaluated geometry data types don't match.
It's always called with a mesh object too.
Pull Request: https://projects.blender.org/blender/blender/pulls/130850
Add the base `Overlay` class for documenting the methods.
This cleans up the inconsistency in the method implementation
and add TODOs for method not complying with the interface.
Pull Request: https://projects.blender.org/blender/blender/pulls/130790
We weren't handling the failure case of `IDP_AddToGroup` when the
property already exists. Arguably this is a bit bad because we're not
recording the type of the second socket with the same name, but we
don't really have the tools to solve that with IDProperties.
Add a Mesh implementation of triangulation, which is currently just
implemented for BMesh. The main benefit of this is performance and
decreased memory usage. The benefit is especially large because the
node currently converts to BMesh, triangulates, and then converts back.
But the BMesh implementation is entirely single threaded, so it will
always be much slower.
The new implementation uses the principle of "never just process a
single element at a time" but it also tries to avoid processing _too_
many elements at once, to decrease the size of temporary buffers.
Practically that means the work is organized into chunks of selected
faces, but within each chunk, each task is done in a separate loop.
Arguably I went a bit far with some optimizations, and some of the
complexity isn't necessary, but I hope everything is clear anyway.
Unlike some other Mesh ports like the extrude node or the split edges
code, this generates a new mesh. I still go back and forth on that
aspect, but reusing the same mesh would have required reallocating
face attributes from scratch anyway. Implicit sharing is used to
avoid copying vertex attributes though.
The result mesh is reorganized a bit. Unselected face data comes first,
then selected triangles, then triangulated NGons, then triangulated
quads. This makes attribute interpolation and internal calculations
more efficient.
The "Minimum Vertices" socket is replaced with versioning. In the new
implementation it would have an impact on code complexity, and for a
builtin "atomic" node it makes more sense as part of the selection.
The performance difference depends on the number of CPU threads, the
number of attributes, and the selection size. As all of those numbers
go up, the benefit will grow. The "modes" also affect the performance,
obviously.
With a Ryzen 7950x, I tested performance in a few situations (in ms):
| | Selection | Before | After | Change |
| -------------------------- | --------- | ------ | ----- | ------ |
| 1.4 m quads (fixed) | 50% | 1533 | 15.9 | 96x |
| 10 m quads (shortest) | 100% | 9700 | 165.0 | 59x |
| 1 m 10-side Ngons (beauty) | 90% | 3785 | 115.9 | 33x |
| 1 m quads many attributes | 100% | 54600 | 332.3 | 164x |
In follow-up commits, I'll move other areas to use mesh triangulation
instead of BMesh. This is the last geometry node using BMesh besides
the Ico Sphere primitive.
Pull Request: https://projects.blender.org/blender/blender/pulls/112264
This is incorrect after the changes in 839108f623.
It was only happening for non edit-mode object evaluation anyway
so it likely didn't have any effect in practice.
Add a `short2` attribute type, intended to store the existing
`CD_CUSTOMLOOPNORMAL` custom data type in order to move the custom
normal storage to generic attributes. This type probably won't get much
use besides that, but generally we don't have reasons not to add these
generic types, besides binary size. In the future we should consolidate
usage of `convert_to_static_type` to avoid large binary size increases
(about 700KB here) for this sort of addition.
This is the first step of #130484.
Pull Request: https://projects.blender.org/blender/blender/pulls/130530
Currently replacing the Mesh during evaluation with the object info node
can cause us to use invalid original indices when the source object is
in edit mode. This is really a more fundamental problem though: we have
no way to tell whether an evaluated mesh actually corresponds to the
object's original mesh.
This commit changes to explicitly propagating the edit mesh pointer
through copied and changed meshes during modifier and nodes evaluation,
instead of just blindly copying the edit mode pointer from the original
mesh to the evaluated mesh. A benefit of not writing to the evaluated
mesh means it can be shared, potentially offering a future performance
improvement for uses of the object info node.
When we detect an invalid correspondence between the evaluated/original
meshes, we skip extracting the cage mesh's data and skip extracting edit
mesh data from the evaluated object.
This commit also moves the source of "object is in edit mode" truth in
the draw module from whether the evaluated mesh has an edit mode pointer
to the object's mode flag. That's a simplification that's also helpful
to reduce the strong linking between BMesh and edit mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/120999
The root cause of this bug can be traced to:
- `ANIM_nla_mapping_get(ac, ale)` conditionally returns an `AnimData *adt`.
- This can be `nullptr` in various cases, depending on the editor (in `ac`) and
the type & source of data (in `ale`).
- This `nullptr` has different meanings:
1. There is not enough information to return an `adt` (like `ac` or `ale`
being `nullptr` themselves).
2. NLA time remapping should not be done. For example for NLA control F-Curves
(like animated strip influence), or Grease Pencil (because that doesn't use
the NLA).
- The above-returned `adt` is passed to other functions. Some of them are aware
of the "`nullptr` means no NLA time remapping" scenario, and gracefully handle
it. Other code, however, just gets "an adt" from the caller and handles it as
normal (and likely crashes on `nullptr`). Other cases start out as the first,
but somewhere in the call stack shift over to the second.
The approach taken in this PR to fix the bug is to (generally) stop signaling
"do not use NLA time remapping" via `adt = nullptr`, and instead explicitly
indicate/check whether remapping should be done.
In most cases this means passing a `bAnimListElem *` instead of an `AnimData *`,
because the former has the information needed to determine if time remapping
should be done or not. However, in some cases there is no `bAnimListElem *` to
pass, and instead other information determines whether remapping is needed. In
those cases we add a `bool` parameter or field in the appropriate place so that
calling code can explicitly indicate whether remapping should be done or not.
To accomplish this a variety of functions have been added to help handle things
correctly. Of particular note:
- `AnimData *ANIM_nla_mapping_get(ac, ale)` (that conditionally returned an
`adt`) has been removed entirely in favor of the new
`bool ANIM_nla_mapping_allowed(ale)` function that simply returns whether
nla remapping should be done or not.
- `ANIM_nla_tweakedit_remap(ale, …)` has been added, which wraps
`BKE_nla_tweakedit_remap(adt, …)` and only performs the remapping when
`ANIM_nla_mapping_allowed()` indicates that it's allowed.
- `ANIM_nla_mapping_apply_if_needed_fcurve(ale, …)` has been added, which is an
alternative to `ANIM_nla_mapping_apply_fcurve(adt, …)` that also only performs
the remapping when `ANIM_nla_mapping_allowed()` indicates that it's allowed.
Note that even with this PR there are still a couple of places remaining that
use `adt = nullptr` to indicate "don't remap", because they appear to be correct
and would require larger changes to make explicit. In those cases comments have
been added to explain the situation, with a reference to this PR. In the future
we way want to take the time to change those as well.
Also of minor note: this PR moves the definition of the type `slot_handle_t`
from ANIM_action.hh to BKE_action.hh. This is due to `BKE_nla.hh` (which needs
that definition) now being included directly and indirectly in a lot more
places. Moving the definition to BKE_action.hh prevents all of those new places
from gaining dependencies on the animrig module.
Co-authored-by: Sybren A. Stüvel <sybren@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130440
This PR changes the default theme color for TH_FACE_FRONT, used by the
Face Orientation overlay, to have zero alpha. That way, by default, it
can be used always and not interfere with the display of (normal) front
faces.
Pull Request: https://projects.blender.org/blender/blender/pulls/130618
Now that another ID can be renamed (again), it also needs to be properly
tagged as needing resync in the depsgraph too.
This commit:
* Moves/add depsgraph tagging to `BKE_id_rename`.
* Moves the WM notifier creation to `ED_id_rename`.
Pull Request: https://projects.blender.org/blender/blender/pulls/130596
The `fmt::format` can process the format string at compile time. Currently, we
don't seem to be using that as we don't use `FMT_STRING`. Starting with C++20,
that will be the default though, and one has to explicitly opt out in places
where the string is not known at compile time using `fmt::runtime(...)`.
Currently, our code does not compile as C++20 because of that. Unfortunately, we
have many places with runtime format strings, because of i18n.
Pull Request: https://projects.blender.org/blender/blender/pulls/130392
There is not really a good definition for what an "attribute kind". There are
many possibilities, it could include domain, type, geometry type, default value,
usage, ...
So it's better not to use this generic name. With the current name, one always
has to look at the definition again to be sure what it contains and what it does
not.
The name `AttributeDomainAndType` is way more explicit and does not have the
same problems. It's a bit longer, but that does not seem to be a problem in the
places where we use it.
Pull Request: https://projects.blender.org/blender/blender/pulls/130505
Previously, the attribute accessor were defined in the `geometry_component_*.cc`
files. This made sense back in the day, because this attribute API was only used
through `GeometryComponent`. However, nowadays this attribute API is independent
of `GeometryComponent`. E.g. one can use `mesh.attributes()` without ever
creating a component.
The refactor contains the following changes:
* Move attribute accessors to separate files for each geometry type. E.g. from
`geometry_component_mesh.cc` to `mesh_attributes.cc`.
* Move implementations of e.g. `Mesh::attributes()` to `mesh.cc`.
* Provide access to the `AttributeAccessorFunctions` without actually having a
geometry. This will be useful to e.g. implement
`attribute_is_builtin_on_component_type` without dummy components.
Pull Request: https://projects.blender.org/blender/blender/pulls/130516
The `add_layers_with_empty_drawings_for_eval` function incremented the
user count of the drawings twice because `add_empty_drawings` creates
drawings with one user.
Pull Request: https://projects.blender.org/blender/blender/pulls/130514
Adds support for saving some view state persistently and uses this to keep the
height of a tree-view, even as the region containing it is hidden, or the file
re-loaded.
Fixes#129058.
Basically the design is to have state stored in the region, so it can be saved
to files. Views types (tree-view, grid-view, etc) can decide themselves if they
have state to be preserved, and what state that is. If a view wants to preserve
state, it's stored in a list inside the region, identified by the view's idname.
Limitation is that multiple instances of the same view would share these bits of
state, in practice I don't think that's ever an issue.
More state can be added to be preserved as needed. Since different kinds of
views may require different state, I was thinking we could add ID properties to
`uiViewState` even, making it much more dynamic.
Pull Request: https://projects.blender.org/blender/blender/pulls/130292
Since all legacy Grease Pencil modifier are converted to regular modifiers
in versioning, we should never be in a position where we need to write the
old modifiers anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/130388
This probably never in practice in these cases.
Constructing a `std::string` from nullptr is invalid.
Starting with C++23, the `nullptr_t` is even explicitly deleted.
wdas_cloud.blend file on 4.3+ raises an assert, due to reading some
VSE data:
readfile.cc:4798, blo_verify_data_address(), at
'MEM_allocN_len(new_address) >= expected_size' Corrupt .blend
file, unexpected data size.
This is caused by 30dbb7820d which removed completely unused
data from Sequence struct. But it turns out, Sequence serialization
inside scene_blend_read_data is "somewhat strange", to put it mildly,
and silently assumes that struct offset of seqbase and channels
will never change.
For now, restore the previously expected struct member offset,
ensure it stays like that via static_assert, and add notes on
how someone should fix this in a better way.
Pull Request: https://projects.blender.org/blender/blender/pulls/130296
This allows using C++ types in the region runtime data, which will
make it easier to move the remaining runtime data out of the
`ARegion` DNA type and improve code readability in these areas.
Pull Request: https://projects.blender.org/blender/blender/pulls/130196
Set unique name for `target_layer_name` to display in pop-up box when
creating a new layer. For that, `unique_layer_name()` is moved to member
function of `GreasePencil`.
Pull Request: https://projects.blender.org/blender/blender/pulls/130208
Currently the node behaves differently from the modifier by default
because it lacks the option to use the limit surface. This is mainly
an oversight, since the option gives better results and better
performance.
This adds a new "Limit Surface" option. Because it's on by default,
there is also versioning to turn it off for existing files.
Resolves#112912.
Pull Request: https://projects.blender.org/blender/blender/pulls/130243
Brush assets from the current file should be supported like other brush
assets.
This assert would fail on startup for example, when opening the
essentials file containing the default brush of this mode.
Videos written out of blender were not explicitly indicating the color
metadata (color range, primaries, TRC, color space). While some video
players assume BT.709, some others assume BT.601, leading to inconsistent
look.
Explicitly indicate BT.709 and limited ("mpeg") YUV range for video
codecs that are YUV based (i.e. final image is non-RGB(A)). Overall now
the code does the same as these command line ffmpeg parameters:
`-vf scale=out_color_matrix=bt709 -color_primaries 1 -color_trc 1 -colorspace 1`.
This also fixes an issue where video proxies were looking wrong within
Blender, if the source video file contained colorspace metadata.
Images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/130021
This commit refactors `BKE_image_load` and `BKE_image_load_exists` APIs:
* Remove the `_ex` versions (the 'exist' boolean return pointer can have
default `nullptr` value instead).
* Add `_in_lib` versions, which match signature and behavior of the
generic ID creation code to allow to find or create a new image ID
directly in a library 'namespace' (as linked data).
This is required by upcommig fixes for Brush Assets, which are using
linked but editable data-blocks.
Fix#130194: When trying to add a new image from the UI (e.g. for a new
texture) for a local ID, if that same exact image was already loaded by
a linked ID, it would trigger an assert in `BKE_id_move_to_same_lib`,
because `BKE_image_load_exists` would return the matching linked Image ID
instead of creating a new local one. In release builds with no assert,
it would result in making a linked ID 'local', while still being used by
original other linked data.
Passing around the intended final destination of the new Image (local or
in a given library) allows `BKE_image_load_exists` to be more specific
when searching for an already loaded matching image ID, and ensures that
a new local Image ID is created in the case described above.
Pull Request: https://projects.blender.org/blender/blender/pulls/130195
This implements the proposal from #124512. For that it contains the following
changes:
* Remove the global override of `new`/`delete` when `WITH_CXX_GUARDEDALLOC` was
enabled.
* Always use `MEM_CXX_CLASS_ALLOC_FUNCS` where it is currently used. This used
to be guarded by `WITH_CXX_GUARDEDALLOC` in some but not all cases. This means
that a few classes which didn't use our guarded allocator by default before,
are now using it.
Pull Request: https://projects.blender.org/blender/blender/pulls/130181
