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
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Some summary of changes:
- Don't use DEG prefix for types and enumerator values:
the code is already inside DEG namespace.
- Put code where it locally belongs to: avoid having one
single header file with all sort of definitions in it.
- Take advantage of modern C++11 enabled by default.
Move all mask-related fields from Object and OperationDepsNode
to Object_Runtime and IDDepsNode. Auto-apply DEG_TAG_GEOMETRY
if the mask changes after DEG rebuild. Update DEG API and all
code that uses it.
This fixes "source mesh data is not ready" errors from Data
Transfer modifier when parameters are changed in the UI after
the recent mesh_get_eval_final fix.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4025
- Use the original ID pointer for lookup in DEG_get_eval_flags_for_id.
- When the flags change after a DEG rebuild, tag the object for update.
- Instead of mixing int and short in different places, use uint32_t.
This fixes text not updating when a Follow Curve reference is set.
When this works correctly, we should be able to feed in an existing
depsgraph instance, and get out a "filtered" copy of it that contains
only the subset of nodes needed to evaluate what we're interested in.
The current implementation only filters on ID blocks/nodes,
and starts by building a full new depsgraph instance first.
I'd originally intended to do it per operation instead, copying
over individual nodes as appropriate to have the smallest and least
memory intensive graph possible. However, I ended up running into
into problems with function binding + COW arguments, hence the
current slow solution.
Calling code is responsible to check on NULL pointers here, or ensure
is does have a fully built and evaluated depsgraph, but this should
never crash in DEG queries themselves.
Make it more reliable and predictable way of getting pointer to
an original mesh which came from copy-on-write engine.
Related change: made it (hopefully) more clear name for flags.
This introduces a new depsgraph API for getting updated datablocks,
rather than getting it from bpy.data.
* depsgraph.ids_updated gives a list of all datablocks in the depsgraph
which have been updated.
* depsgraph.id_type_updated('TYPE') is true if any datablock of the given
type has been added, removed or modified.
More API updates are coming to properly handle multiple depsgraphs and
finer update granularity, but this should make Cycles work again.
Without the exception, adding new poses to pose libraries took several seconds
with only <= 4 bones selected. While we may still need this for other cases too,
since bones are such a common use case, it makes sense to provide some level
of optimisation for them.
This now works by getting the RNA Path from the given PointerRNA to go from the
ID block to the data it points to, then uses this path to find the new data
relative to the COW ID.
Note: This currently still has all the debug prints left in - As can be seen,
I was testing this against the earlier PoseBone hack/special case. We may still
need to bring such special cases back in future, since looking up RNA Paths
like this can be slow.
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
Previously it could have happened on every request to evaluated scene
or view layer.
This commit also removes expansion of view layer and scene from iterator.
Iterator is not to be used before depsgraph is evaluated.
Scene, view layer and mode are now set in the constructor and never changed.
Time is updated on frame changes to indicate which frame is being or has been
evaluated last.
This is a step towards making EvaluationContext obsolete.
Differential Revision: https://developer.blender.org/D3144
Quite straightforward implementation, allows us to remove all the cherry-picking
update of specified scene/view layer/collection fields. Makes it possible to use
generic function to update scene.
The tricky part is that we need to know view layer pointer before the whole
evaluation starts. So we actually expand scene at initialization of evaluation.
context. This is still a bit of an exceptional case, but at least we still avoid
dangerous cherry-picking update.
It makes more sense to stick to DEG_iterator_object order in name, since we can
have functions to iterate over different entities and we want all of them to
have common prefix.
Previously it was done during depsgraph iteration, which is not good at all,
since after evaluation nobody should really modify how object was evaluated.
The RenderResult struct still has a listbase of RenderLayer, but that's ok
since this is strictly for rendering.
* Subversion bump (to 2.80.2)
* DNA low level doversion (renames) - only for .blend created since 2.80 started
Note: We can't use DNA_struct_elem_find or get file version in init_structDNA,
so we are manually iterating over the array of the SDNA elements instead.
Note 2: This doversion change with renames can be reverted in a few months. But
so far it's required for 2.8 files created between October 2016 and now.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D2927
This is a final step of having proper ownership. Now selecting different
layers in the "top bar" will actually do what this is expected to do.
Surely, there are still things to be done under the hood, that will happen
in a less intrusive way.
This fixes the issue for the Draw Manager, but for Cycles this is still not
working. The iterator bpy.context.depsgraph.duplis seems to be correct though.
We now initialize iter.valid as true as part of the main iterator (and manually
when using via Python). And we don't even bother setting iter->current to NULL
if it's invalid. Let's stick to using iter->valid only.
This was leading to crashes on Cycles as well as misleading
len(bpy.context.depsgraph.objects)
I can even move the iter->skip as part of DEGObjectsIteratorData instead of
BLI_Iterator, but if I do it will be a separate commit.
Thanks Sergey Sharibyn for the well done sample file and patch suggestion.
Although this works by itself, it should actually happen after:
"Reshuffle collections base flags evaluation, make it so object is gathering
its base flags from collections."
Meanwhile we have one single hacky function (deg_flush_base_flags_and_settings)
to be removed once the task above is tackled.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D2899
Iterate over invisible objects too, so lamps can still lit the scene.
Also, now you can use a collection to set an object to invisible, not
only to visible.
For example:
Scene > Master collection > bedroom > furniture
Scene > View Layer > bedroom (visible)
> furniture (invisible)
The View Layer has two linked collections, bedroom and furniture.
This setup will make the furniture collection invisible.
Note: Unlike what was suggested on D2849, this does not make collection
visibility influence camera visibility. I will keep this as a separate
patch.
Reviewers: sergey
Subscribers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D2849
This commit effectively makes workspace switching useless as far as the
active scene layer goes.
The functions from the scene layer API to get the correct scene layer
from "context" were a placeholder to be addressed by the workspace
commit.
When workspace was merged, however G.main was used as a replacement to pass the
correct argument for the functions. As it turned out (surprise!) this
leads to crash on render preview.
We need to get rid of:
* BKE_scene_layer_context_active_ex_PLACEHOLDER
* BKE_scene_layer_context_active_PLACEHOLDER
And either use SceneLayer explicitly or replace it by:
* BKE_scene_layer_from_workspace_get
< Dependency graph Copy-on-Write >
--------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
This is an initial commit of Copy-on-write support added to dependency graph.
Main priority for now: get playback (Alt-A) and all operators (selection,
transform etc) to work with the new concept of clear separation between
evaluated data coming from dependency graph and original data coming from
.blend file (and stored in bmain).
= How does this work? =
The idea is to support Copy-on-Write on the ID level. This means, we duplicate
the whole ID before we cann it's evaluaiton function. This is currently done
in the following way:
- At the depsgraph construction time we create "shallow" copy of the ID
datablock, just so we know it's pointer in memory and can use for function
bindings.
- At the evaluaiton time, the copy of ID get's "expanded" (needs a better
name internally, so it does not conflict with expanding datablocks during
library linking), which means the content of the datablock is being
copied over and all IDs are getting remapped to the copied ones.
Currently we do the whole copy, in the future we will support some tricks
here to prevent duplicating geometry arrays (verts, edges, loops, faces
and polys) when we don't need that.
- Evaluation functions are operating on copied datablocks and never touching
original datablock.
- There are some cases when we need to know non-ID pointers for function
bindings. This mainly applies to scene collections and armatures. The
idea of dealing with this is to "expand" copy-on-write datablock at
the dependency graph build time. This might introduce some slowdown to the
dependency graph construction time, but allows us to have minimal changes
in the code and avoid any hash look-up from evaluation function (one of
the ideas to avoid using pointers as function bindings is to pass name
of layer or a bone to the evaluation function and look up actual data based
on that name).
Currently there is a special function in depsgraph which does such a
synchronization, in the future we might want to make it more generic.
At some point we need to synchronize copy-on-write version of datablock with
the original version. This happens, i.e., when we change active object or
change selection. We don't want any actual evaluation of update flush happening
for such thins, so now we have a special update tag:
DEG_id_tag_update((id, DEG_TAG_COPY_ON_WRITE)
- For the render engines we now have special call for the dependency graph to
give evaluated datablock for the given original one. This isn't fully ideal
but allows to have Cycles viewport render.
This is definitely a subject for further investigation / improvement.
This call will tag copy-on-write component tagged for update without causing
updates to be flushed to any other objects, causing chain reaction of updates.
This tag is handy when selection in the scene changes.
This basically summarizes ideas underneath this commit. The code should be
reasonably documented.
Here is a demo of dependency graph with all copy-on-write stuff in it:
https://developer.blender.org/F635468
= What to expect to (not) work? =
- Only meshes are properly-ish aware of copy-on-write currently, Non-mesh
geometry will probably crash or will not work at all.
- Armatures will need similar depsgraph built-time expansion of the copied
datablock.
- There are some extra tags / relations added, to keep things demo-able but
which are slowing things down for evaluation.
- Edit mode works for until click selection is used (due to the selection
code using EditDerivedMesh created ad-hoc).
- Lots of tools will lack tagging synchronization of copied datablock for
sync with original ID.
= How to move forward? =
There is some tedious work related on going over all the tools, checking
whether they need to work with original or final evaluated object and make
the required changes.
Additionally, there need synchronization tag done in fair amount of tools
and operators as well. For example, currently it's not possible to change
render engine without re-opening the file or forcing dependency graph for
re-build via python console.
There is also now some thoughts required about copying evaluated properties
between objects or from collection to a new object. Perhaps easiest way
would be to move base flag flush to Object ID node and tag new objects for
update instead of doing manual copy.
here is some WIP patch which moves such evaluaiton / flush:
https://developer.blender.org/F635479
Lots of TODOs in the code, with possible optimization.
= How to test? =
This is a feature under heavy development, so obviously it is disabled by
default. The only reason it goes to 2.8 branch is to avoid possible merge
hell.
In order to enable this feature use WITH_DEPSGRAPH_COPY_ON_WRITE CMake
configuration option.
