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.

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

@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.

Currently if you delete objects, end up with unused object-data which can take a lot of memory & space in the blend file.

Brecht suggested: "When deleting an object, also immediately delete its object data..." ~ if that's done it's not an issue.

If you change the mesh an object references some other way (besides explicitly deleting), it's unlikely you will want it to be kept.

@Campbell Barton (campbellbarton) it may happen that you delete an object but you don't want to delete his material.
So we come back to the same question: is there a hierarchy between the data? Why keeping my object material and not my mesh or my walk-cycle animation, so carefully crafted?
And my node-group?

What if I remap the mesh (read material, texture, data-block) of an object? Will the old one be deleted as soon as it is un-linked?
The data-block linking/keeping is so powerful!

If it is necessary I can provide some real usage case of keeping data and work.

Thank you,
Riccardo

@Riccardo Gagliarducci (rickyx) not sure about the situation w/ materials, I assumed it would have a fake-user.

Responding the the point @William Reynish (billreynish) was making about why you might want some data-blocks to have fake users and not others.

If some object data isn't used anywhere (which can happen even if it's less likely if ob-data is removed on deletion), it's not likely you will want to keep it. Hence there is a reason you might not want to have fake users for object-data by default, but have it for materials.

How's this moving along? :) Given the huge value of this in everyday workflows of pretty much everyone, I think it deserves priority.

Priority is fixing bugs and getting 2.80 released with the planned targets.

@Ludvik Koutny (rawalanche): in general, please don't do "thread bumping" on developer.blender.org. If all users start doing this it will be a mess.

In T61209#632775, @Brecht Van Lommel (brecht) wrote:

Priority is fixing bugs and getting 2.80 released with the planned targets.

@Ludvik Koutny (rawalanche): in general, please don't do "thread bumping" on developer.blender.org. If all users start doing this it will be a mess.

Okay. I understand.

In T61209#613966, @Brecht Van Lommel (brecht) wrote:

• Enable fake user by default for materials, textures, images, node groups and maybe a few others.

Does it mean that all the trash will left in file if it was once placed there? =)
This violates "always keep blend file clean" strategy.

Or is it supposed that I, as a project manager, should clean all the mess after artists instead of software?

In T61209#615458, @Ludvik Koutny (rawalanche) wrote:

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.

Agree. Nice examples by the way.

Here's how it should work:

The problem is that this cannot be expressed with a simple rule like "everything that is not used will be removed."
As a result you have to remember what and when will be purged, this will make management difficult.

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.

No, mesh data allow to control instancing, and exposes real objects structure. Hiding it will bring the same confusion like in max or maya, where instances management is pretty painful.

On massive progects gigabytes of possible trash are iterating through our files just daily during creation process.
What is the point to keep it in file?
Having 200 Gb blend files instead of 2?

@Paul Kotelevets (1D_Inc) Totally agree that "mesh data allow to control instancing, and exposes real objects structure" is a massive advantage and a key improving difference from other software.

If this topic is still active...
after much thought this year, the countdown is not such a bad system and allows for a slow elimination of obsolete content, keeping a balance between distracted users and huge files.

We already have tools in the outliner to batch-delete orphaned data-blocks, proposal here is rather to not do that implicitly on .blend file save, which is a fairly unexpected (especially from new users) behavior...

Further more, keeping too much trash data is always better than losing valuable one imho.

In T61209#1079385, @Bastien Montagne (mont29) wrote:

Further more, keeping too much trash data is always better than losing valuable one imho.

You stop losing valuable data, when start to care about it.
That's the basics that deserves to be learned before starting any kind of massive production, because there is no other way to stop massive pollution there.
And there is no simple way to learn it, so it better be done in the very beginning, when there is nothing valuable anyway.

In T61209#1079391, @Paul Kotelevets (1D_Inc) wrote:

You stop losing valuable data, when start to care about it.

The problem is they come from different culture and they don't understand how practical the actual Blender structure is, this is sad :(

In my opinion the problem is not in automatic garbage collecting, but in the lack of notification. (which can be optional to not to annoy experienced users, who already mastered such a workflow tool as controlled losses)

Also, considering garbage collection, it would be nice to have a recursive cleanup to perform garbage cleanup faster.

No, the main problem is that there is no proper, easy to access and easy to use UI space to manage datablocks. That's exactly why I wrote my post in the datablock selector redesign thread. Of course no one is going to care about datablock management when the entire datablock management is hidden inside one, clumsy, frustrating to use outliner mode. That's why asset manager should be a datablock manager, primarily. You are doing your best to justify Blender's convoluted way of managing datablocks, while game engines such as Unreal or Unity have been proving for over a decade now, that asset manager based data asset management is the best, easiest and most straightforward way of doing this task.

Users themselves should decide whether or not should the unused materials be removed or not, because only users themselves known which material they want to remove, and which ones they want to keep for later, even unused. No AI, let alone simple heuristic based on references can decide that for user. But if you have such a bad solution like Blender currently has, where the Blender does keep unused materials but does not give users any acceptable user interface to manage them within, you end up with exactly the dumpster fire we have now.

In T61209#1079561, @Ludvik Koutny (rawalanche) wrote:

