This is essentially a huge refactor/extension of our existing RNA
compare & copy code, since static override needs more advanced handling here.
Note that not all new features are implemented yet, advanced things like
collections insertion/deletion are still TODO (medium priority).
This completes the ground work for overrides, remaining commits will be
about UI and some basic/testing activation of overrides for a limited
set of data-blocks & properties.
For details see https://developer.blender.org/D2417
See https://developer.blender.org/D2417 for details.
Note that since static overrides rely heavily on RNA, this commit is
essentially invisible from user PoV, more in next commits.
This function swaps the memory content of two data-blocks (of same type
obviously), while preserving most of the ID 'header' itself.
It is intended to be used to quickly and easily replace the data of an
existing ID by another one, presumably a temporary 'working' one,
without having to suffer from things like name changes,
registering/removing from Main database, etc.
Do a direct update of object transform instead, without involving
manual trickery of recalc flag.
Shouldn't be functional changes as far as artists are concerned,
but will allow us to get rid of recalc flags in 2.8.
Thanks Bastien for review!
There were following issues:
- This was used in a similar way of DEG's ID update callback. No reason to have
yet-another-way of informing editors/engines about changes. Better to keep
regular update mechanism usable and fast for those needs.
- It wasn't granular at all, and granularity in flags is something what we
need to support anyway, even for existing ID update.
- There is no reason to have it per-object. Depsgraph operates on IDs.
- It wasn't clear when and who clears the flag, and was possible to run into
conflicts.
This commit effectively reverts fix T45702 done in 067fe2719a.
Reasoning:
- Blender Internal is being replaced with Eevee, and will be removed entirely
rather soon.
- All render engines are planned to have own depsgraph, so such threading
conflicts should no longer be an issue.
- We don't want to spend time on porting workarounds for EOL things to a new
design. Less code -- faster the work :)
- If such notifications will end up needed for some other cases, we would
need to re-implement this a more proper depsgraph tagging/flushing and make
it to work with all copy-on-write datablocks and everything.
User count was wrong for newly created files. We increase/decrease user count
when we link/delete objects from a SceneCollection.
So we don't want to leave user count of 1 after calling BKE_libblock_alloc in
BKE_object_add_only_object().
This is fully unreadable to have lots of boolean arguments scattered across the
whole argument list. What does `false, true, true` mean in terms of behavior?
Replace those with bitfield which has advantage of having more human readable
meaning.
Pretty straightforward this time, we already have a single struct
pointer containing all needed data (or nearly).
And we gain about 10-15% speed on tracking! :)
While this probably isn't the final solution we'll go with, it's nicer
as current one, which was basically broken. So consider this as
temporary solution.
It also allows testing how changing workspace changes mode & active
object, but only by having the workspaces use different view-layers.
Decided to remove WorkSpace.mode for now. If we need to bring it back,
we'll have to version patch it anyway.
Previously it was done during depsgraph iteration, which is not good at all,
since after evaluation nobody should really modify how object was evaluated.
This is crucial bit since batch cache is stored in the evaluated object,
meaning we can't tag it's hatch cache dirty from the notifier system.
Not easily at least. Better to leave this job to depsgraph, it knows
all the copies of data.
