| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Missing dependency graph relation from geometry to simulation,
which made simulation to use evaluated mesh while it is being
evaluated.
|
|
Relation in dependency graph is something else. So make it clear
that those are the effector ones.
|
|
evaluations.
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.
|
|
Makes it possible to handle them the same from drivers
relations builder.
Solves missing operations errors printed when opening
autumn character.
|
|
|
|
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.
|
|
Is a dependency cycle problem. Fix is similar to what is done in 024f5ba2bdb.
|
|
|
|
Missing dependency graph update due to wrong relation.
|
|
|
|
The general idea of this change is to have a runtime data pointer
in the ModifierData, so it can be preserved through copy-on-write
updates by the dependency graph.
This is where subdivision surface modifier can store its topology
cache, so it is not getting trashed on every copy-on-write which
is happening when moving a vertex.
Similar mechanism should be used by multiresolution, dynamic paint
and some other modifiers which cache evaluated data.
This fixes T61746.
Thing to keep in mind, that there are more reports about slow
subdivision surface in the tracker, but that boils down to the
fact that those have a lot of extraordinary vertices, and hence
a lot slower to evaluated topology.
Other thing is, this speeds up oeprations which doesn't change
topology (i.e. moving vertices).
Reviewers: brecht
Reviewed By: brecht
Maniphest Tasks: T61746
Differential Revision: https://developer.blender.org/D4541
|
|
Currently not needed that much, but will ease some further
development which is related on preserving runtime modifier
data.
|
|
|
|
|
|
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
|
|
|
|
Mostly functions wrapping args, not confirming to our style guide.
|
|
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.
|
|
Need to always ensure objects form rigid body wortld are part
of dependency graph.
|
|
Inheriting the display type from the instancer should only happen if it's
a simpler one.
|
|
Otherwise it's impossible to set the color of instanced library objects.
Follows convention of instancer controlling draw options.
|
|
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.
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4497
|
|
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.
|
|
Fix T61152 Instanced Collections Don't Honor Viewport Display Setting
|
|
Related on T61937.
|
|
This removes special dependency graph code that was intended to avoid GPU
shader recompiles by preserving the node tree and GPU material in specific
cases. This is no longer needed now that we have a general shader pass
cache that compares the generated shader code. The GPU material is already
being freed in material and world eval as well, so there's no point.
Note also that GPU materials are now safe to free from threads, actual
OpenGL buffer freeing happens delayed.
|
|
Modifier stack was forced to be re-evaluated when it was not
supposed to. Should also improve sculpt performance.
|
|
Convention was not to but after discussion on 918941483f7e 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
|
|
|
|
Memory optimization in dependency graph was using wrong view layer
for the scene which came via set.
|
|
|
|
The issue was discovered only after recent changes, but roots back
to much older changes.
What was happening is scene's ID recalc flags where never cleared,
which caused ensure_view_layer() to always run copy-on-write on the
scene. This resulted in certain runtime data being cleared, without
proper flag stored in the dependency graph.
This was caused by ID recalc clear function checking whether any ID
was tagged for recalc in that graph or not. This was happening due
to all areas using DEG_id_type_tag() which can only set flags on the
graph from viewport scenes, and could not inform render dependency
graph.
Now ID tyoe tagging is happening on per-graph level, which avoids
possibility of flags running out of sync.
In a bit longer term we also need to get rid of two functions which
are clearing flags: DEG_id_type_tag() and deg_graph_clear_tags().
|
|
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
|
|
|
|
The idea is to keep bases which are known for sure to be in the
dependency graph. Previously, this code was duplicating logic
around checking restriction flags, which becomes more hard to
maintain once we are moving towards to more comprehensive checks
about whether base is a part of evaluated scene or not.
|
|
|
|
Just de-duplicates some logic. Should be no functional changes.
|
|
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
|
