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
No functional changes, but it makes all the coordinates more consistent
(going from small to larger values). It helps debugging in the future
to be able to rule out vertex order as a culprit.
The top-left and bottom-right corners were creating the new area in the
wrong place.
Blender 2.7x only had action zone corners in the top-right, and
bottom-left corners. So it had some hardcoded assumptions based on that.
This commit feels a bit like a hack, but I think it may be fine.
Bug reported via IRC, how to reproduce:
* Change shading to Rendered.
* Split viewport from the top-left corner.
