利用者:Aligorith/250 AnimPropertiesPlans

Rationale

Blender's current system of data-access is flawed in many respects. Different sets of code have different ways of accessing data, and thus present it in different ways (there are separate systems for Animation System, UI, PyAPI). The goal of this 'mini' (but substantial) project, is to create some kind of generic system that can be used by all to access data in some reasonable form.

Analysis of Existing Systems

Starting with the simplest one first, the UI. The UI's data-access method is such that it only receives a pointer to the data that it deals with, knows some information about how to present itself to the user, and is given enough information about how to read-from/write-to this address. There isn't much overhead, but it is strictly limited to one setting per variable (direct-correspondence) which is a bit problematic for the 'resuable' aspect of animation data, and also poses problems for creating any kind of 'template-vars' based approach (where templates have some notion of how to generally access a given setting). There is support for all sorts of data here.

The next level of complexity we have is the Animation System. To 'simply' this matter, settings are divided into groups based on the block they operate on (leading to the nomenclature of 'blocktype' being used to describe their organisation). For each blocktype, there are a set of settings that can be animated. However, adding such a setting is a lot of work, given that code must be added in many different places. The code to access these variables is not strictly-bound to any specific variable, but rather works in a 2-stage process: 1) pointer to data is obtained by a function which takes an ID-block and a variable's code as input and returns a pointer to it, 2) data from pointer is read, with prior knowledge of the type of data it is. There is only support for a limited range of data. In particular, there is an alarming lack of any capability for proper bitflag support (raw ints are presented to the user), and any range validation is flaky at best (implemented quite badly). As such, this system is not OK for any dynamic purposes. Another major drawback of this system is that it will happily overwrite unkeyframed data. Although there are creative hacks in place for SOME things, they aren't there for everything (resulting in some vars not being animatable after inserting a keyframe somewhere).

The most complex of the three is the PyAPI. It basically has access to the whole database, by virtue of wrapping bits of the database to provide access. The benefit of this is, it is easy to access data (depending on how well designed that part of the API is). However, this depends on a setting having been wrapped in the API. Unfortunately, this is all too often not the case. Access is frequently missing/bad in some places. If all of Blender's core was based on such an API, speed+memory-usage would be a major drawback (due to CPython's limitations).

Overview of Basic Requirements

For Settings/Properties, the following things are required:

• Name - for identification + display in many places
• Min/Max Values - mostly applicable to floats, but for boolean-type settings, the max value can represent the 'on' state when using bitflags. Doesn't really apply for pointer-type things, which won't really get supported.
• Tooltip - for description of purpose/actions of setting
• Translation ID - or some means of making sure that name/tooltip can get translated easily. This may/may-not also function as a means by which properties get identified.
• 'Link' to Setting - 1) directly referring to 'sdna'/'source' variable (this means we have trouble reusing motion data though), 2) referencing 'sdna'/'source' variable by means of some hierachial data-access method such as ID->settings_group->[...sub_settings_group_n...]->setting_name (the downside of this is quite significant memory overhead, as this is done PER SETTING), 3) have this done at runtime by using some special functions which interpret various settings to do so.
• Animatable / Protection - there need to be settings to determine what the user can modify, what can get overridden, etc.

For any system for data-access:

• Ease of use - coders should not have to jump through hoops (i.e. make a series of complex steps to set up one property for example as for ID-Props)
• Access to "everything" in database. However some things should get prevented from being animated (such as pointer-type relations), as they're not readily represented in curve-form (maybe a 'hidden' keyframe format could be used there?).
• Flexibility - there should be allowance for 'dynamically' added settings that could be accessed
• Data for each built-in type should be defined in a 'single' place (at most two places, only if absolutely impossible to do any other way nicely).

Draft Solution

The following diagram (yes, it's a bit crappy in places), should explain the basic idea of this first draft. I've aimed to satisfy as many of the design constraints as possible.