The remapping code was creating plkaceholders for objects coming from legacy
bases, but since those objects were never created by dependency graph (since
they are supposed to be ignored) the copy on write relations creation was
confused.
Now we do some special trickery to clear legacy bases on copy on write.
Currently RNA doesn't give us a good way of accessing singleton layers,
for now expose as a layer list (skin & paint-pask do this too).
Noted in T47811 that this should be changed.
Those checks are not always helpful, since id remapping doesn't want to
worry about which components to tag for update. Perhaps in the future we
will introduce special flag which would mean "tag everything possible"/
We get already enough reports of people complaining about crashes on
edit mode unaware that they are in the non-supported Blender Render
engine.
Blender Render is going away, no reason to keep it around. Once we have
a nice fallback on Eevee and fast file loading we can default to Eevee
instead.
This is the fake ID nature of compositor again. Need to discard such
pointers before freeing datablock even for scenes (before it was done
for objects only).
Previously it was possible to run into situation when armature is constructed prior to
objects which are used for it's constraints. This was causing wrong scene evaluation.
Now we create placeholders for objects used by armature in case they don't have ID node
yet, which ensures we have proper mapping from original to copy-on-write ID pointer.
This shows the bug when IK solver doesn't update reliably when targeted an external
object and when that object is handled by build_object() after the armature.
The issue was caused by id_copy_no_main() changing pointers of constraints used
in pose to a newly allocated ID. This is correct, but caused confusion too our
copy on write remapping, because we are mimicing inplace duplication by copying
memory over from a temporarily duplicated ID to a proper placeholder. This was
causing dangling pointers in pose to a temporarily allocated ID.
Now we add special code to remapping callback which replaces temporary ID with
a proper one.
Couple of main things here:
- Properly handle PSYS_UPDATE_* flags from DEG_id_tag_update.
There are still some possible issues here related on the fact
that we don't differentiate different PSYS_UPDATE_* flags here
and handle the mall the same.
Other possibility here is that object level particle settings
evaluation might be forced when particle system evaluation is
tagged for update. Didn't see actual issue here yet, but need
a closer look.
- Don't tag non-object datablocks on visibility changes.
Those don't depend on visibility anyway. This prevents particle
settings IDs from flushing updates to all objects, causing all
cached particles to be lsot.
- Only update translation and geometry components on visibility
changes.
Once again, this prevents particle cache from being invalidated.
We might need to tag material components here still tho.
This commit makes it so that only ID components which correspond to the tag
flag are tagged for update (previously the whole ID would have been updated
in the most of cases).
This allows us to have more granular tag flags and prevent tagging of things
we don't want to be tagged.
Previously tagging particle settings for update will iterate over all objects and
all their particle system to see whether something needs an update or not. Now we
put ParticleSettings as an ID to the dependency graph, so tagging it for update
will nicely flush updates to all dependent particle systems.
Current downside of this is that due to limitation of flush routines it will cause
some extra particle system re-evaluation when it technically not needed, and what's
more annoying currently it will discard point caches more often.
However, this is a good and simple demonstration case to improve tagging/flushing
system to accommodate for such cases (similar issues happens with CoW and shading
components). So let's try to find some generic solution to the problem!
This replaces usage of generic PLACEHOLDEWR with string lookup with more
explicit opcode. This should make it faster to build dependency graph by
avoiding string comparisons when it's not needed.
There should be no user measurable different.
Hopefully fix it actually, at least could not reproduce it anymore with
that changen, but Was already quite hard to trigger before.
We need a memory barrier at this allocation, otherwise it might happen
after preview gets added to done queue, so preview could end up being
freed twice, leading to crash.
