Blenloader API: lib linking and animdata read/write
AbandonedPublic
Actions

Authored by Jacques Lucke (JacquesLucke) on Apr 3 2020, 2:40 PM.

Details

Reviewers: None

Summary

In this patch I continued to experiment with the blenloader api.
Also see D7061 and D7062.

This patch adds a few more direct linking utilities as well as a method for getting the new address of an id data block.
To test the API, I move writing and reading of AnimData to blenkernel. This includes nla strips, fcurves and id properties.

I can split this up into separate patches for API and usage of the API eventually. But for now it is easier to have both in the same patch.

The naming conventions are not worked out everywhere yet. Feedback on naming conventions is welcome.

Diff Detail

Repository

rB Blender

Branch

arc-blenloader-api-lib-linking (branched from master)

Build Status

Buildable 7433
Build 7433: arc lint + arc unit

Event Timeline

Jacques Lucke (JacquesLucke) created this revision.Apr 3 2020, 2:40 PM

Harbormaster completed remote builds in B7433: Diff 23393.Apr 3 2020, 2:40 PM

Jacques Lucke (JacquesLucke) edited the summary of this revision. (Show Details)Apr 3 2020, 2:41 PM

Jacques Lucke (JacquesLucke) edited the summary of this revision. (Show Details)

Jacques Lucke (JacquesLucke) added reviewers: Brecht Van Lommel (brecht), Bastien Montagne (mont29), Campbell Barton (campbellbarton).Apr 3 2020, 2:43 PM

Jacques Lucke (JacquesLucke) added a parent revision: D7062: Use Blendloader API for modifiers.Apr 6 2020, 11:40 AM

Jacques Lucke (JacquesLucke) retitled this revision from Blenloader API: lib linking and animdata read/write [WIP] to Blenloader API: lib linking and animdata read/write.

Can we please have design tasks about these changes before getting patches? thanks.

Yeah, right. Thing is, I need to work on this, before I'm capable to make an actual design proposal.. I just shouldn't add you as a reviewer, just as a subscriber maybe.

Brecht Van Lommel (brecht) mentioned this in T75724: Extensible Architecture Refactoring.Apr 14 2020, 1:52 PM

Is this patch ready for review?
It lacks reviewers assigned. If you still plan to work on it please use "Plan Changes" feature.

All in all from personal feeling of the change I think this is a right direction to move to.

In general seems fine, although we could either split out the reading/writing into own files (_io.c suffix for example). Or, use doxy sections for io code.

I plan to do some final experiments next cleanup day, and prepare a separate task for this project afterwards.

I'm fine with splitting reading/writing into _io.c files. However, we probably don't want this everywhere. E.g. for nodes and modifiers it might be good to keep things in a single file.

In D7321#178234, @Campbell Barton (campbellbarton) wrote:

In general seems fine, although we could either split out the reading/writing into own files (_io.c suffix for example). Or, use doxy sections for io code.

The way I see it working is that these go along with standard init_data, copy_data, free_data methods in IDTypeInfo. Animation data is not an ID type, but data structures like this can follow the same naming and organization. Doxy sections for that is fine with me.

anim_sys.c is too big and should be split up, but it's e.g. the evaluation code that should move out I think. I'd rather not have _io.c files.