The object "delta_" rna variables were not added to the depsgraph search
and thus it would not trigger updates of the object during animation
playback.
This does not fix all the cases in the bug report, because there are multiple
different issues. Only the first two are fixed. The third is probably a known
issue for now.
Before this patch, the rigid body simulation was always done after modifiers
are evaluated, because to perform the simulation, the final geometry of the
object was required. However, the geometry is not required in all cases,
depending on the selected collisions shape.
This patch changes it so that when the simulation does not need the
evaluated geometry, the simulation will be done before the modifiers
are evaluated. This gives the modifiers access to the simulated positions.
When the rigid body simulation does depend on the evaluated geometry,
it will still be performed after modifiers are evaluated.
The simulation will be performed after modifiers are evaluated, iff
the collision shape is "Convex Hull" or "Mesh" and the source is set
to "Deform" or "Final".
Reviewers: sergey
Differential Revision: https://developer.blender.org/D8487
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
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
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.
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.
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
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.
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
For now the "Simulation" modifier only exists for point cloud objects, because
we need this for the particle system. Right now, the modifier is doing nothing.
There is a new `DEG_add_simulation_relation` function that is used
by the modifier to make sure that the simulation is evaluated before
the modifier is executed.
Reviewers: brecht, sergey
Differential Revision: https://developer.blender.org/D7549
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
Dependancy missing while building depsgraph for particle systems.
fix: adding a relation texture->particles when texture has animation data.
Reviewed By: sergey
Maniphest Tasks: T76251
Differential Revision: https://developer.blender.org/D7573
This fixes an issue where an animated modifier property that's used as
variable in a driver wouldn't animate that driver's value.
Building the relations for the driver target creates the relation
`PARAMETERS_EVAL` → `DRIVER(variable)`. Building the relations for the
FCurve targeting the modifier property creates the relation
`ANIMATION_EXIT` → `GEOMETRY_EVAL_INIT`.
This means that there is NOT a relation `ANIMATION_EXIT` →
`PARAMETERS_EVAL`, and as a result, the driver is not properly updated
when its variable reads animated data. This is resolved in this commit
by adding the missing relation.
Differential Revision: https://developer.blender.org/D7615
All the driver-specific code in `fcurve.c` has been moved into a new file
`fcurve_driver.c`. The corresponding declarations have been moved from
`BKE_fcurve.h` to `BKE_fcurve_driver.h`.
All the `#include "BKE_fcurve.h"` statements have been investigated and
replaced with `BKE_fcurve_driver.h` where necessary.
No functional changes.
