My main concern here is that we end up in a situation where users have to press Purge often to keep memory usage under control. And then if they learn to do that, they still end up accidentally losing data in the same way as before.

I think we could tweak behavior a bit depending on the data type:

• Enable fake user by default for materials, textures, images, node groups and maybe a few others.
• Alternatively if we keep unused IDs, give the Purge operator settings to delete on certain data types and disable materials and similar by default.
• When deleting an object, also immediately delete its object data, shape keys, action if they have no other users. This is probably what users expect to happen and saves memory immediately.

This hopefully then makes running Purge less important in typical cases, while also being a safer operation. There are a few other things that could be improved:

• Make it accessible from the File menu and Blender File view in the outliner.
• Before it runs, show a popup with info on data types that will be deleted (5 materials, 3 meshes, etc) and allow users to confirm or cancel. Ideally should also allow expanded to see exactly which datablocks.
• After running, show "X datablocks deleted" message in the status bar.
• Make it not save and reload?

Good initiative to take a look at this. Here are my thoughts:

I definitely think we should remove the auto-purge feature. It causes lots of confusion, complexity and loss of user data, which I don't think is acceptable. It's too easy to lose real work, and going through and managing this is a pain.

This is going to sound hyperbolic, but I find the concept of auto-purging downright user-hostile. User data should be treated as sacred, not to be auto-purged, just because a material happens to not be in use.

The biggest problems with Fake Users & auto-purging are:

• It's difficult to avoid losing data (if you forget to enable Fake User for a datablock)
• It's actually difficult to remove something intentionally, because you first have to make sure it has zero users.

So, it's hard to keep data and hard to remove data with this system. I think the entire concept of Fake User should be abolished. If we don't do auto-purge, it is not needed anyway.

To me it seems as if we have an opportunity to change this while we introduce the Asset Manager. As part of the Asset Manager design doc, we came up with the idea of having a category for the current blend file, to give users an overview of all the datablocks inside the current blend:

Here we could add a section called 'Unused Data', which displays all datablocks which aren't in use. Users can then purge this data from here.

This kind of thing would be helpful if we make this change, to giver users a better overview of what data they have inside the file.

So, my proposal would be to bundle this behavior change in when the Asset Manager is added, to give extra clarity for users who can get a better overview of their document data and usage.

The outliner already has an "Orphaned Data" view for this. Maybe it should be renamed to "Unused Data", or folded into "Blender File" somehow (which could also use a rename).

I'm not sure the asset manager should become a place to manage Blender data in the current file.

Yes, the Orphaned Data in the Outliner is ok, but doesn't give very much information about who is using the data where.

The nice thing about a section like that in the Asset Manager, is that users might want a nice overview of their materials/node groups/worlds/textures etc inside the current document anyway, as part of the asset manager. Not all projects need external libraries or folder structures. Most other 3D DCC apps have some way to get a visual overview of your materals, textures etc.

And once we have that, we can use it for this purpose too. The nice thing is that, if you were to select a datablock here, we could have a way to tell users where it is being used, by which object, etc.

The Asset Manager is strictly speaking a separate thing, but it can be used to get a better overview of user data, which is exactly what is needed if we get rid of auto-purge and fake users.

So it's just happens to be good timing, that's all.

@William Reynish (billreynish) I definitely agree. Having the current file visible in the asset manager also means there's now an easy overview of all used materials, or all of your meshes, and an easy way to mark them for storage in the Asset Manager itself.

Keep in mind that this needs to be managed on per-case basis, and some common sense needs to be used. Generally, the way this is handled should be aligned with general expectations of users. Let me show you two examples:

1:
User spends some time creating the material.
User decides not to apply the material yet.
User saves the file.
User re-opens the file and material is gone.
That is wrong.

2:
User creates a material by accident.
There is no simple straightforward way to delete the material except one very obscure mode of outliner or restarting Blender.
That is wrong.

3:
Use creates a mesh model in his scene.
Later in the process, user no longer needs the mesh.
User deletes the mesh object from the scene.
User saves the scene, and proceeds to continue working on the scene file until the mesh object deletion is pushed out of the undo stack.
The mesh data still remains in scene file and gets deleted only on scene close/reload.
That is wrong.

4:
With new proposed behavior, when user deletes all objects referencing particular mesh datablock, the mesh datablock still stays in the scene. Especially meshes are quite heavy datablocks.
This now requires user to drop his work often and go do chores of manually cleaning up unused mesh datablocks.
That is wrong.

With the few examples above, you can't see that Williams idea of treating user data as sacred can not be applied in the same manner to all different types of data blocks.

