2024-12-12 Core Meeting

Meetings
1

Everyone is welcome on the Google Meet linked below every other Thursday, alternating between 10:00 CET and 16:00 CET.

Present:

The meeting covers the core module topics (DNA/RNA, ID management, Depsgraph, Blendfile I/O, etc.) .

Links

Ongoing Work

  • PointerRNA Ancestors: Bastien had no time to work on this in the past two weeks.
  • Bastien worked a bit more on adding tests to validate py scripts needed for release on the buildbot versions of python.
  • Jacques kept cleaning up readfile and writefile code in preparation for the embedded linking project.
  • Hans is working on deduplicating the blenlib math implementation between C and C++ code (goal is to make the C headers use the C++ implementation).
  • Making numpy a hard dependency (as in, automatically included when python is enabled) has been agreed on in last Admins meeting.

Data-block Caches and DNA Invariants

  • Storing ID pointers in runtime data. There are two cases:
    1. The pointer refers to other data in bmain and thus is affected by id management code.
    • Needs to be iterated over in the foreach-id loop.
    • We might need to add an additional IDWALK_CB_* flag to tag such cases at some point, but does not seem strictly necessary for now.
    • This can be used e.g. by caches.
    • When used, the system has to be aware that id management code may change or clear the data-block pointer.
    • Would be good to make the core module aware when implementing a cache that has data-block references.
    1. The referenced data block is local to the data block and thus “just data” that is uneffected by general id management code.
    • This can be used e.g. for baked data like meshes owned by an object.
    • No need to iterate over these data-blocks in the foreach-id loop.
    • Need to be careful not to have indirect references to other data-blocks in bmain.
  • Updating data-block related caches:
    • Updating these caches as part of general id management code seems impossible.
    • It may only be possible as optimization in a few specific cases. Needs to be checked if this is worth it on a case-by-case basis.
    • Generally, such caches need to be tagged as dirty and then recomputed later on.
      • Ideally it’s possible to recompute them on demand as this gives the most flexibility and optimization opportunities.
      • Sometimes it’s fine to update the cache at a predefined point in time though. E.g. at the end of an operator or before building the depsgraph or similar.
    • Code that builds the cache from scratch has to exist anyway, because it has to run at file-load.
  • Invariants in DNA data.
    • We have a few invariants in original DNA data that need to be kept intact. For example:
      • The sockets of a group node need to correspond to the interface of the referenced group.
      • The set of Bone and bPoseChannel need to be kept in sync.
    • Currently, there is no unified system for maintaining these kinds of invariants.
    • Generally, these invariants have to be ensured by some update code whenever a corresponding data-block is changed.
    • Except for caches, this update code has to run eagerly as part of operators or RNA update functions.
      • That’s because they semantically belong to the operation and need to be part of the same undo step.
    • A good next step is to introduce a new function like BKE_main_ensure_invariants that can be called when certain changes are done.
      • Initially, this function would run the node update code, but it would be great to move other similar code there too.
      • Anything that’s added to this function has to fulfill one specific criteria: it has to be idempotent, meaning after calling it once, a second call should have no effect.
      • It’s important that this function is not too costly all the time. So there have to be tags at the Main or ID level that indicate whether any work has to be done at all.
      • Long term, this function might have to evolve into a DNA level dependency graph system, but for now the individual invariants are disconnected enough that it’s not necessary.
  • Unifying update tagging.
    • Currently, there are different tagging mechanisms one must use when changing data. For example, for node trees one has to care about:
      • Node tree tagging: e.g. BKE_ntree_update_tag_node_property.
      • Dependency graph tagging: e.g. DEG_id_tag_update.
      • Notifiers: e.g. WM_main_add_notifier.
    • Ideally, one would only have to call a single granular tag function that then makes sure that everything is tagged correctly.
    • A more specific design task for this still has to be written.

Next Meeting

Due to the end of the year context, it will be in three weeks instead of two.

The next meeting will be on Thursday 2nd January, 10:00 CET/Amsterdam time (your local time: 2025-01-02T09:00:00Z).

The provisional meeting agenda will be linked in the #Core module channel before the meeting.

5 Likes