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
The only remaining part is the particle stuff, which needs a pointer to exact
particle system which does not exist yet. Leaving it for later a bit for until
it's more clear what do we do with particles.
Unless i'm mistaken, we've got all proper CoW pointers bound now.
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.
The idea is to allow iterating over ID nodes in exact order of their
construction, and in order which will not change dependent on memory
pointers or anything.
Depsgraph itself is still created fer the whole scene rather than for a
single layer, this is to be addressed next.
The storage for those dependency graphs is in scene, but now it is a hash
indexed by layer. In the future we can extend hash key to include extra
information (workspace? window?).
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.
