Page MenuHome

Recursive Purge Orphans datablocks on file save
Needs Triage, NormalPublicDESIGN


Currently, and always, in Blender, zero-user datablocks without a fake user are not saved when saving a .blend file, so the next time that .blend file is re-opened, such datablocks are gone without any way to recover them. The same can also be achieved with the Purge Orphans operator, so no reloading of the .blend file is necessary. The Purge operator recently got a much needed "Recursive" option, which I find extremely useful; With this option enabled, not only will it purge zero-user datablocks, but also datablocks whose only users were zero-user datablocks.

This behaviour works great for cleaning up a .blend file after deleting complex elements like an entire character, and I propose having this behaviour available also for saving files. Personally, I would make this the default, but I know that could be controversial, so having it be an option that is disabled by default would still be welcome.

Use case, sort of

Not only would this make perfect sense according to everyone I've talked to so far (@Sybren A. Stüvel (sybren) @Bastien Montagne (mont29) @Julian Eisel (Severin) @Simon Thommes (simonthommes) ) but also help us keep clean scenes during production. Currently, this can very easily happen:

  • Animator duplicates an overridden character. All its objects get a .001 suffix.
  • Animator deletes that copy, saves their file, and later re-opens it. Only one "layer" of unused objects has been cleaned, so there can still be orphan object datablocks lying around unseen.
  • Animator duplicates the character again. Now the number suffix of their objects are all over the place. Some of them have .001 and others have .002.

As they continue working and duplicating characters, the old, unused objects slowly get deleted, and the name suffixes really get all over the place. It's not nice to get your objects names all mixed up like this, as things get really confusing when trying to troubleshoot problems in a production file, since everywhere where one object references another, the mismatching suffixes give the troubleshooter anxiety and uncertainty. The only way to avoid this currently is to tell the entire production team to always run a recursive Purge after deleting anything, which is very error-prone.

Potential issues

  • The current recursive purge purges Text datablocks, which is bad because they don't have the possibility of a "Fake User", so they should be excluded (or better yet, be included in the "fake user" system, and get a fake user by default). (T87489)
  • Actions still don't have fake user enabled by default, which, as someone who's job it is to listen to animators complain about Blender all day, I think is a massive blunder. This long standing issue of Action datablocks "disappearing" on users and making them lose hours of work if they forget to click Fake User will be exacerbated by this change.

Event Timeline

Marking as "Good first issue" on Julian's suggestion, if any contributors would like to pick this up, it's probably(hopefully) simple on the implementation side.

Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Design".Wed, Apr 14, 1:29 PM

Whoops, so much for "Good first issue"! I forgot about that task, thanks for the reminder. Maybe this task is sort of redundant then, since the design proposed in T61209 solves the same issues, and perhaps more elegantly. It's just a shame since that seems like a pretty daunting task that probably won't be tackled for some time, so until then I am left with shoving a "Purge All" button in the animation team's face and hope that they press it often. :/

With that design in mind, I think what I'm asking for here could manifest as a "Purge on Save" user preference, that would bring back the old(current) behaviour except with a recursive purge. (Performance be damned.) Alternatively, it would be interesting to explore more ways to allow datablocks to not have to share a name space. Right now, linked and local datablocks are in separate name spaces, which I think is great. If we could have a similar thing for deleted databloks, I think that could be interesting, and also make sense from user PoV.

@Bastien Montagne (mont29) Do you think it's better to close this task and add my thoughts to the discussion in the other thread, or is it worthwhile to keep this separate?

@Demeter Dzadik (Mets) would keep both for now, while related they are not entirely the same. We can re-iterate on designs and such once we actually start working on those.