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
Either initial fix (9405bd25d6) was not fully correct (and properly
tested), or something else changed since then, but the handling of
liboverrides in copy/paste of poses would not be correct for local
overrides.
Instead of relying on generic `BKE_lib_id_make_local` to also work
for local liboverrides, add some more logic in `PartialWriteContext::make_local`
to properly handle local liboverrides when the override data needs to get
removed in the copy buffer blendfile.
NOTE: Not super-happy with how make local and removal of liboverrides
somewhat mix together currently. Will need to revisit once again that
whole process at some point.
The "use attribute" and "attribute name" IDProperties were missing
the overrideable status and the static type status. This was an oversight
from when those tags were added.
This commit fixes the flag on new modifier properties as they're created
and applies versioning to old properties. It also fixes the poll of the toggle
input attribute operator so that it isn't possible on non-editable objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/131768
As characters were evaluated, the VFontData was set.
This was then used to calculate text alignment.
Resolve by always using the "Regular" font metrics.
Currently each node's position is stored in the coordinate space of
its parent. To find the location of a node on the canvas, we have to
apply the translation of each of its parents. Also, nodes have hidden
"offset" values used while transforming frame nodes. Together,
those made the system much more complicated than necessary,
and they made the Python API ineffective.
This commit removes usage of the offset values and moves nodes
to be stored in the "global" space of the node canvas. It also resolves
some weird behavior when resizing frame nodes, and fixes a few bugs.
The change is forward compatible, so we still write files with nodes in
the old parent-space format. In 5.0 the conversion when writing can be
removed. The existing Python API also stays the same. A new
"location_absolute" property gives node locations in global space,
and changing the old property also moves the child nodes of frames.
Resolves#92458, #72904.
Pull Request: https://projects.blender.org/blender/blender/pulls/131335
Mistake in f6a4d01703. This refactored the lookup for a named string context
member to avoid code duplication.
Intention was to construct a StringRef referencing the string stored in
context. But the refactored lookup returned an unintentional string copy, so
the reference would be constructed from a temporary string object that would
get destructed immediately.
Renaming attributes in the property editor didn't take into account
the required domains and types for builtin attributes. It might be
possible to trigger crashes by using a builtin name with the wrong
metadata. At the very least it would be confusing.
This commit extends the attribute provider check for builtin
attributes to give the required domain and type. We check that in
the attribute rename function to make sure the new name is valid.
Pull Request: https://projects.blender.org/blender/blender/pulls/131702
Similar to 2fbf206491, but for integers (not strings). Essentially this
allows passing named integer values through UI abstractions in a clean
way.
I used 64 bit integers here, since space isn't an issue here, and it
fits common integer types (so we don't have to add APIs for multiple
integer types).
Planned to be used to fix#111463 (following commit).
This avoids assuming that `BKE_ntree_update_main` has run on a node tree before
the depsgraph is build. The update code already finds the dependencies to
determine if a relations update is necessary or not. To avoid detecting these
dependencies again (which requires iterating over all the nested nodes), they
were cached on the node group so that they can be used when the depsgraph is
build.
However, since the update code does not run in all necessary cases yet
(#131598), this does not work currently. This patch fixes the situation by
removing the optimization of not having to find all dependencies again when the
depsgraph is build.
This optimization can be introduced again after we can be more sure that the
node tree update code runs whenever the node tree changes (which is what #131665
tries, but requires more discussion).
Pull Request: https://projects.blender.org/blender/blender/pulls/131685
Edit mode for curves and Grease Pencil was using the plain object transform for
all points without support for individual crazyspace transforms. This patch adds
support for the local rotation matrices, so editing curves on top of modifiers
converts offsets into original geometry space.
For Curves objects these matrices are currently only computed by the surface
deformation node, so editing on top of a surface deformation is the only case
that works currently.
For Grease Pencil the armature modifier is supported and more should be added
in future (see overview task #131599).
Pull Request: https://projects.blender.org/blender/blender/pulls/131619
Grease Pencil v3 did not have crazyspace support yet. Without this sculpting on
deformed geometry (e.g. on top of an armature modifier) will yield incorrect
offsets because the tool writes to original data based on deformed positions.
This patch adds computation of local deformation matrices which are stored in
the `GeometryComponentEditData`. Those matrices are then used to convert local
deformation of the evaluated geometry back to a deformation of the original
geometry. All the relevant sculpt tools support the crazyspace correction now,
using the `compute_orig_delta` helper function.
Computing the deformation matrices should happen alongside modifier evaluation
for any deforming modifier. This has been implemented for the armature modifier,
others can be added.
A fallback implementation for curves could also be added for modifiers that
don't have an easy way to calculate local transformation. A "natural"
orientation for both the original and deformed positions is calculated, then the
difference yields deform matrices. For meshes the approach is to use the surface
normal and a stable tangent space. For curves the common local coordinate frame
based on parallel transport might be used.
Currently crazyspace correction for the _Clone_ tool does not work because of
#131496.
Pull Request: https://projects.blender.org/blender/blender/pulls/131499
Missed in 9945d511a9
The previous commit fixed files that had not yet been saved in 4.3,
however, the versioning code was not bumped which means that a user who
had a file in a version prior to 4.2 that then saved with the full
release of 4.3 would not have the corrected versioning applied for their
texture paint workspaces.
This commit re-applies similar versioning code and bumps the version
to ensure files are up to date.
Pull Request: https://projects.blender.org/blender/blender/pulls/131337
When rendering animation without baking dynamics first, rigid body
objects/shapes might be set up for the fist time (see
`rigidbody_update_simulation`).
Here is my take on what happens when we run into the reported crash:
In `rigidbody_validate_sim_object`, `rigidbody_validate_sim_shape` can
be called (which -- amongst other things -- can call `RB_shape_delete`).
It does not set `RBO_FLAG_NEEDS_RESHAPE` nor calls
`RB_body_set_collision_shape`. It only sets `rbo->shared->physics_shape`
(which only seems to to update the "blender side of things", but not the
"bullet side of things").
Then later (still in `rigidbody_validate_sim_object`),
`RB_dworld_add_body`/ `btDiscreteDynamicsWorld::addRigidBody`>
`btCollisionWorld::addCollisionObject` > collisionObject->getCollisionShape()
is called, but confused because we called `RB_shape_delete` before.
Also see the TODO(Sybren) comment from 98a0bcd425 (which might even be
removed with this PR, but not I havent verified "collision shape being
created twice" is now not happening anymore).
One might think that flagging `RBO_FLAG_NEEDS_RESHAPE` might be enough,
but reacting on that only happens later in `rigidbody_update_simulation`
(so not early enough to not run into the issues of `RB_dworld_add_body`
above).
So to resolve, call `RB_body_set_collision_shape` in
`rigidbody_validate_sim_shape` if we actually made a new one.
Fixes#130991
Pull Request: https://projects.blender.org/blender/blender/pulls/131039
- Gives O(1) access to string length in more cases
- Convenient string manipulation functions
- Clarify difference between "no string" and "empty string"
- Avoid the need for raw pointers in the API
- Shows which API string arguments are optional
Pull Request: https://projects.blender.org/blender/blender/pulls/131473
Previously, the data-block dependencies were always detected in
`update_depsgraph` in `MOD_nodes.cc`. This would only be called when something
called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph
rebuild after each operation in the node editor, as that would be expensive.
However, that also meant that we often had to add data-block dependencies that
are not actually used, but might be used if the user changed e.g. a link. A
typical example for that is a object socket that has a default value, but the
socket is also linked.
Now, the dependencies referenced by the node tree are collected by the node tree
update code which runs after all changes. This way we can detect whether the
dependencies have changed. Only if they have changed, a depsgraph rebuild is
triggered. This now allows also taking into account the mute status of nodes and
whether an input is linked.
There are still more things that could be taken into account. Most obviously
whether a node is connected to an output. This can be done later. The most
tricky aspect here is probably that we also have to consider all viewer nodes as
output, because at the time the node runs, it's not known which viewer will
actually be used (which depends on other editors).
This also cleans up some special cases we had for e.g. the scene time node where
we always had to trigger a depsgraph rebuild when it was added/removed because
of its time dependence. This is now part of a more general system.
This fixes#109219.
Pull Request: https://projects.blender.org/blender/blender/pulls/131446
This commit adds a new `color_tag` read-only enum property to nodes,
expanding on the existing node group `color_tag` property. The existing
node group color tag enum (`NodeGroupColorTag`) was renamed to the more
generic `NodeColorTag` and expanded to support all possible color tags.
This new property also works on node group nodes with custom color tags
set by the user.
Pull Request: https://projects.blender.org/blender/blender/pulls/131101
Copy the interface socket directly which makes sure that all relevant data is passed on.
The default is still adapted from the current socket value.
There are still places that could be improved that are not covered by this patch yet.
For example creating a group from a Set Position node changes the default Position input.
That could be fixed separately.
I removed one `assert` that did not seem important. It was making sure that an interface
item is only copied within a group, but I don't see a reason for why it should not be possible
to copy an item to a different group.
Pull Request: https://projects.blender.org/blender/blender/pulls/131394
This patch adds an option to use the new perlin noise as a noise function for the FCurve modifier.
That fixes the issue of the old noise function which could produce values outside the -0.5/0.5 range (For a strength of 1).
The old way is still preserved and will be automatically used for old files.
Because of the different noise function, I've added two more parameters to the noise modifier.
The default values for those parameters are chosen to be as close to the original noise modifier as possible.
However the match is not 1:1
## Depth
With the new noise, the parameters for "Lacunarity" and "Roughness" are available to the user.
By default they are set in such a way that changing the "Depth" results in a similar noise pattern.
## Offset and Scale
The offset and scale parameters now behave differently. Before they would also shift the phase in some way, now all they do is shift or scale the noise.
## Amplitude
The biggest difference is in the amplitude of the noise.
Overall the amplitude is a lot smaller in general than with the legacy noise, but it does fix the issue of the amplitude reaching outside the -0.5/0.5 range.
By shifting the phase I was able to find points where the amplitude reaches 0.5 but never above that.
Pull Request: https://projects.blender.org/blender/blender/pulls/129535
Vertex groups are written as generic attributes in bakes currently.
In order to restore them as vertex groups properly when reading bakes,
keep track of the vertex group names in the bake metadata.
Pull Request: https://projects.blender.org/blender/blender/pulls/131393
