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.
We should keep base_flags after CoW object datablock was updated. Not entirely
happy with current solution, but it fixes crash and allows us to run tests
again.
More proper solution would be to make CoW operation a per-component thingie,
which will only update corresponding parts.
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 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.
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
Was never actually used and implementation seems to be slow: we shouldn't be
doing per-node evaluation hash lookups, adds too much overhead. We can instead
store statistics in the node itself, and maybe even group them somehow.
Ideally such a statistics should be user-friendly so riggers and animators
can see exactly what's happening.
Was never actually used and implementation seems to be slow: we shouldn't be
doing per-node evaluation hash lookups, adds too much overhead. We can instead
store statistics in the node itself, and maybe even group them somehow.
Ideally such a statistics should be user-friendly so riggers and animators
can see exactly what's happening.
This way evaluation routines will know which exact depsgraph evaluation
is happening for.
Mainly needed to get evaluation flags associated with ID nodes.
This solves issue with user counter on materials, objects and such,
additionally avoids having too much overhead of temporary lock and
datablock allocation.
Still need to do similar thing for scene copy, and look into nested
ID datablocks somehow.
Before it was a compile time option which was not very easy to use or test. Now
the project is getting more mature, so very soon we will be able to call for a
public tests of limited features.
The copy-on-write (which includes animation, modifiers) is enabled using
--enable-copy-on-write command line argument.
Engine is not stored in WorkSpaces. That defines the "context" engine, which
is used for the entire UI.
The engine used for the poll of nodes (add node menu, new nodes when "Use Nodes")
is obtained from context.
Introduce a ViewRender struct for viewport settings that are defined for
workspaces and scene. This struct will be populated with the hand-picked
settings that can be defined per workspace as per the 2.8 design.
* use_scene_settings
* properties editor: workshop + organize context path
Use Scene Settings
==================
For viewport drawing, Workspaces have an option to use the Scene render
settings (F12) instead of the viewport settings.
This way users can quickly preview the final render settings, engine and
View Layer. This will affect all the editors in that workspace, and it will be
clearly indicated in the top-bar.
Properties Editor: Add Workspace and organize context path
==========================================================
We now have the properties of:
Scene, Scene > Layer, Scene > World, Workspace
[Scene | Workspace] > Render Layer > Object
[Scene | Workspace] > Render Layer > Object > Data
(...)
Reviewers: Campbell Barton, Julian Eisel
Differential Revision: https://developer.blender.org/D2842
The is following: split copy on write update for node trees, and if we are only
tagging for uniform buffer update we skip whole datablock copy and only invoke
copy default_values form original nodetree to a copied one.
Thing which i'm not sure is: whether we need to use different branches in graph
itself to control such a conditional behavior, or whether we need to store tag
somewhere in the dependency graph. There are obviously cons and pros in both
approaches, and need to think about this. Maybe with more examples it becomes
more obvious which way is better.
This only fixes manual tweaks for now, animation support is coming.
There were two issues here:
1. material_update did not do anything, because DEG_id_tag_update was storing
update tags in original IDs, which had nothing evaluated. Even more, material
update should have been called with evaluated version of material, Solved
this by copying update tag from original ID to a copied one.
However, perhaps DEG_id_tag_update should tag both original and copied ID,
so updates are never gets lots if some depsgraph is not visible.
2. Tagging material for update should ensure it's copied version of node tree is
up to date, otherwise material will still use old node tree.
This solves missing material updates when changing topology. Tweaking values is
still broken, because of GPUMaterial using pointer to original node's socket
value, which gets broken after copy-on-write of the node tree (pointers of nodes
are changing).
Originally we were not respecting the original visibility flags of the
collections. However this is required for Copy-on-write (CoW).
Remember to update the svn lib tests folder. I had to update some of the
json files there.
Also adding a new unittest for this particular issue:
Test render_layer_scene_copy_f
