Files
test2/source/blender/editors/interface/templates/interface_template_modifiers.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

81 lines
2.4 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2024 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
/** \file
* \ingroup edinterface
*
* Template for building the panel layout for the active object's modifiers.
*/
#include "BKE_context.hh"
#include "BKE_modifier.hh"
#include "BKE_screen.hh"
#include "BLI_listbase.h"
#include "ED_object.hh"
#include "RNA_access.hh"
#include "RNA_prototypes.hh"
#include "UI_interface.hh"
static void modifier_panel_id(void *md_link, char *r_name)
{
ModifierData *md = (ModifierData *)md_link;
BKE_modifier_type_panel_id(ModifierType(md->type), r_name);
}
void uiTemplateModifiers(uiLayout * /*layout*/, bContext *C)
{
ARegion *region = CTX_wm_region(C);
Object *ob = blender::ed::object::context_active_object(C);
ListBase *modifiers = &ob->modifiers;
const bool panels_match = UI_panel_list_matches_data(region, modifiers, modifier_panel_id);
if (!panels_match) {
UI_panels_free_instanced(C, region);
LISTBASE_FOREACH (ModifierData *, md, modifiers) {
const ModifierTypeInfo *mti = BKE_modifier_get_info(ModifierType(md->type));
if (mti->panel_register == nullptr) {
continue;
}
char panel_idname[MAX_NAME];
modifier_panel_id(md, panel_idname);
/* Create custom data RNA pointer. */
PointerRNA *md_ptr = MEM_new<PointerRNA>(__func__);
Core: Add info about chain of ancestors (owner data) of a PointerRNA. The general idea is to store an array of (type, data) pointers of all PointerRNA ancestors of the current one. This will help solving cases in our code where the owner (or sometimes even the owner of the owner) of a random PointerRNA needs to be accessed. Current solution mainly relies on linear search from the owner ID, which is sub-optimal at best, and may not even be possible in case a same data is shared between different owners. This lead to refactoring quite a bit of existing PointerRNA creation code. At a high level (i.e. expected usages outside of RNA internals): * Add `RNA_pointer_create_with_parent` and `RNA_pointer_create_id_subdata` to create RNA pointers with ancestors info. * `RNA_id_pointer_create` and `RNA_main_pointer_create` remain unchanged, as they should never have ancestors currently. * Add `RNA_pointer_create_from_ancestor` to re-create a RNA pointer from the nth ancestor of another PointerRNA. * Add basic python API to access this new ancestors data. * Update internal RNA/bpy code to handle ancestors generation in most common generic cases. - The most verbose change here is for collection code, as the owner of the collection property is now passed around, to allow collection items to get a valid ancestors chain. Internally: * `PointerRNA` now has an array of `AncestorPointerRNA` data to store the ancestors. * `PointerRNA` now has constructors that take care of setting its data for most usual cases, including handling of the ancestor array data. * Pointer type refining has been fully factorized into a small utils, `rna_pointer_refine`, that is now used from all code doing that operation. * `rna_pointer_inherit_refine` has been replaced by `rna_pointer_create_with_ancestors` as the core function taking care of creating pointers with valid ancestors info. - Its usage outside of `rna_access` has been essentially reduced to custom collection lookup callbacks. Implements #122431. -------------- Some notes: * The goal of this commit is _not_ to fully cover all cases creating PointerRNA that should also store the ancestors' chain info. It only tackles the most generic code paths (in bpyrna and RNA itself mainly). The remaining 'missing cases' can be tackle later, as needs be. * Performances seem to be only marginally affected currently. * Currently `AncestorPointerRNA` only stores PointerRNA-like data. This will help `StructPathFunc` callbacks to more efficiently generate an RNA paths when calling e.g. `RNA_path_from_ID_to_property`, but will not be enough info to build these paths without these callbacks. And some cases may still remain fuzzy. We'd have to add thinks like a `PropertyRNA` pointer, and for RNA collection ones, an index and string identifier, to store a complete unambiguous 'RNA path' info. This is probably not needed, nor worth the extra processing and memory footprint, for now. Pull Request: https://projects.blender.org/blender/blender/pulls/122427
2025-02-05 15:45:04 +01:00
*md_ptr = RNA_pointer_create_id_subdata(ob->id, &RNA_Modifier, md);
UI_panel_add_instanced(C, region, &region->panels, panel_idname, md_ptr);
}
}
else {
/* Assuming there's only one group of instanced panels, update the custom data pointers. */
Panel *panel = static_cast<Panel *>(region->panels.first);
LISTBASE_FOREACH (ModifierData *, md, modifiers) {
const ModifierTypeInfo *mti = BKE_modifier_get_info(ModifierType(md->type));
if (mti->panel_register == nullptr) {
continue;
}
/* Move to the next instanced panel corresponding to the next modifier. */
while ((panel->type == nullptr) || !(panel->type->flag & PANEL_TYPE_INSTANCED)) {
panel = panel->next;
BLI_assert(panel !=
nullptr); /* There shouldn't be fewer panels than modifiers with UIs. */
}
PointerRNA *md_ptr = MEM_new<PointerRNA>(__func__);
Core: Add info about chain of ancestors (owner data) of a PointerRNA. The general idea is to store an array of (type, data) pointers of all PointerRNA ancestors of the current one. This will help solving cases in our code where the owner (or sometimes even the owner of the owner) of a random PointerRNA needs to be accessed. Current solution mainly relies on linear search from the owner ID, which is sub-optimal at best, and may not even be possible in case a same data is shared between different owners. This lead to refactoring quite a bit of existing PointerRNA creation code. At a high level (i.e. expected usages outside of RNA internals): * Add `RNA_pointer_create_with_parent` and `RNA_pointer_create_id_subdata` to create RNA pointers with ancestors info. * `RNA_id_pointer_create` and `RNA_main_pointer_create` remain unchanged, as they should never have ancestors currently. * Add `RNA_pointer_create_from_ancestor` to re-create a RNA pointer from the nth ancestor of another PointerRNA. * Add basic python API to access this new ancestors data. * Update internal RNA/bpy code to handle ancestors generation in most common generic cases. - The most verbose change here is for collection code, as the owner of the collection property is now passed around, to allow collection items to get a valid ancestors chain. Internally: * `PointerRNA` now has an array of `AncestorPointerRNA` data to store the ancestors. * `PointerRNA` now has constructors that take care of setting its data for most usual cases, including handling of the ancestor array data. * Pointer type refining has been fully factorized into a small utils, `rna_pointer_refine`, that is now used from all code doing that operation. * `rna_pointer_inherit_refine` has been replaced by `rna_pointer_create_with_ancestors` as the core function taking care of creating pointers with valid ancestors info. - Its usage outside of `rna_access` has been essentially reduced to custom collection lookup callbacks. Implements #122431. -------------- Some notes: * The goal of this commit is _not_ to fully cover all cases creating PointerRNA that should also store the ancestors' chain info. It only tackles the most generic code paths (in bpyrna and RNA itself mainly). The remaining 'missing cases' can be tackle later, as needs be. * Performances seem to be only marginally affected currently. * Currently `AncestorPointerRNA` only stores PointerRNA-like data. This will help `StructPathFunc` callbacks to more efficiently generate an RNA paths when calling e.g. `RNA_path_from_ID_to_property`, but will not be enough info to build these paths without these callbacks. And some cases may still remain fuzzy. We'd have to add thinks like a `PropertyRNA` pointer, and for RNA collection ones, an index and string identifier, to store a complete unambiguous 'RNA path' info. This is probably not needed, nor worth the extra processing and memory footprint, for now. Pull Request: https://projects.blender.org/blender/blender/pulls/122427
2025-02-05 15:45:04 +01:00
*md_ptr = RNA_pointer_create_id_subdata(ob->id, &RNA_Modifier, md);
UI_panel_custom_data_set(panel, md_ptr);
panel = panel->next;
}
}
}