We were storing the 'item' part in the RNA path of the override op
itself, which will not work with IDs because overriding local one might
not have the same name as the linked one (when some local ID with same
name already exists).
Now we are properly handling this using the expected actual override
operation, which stores necessary data (names or indices) from both
local and linked data.
This checkbox replaces the "Disabled" and "Enabled" entries in the
filter drop-down. As a result, it now takes a single click to limit the
shown entries to enabled add-ons only. This is also an actual flag in
the preferences, and thus its state is saved between runs on Blender (in
contrast to the filter, which is always reset to "All").
Reviewed by: brecht, billreynish
This fixes the glitching hairs described in T56408, T63534, and possibly
also T63534.
The fix consists of returning the original mesh (i.e. as visible in edit
mode) when constructing the ORCO mesh. This allows a static set of
coordinates to be used when computing the child hair positions.
The original mesh is only returned when it has the same topology (at
least same number of vertices, loops, and polys. It's up the author of
the Alembic file to ensure stable geometry when it's desired to be
compatible with Blender's hair system.
Reviewers: mont29, brecht
Differential Revision: https://developer.blender.org/D5492
The `BKE_material_pop_id()` and `BKE_material_clear_id()` functions had
a parameter `update_data` that, when `false`, would cause the mesh polys
to keep their material index, even when the indexed material slots were
removed. This behaviour was never used in the C code and not supported
by the drawing code, making polygons disappear and causing crashes. The
Python binding in RNA, however, defaulted to `update_data=False`.
This commit removes the `update_data` parameter altogether, and makes
the functions always fix up the material indices.
Reviewed by: mont29, brecht
This was a mistake in rB87629b2a7443
`BKE_object_shapekey_free` would never return `true`, so DEG updates
would not happen...
So `ob->shapenr` was not up-to-date etc., leading to crash in
`BKE_mesh_nomain_to_mesh` shapekey handling...
Reviewers: brecht
Maniphest Tasks: T68710
Differential Revision: https://developer.blender.org/D5501
This is 2.7x behavior, while there are plans to improve on this,
committing in case larger changes take longer.
Without this it's not easy to select object data without changing modes.
See D5493
But in the future the selection code may also be used in object mode (eg for snapping).
So to avoid using too much VRAM resources, it is good to avoid drawing all objects in the viewport.
The solution was to create an array with only objects that are detected within the selection area.
If the selection operator is modal, objects already detected are not removed from the array until view3d is moved or orbited.
To detect the object, its BoundBox is tested.
Since the Select Engine does not have a dedicated depth texture, whenever a new object is "found" the depth of the objects in the array already drawn is redrawn.
Reviewers: campbellbarton, fclem
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D5435
- When no change is performed on a float button, cancel the action.
- Move left/right clicks into the same block.
- Replace ambiguous names: temp, tempf.
In rB9c010c44f420, DRW_mesh_batch_cache_create_requested was changed to
take a scene (instead of toolsettings directly), but
DRW_draw_depth_object is calling this with with NULL, just checking for
this seems to fix...
Reviewers: fclem
Maniphest Tasks: T68675
Differential Revision: https://developer.blender.org/D5488
Just enable some commented-out code from rB636289b755f6ce (disabled at
that time because we were too close of 2.79 release...).
Issue raised in D5486, thanks.
This is done because they don't have the same update frequency. UV can be
persistent even on geometry update (ex: skinned object) but tangents
can change if the normals change.
Also the name buffer per vbo was too small to contain all names.
These functions make possible porting the tools from the sculpt branch, making them compatible with PBVH_FACES and PBVH_BMESH without duplicating the code. They can also help to simplify some existing code.
These functions should not be used when working with PBVH_GRIDS data in SculptSession. PBVH_GRIDS needs to be removed from the sculpt code and converted to PBVH_FACES to be compatible with this API.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5352
