Since it is a continuous cycle, there's no need to repeat the
name of the previous bone. Also, dot is a common symbol in object
and bone names, so use '/' instead for node nesting.
Targeting a different object always requires its transform,
and normally dependencies should go to the solver node.
ITASC is quite broken so special case it until fixed.
Although technically evaluating the proxy copy nodes doesn't require
the parent bone to be copied, other nodes that depend on the bones
sometimes expect the parent to be ready. To meet this expectation
it's necessary to add the dependency to the graph.
The bug is caused by problems in the dependency graph. Unfortunately,
fixing is not just a matter of fixing the graph, because correct
dependencies would cause a cycle here and in other reasonable use
cases. The real fix thus requires refactoring Spline IK to require
curve data only in the actual evaluation phase, and not in POSE_INIT_IK.
In addition, this separates the normal bone evaluation loop from
Spline IK computations for two reasons:
- That still needs to be done even if spline IK can't evaluate
due to missing curve data.
- It should reduce issues with induced shearing, as Spline IK now
controls how parent-child relations are handled in the chain, and
can take care to only carry over rotation and location.
Random place in the modifier stack can not be referenced,
so it doesn't make sense to sue GEOMETRY component as a
FROM operation.
So now drivers on modifiers are driving GEOMETRY component,
but are using PARAMETERS as a source for variables.
BKE_mesh_new_nomain automatically added a CD_ORIGINDEX layer initialized to 0,
which was never filled in correctly. In 2.7 the equivalent function used to
modify the source derivedmesh and add valid original indices to it, but this
is no longer possible in the new design and was quite unpredictable anyway.
Now instead rely on mesh_calc_modifiers and the depsgraph to determine when
CD_ORIGINDEX should be added.
Was a mistake in the recent change.
The idea here is: manual should invalidate point cache, but
rigid body simulation should only happen after point cache
was ensured to be in the correct state.
There was missing flush from transform update to the point cache
reset. Caused by the fact that when update happens in the "middle"
of component all the component operations will be tagged for update
(since the intermediate state is not stored), but that will not
flush updates to other operations since that would cause too much
of updates.
This now we tag point cache for reset after evaluation operation
but before final transform and before rigid body world.
The issue is a feedback loop with point cache reset operation.
Solved by introducing extra node which ensures object's transformation
is ready for simulator input. Allows to route relations without causing
a fake dependency cycle now.
This was already supported for Cycles shader nodes, but now also works for
Eevee and compositing nodes. Instead of a generic NodeCustomGroup, now
there is ShaderNodeCustomGroup and CompositorNodeCustomGroup that can be
subclassed and registered.
Differential Revision: https://developer.blender.org/D4370
The core was hooking up relation to a wrong operation, in an
attempt to cause proper full update of the pose (since there
is no intermediate state stored anywhere). This is now done
as a part of flush_handle_component_node(), so can properly
route more granular relation.
This fixes the crash which was caused by an access of partially
evaluated data by solving the fake cycle. However, if there
is a real cycle involved the code will still not survive, but
this is more generic issue (which also includes modifiers
for meshes and curves).
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4509
Use dedicated flag to tag animation just for copy-on-write synchronization,
which makes it so copies of the original data blocks gets in sync with the
original ID. This will not flush the animation update to all objects which
depend on that animation.
If such flush is required, use ID_RECALC_ANIMATION.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4508
When having loops in a kinematic chain and also a IK constrain,
the solve_cycle function removes graph relations necessary to ensure
the cleanup operation was running at the very end.
Due to his Blender was crashing when some operations (the bone
constraints) accessed a pointer that was already freed.
Solved by adding more relations between crucial nodes.
Do proper tagging for material changes, and avoid grease-pencil hack
in the relations builder.
The dependency graph code was forcing animation to be run for any
copy-on-write change of material. However, animation is not supposed
to be run on copy-on-write changes.
This allows to have drivers on node trees.
Probably now it will be better to simply add parameters for any
ID node, to avoid such amount of manual work.
Initial idea was to not have nodes if it's not needed to avoid
any possible overhead. Having more robust system is probably more
valuable. We can always optimize overhead in one way or another.
Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
Object of evaluated base is not yet copied, so we can not know whether
it has animation on visibility or not.
This issue was reported in T56635#630383.
Original optimization idea was wrong: it is possible that some other
ID would reference an object which is also used by a base.
Rolled back to a bit more fragile solution.
In the future would be nice to make it somewhat less duplicated with
the builder itself.
Fixes assert failure (and possibly crashes) when adding grease pencil
object and switching to a draw mode.
While it's kind of common to use camel case in C++ this is not
currently agreed style for C++ in Blender.
Got confused by working on other areas with 3rd party libraries.
This allows dependency graph to evaluate drivers of those objects
and put them to a correct state. It will increase memory usage
since now we can no longer save it by skipping copy-on-write for
such objects. It will also currently make things slower, because
we do not have granular enough visibility update of components in
the dependency graph. Can do it later when the rest of the changes
are finished.
This commit does not update restriction flags on the base, since
that is somewhat tricky to do currently: need to somehow see whether
object is disabled due to flags on collection or due to own flags.
Differential Revision: https://developer.blender.org/D4419
No need to have iterator loop in the view layer evaluation,
this only makes it more difficult to have base flags covered
by the dependency graph.
Other good thing is that we don't need to worry about whether
base has been removed from the evaluated view layer or not.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4414