Users themselves should decide whether or not should the unused materials be removed or not, because only users themselves known which material they want to remove, and which ones they want to keep for later, even unused.

They already doing this, by flagging datablocks.
However, from our management experience, artists never know what they really need, except everything at once. This is a huge problem.

No, the main problem is that there is no proper, easy to access and easy to use UI space to manage datablocks.

Sounds like a lot of design work.

In T61209#1079638, @Paul Kotelevets (1D_Inc) wrote:

In T61209#1079561, @Ludvik Koutny (rawalanche) wrote:

They already doing this, by flagging datablocks.
However, from our management experience, artists never know what they really need, except everything at once. This is a huge problem.

Yes, because something as trivial as material management should not have any learning curve, let alone one as confusing as Blender has. Blender is one of the very few 3D software packages where material management is something that is complicated.

In T61209#1079638, @Paul Kotelevets (1D_Inc) wrote:

In T61209#1079561, @Ludvik Koutny (rawalanche) wrote:

No, the main problem is that there is no proper, easy to access and easy to use UI space to manage datablocks.

Sounds like a lot of design work.

No, not at all. I mean it's a lot of design work if you overcomplicate it, as is tradition for Blender. But otherwise, it can be as simple as having a visual editor which can browse currently active .blend file, very similar to how append/link dialog can:

1. Remove in the entire .blend file, similar to current purge.
2. Remove in current asset browser folder.
3. Remove in current asset browser folder and all its subfolders.

There, it's that simple. A material and other datablock management with close to 0 learning curve and/or confusion. And then, fake user could finally go to hell, where it belongs.

In T61209#1079561, @Ludvik Koutny (rawalanche) wrote:

Blender is one of the very few 3D software packages where material management is something that is complicated.

I am not sure, because I remember multimaterial in 3dsmax. You also have explanation video about its material editors on your youtube channel. That was a learning curve.

it can be as simple as having a visual editor which can browse currently active .blend file, very similar to how append/link dialog can:

M_Building_windows? Such a self-representing information.
Have you worked with BIM imports? There will be mostly things like Building_Windows_025645656 and Building_Windows_778546588
This is not even trash on your screenshots, so you can manage it by names in lists.

In T61209#1079682, @Paul Kotelevets (1D_Inc) wrote:

In T61209#1079561, @Ludvik Koutny (rawalanche) wrote:

Blender is one of the very few 3D software packages where material management is something that is complicated.

I am not sure, because I remember multimaterial in 3dsmax. You also have explanation video about its material editors on your youtube channel. That was a learning curve.

WTF are you talking about? That video is over 5 years old. I do not use 3ds Max for over 3 years now, and when I said "Blender is one of the very few 3D software packages where material management is something that is complicated" I'd also count 3ds Max among those.

it can be as simple as having a visual editor which can browse currently active .blend file, very similar to how append/link dialog can:

M_Building_windows? Such a self-representing information.
Have you worked with BIM imports? There will be mostly things like Building_Windows_025645656 and Building_Windows_778546588
This is not even trash on your screenshots.

So? What's your point? There's absolutely no reason the asset manager should not have options to change how entities within the folder get displayed:

Can this option be toggled somewhere in preferences (Save & Load is a perfect place)? Checkbox with option to save/purge trash data when saving file?

In T61209#1079710, @Eugene Du (APEC) wrote:

Can this option be toggled somewhere in preferences (Save & Load is a perfect place)? Checkbox with option to save/purge trash data when saving file?

No. If you send file to your team, they will purge its content if they have different setup. (Teamwork issue)

@ All Please remember that this tracker is not a forum, but a tool to help the development team.

Please strictly stick to the topic of this task, and avoid endless ping-pong wall-of-text discussions, those should happen elsewhere.

That was even more off-topic, please respect the rules of this website. developer.blender.org is the workplace of Blender developers. Please treat it with the same kind of respect as would be expected when walking into an office where developers are working.

In T61209#1080029, @Brecht Van Lommel (brecht) wrote:

Please treat it with the same kind of respect as would be expected when walking into an office where developers are working.

Sure. I am also addons developer, and know how hard this work is and how concentration is important.
But, please, be careful with workflow design, otherwise you will completely push us out of production.

Design process in a nutshell, pretty accurate.
Over the course of several iterations, when important data becomes garbage and garbage becomes important at any moment, sooner or later there comes a point when it simply cannot be taken care of, especially at deadlines.
Projects cleanliness in business always has a lower priority than results (because results are paid for), and this is a problem of the entire industry.

This whole proposal looks strange. It looks like you are trying to design a part of the engine without considering the whole engine.

I think it's like turning an automatic transmission into a manual.
The manual purge solution is familiar from the Autodesk family of products and all of their longstanding problems.

As I understood it's because with new Asset Browser we need to store for example unused material with it nodes and not be purged after close blender.

Asset Browser allows you to simply view some data, and that's it, its presence cannot affect the saving of unused data in the file.

Just checked, and indeed when we mark asset it become a fake user, so why need to store all trash data? - unclear.

It is logical when we mark something as an asset in library file, because this way we confirm that we need it.