It is not allowed to do tagging or updates while dependency graph is
in the middle of evaluation.
This is something what is simple to violate from python code. This
change adds some sanity checks.
The request to update view layer or dependency graph will raise an
exception in Python now, so it's easy for scripters to notice.
Tagging for update will do silent return unless running with debug
command line argument. This is because it's a bit tricky to know
which exact dependency graph corresponds to a context from which
an update tag was triggered.
Differential Revision: https://developer.blender.org/D6035
Main goal here is to make it obvious and predictable about
what is going on.
Summary of changes.
- Access to dependency graph is now only possible to a fully evaluated
graph. This is now done via context.evaluated_depsgraph_get().
The call will ensure both relations and datablocks are updated.
This way we don't allow access to some known bad state of the graph,
and also making explicit that getting update dependency graph is not
cheap.
- Access to evaluated ID is now possible via id.evaluated_get().
It was already possible to get evaluated ID via dependency graph,
but that was a bit confusing why access to original is done via ID
and to evaluated via depsgraph.
If datablock is not covered by dependency graph it will be returned
as-is.
- Similarly, request for original from an ID which is not evaluated
will return ID as-is.
- Removed scene.update().
This is very expensive to update all the view layers.
- Added depsgraph.update().
Now when temporary changes to objects are to be done, this is to
happen on original object and then dependency graph is to be
updated.
- Changed object.to_mesh() to behave the following way:
* When is used for original object modifiers are ignored.
For meshes this acts similar to mesh-copy, not very useful but
allows to keep code paths similar (i.e. for exporter which has
Apply Modifiers option it's only matter choosing between original
and evaluated object, the to_mesh() part can stay the same).
For curves this gives a mesh which is constructed from displist
without taking own modifiers and modifiers of bevel/taper objects
into account.
For metaballs this gives empty mesh.
Polygonization of metaball is not possible from a single object.
* When is used for evaluated object modifiers are always applied.
In fact, no evaluation is happening, the mesh is either copied
as-is, or constructed from current state of curve cache.
Arguments to apply modifiers and calculate original coordinates (ORCO,
aka undeformed coordinates) are removed. The ORCO is to be calculated
as part of dependency graph evaluation.
File used to regression-test (a packed Python script into .blend):
{F7033464}
Patch to make addons tests to pass:
{F7033466}
NOTE: I've included changes to FBX exporter, and those are addressing
report T63689.
NOTE: All the enabled-by-default addons are to be ported still, but
first want to have agreement on this part of changes.
NOTE: Also need to work on documentation for Python API, but, again,
better be done after having agreement on this work.
Reviewers: brecht, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D4834
This is a follow-up to rBb44e6f2b3d32, for some reason that issue was
not detected back then: in some cases, DEG_iterator_objects_next() will
free the temp list of dupli objects once it does not need it anymore,
henceforth freeing the dupli_object_current memory of the DEGObjectIterData
that we are storing in the RNA_Depsgraph_Instances_Iterator struct.
And yes, the uglyness of that hack is getting even better now...
Found while trying to export dupliobjects with FBX...
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.
While form a strict consistency point of view it could make sense to
return identity matrix for non-instance items, it can be very handy to
get that info (common to both instances and regular objects) directly in
all cases.
Object visibility is now handled by the depsgraph iterator, but this API
was incomplete as it made no distinction for visibility of the object itself,
particles and generated instances.
The depsgraph iterator API now includes information about which part of the
object is visible, and this is used by Cycles to replace the old custom logic.
Cycles and EEVEE visibility should now be consistent, which unfortunately does
means some subtle compatibility breakage for both.
Fixes T58956, T58202, T59284.
Differential Revision: https://developer.blender.org/D4109
It appears that Python gets next item before using current one, which
would break our Depsgraph instance iterator (since only current item is
valid there, we use the same memory at each iteration).
Working around that with an ugly ping-pong game between two sets of
iterator data, so that previous one (C RNA-iterator-wise) remains valid
memory for Python to access to.
It is crucial that scripts do not write, and even more importantly, do
not store any references to those. Otherwise, that’s a rather straight
path to crash.
Previous code would crash on whole lot of accessors in case current item
was not a real dupli instance.
And code was missing access to crucial dupli (world) matrix! Pretty
useless without that.
Also reordered a bit members in here, let's try to keep a bit of logic...
* depsgraph.ids: all evaluated datablocks in the depsgraph
* depsgraph.objects: all evaluated objects in the depsgraph
* depsgraph.object_instances: all object instances to display or render
* depsgraph.updates: list of updates to datablocks
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.
This allows a duplicator (as known as dupli parent) to be in a visible
collection so its duplicated objects are visible, however while being
invisible for the final render.
An object that is a particle emitter is also considered a duplicator.
Many thanks for the reviewers for the extense feedback.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2966
This statistics is only collected when debug_value is different from 0.
Stored in depsgraph node itself, so we can always have access to average data
and other stats which requires persistent storage. This way we also don't waste
time trying to find stats from a separately stored hash map.
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.
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.
Make it a tag for relations update function instead, since we will not be able
to easily rebuild relations, and we wouldn't be able to iterate all scenes.
This is a part of mowing depsgraph to be per-workspace/layer in 2.8 branch.
