While this should not be allowed in general, there are some cases
(library overrides at least) where supporting this is mandatory.
Further more, comment stating that this could crash is from 2011, could
not reproduce any issue with current code. Commit comment was referring
to undo/redo, but in use cases here those should not affect things.
Note that in general, such relatively high-level checks should be
handled by high-level, close to user code (like in ED area e.g.), not in
low-level BKE code anyway.
When changing to another texture paint slot, the texture displayed in
the viewport should change accordingly (as well as the image displayed
in the Image Editor).
The procedure to find the texture to display in the viewport
(BKE_texpaint_slot_material_find_node) could fail
though because it assumed iterating nodes would always happen in the
same order (it was index based). This is not the case though, nodes can
get sorted differently based on selection (see ED_node_sort).
Now check the actual image being referenced in the paint slot for
comparison.
ref T88788 (probably enough to call this a fix, the other issue(s)
mentioned in the report are more likely a feature request)
Reviewed By: mano-wii
Maniphest Tasks: T88788
Differential Revision: https://developer.blender.org/D11496
This fixes T88455 by adding an empty material slot to newly
generated meshes. This allows the object to overwrite the
"default" material without any extra nodes. Technically,
all polygons reference the material index 0 already, so it
makes sense to add a material slot for this material index.
Differential Revision: https://developer.blender.org/D11439
This fixes the `Apply Modifier` and `Visual Geometry to Mesh` operator
when a modifier changed materials on the evaluated geometry.
This is necessary since rB1a81d268a19f2f1402f408ad1dadf92c7a399607.
Differential Revision: https://developer.blender.org/D11303
This commit allows that the evaluated geometry of an object has
different materials from the original geometry. This is needed
for geometry nodes.
The main thing that changes for render engines and exporters
is that the number of material slots on an object and its geometry
might not match anymore. For original data, the slot counts are
still equal, but not for evaluated data.
Accessing material slots though rna stays the same. The behavior
adapts automatically depending on whether the object is evaluated.
When accessing materials of an object through `BKE_object_material_*`
one has to use a new api for evaluated objects:
`BKE_object_material_get_eval` and `BKE_object_material_count_eval`.
In the future, the different behavior might be hidden behind a more
general C api, but that would require quite a few more changes.
The ground truth for the number of materials is the number of materials
on the geometry now. This is important in the current design, because
Eevee needs to know the number of materials just based on the mesh in
`mesh_render_mat_len_get` and similar places.
In a few places I had to add a special case for mesh edit mode to get it
to work properly. This is unfortunate, but I don't see a way around that
for now.
Differential Revision: https://developer.blender.org/D11236
This concerns currently only collections (`master_collection` of scenes)
and root node trees. It removes the matching type-specific helpers
(`BKE_collection_master_scene_search` and `BKE_node_tree_find_owner_ID`).
No functional change expected here.
NOTE: Current implementation of `owner_get` is far from optimal, we
could probably do it better, see {T69169}.
NOTE: While it could also have it, shapekeys IDTypeInfo was left out of
this change for now. Mainly because it sould not be used currently, and
we ultimately want to demote shape keys from ID status anyway.
Currently this is needed to properly tag PointCache's for info update
(fixes an issue reported in T82503).
Suspect we may need this in more cases in the future though, RNA
assign/update processes are not always 100% enough to deal with
complicated corner cases.
This is essentially adding that new callback, and using it only for already
existing Scene's 3DCursor.
Note that the place where this is called has been moved again, after all
have been lib-linked, such that those callbacks may also work on ID pointers.
Maniphest Tasks: T71759
Differential Revision: https://developer.blender.org/D9237
Better use higher-level code from common ID management when possible.
Helps to de-duplicate logic, and reduces outside usages of more
'dangerous' functions.
Note that we could get rid of many of those `BKE_<id_type>_add`
functions now, but on the other hand several of those take extra
parameters and perform additional actions, so think we can keep them all
for now as 'non-standard ID specific creation functions'.
Those were only shallow wrappers around `BKE_id_copy`, barely used (even
fully unused in some cases), and we want to get rid of those ID-specific
helpers for the common ID management tasks. Also prevents weird custom
behaviors (like `BKE_object_copy`, who was the only basic ID copy
function to reset user count of the new copy to zero).
Part of 71219.
Besides the NodeTree case (which remains unchanged), the localize code
is only used in one place (to generate previews of shading data-blocks).
This commit introduces a new `LIB_ID_CREATE_LOCAL` option for ID
creation/copying, which essentially implements the behavior of the
removed `BKE_XXX_localize()` functions into regular mainstream ID copy
code. When this option is set:
- new ID is tagged with `LIB_TAG_LOCALIZED`;
- Some ID copying callbacks have specific behaviors, mainly the root
nodetree of shading IDs gets duplicated with specialized
`ntreeLocalize()` function.
Note that I would not consider getting rid of `ntreeLocalize` for now,
this function is recursive, which should ideally never happen within ID
management copying code (this introduces all kind of complications).
No behavioral change expected from this commit.
Just converts verts to points and vice versa.
Materials and Attribute layers are preserved (so for example if you set
custom radii on the pointcloud, convert to mesh, then convert back to
pointcloud, this will be preserved).
Also not add a Radius layer by default (it is still added and
filled when adding a pointcloud object from the menu), a global Radius
property that will be used if there is no radius attribute can be added
later. A Radius attribute can also be added in the pointcloud data
properties (and filled via python).
This will also add a new utility function that copies materials between
datablocks: BKE_id_materials_copy
ref T75717
Differential Revision: https://developer.blender.org/D7391
This is part of T76372.
It adds the `blend_write`, `blend_read_data`, `blend_read_lib`
and `blend_read_expand` which correspond to the various
steps when reading and writing .blend files.
Having these callbacks allows us to decentralize the blenloader
code a lot more. This has the affect that code related to any
specific ID type is less scattered.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D8670
Build a temp matarray storing materials from obdata and source object
(depending on slots 'allocation' of source object), and assign those to
targets.
Also remove limitation of 'using same obdata is forbidden', just never
edit obdata materials in that case...
Certainly not perfect, but already much better than existing code.
This fix the issue by introducing a default material only for collection
holdouts. This avoids hash colision when the same material is used in
collections without holdout enabled.
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
This has been long standing TODO...
Note that remaining usages of BKE_xxx_delete should all be carefully
checked for and utilmately nuked in favor of `BKE_id_delete()`, think we
still have quiet a few bugs hidden in those (code seems to usually
assume those functions do a full ID deletion, which is not the case).
This commit is a full refactor of the grease pencil modules including Draw Engine, Modifiers, VFX, depsgraph update, improvements in operators and conversion of Sculpt and Weight paint tools to real brushes.
Also, a huge code cleanup has been done at all levels.
Thanks to @fclem for his work and yo @pepeland and @mendio for the testing and help in the development.
Differential Revision: https://developer.blender.org/D6293
- Use 'BKE_object_material_*', 'BKE_id_material_*' prefix
for functions that operate on Object and ID types.
- Use '_len' suffix for length (matching BLI naming).
- Use '_p' suffix for functions that return a pointer to values
where the value would typically be returned.
Functions renamed:
- BKE_object_material_resize was BKE_material_resize_object
- BKE_object_material_remap was BKE_material_remap_object
- BKE_object_material_remap_calc was BKE_material_remap_object_calc
- BKE_object_material_array_p was BKE_object_material_array
- BKE_object_material_len_p was BKE_object_material_num
- BKE_id_material_array_p was BKE_id_material_array
- BKE_id_material_len_p was BKE_id_material_num
- BKE_id_material_resize was BKE_material_resize_id
- BKE_id_material_append was BKE_material_append_id
- BKE_id_material_pop was BKE_material_pop_id
- BKE_id_material_clear was BKE_material_clear_id
Instead of using anonymous booleans flags, also allows to keep the same
behavior in all cases, without needing special handling from calling
code for our beloved oddballs object proxies...
Private ID data (nodetrees and scene collections...) need special care
and handling of their copy flags, and checks must be adapted too.
In that case, issue came from the fact that even though those IDs have
to be copied outside of bmain, we may still require usercount handling.
That commit also fixes a somewhat related issue - we cannot use the
non-id private data copying flag for private IDs copying, due to
difference in handling of usercount again.