It all comes down to main underlying issue. Blender treats both low level and high level data as data blocks, even though both of these require quite different workflows. In many other packages, users do not even come in contact with low level data. In Blender they do. It's sometimes a blessing, mostly a curse though.

Here's how it should work:
High level data, such as scene objects, materials or texture maps should be managed explicitly. Meaning they can be created and deleted by users, and they never get purged automatically. True deletion of these should be easily accessible from the same place they are created and managed at.

Low level data such as mesh data should be managed implicitly. Meaning that for example as soon as mesh data block becomes orphaned, it gets purged. But immediately, as soon as it drops out of the undo stack. Otherwise yes, users will run into memory issues.

So again, source of most of these issues is that Blender treats both high level data and low level data as same type of data block, despite these two data types requiring different kind of management.

If you think about it, unless user decides to pack external assets within Blend file, then mesh data is really the only data block type that has any significant size. Most of all the other data block types are procedural. Mesh data datablocks are probably the only ones that require the kind of implicit management that is present in Blender now. I'd perhaps go as far as to suggest users should not be able to interact with mesh data at all. It should happen under the hood.

Right now, exposure of mesh data to users only brings issues, especially having to do naming for both scene objects and mesh data blocks, since exporters mostly use names of mesh data blocks rather than scene objects.

After all these measures, the dreaded fake user button can finally go away.

I’d rather leave the asset thing outside of this discussion, though related, it's still kind of off-topic (and should not be used to do current .blend file management, IDs and assets are not the same things). :)

@Brecht Van Lommel (brecht) your propositions make sense… I wasn’t even aware that Purge was doing a mere save/reload, that can be changed immediately to a proper on-the-fly IDs removal, will do that already.

Edited task description to add suggestions from @Brecht Van Lommel (brecht), and to reflect work already done on Purge operator.

Also fixed a crash when undoing ID deletion (since yes, new code should allow to undo ID deletion/purge ;) ).

@Bastien Montagne (mont29) As I understand, you proposal is to only display the Fake User toggle inside the Outliner. If Fake User must be kept, which I'm not sure it does, then I agree that demoting it to the Outliner is nicer. Because then at least the Fake User is not something most users ever have to worry about.

I think it would be a shame to not take the opportunity to simplify things for users. If the ID's are all saved in the blend file, there's no need to keep clicking on the Fake User button. Removing this toggle from the ID selector is a nice way to simplify things for users.

I think Fake User could be removed, but only if we add options to the Purge operator to specify types of datablocks to delete. Because you still need a way to reclaim memory (at least until deeper design changes happen), but without deleting datablocks like materials.

As for icons, I suggest to have:

• Remove from list: -
• Unlink: X
• Delete: trashcan

The "-" (remove from the list) and "X" (unlink) - let's imagine, that the F-user toggle is demoted to the Outliner and all ID's are kept. What's the difference between both of those functions then? Wouldn't the "unlink" be enough? This part of the UI seems to be counterintuitive from my point of view..

@Andrzej Ambroz (jendrzych) think @Brecht Van Lommel (brecht) was more on general UI level: - to remove from lists (aka UI lists, like for vgroups, UVMaps, etc.), X and trashcan would be for IDs (unlink removes the ID usage represented by the IDTemplate UI, but does not remove used ID itself, while trashcan will fully delete that used ID). Also probably for historical reason it's better that way (we have used X to unlink IDs for ages).

@William Reynish (billreynish) yes, fake user would be for outliner only. I would keep it though, it's a nice way to fine-grain select IDs you want to protect from Purge (even if/when we add by-type option to purge). And thinking forward a little bit, it could be a handy way to import existing .blend files used as libraries into some asset management system, too.

@Bastien Montagne (mont29) Ok, in that case I don't mind keeping the Fake User then. We could even probably rename it to 'Resist Purge' , 'Don't Purge' or 'Exclude from Purge'. Something like that.

The term 'Fake User' is also just a confusing name - both the term 'fake' and 'user' don't make any intuitive sense in this context at all.

In T61209#617807, @William Reynish (billreynish) wrote:

@Bastien Montagne (mont29) Ok, in that case I don't mind keeping the Fake User then. We could even probably rename it to 'Resist Purge' , 'Don't Purge' or 'Exclude from Purge'. Something like that.

The term 'Fake User' is also just a confusing name - both the term 'fake' and 'user' don't make any intuitive sense in this context at all.

