[Bf-taskforce25] data api proposal

[Joshua Leung]

Hi Brecht,

Re-IPO's:
There are several issues that need to be considered when dealing with IPO's,
which I don't think are currently covered.
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

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.

- BTW, I think Drivers should be made separate from normal animation-based
IPO's. The current situation is a can of worms in terms of defining rigs
that won't be broken that easily, and also means that we have heaps of weird
exceptions for filtering out which ones are handled at a particular point in
time. Maybe later when this is all working we could consider adding tweaks
on top of drivers...

- (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.

Re-Duplis/Proxies:
I agree with the points made here. It is a bit too much to cover at this
stage, but it would be nice to have at some point.


Regards,
Joshua

On Mon, Sep 29, 2008 at 8:11 AM, Brecht Van Lommel <brecht at blender.org>wrote:

>
> Hi,
>
> Made some changes, and added a bit of text on IPO's. Haven't written
> too much about it since I'm not very familiar with the issues there,
> but I don't foresee many difficult issues, only thing I wonder about
> is how to identify the property best (unique ID, name, ..).
>
>
> http://wiki.blender.org/index.php?title=BlenderDev%2FBlender2.5%2FDataAPI&diff=57242&oldid=57172
>
> Renamed list -> collection, added modify(), and a bunch of other changes.
>
> Martin Poirier wrote:
> > Getters will have to take a pointer as argument, the getter function
> > will copy data in there. The same problem/solution applies to matrix,
> > quat, color getters.
>
> The reason I mentioned strings is that they can be variable length.
> Though of course ID names for example have fixed length. I think a
> function that gives a pointer + maxlength, and another function to
> retrieve the length should work.
>
> Both thanks for the feedback,
>
> Brecht.
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20080929/0dd07c0b/attachment.htm