This is unreliable for cases when multiple dependency graphs
are to be updated.
The only reason why it was attempted to be made is to deal
with cases when ID appears in the dependency graph for the
first time. But even then it should be smart enough bring
itself to an up-to-date state without any extra tricks.
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.
There were at least three copies of those:
- OB_RECALC* family of flags, which are rudiment of an old
dependency graph system.
- PSYS_RECALC* which were used by old dependency graph system
as a separate set since the graph itself did not handle
particle systems.
- DEG_TAG_* which was used to tag IDs.
Now there is a single set, which defines what can be tagged
and queried for an update. It also has some aggregate flags
to make queries simpler.
Lets once and for all solve the madness of those flags, stick
to a single set, which will not overlap with anything or require
any extra conversion.
Technically, shouldn't be measurable user difference, but some
of the agregate flags for few dependency graph components did
change.
Fixes T58632: Particle don't update rotation settings
Among all the lines moved around, the general idea is quite simple.
Actually, there are two ideas implemented there.
First one, is when object itself is tagged for update, we tag its
point cache component for evaluation, which makes it so point cache
is properly reset. We do it implicitly because otherwise we'll need
to go everywhere and add explicit tag in almost all the properties.
Second thing is, we link all collider and force fields to a point
cache component using special type of link. This type of link only
allows flush if change is caused by a user update. This way reset
does not happen when change is caused due to animation, but will
properly happen when user causes indirect change to the objects
which are part of physics simulation.
If something is a list of data, it is to be called list, and data
is to be called data. No need to call list a data and data a weird
two letter abbreviation.
Clarity is our friend!
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.
Unless there is an external action from an user, there should not
be need in re-copying original datablock to a copied one.
This brings performance up from 5fps to 11fps with Spring runcycle
(performance in master is 14fps).
- When returning the number of items in a collection use BLI_*_len()
- Keep _size() for size in bytes.
- Keep _count() for data structures that don't store length
(hint this isn't a simple getter).
See P611 to apply instead of manually resolving conflicts.
General idea of the fix: skip the whole draw manager callback madness which
was used to tag object's engine specific data as dirty. Use generic recalc
flag in ObjectEngineData structure instead. This gives us the following
benefits;
- Sovles mentioned bug report.
- Avoids whole interface lookup for opened viewports for EVERY changed ID.
- Fixes missing updates when viewport is temporarily invisible.
Reviewers: dfelinto, fclem
Differential Revision: https://developer.blender.org/D3028
Helps in cases of not very complex scenes and lots of system threads available.
A bit hard to measure change on it's own, it works best with the upcoming
changes and gives measurable improvements.
Now all the fine-tuning is happening using parallel range settings structure,
which avoid passing long lists of arguments, allows extend fine-tuning further,
avoid having lots of various functions which basically does the same thing.
The goal is: have id->recalc flags set to components which got changed.
To make it possible for render engines to check on a more granular basis
what changed in the object. For example, is it a transform which changed
or is it just some ID property changed which has nothing to do with rendering.
The tricky part is: we don't want duplicated logic in tagging and flushing.
In order to avoid this duplication, we store ID recalc flag in the component
node type information. That type information could easily be accessed by both
tagging and flushing routines.
Remaining part of the changes are related on changing the way how tagging
works. The new idea here is to have utility function which maps update tag to
a component. This way we can easily set ID recalc flags right away. Without
any duplication of ID recalc flags set in multiple flag handler functions.
With all this being said, there should be no user measurable difference for
now, it's a gigantic basement for some upcoming work and fixes.
Not only this helps merges form master to the branch, but also:
- Allows us to production-check changes as soon as possible.
- Avoids some unnecessary editors update about ID changes.
- Adds small optimization on queue size by always keeping one of the pointers
outside of the queue.
Currently this is a no-visible-changes change, but the idea is to use this
dedicated flag to tell which exact components of ID changed, make it more
granular than just OBJECT and OBJECT_DATA. Allow setting this field based
on what components new dependency graph flushed on evaluation.
The possible issue with just listing arguments is that it might not be clear
what particular value is used for. For example, is it a scene itself, or is
it a parent scene?
Not as if it's not very clear now, but better be explicit for the future,
and me reading code in 10 years.
This way we can inform editors about all edits at once. Currently this is not
used, but in the next commits we will inform editors about what exactly has
changed.
