Make the SHADING_PARAMETERS operation on node tree a real no-op.
The function used as a callback was only doing a debug print.
The issue with this function was that an original ID was passed
as an argument. This is a violation of design, and if anything it
should be left up to the implementation to check whether depsgraph
is active.
There are no functional changes for users in the interface. The
only difference is that the debug print will no longer happen.
This change removes copy-on-write operations from ID nodes which do not
need copy-on-write.
Should be no functional changes, as before the copy-on-write operation
would do nothing for those nodes anyway.
Building IDs which are not covered by copy-on-write process was not
implemented, which was causing parameters block not present, and, hence
causing crashes in areas which expected parameters to present.
First part of this change is related on making it so Copy-on-Write is
optional for ID nodes in the dependency graph.
Second part is related on using a generic builder for all ID types
which were not covered by Copy-on-Write before.
The final part is related on making it so build_id() is properly
handling ParticleSettings and Grease Pencil Data. Before they were not
covered there at all, and they need special handling because they do
have own build functions.
Not sure it worth trying to split those parts, as they are related to
each other and are not really possible to be tested standalone. Open
for a second opinion though.
Possible nut-tightening is to re-organize build_id() function so
that every branch does return and have an assert at the end, so that
missing ID type in the switch statement is easier to spot even when
using compilers which do not report missing switch cases.
As for question "why not use default" the answer is: to make it more
explicit and clear what is a decision when adding new ID types. We do
not want to quietly fall-back to a non-copy-on-write case for a newly
added ID types.
Differential Revision: https://developer.blender.org/D10075
If a force field was of type "Texture", any changes of that texture (e.g.
its type - as reported in T85139 - or also its properties) were not
properly updating rigid bodies and particle systems.
Now ensure that texture is actually in the depsgraph and set up relation
accordingly.
Also fixes T75198.
Maniphest Tasks: T85139
Differential Revision: https://developer.blender.org/D10234
This reverts commit 76fd41e9db. This should have
been reverted along with 0f95f51361, since this
change by itself is causing crashes when the depsgraph accesses a non-existent
copy-on-write component.
Ref T84717
Revert "Fix T83411: Crash when using a workspace/layout data path in a driver"
The fix for the crash exposed design violation in the viewport shading updates,
which is for some reason relying on dependency graph tag of interface data.
The viewport module did not respond to the issue in 2 weeks, and the architect
considered missing update for multiple users a more serious issue than a crash
in a very specific case.
This reverts commit 0f95f51361.
The WORLD_UPDATE operation (needed to free the gpu material) was already
defined in DepsgraphNodeBuilder::build_world, but corresponding relation
was only set up for changes in the nodetree, not for changes in the
world/material itself in DepsgraphRelationBuilder::build_world.
Direct changes to these surface properties in the UI were updating
properly through RNA property update callbacks, but these are not called
from the animation system.
So now add these relations in the depsgraph.
Not 100% sure this is the right place for this (since e.g. eevee engine
seems to handle e.g. animated light paramters just fine through
EEVEE_cache_populate / eevee_light_setup, but properly freeing gpu
materials wont happen for worlds in e.g eevee_id_world_update and also
not for materials)
Maniphest Tasks: T84250
Differential Revision: https://developer.blender.org/D9959
This change removes copy-on-write operations from ID nodes which do not
need copy-on-write.
Should be no functional changes, as before the copy-on-write operation
would do nothing for those nodes anyway.
Building IDs which are not covered by copy-on-write process was not
implemented, which was causing parameters block not present, and, hence
causing crashes in areas which expected parameters to present.
First part of this change is related on making it so Copy-on-Write is
optional for ID nodes in the dependency graph.
Second part is related on using a generic builder for all ID types
which were not covered by Copy-on-Write before.
The final part is related on making it so build_id() is properly
handling ParticleSettings and Grease Pencil Data. Before they were not
covered there at all, and they need special handling because they do
have own build functions.
Not sure it worth trying to split those parts, as they are related to
each other and are not really possible to be tested standalone. Open
for a second opinion though.
Possible nut-tightening is to re-organize build_id() function so
that every branch does return and have an assert at the end, so that
missing ID type in the switch statement is easier to spot even when
using compilers which do not report missing switch cases.
As for question "why not use default" the answer is: to make it more
explicit and clear what is a decision when adding new ID types. We do
not want to quietly fall-back to a non-copy-on-write case for a newly
added ID types.
Differential Revision: https://developer.blender.org/D10075
The root of the issue was caused by the dependency graph using ID pointer
to map evaluated state from old depsgraph to new one upon relations update.
This was failing when IDs were re-allocated rapidly: was possible that
Object ID's evaluated state assigned to Mesh and vice versa.
Now depsgraph uses Session UUID to identify which IDs to restore evaluated
state to. The session UUID is stored in the IDNode, so that id_orig is not
dereferenced on depsgraph update since the ID might be freed.
The root of the issue is identified by Campbell, original patch was done
by Bastien, thanks! Also thanks to Oliver and Ray and everyone else for
testing!
Remove DNA headers, using forward declarations where possible.
Also removed duplicate header, header including it's self
and unnecessary inclusion of libc system headers from BKE header.
The implementation is pretty much the same as for Object sockets.
The socket color is the one that is used for collections in the outliner.
Part of D9739.
Modernize loops by using the `for(type variable : container)` syntax.
Some loops were trivial to fix, whereas others required more attention
to avoid semantic changes. I couldn't address all old-style loops, so
this commit doesn't enable the `modernize-loop-convert` rule.
Although Clang-Tidy's auto-fixer prefers to use `auto` for the loop
variable declaration, I made as many declarations as possible explicit.
To me this increases local readability, as you don't need to fully
understand the container in order to understand the loop variable type.
No functional changes.
Only a single DEG operation node `POSE_SPLINE_IK_SOLVER` should
be added in this case [ see `build_splineik_pose`, same is already done
for overlapping IK in `build_ik_pose`]
ref T82347.
Reviewers: sybren
Maniphest Tasks: T82347
Differential Revision: https://developer.blender.org/D9471
Not sure why Collection was the only ID for which depsgraph building did
not check for potential recursion?
Reviewed By: sergey
Maniphest Tasks: T82149
Differential Revision: https://developer.blender.org/D9365
It is possible to create scene strips pointing to each other. This is
sanitized when rendering, but in dependency graph such setup will cause
infinite loop.
This patch fixes loop in dependency graph, but same problem exists in
audaspace
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9262
The design for how we approach the "Everything Nodes" project
has changed. We will focus on a different part of the project initially.
While future me will likely refer back to some of the code I remove here,
there is no point in keeping this code around in master currently.
It would just confuse other developers working on the project.
This does not remove the simulation modifier and data block. Those are
just cleaned up, so that the boilerplate code can be reused in the future.
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
The example file in T81218 has a driver that maps a bone's X-location to
the number of BBone segments. This caused a dependency cycle, which
resulted in bad thread serialisation, which caused the crash.
This patch breaks the dependency cycle `BONE_LOCAL` →
`DRIVER(bones["Bone"].bbone_segments)` → `BONE_LOCAL`. The 'Driver Data'
relation now points to `BONE_SEGMENTS` when the driven property starts
with `bbone_`.
Differential Revision: https://developer.blender.org/D9122
Add a dependency graph relation Force Object Animation → Scene Rigid
Body World Rebuild. This ensures that the rigid body world is rebuilt
when a force object is re-tagged for animation updates.
The extra relation doesn't add any new calculations when the animation
is running, as the Time Source node already had a relation to the
scene's `RIGIDBODY_REBUILD` node.
The relation is created directly to the `RIGIDBODY_REBUILD` Operation. I
would have liked to target the containing Component instead. However,
that has the `RIGIDBODY_SIM` operation as entry node, which isn't enough
to actually fix T80121.
Reviewers: Sergey
Differential Revision: https://developer.blender.org/T80121
Allows scripters to store additional information in the marker itself instead
of using work-around approach based on marker names and such.
Differential Revision: https://developer.blender.org/D8944
Because depsgraph isn't rebuild for animated properies, we have to
assume that active bodies will always want to have updates from the
rigidbody simulation.
We need to have transforms from passive objects if they are animated or
driven by parent relations. This is not immediately obvious as the
object transform matrix will still be available, it is just one frame
behind in some cases.
Fixed dependency cycles if there is a constraint between two rigid
bodies. Because bullet keeps track of its simulated bodies, we do not
need to supply objects transforms as bullet should already have them.
I need combine these two fixes because otherwise we will get depsgraph
warnings that nodes are missing that it expects to be there.
Reviewed By: Sergey, Jacques
Differential Revision: http://developer.blender.org/D8732
