FBX IO: Add attributes utility functions #104645
No reviewers
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#104645
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Mysteryem/blender-addons:attribute_access_base_pr"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
These are used by subsequent patches to update mesh data access to use
attributes.
The ability to specify the foreach_get/set Python attribute in attribute
utility functions is not currently used, but is to facilitate color
attributes which might want to by accessed with "color_srgb" instead of
the default of "color".
Besides note below, this (and following dependent patches) LGTM.
@ -543,0 +558,4 @@
}
def attribute_get(attributes, name, data_type, domain):
I wonder if it would not be simpler if
attributes
was a dict withname, type, domain
as keys?For only the purpose of getting existing attributes I think it would work well, but sometimes the attributes need to be created if they don't exist at which point the
attributes
(AttributeGroup
) is needed. I think that to support both getting and creating like this would either mean passing bothattributes
and a newattributes_dict
to most of the attributes helper functions or creating a dict fromattributes
each timeattribute_get
is called. I'm not a fan of either option, but I can make changes if you want.There has been some recent discussion between Hans/HooglyBoogly and ideasman42 in #blender-coders on blender.chat about a similar function that would be useful for script authors such as
or
so I'm hopeful that this area of the Python API will see some improvements at some point and then the new function(s) can replace some of the helper functions added by this patch.
We could push for more discussion/development on this API feature. The main requirements from my perspective that might be missing from what has been discussed is having an equivalent 'get' function when there's no need to create the attribute if it doesn't exist, and ensuring that whatever functions we do get in the Python API have well-defined behaviour when there are name collisions in the attributes.
There are already some helper functions in
bpy_types
that theMesh.edge_creases
andMesh.vertex_creases
properties use for getting/ensuring/removing attributes, though they are currently private:Yeah I would have expected a thin class wrapper (maybe even a simple named tuple) around
attributes
, storing both the blender data itself and the mapping...But indeed if better helpers are scheduled in Blender API itself to handle these tasks, then current code is fine by me for now.
595a48c421
toe2b4639d26