To be honest, there's no other software I know of that has any concept of purging. It's concept unique to Blender. All the truly modern pieces of software dedicated to digital creation manage these types of data automatically. So if you are a new user, and expect Blender to be just another digital creation software, then button with tooltip saying "resist purge" will be equally as confusing as button saying "fake user". No win here.

If you want to keep this feature (which I am against), and want to introduce this unusual mechanism to new users, then I would rename purge to "Data Cleanup" and the button would be labeled something like "Ignore Data Cleanup"

Remember we are not talking about auto-purging, but manual purging inside the Outliner or Asset Browser.

If we are to keep the concept of manually purging unused datablocks, which I think is reasonable and useful, then a toggle to make items resist this purging is OK. We just should not call it Fake User then - that name no longer makes any sense (if it ever did).

Unlike the current Fake User toggle, this toggle is not something users would have to worry about, unless they do manual purging of unused data.

As @Bastien Montagne (mont29) suggests, it will only be visible inside the Orphaned Data section in the Outliner.

Alright, I will wait and see how it works out in practice :)

@Bastien Montagne (mont29):

Likwise, when deleting any ID, also delete its animdata's Action if not used anywhere else.

Eh, I'm not sure about that. Just like with materials, users might build up a library of actions. Deleting objects should not delete their actions, otherwise you will lose important user-created data.

'Fake User' is actually an excellent example of naming that totally makes sense at the technical level (how it is implemented in code), but is absolute non-sense for any normal user. :) Regarding new name, I would not reference purge here, something as simple as 'always keep', or 'don't auto-delete', or in that area? Anyway, this is a bit detail for now ;)

@William Reynish (billreynish) thing is, actions can also become very heavy at some point, and you could have that argument for meshes as well anyway… I'd still expect the 'Fake User' flag (whatever would be its new name) to be set on those data-blocks then. On the other hand, I wouldn't mind adding a setting to control which ID types to auto-delete either.

Those names would be fine with me too. And yes, I do understand the technical reason for the old name, but you have to have quite an intimate knowledge of the technical details for it to make sense.

As for actions:
Currently, actions actually *do* have Fake User enabled by default, at least armature actions do. Although in this new proposal I thought the idea was that it would not auto-purge, so there's no need for Fake User to be enabled for anything, surely?

If your file gets too big you could always go and purge unused.

Enabling Fake User by default for certain things doesn't seem to make sense in this new world where auto-purging goes away. It seems random that some things are born with fake user enabled, and not necessary if Blender stops deleting user data without their consent.

"A computer shall not harm your work or, through inaction, allow your work to come to harm".

I always teach my students how to use the fake user button (on mesh, actions, ecc...) and everyone is admired that blender takes care of delaying the deletion of user data:
we, me and my colleagues, approve that blender does not delete datablock itself. Having a purge command (having clear what you purge) could be a nice improvement, making clear what happens.

Moreover, I am convinced that there is no data of series A (objects, materials) or series B (mesh, or other): it would only create confusion not to have a unique behavior.
We believe that blender linking (ex. object-mesh-mat-text-image ecc... ) is unique and better than the one of other software, giving artist more freedom, having explicit commands.

@Riccardo Gagliarducci (rickyx) Nice Jef Raskin quote.

I also don't find it completely clear why some ID types are to be given 'fake users' by default and others not. I don't see how we can rationalise what data the user prefers to keep from purging.

The user may have created a material or texture by mistake and wish to purge materials - why do they have fake user enabled but other things not? I don't get that.

The good thing is that fake users aren't needed to keep Blender from lynching your work.

@William Reynish (billreynish) Ton suggested me to read The Humane Interface 12 years ago: super, you got it right away!

Choosing the precautionary approach I suggest to consider all datablocks equally important ( I don't think that any modern pc gets nailed because, by mistake, I created material.001). There is no rationale about having data hierarchy: too many hours spent on creating 3d (action, texture, node group, armature, text, world, ecc...).

I do agree to remove fake-user and create a purge procedure.

Ex. Inkscape does that: File -> Clean up Document
If you have create a pattern, and removed the "father" object the patterns stays in the xml until you manually purge: unused definitions goes away. And it is clever.
From the guide:
"Many of the no-longer-used gradients, patterns, and markers (more precisely, those which you edited manually) remain in the corresponding palettes and can be reused for new objects. However if you want to optimize your document, use the Clean up Document command in File menu. It will remove any gradients, patterns, or markers which are not used by anything in the document, making the file smaller. "

I agree with @William Reynish (billreynish) , a better user experience would be to manage everything from the asset manager.

@Brecht Van Lommel (brecht) - You ask, You get.