LaplacianDeform binding handling is a catastrophee in CoW context,
because half of the binding (the laplacian solver cache thingy) is not
saved, and can be re-generated on the fly from stored vcos.
This means that binding is not only done when hitting 'bind' button, but
also at file load, and when some things change.
And this utterly breaks with CoW design, not sure how to fix, will add a
task about that.
But this also means that NULL laplacian solver cache pointer is not a
good check to know whether it is binded or not, only stored vcos are
relevant for that (and the binding flag, of course).
This fixes/clarifies Surface Deform evaluation code that does the
binding, since that part should only be called outside of depsgraph
evaluation, with orig data-blocks and not CoW ones.
Now we have a decent amount of asserts and checks to ensure eveything
works as expected.
Also had to add a special case to get target's mesh in binding case,
since often target's evaluated mesh is not available, in that case (and
in that case only), we can actually compute that mesh (because we are
out of depsgraph evaluation).
Binding and unbinding *has* to happen outside of 'normal' depsgraph
evaluation of modifiers now that we have CoW, otherwise persistent data
stored in modifier data are always lost!
Note that this is only first step of the fix, modifiers code needs also
some work. Surfacedeform one is in next commit, Laplacian case is much,
much more complicated to handle, given how it uses its cached data. :(
This would overlap with buttons in the header. It's smaller to hit, but
still wider than the outlines for resizing, so hopefully it's fine.
Differential Revision: https://developer.blender.org/D4033
Was initially reported when painting on a mesh with armature,
which was failing due to missing bbone cache. The issue was
deeper, and was related on the way which object was used to
calculate crazyspace.
The layout changed when the radius property was added to shape
keys in 2.8, but the RNA code wasn't updated.
Also, even before that, the code didn't do anything to correctly
handle mixing sub-curves of different type (nurbs vs bezier) in
the same Curve object. Now that case is handled correctly but not
very efficiently by allocating a mapping table when necessary. To
recover some performance, a custom index lookup function is added.
When enable annotations with a grease pencil object, the GP Object must be set to Object mode because the annotation Draw and the GP draw are incompatible.
This is something what is caused by OCIO library. The patch
has been submitted there:
https://github.com/imageworks/OpenColorIO/pull/638
For until it is refined and checked we do workaround from
our side.
Solves weird situation when default display name is queried
from OCIO, but Default view being assumed to be set for it.
Now view is initialized to a default view of that display.
That one was flagged as useless since 2.77, and only kept 'to be sure'
everything was OK. This was years ago now, and never got any report on
this, so 2.8 sounds like a good time to nuke it.
Nice side-effect of using new __annotations__ thingy to store
dynamically-generated fields in a class: __annotations__ dict is not
ensured to exist for a given class, so we may end up modifying on of the
parents' one!
Passing depsgraph instead of scene, since a scene does not fully define the
state of object you want to use for the BVH.
Also, mesh_create_eval_final_view and mesh_create_eval_final_render are pretty
much the same, so mesh_create_eval_no_deform and
mesh_create_eval_no_deform_render are as well.
Issue reported on: T58734
Reviewers: sergey
https://developer.blender.org/D4032
