Page MenuHome

Add UUID to Blender data-blocks
Confirmed, NormalPublicDESIGN

Description

Having UUIDs to reference data-blocks of Blender would help in some cases with interaction with third party tools, especially when relations between different types of data storage is needed, and handling renaming of data-blocks across those is not possible.

This design task is here to define what would be expected from such feature, and how various issues should be addressed.

See also this ML discussion.

Disclaimer: this is a draft design proposal currently.

Core Ideas

  • UUIDs should be 'real' ones, 128bits long.
  • UUIDs should be generated on demand, not systematically. This process is not free, and internal handling of data-blocks by Blender itself should not use them at all.
    • Think we should still store them as a systematic fixed chunk of data in the ID block in the .blend file though (being zeroed for non-generated ones), to ease their retrieval from third-party code 'parsing' .blend files?

Issues to Investigate

  1. Collision and Uniqueness
    • UUIDs should be absolutely unique withing a .blend file. This would be easy to ensure. Linked data-block would not be concerned by this, since they belong to another .blend file.
    • UUIDs should be reasonably unique across .blend files.
      • Creating new IDs from existing ones (internal copy, appending from a library, creating proxies or overrides from linked data) should nullify the UUID of the new data-block.
      • 'Save file' operations explicitly creating a duplicate file (Save as, Save copy) should maybe enforce re-generating UUIDs?
      • .blend file duplication would be the main source of collision. Not sure how to deal with that case, besides offering the possibility of a manual re-generation of UUIDs by user?
      • If the 'file copy' case is solved, collision between different .blend files remains possible, though extremely unlikely.
  2. Runtime IDs
    • Some system may generate a random number of data-blocks in a procedural way (e.g. from future geometry nodes evaluation.
      • Persistence of UUID in such IDs is probably not possible? We should then accept that it would need to be re-generated when nodetree re-create data-blocks?
      • This only concerns IDs that would be generated in Main database (and hence saved on disk), not runtime IDs.

Implementation Hints

  • Search for existing implementations of UUIDs (e.g. in python).
  • Using OS-provided tools should be preferred solution as much as possible.
  • How should RNA (Py API) expose those 128bits UUIDs, as an array of 4 integers? An hexadecimal-encoded string?

Event Timeline

Bastien Montagne (mont29) changed the task status from Needs Triage to Confirmed.Nov 25 2020, 8:43 PM
Bastien Montagne (mont29) created this task.
Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Design".

to ease their retrieval from third-party code 'parsing' .blend files?

I don't think this is really important to take this into account, in general I don't think third-party code should be parsing .blend files. If they do I imagine they should be able to read arbitrary structs anyway.

UUIDs should be absolutely unique withing a .blend file. This would be easy to ensure.

It is easy, but if we want to make them unique across .blend files, then we probably use an algorithm where it's not so easy to ensure this. We could check for collisions, but the memory/performance cost is probably not worth it.

Runtime IDs: Persistence of UUID in such IDs is probably not possible?

I think we can probably generate persistent IDs, by hashing the UUID of the original datablock with the persistent ID for instances somehow:
https://docs.blender.org/api/current/bpy.types.DepsgraphObjectInstance.html#bpy.types.DepsgraphObjectInstance.persistent_id

Hi, just a simple comment: maybe the UUIDs are in a way not Blender core data, but more like saved information about a previous export. So consecutive exports to update the model in game engine or BIM tool could manage the update in the import respectively. Blender already has internal IDs which are unique within the session. The idea to have optional UUIDs is in line with this thinking. I mean, an export can create the UUIDs when necessary, but Blender would then store them. Maybe there are no other consequences from this point of view.

The UUIDs could also be in just some exporter specific history data but it seems nice that Blender would support them internally so they'd show in the GUI the same way and it would be consistent for all exports (given they support UUIDs, what else besides BIM does?).