[Bf-taskforce25] data api proposal

[Brecht Van Lommel]

Hey Joshua, Martin,

Joshua Leung wrote:
> 1) There should be some in-built mechanism to prevent IPO's flushing 
> over newly changed data when a refresh is done (i.e. after transform, 
> but before keyframe is added).
> Currently, we rely on using setting flags at the object/bone level 
> and/or the depsgraph to prevent this flushing from occurring, however 
> this situation is not optimal as it's rather too coarse. A noticeable 
> example of where this doesn't work, is in the buttons window after 
> inserting keyframes, it sometimes becomes impossible to change some of 
> the sliders. I would like to see this done per property if possible

Indeed, so there should be some way to flag each property as not 
permitted to be flushed, to be checked by the IPO evaluation. I don't 
have a good picture on where to store this yet. I think you don't want 
to share this flag between actions, so it can't be stored alongside 
the list of IPO pointers, but somewhere else in the struct itself. But 
you still want it to be efficiently checked during IPO evaluation.

> 2) You mention " IPO's of properties in a struct would be stored in list 
> of property identifier + IPO curve / driver pointer".
> - I wonder whether this should be extended to including provision for 
> storing user-modified settings about the access of that property - i.e. 
> setting whether something is animateable or not would need to be done at 
> such a level. This does appear to be something that riggers/TD's of 
> other packages do a lot to simplify life for their animators.

It would be good to have this locking available for all properties 
yes. Again not sure how to store this. Would this be stored per action 
too so they are editable at that level, or in the struct itself?

> - (Perhaps this is bordering more on Animation System design...)
> I suppose that Actions would simply do something similar too, but just 
> act as containers(?). This does bring up the issue of reuse.
> Any property-identifier should be able to support this easily, by 
> offering some way by which properties in one struct/place can be 
> compared with those in another place that the user would consider 
> similar/compatible. It occurs to me that in a few packages such as XSI, 
> they seem to use unique ID's for everything (though it is mostly hidden 
> from the user). String/name based identifiers would be the easiest way 
> to do this, but as you mention, it could get much slower.

I can't really guess well what if there would be performance issues. I 
  think that with hash tables for looking up native properties this 
may be a non issue. Though for actions with user defined properties I 
can't think of a good alternative to strings even. Makes me think we 
should decide to refer to properties with strings always, unless it 
turns out to be a performance problem in which case we can use unique 
integers for native properties at least.

But as for actions, yeah this gets into animation system design, still 
it's relevant I think, but not an area I know much about or have ideas 
on what the future plans are. Would actions and NLA become something 
that can be used for any datablock (materials, textures, sound 
datablocks, whatever)?

 From the data API standpoint, I think the general idea is, that in a 
struct you have properties and in addition an 'IPO bag', actions, NLA, 
.. doesn't really matter what exactly, but something that can refer to 
properties and then be executed during depsgraph evaluation to set 
those properties to some value. And that identifier referring to 
properties should be shareable to different objects even with user 
defined properties, so we need a property identifier independent of 
the particular object.

Also a random idea, since the action channels in a pose action don't 
refer to the armature itself but it's bones, you could have a property 
identifier string like "bones[upperarm].quatx", which would be 
resolved by the data API. A similar system would then work for nodes 
or texture slots in a material, or multiple objects and their 
properties in a dupligroup, or constraints on bones for example. But 
OK, maybe this goes a bit far :) still interesting how the data API 
would allow you to decouple actions from specific data this way and 
have it reapplied recursively.

>>> I've been wondering if Multiuser IPO blocks are still
>>> actually worthwhile to
>>> have. Quite often, they seem to be more of a hassle than a
>>> genuine benefit...
>> 
>> Much useful for Layer IPO, when you want stuff appearing and
>> dissappearing at the same time (without having to key all of them
>> individually).
>> 
>> Actually, that's one example where Actions that can be applied to
>> any objects would be nice, then you could apply the same layer keys to
>> many objects while still having individual loc/rot IPO for each.

I tend to agree they should be kept. For correct updates, you should 
have some way to go over all data that points to an IPO and check if 
that's one of the IPO's being changed.. Perhaps something that can be 
implemented with an IPO_CHANGE type of notifier, which goes over all 
data and their IPO's with the data API? There's similar kinds of 
update issues that I would like to see improved using notifiers, like 
changing materials, textures, those should also call the right 
depsgraph updates for objects using them.

Brecht.