This makes `RNANodeQuery::construct_node_identifier()` more strict in
its matching of certain property names.
The downside of this approach is that it's not possible any more to use
`"rotation"` and expect a match for `"rotation_euler"` and friends, so
the list of strings to test against is now 3x as long.
Reviewed By: sergey
Maniphest Tasks: T79121
Differential Revision: https://developer.blender.org/D8375
The extra depsgraph relations that were added to prevent threading
issues during evaluation (rB4c30dc343165) caused a considerable slowdown
on complex scenes with many drivers (T77277, T78615). This commit
improves this as follows.
Only the following drivers are considered for execution serialisation:
- Drivers on Array elements, and
- Drivers on Boolean or Enum properties.
Relations between drivers of the same arrays are added blindly, i.e.
without checking for transitive or cyclic relations. This is possible as
other relations will just target the `PROPERTIES_ENTRY` or
`PROPERTIES_EXIT` nodes.
Checking whether a driver is on an array is first done by checking
`array_index > 0`, and then falling back to resolving the RNA path to an
RNA property and inspecting that.
The code also avoids circular dependencies when there are multiple
drivers on the same property. This not something that is expected to
happen (both the UI and the Python API prevent duplicate drivers), it
did happen in a file (F8669945, example file of T78615) and it is easy
to deal with here.
Reviewers: sergey
Subscribers: mont29
Comment update
Those are useful when you have to create containers with static
storage duration. If those would use Blender's guarded allocator,
it would report memory leaks, that are not actually leaks.
This updates the usage of integer types in code I wrote according to our new style guides.
Major changes:
* Use signed instead of unsigned integers in many places.
* C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`).
* Hash values for C++ containers are 64 bit wide now (instead of 32 bit).
I do hope that I broke no builds, but it is quite likely that some compiler reports
slightly different errors. Please let me know when there are any errors. If the fix
is small, feel free to commit it yourself.
I compiled successfully on linux with gcc and on windows.
Having a sound strip in the VSE caused a missing relation error to be
logged on the console. This was caused by the AUDIO depsgraph component
not having an entry node. This commits adds that node, and sets up
relations correctly.
Differential Revision: https://developer.blender.org/D8290
Reviewed By: Sergey
Every Particle Simulation node has a name (or a path when it is in a node group).
This name has to be used in the Simulation modifier on a point cloud to see
the particles.
Caching has been disabled for now, because it was holding back development
a bit. To reset the simulation, go back to frame 1.
Currently, there is no way to influence the simulation. There are just some
randomly moving points. Changing that is the next step.
This is a fix for c7694185c9. An object without base can still be in the
depsgraph, and then the `VIEW_LAYER_EVAL` node does not exist.
This popped up while @Sergey was looking into T78264.
Note that this is partially WIP code, we only take care of shapekeys
here for now.
Also, move this tagging for liboverride refresh into same chack as the
one for tagging editors, sounds more logical that way.
The `Base *` parameter of `DepsgraphRelationBuilder::build_object()` was
made redundant by c7694185c9. This commit actually removes it.
No functional changes.
A driver reading `Object.hide_viewport` would break when that object was
hidden. Hidden objects don't have the `OBJECT_BASE_FLAGS` node in the
depsgraph, but that node was required for the driver to work.
Now the `OBJECT_FROM_LAYER` component (which optionally contains the
`OBJECT_FROM_LAYER` node) has explicit `ENTRY` and `EXIT` nodes, which
are used for relations with other components. These relations now remain
valid, even when the `OBJECT_FROM_LAYER` node is absent.
Differential Revision: https://developer.blender.org/D8124
Reviewed By: sergey
This reverts commit baa0da3e69.
The commit causes some issues I didn't foresee, I'd rather take the time
to do it properly than hastily try and commit a fix for it.
An object can be targeted by a driver that reads its `hide_viewport` or
`hide_render` property. The existence of such a driver will create a
relation between the 'sync base flags' depsgrpah node, and the datablock
containing the driver. When the object is hidden, however, it has no
base, and thus it had no 'sync base flags' depsgraph node. To support
such a driver, that depsgraph node is now always added, but for hidden
objects it will just be a no-op. If the node is not used by anything, it
will be automatically disconnected and have a negligible effect on
performance.
It turns out that
`DepsgraphNodeBuilder::build_object_data_geometry(Object *object, bool
is_object_visible)` was called for the custom shape with
`is_object_visible=false` when there are drivers, and
`is_object_visible=true` when there aren't any.
This makes any operation (including mere bone selection) several times
faster on some complex production character, since we typically now only
need to diff a single ID, instead of tens of them.
We decided to use our own map data structure in general for better
readability and performance.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7987
Now all overrides are handled that way. Performances of the process look
decent enough, even with production characters...
If performance issues still arise, we'll investigate other solutions.
This should also make T73154 obsolete now.
We decided that `blender::Set` should be the default choice for a set
data structure in Blender.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7982
We decided that `blender::Vector` should be the default choice for
a vector data structure in Blender.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7981
Previously, this function would expect a callback function as parameter.
This behavior is now in Map.lookup_or_add_cb. The new version just
takes the key and value directly.
This also renames `MutableArrayRef` to `MutableSpan`.
The name "Span" works better, because `std::span` will provide
similar functionality in C++20. Furthermore, a shorter, more
concise name for a common data structure is nice.
The main focus here was to improve the docs significantly. Furthermore,
I reimplemented `Set`, `Map` and `VectorSet`. They are now (usually)
faster, simpler and more customizable. I also rewrote `Stack` to make
it more efficient by avoiding unnecessary copies.
Thanks to everyone who helped with constructive feedback.
Approved by brecht and sybren.
Differential Revision: https://developer.blender.org/D7931
The current particle state is stored in a `CustomData` instance and
the cache is stored in `PointCache`.
The current state exists on the copy-on-write copies of the simulation,
while the cache only exists in the original data block.
This patch implements a temporary trivial particle simulation that does not
use the node system yet. It is used for testing and will be replaced soon.
`PointCache` still has some limitations that need to be overcome using
separate refactorings. For example, we need to be able to store the number
of particles in the point cache. Also we need to change which attributes
are stored for a particle system more dynamically than is currently possible afaik.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7836
Found during research of {T77124}. In `build_driver_data` an identical
RNA_path is resolved twice. In stead of resolving it twice this patch
will construct the `property_exit_key` based on the resolution of
`property_entry_key`.
This change isn't noticeable for users. Just a cleanup as it isn't
needed to do the same logic twice.
Reviewed By: Sergey Sharybin
Differential Revision: https://developer.blender.org/D7872
It was causing wrong binding for image animation: since there was no
ID node for texture at the moment of build_animdata original texture
ID was passed to the callback. This is not what is supposed to happen.
This is part of fix for T65889.
Lamps were not tagged with `ID_RECALC_SHADING` when they were updated
from drivers. As a result, Cycles considered the lamp as unchanged. This
is resolved by having a (seemingly non-functional) callback in a new
`LIGHT_UPDATE` depsgraph node.
This patch unconditionally adds the `LIGHT_UPDATE` node + the relation
from the lamp's PARAMETERS node.
Differential Revision: https://developer.blender.org/D7822
Reviewed by: brecht
From what I can see, there are two issues at play in {T76689} and its merged-in report {T76590}:
- In Blender ≤ 2.79 the bone layer dots were updated in the draw code. This ensured the info was up to date before drawing. This is no longer possible, as the drawing code uses evaluated objects, and those should not be written to. This has been addressed in rB709f126e8143 by calling the update function explicitly in various places in the code. The problem is that this wasn't added to all necessary spots.
- When in edit mode, changes are made to the edit bones but not to the 'actual' bones (this is synced when exiting edit mode). This causes undo to mess up the layer indicators.
I think both issues can be addressed by having the dependency graph update the used layer info as part of the armature evaluation. This will make the undo system work properly, and allows the removal of some `BKE_armature_refresh_layer_used()` from various places.
There is still the issue that there are two functions (`BKE_armature_refresh_layer_used()` and `ED_armature_edit_refresh_layer_used()`) that are both responsible for updating `bArmature::layer_used`. This is a trickier thing to solve, though, as the definition of the `EditBone` struct resides in the armature editor module. This means that blenkernel can't iterate over edit bones, but on the other hand the dependency graph shouldn't call any editor functions either. This is why I left the `ED_armature_edit_refresh_layer_used()` calls untouched.
The downside of recalculating `layer_used` from the dependency graph (at least in the way that I did it now) is that it is called every time a user moves a bone in pose mode. This frequency of updates is not necessary.
Differential Revision: https://developer.blender.org/D7709
