The new --disable-liboverride-auto-resync commandline option will prevent
running liboverride auto-resync immediately after loading a blendfile.
This is an alternative way to setting the User Preferences Debug option
`No Override Auto Resync`.
-------
Some quick performances tests:
Loading a Gold production file goes from 26.5s to 25.9s.
Combined with the recent `--disable-depsgraph-on-file-load` option, it
goes from 3.5s to 2.9s, so another nice extra 15% speedup when only
bare-metal blendfile loading is needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132017
The realize instances code didn't have a way to use the existing
`#BuiltinAttributeProvider::default_value()`s to initialize attributes that
have to be created.
Now this writes default values of builtin attributes to the curve `attribute_fallbacks`.
Removes the need for the code to explicitly write the `resolution` and
`nurbs_weight`.
The other attributes that are written explicitly (like `radius`) don't have
builtin default values unfortunately. Ideally those would also just be provided
by the respective `BuiltinAttributeProvider`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131799
The `double inittime` attribute on strokes is truncated to a `uint32_t`
range. This wasn't done explicitly and the code only did a cast.
The `double` should be clamped to a legal `uint32_t` value before
casting it.
Pull Request: https://projects.blender.org/blender/blender/pulls/131625
The code tried to sync the playback to audio in two places:
1. In the screen_animation_step_invoke function in screen_ops.cc
2. In wm_event_do_handlers which would trigger on every screen refresh/event
However because of some oversight on how the Audaspace API worked,
the wm_event_do_handlers code was only triggered for JACK and CoreAudio.
Remove this code as we shouldn't need to update the current scene frame
in two places.
The wm_event_do_handlers way would also lead to bugs as it would try to
sync regardless if we were playing back audio or not.
The type check there should not be necessary anymore nowadays. It looks like it
might have been necessary when it was introduced in
eed45d2a23. Back then the object was still passed
into `BKE_mesh_wrapper_ensure_subdivision`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131857
The issue here was sometimes an output socket of a `Group Input` node has a
reference to a data-block. The value stored on these output sockets are never
used, and thus is not exposed in the UI which made it impossible for the user to
find that there still is a data-block reference.
The root cause for this seems to have been fixed a few releases ago. I can
reproduce that the pointer was set in 3.3, but not in 3.6.
This patch only adds some versioning to remove the unnecessary data-block
references to fix old files that might have this issue (e.g. the file from the
report).
Pull Request: https://projects.blender.org/blender/blender/pulls/131900
Previously, calling `clear()` on `Map`, `Set` or `VectorSet` would remove all
elements but did not free the already allocated capacity. This is fine in most
cases, but has very bad and non-obvious worst-case behavior as can be seen in
#131793. The issue is that having a huge hash table with only very few elements
is inefficient when having to iterate over it (e.g. when clearing).
There used to be a `clear_and_shrink()` method to avoid this worst-case
behavior. However, it's not obvious that this should be used to improve
performance.
This patch changes the behavior of `clear` to what `clear_and_shrink` did before
to avoid accidentally running in worst-case behavior. The old behavior is still
available with the name `clear_and_keep_capacity`. This is more efficient if
it's known that the hash-table is filled with approximately the same number of
elements or more again.
The main annoying aspect from an API perspective is that for `Vector`, the
default behavior of `clear` is and should stay to not free the memory. `Vector`
does not have the same worst-case behavior when there is a lot of unused
capacity (besides taking up memory), because the extra memory is never looked
at. `std::vector::clear` also does not free the memory, so that's the expected
behavior. While this patch introduces an inconsistency between `Vector` and
`Map/Set/VectorSet` with regards to freeing memory, it makes them more
consistent in that `clear` is the better default when reusing the data-structure
repeatedly.
I went over existing uses of `clear` to see if any of them should be changed to
`clear_and_keep_capacity`. None of them seemed to really benefit from that or
showed that it was impossible to get into the worst-case scenario. Therefore,
this patch slightly changes the behavior of these calls (only performance wise,
semantics are exactly the same).
Pull Request: https://projects.blender.org/blender/blender/pulls/131852
The new `--disable-depsgraph-on-file-load` commandline option, when used
together with the `--background` or `--command` ones, will prevent
building a depsgraph immediately after loading a blendfile.
The goal is to improve performances of batch-processing of blendfiles by
python scripts. It is intended to become the default behavior in Blender
5.0.
Scripts requiring evaluated data then need to explicitly ensure that
an evaluated depsgraph is available (e.g. by calling
`depsgraph = context.evaluated_depsgraph_get()`).
------
This disables the call to `wm_event_do_depsgraph` in `wm_file_read_post`.
Some quick performances tests:
* The whole `blendfile_versioning` tests gain about 2% speedup. These are
almost always small and simple blendfiles.
* Loading a Gold production file however goes from 26.5s to 3.5s (almost
90% faster) when this new option is specified.
Pull Request: https://projects.blender.org/blender/blender/pulls/131978
Previously, the number of material slots on the geometry (e.g. mesh) was the
ground truth. However, this had limitations in the case when the object had more
material slots than the evaluated geometry. All extra slots on the object were
ignored.
This patch changes the definition so that the number of materials used for
rendering is the maximum of the number of material slots on the geometry and on
the object. This also implies that one always needs a reference to an object
when determining that number, but that was fairly straight forward to achieve in
current code.
This patch also cleans up the material count handling a fair amount by using the
`BKE_object_material_*_eval` API more consistently instead of manually accessing
`totcol`. Cycles uses the the same API indirectly through RNA.
Pull Request: https://projects.blender.org/blender/blender/pulls/131869
UNICODE code points were named "ascii" or "cha",
use the term "charcode" as used elsewhere in BLF and FreeType.
Also use char32_t internally and add a utility function to apply the
small-caps flag.
Resolve by welding overaps between adjacent underline glyphs.
Besides avoiding overlap, this makes underlines work better when the
text follows a curve.
Also remove increased underline width which was originally added in [0].
This may have been done to avoid gaps - which is no longer needed.
Further, underlines typically don't extend beyond the glyphs bounds
so the increased width isn't expected behavior.
[0]: a07394ef2c
This adds a new `bl_use_group_interface` property that can be set on custom node
group types. By default it is `true` to avoid this being a breaking change. If
it's set to `false` some UI elements related to the built-in node group
interface are hidden.
Pull Request: https://projects.blender.org/blender/blender/pulls/131877
Refactoring functions out of the 3D text layout funciton was
becoming difficult because vfont.cc mixed API's that use VFont
for different purposes (clipboard, text layout, ID management.. etc).
Split VFont to character & text layout into its own file.
Resolve multiple inconsistencies when 3D text could not load fonts.
- When the font wasn't found:
The default font was used.
- When the font existed but could not be loaded:
The 3D text would fail to display anything.
- When only the VFont assosiated with a style failed to load:
The 3D text would fail to display only when the stype existed.
So toggling bold for example could cause all 3D text to vanish.
Instead of falling back to defaults, display a placeholder glyph
(a hollow rectangle) displayed when the font can't be used.
For the UI fallbacks are fine, for user content, it indicates something
is wrong as needs to be corrected - similar to a bright magenta in
renders when images fail to load. This means it's clear to users when
they have broken paths which need to be corrected.
This also simplifies vfont_to_curve, removing a "goto" to go to the
end of the function to cancel 3D text rendering entirely.
This adds material propagation in two places to fix the bug:
* Conversion from legacy to new curves.
* From the main curve input to the output mesh in the Curve to Mesh node.
Pull Request: https://projects.blender.org/blender/blender/pulls/131862
Give the `IDWALK_CB_…` enum an explicit name:
`LibraryForeachIDCallbackFlag`. This way the flags are type-safe, and
it's known where values come from. This is much preferred (at least by
me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_CB_NOP` as that has the same
value and is of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int` though.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Give the `IDWALK_…` enum an explicit name: `LibraryForeachIDFlag`. This way
the flags are type-safe, and it's known where values come from. This is
much preferred (at least by me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_NOP` as that has the same value
and is of the right type.
One invalid use of `IDWALK_CB_NOP` was detected by this change, and is
replaced by `IDWALK_NOP`.
This change might be incomplete; I gave the enum a name, and then fixed
the compiler errors.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Previously, the number of material slots on the geometry (e.g. mesh) was the
ground truth. However, this had limitations in the case when the object had more
material slots than the evaluated geometry. All extra slots on the object were
ignored.
This patch changes the definition so that the number of materials used for
rendering is the maximum of the number of material slots on the geometry and on
the object. This also implies that one always needs a reference to an object
when determining that number, but that was fairly straight forward to achieve in
current code.
This patch also cleans up the material count handling a fair amount by using the
`BKE_object_material_*_eval` API more consistently instead of manually accessing
`totcol`. Cycles uses the the same API indirectly through RNA.
Pull Request: https://projects.blender.org/blender/blender/pulls/131761
This PR improves the animation editor's display of node socket property
animation names, and names from geometry nodes modifier inputs. In both
cases, the names currently displayed are not very useful.
For geometry nodes inputs, the we now look up the name of the the input
rather than just displaying the identifier from the IDProperty name.
For node sockets, we now display the name of the socket instead of just
"Default Value" (which is technically the name of the RNA property).
We also display the label of the node if it's available. We also display
node labels instead of names for node properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/131766
Add a comment that documents the assumption that a node tree can only be
embedded by animatable ID types. At this moment this assumption holds.
`blender::animrig::internal::rebuild_slot_user_cache()` uses this for an
optimisation. It fully skips all non-animatable IDs, and would therefore
also not see any hypothetically animated node tree embedded in a
non-animatable ID type.
Pull Request: https://projects.blender.org/blender/blender/pulls/131844
This reverts commit 26ea1f42c3.
In line with [0] which prevents default characters from being used when
a font is selected, don't return characters from the default font when
the font cannot be loaded.
This should be addressed using place holder characters instead.
[0]: 6fa5295c1d
When "Developer Extras" is disabled, the experemental options
must not be used.
Some checks for experemental options weren't using the macro which
checks both are set.
Add comment to avoid this happening in the future.
Instead of storing an optional in the runtime data of each node,
move the field status for the socket to an array in the node tree's
runtime data. This wasn't possible before because selecting nodes
reordered nodes which caused too much cache recomputation.
The benefit is having less geometry-nodes specific data in the
node socket runtime struct, and a slight move to a more data-
oriented storage format.
Pull Request: https://projects.blender.org/blender/blender/pulls/131822
When the user selects a font, only use characters from that font,
see code comments in BKE_vfontdata_char_from_freetypefont
for details.
Partially reverts [0] which changed behavior when VFont was
updated to use BLF.
Ref: !131821
[0]: 604ee2d036
Don't just initialize new values to zero but actually take the existing attribute into account.
Once supported, this can also automatically take defaults for built-in attributes into account
without further changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131794
- Use return values instead of return arguments
- Remove the socket index lookup which was only used once
- Always use the topology cache for node_find_node
- Improve the documentation
- Add a const version of node_find_node
Overall, I think always using the topology cache will give more
predictable performance. Though it may require more cache
rebuilds after the node tree is changed, in practice there are
plenty of other things that require that already. This way, code
that doesn't change the node tree will get better performance
without having to think about the caching.
Pull Request: https://projects.blender.org/blender/blender/pulls/131811
Two commits that basically do the same thing for two `enum`s: give
them a name.
- the `IDWALK_…` enum → `LibraryForeachIDFlag`.
- the `IDWALK_CB_…` enum → `LibraryForeachIDCallbackFlag`.
This way the flags are type-safe, and it's known where values come
from. This is much preferred (at least by me) to just having `int
flags`.
Uses of `0` have been replaced with `IDWALK_NOP` and `IDWALK_CB_NOP`,
as those have the same value and are of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`. And another one in the opposite
direction.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int`
though.
No functional changes.
----------
I intend to land this PR as its two separate commits. I just put them in the same PR so the buildbot can handle them in one go, and we don't have a stack of highly relatled PRs.
In the future this could also apply to the `IDWALK_RET_…` enum. This one I left out, though, because a proper cleanup there would also have to include their ambiguity on whether they are bitflags (like the enums in this PR) or not. Their values and the code in `BKE_lib_query_foreachid_process()` implies they are bitflags, but in practice they are never or'ed together and just used as discrete values.
Pull Request: https://projects.blender.org/blender/blender/pulls/131803
