3905cdd89a73378c91a84a2fa804d76728ff2e73
The case when no mesh can be retrieved from the shrinkwrap target object can be
retrieved was not handled. It was handled by `ensure_shrinkwrap_cache_data` but
the calling function didn't check if the cache was actually created.
`BKE_modifier_get_evaluated_mesh_from_evaluated_object` can return null for an
object that would usually have a mesh but the object has not been evaluated yet,
as can be the case when there is a depsgraph cycle.
From my current understanding, the issue existed without 83325d1fd. Changing the
hash just made the depsgraph do different scheduling decisions so that now the
shrinkwrap was evaluated before the target object. The order in which these two
things are evaluated is arbitrary when there is a depsgraph cycle.
Pull Request: https://projects.blender.org/blender/blender/pulls/143757
…
Blender
Blender is the free and open source 3D creation suite. It supports the entirety of the 3D pipeline—modeling, rigging, animation, simulation, rendering, compositing, motion tracking and video editing.
Project Pages
Development
License
Blender as a whole is licensed under the GNU General Public License, Version 3. Individual files may have a different but compatible license.
See blender.org/about/license for details.
Description
Languages
C++
78%
Python
14.9%
C
2.9%
GLSL
1.9%
CMake
1.2%
Other
0.9%
