I don’t personally think that the data needs to have a fake user by default, and data without a user should be able to be purged upon request but it should absolutely not be done when closing a saved file.
A saved file should restore to the state it was in when it was saved. Period.
If that state was that there are unused data blocks waiting either for a user or to be removed by a purge command, then that is what should come back. It’s what the user expects. It’s what all other programs with similar concepts do.
It’s not like this feature has no reason to exist. Leaving garbage collection to the user is bad design as well.
This doesn’t just encompass materials, but all kinds of possible data that warrant this feature:
Deleted objects leave behind their mesh
Every texture that is/was used is still available even if it has been swapped out
Imported Objects can bring along many assets the user might not be aware of
Default materials (“Material.001 ect”) that have been replaced
Cycling through fonts will leave a copy of each type
Some of them are even kept until they’ve been unused for two saves (newly created images for example)
I don’t want to manually scrape away unused data like food stuck between teeth.
Materials however obviously display a big disparity between “unused” and “redundant”. In my opinion marking new materials (and the ones explicitly appended) as protected would thus be the best approach - at least without having to come up with a more intelligent system.
This just screams inexperience at being a pro & lazy as all can be. This is where I’ll counter your talking points to say. Make me a button that does it all.
The only way people get better at anything is by practicing and learning from repeated experience. Things like file management and self-organization are part of those things. Much like cleaning your room. If you don’t, who will? When you finally arrive in a production setting, and with a team. How will you know you are actually delivering the goods you intended for the next person in line of that production? Having Blender just outright delete any data when not intended, and even thought of. Is a nuisance for anyone who is actually serious about their own projects and what they’re doing while learning how to construct them. Just consider the fact, that this is a new piece of software they are moving towards from a much more standard one that’s held in high esteem of being considered professional.
Everything about your post in all honesty, just says why the developers don’t take steps with confidence, but instead step in every which direction often questioning everything they do with skepticism because of this communities level of insecurity to accept and deal with change. Rather than to outright encourage it with every design made in mind to allow a user to customize it to their liking.
I’d say, get rid of this fake user auto-delete functionality from Blender, it’s got my vote!
The problem here is as usually extremism. On the one side, deleting all unused data on file save, on the other side, not deleting any data whatsoever on the file save.
Both extremes are bad. Some people have hard time understanding that the correct balance always lays somewhere in the middle.
In this particular case, we need to cherry pick specific datablock types which should not be automatically purged, but it should not be part of them. Meshes should still be auto-purged for example, while materials, textures, node groups and such should not.
Some people just can’t get over the idea that there’s no one size fits all solution. And that unfortunately includes also some developers. We really need to make sure that if the change comes, it’s not swapped for the opposite extremes of people having to manually clean up unused meshes as well. If other 3D software got it right, I don’t understand why blender should not.
This kind of maintenance isn’t hard if you make it formal and expose how it works in the user interface.
Therefore it should be possible to list unbound/orphaned items and show what will happen to them and allow the user to manually purge them, if desired or to assign fake users to them (the fake user term may need changing, because this term shown in many places in the UI is certainly confusing to new comers).
Then you can provide a summary of the number of unbound items scheduled for deletion as a single value per type.
Then you implement default deletion settings for each item type and use that as the standard.
This way, you can fix the original problem for users who don’t care at all and don’t need to visit that user interface, while also catering to users, who care about this.
Finally, it could mean getting rid of the fake user buttons, that currently must be visited per orphaned item.
Yup. Your proposal I think, at least as a new comer, would make the most sense to me.
It gives both fine grained control as to what is purged and per datablock default preferences exposed in the user preferences.
Provide an optional closeout summary as well as a panel in the interface to see pre-purge / protected / orphaned items. From there users could mark specific items that by default would be purged, as items they want to keep. Marking them Non-Purge or Protected or something like that (basically what Fake User does currently)
Potentially remove the fake user button from the UI since those actions can be taken from the centralized panel / closeout summary, or move it to a right click menu under a different name for people who want to use it as it. Or conditionally only show the protection / keep button on datablock types that are set to auto-purge
Change the fake user term everywhere so that it makes more sense for what it actually does. E.G Auto Purge or something like that
As you say, this is the best of both worlds, as it allows for people to tell blender how they want it to deal with their data. And it follows that. Aka there is no unexpected behavior. For those who want to roll as is, they could set it up in their preferences to operate how it is.
It’s also elegant in that it doesn’t require an overhaul of the existing system. Just exposes the systems behavior and allows the user to interact and customize it per their preferences.
I’m going to see if I can mock this up either through design and or through code.
Overall, I think this discussion has been extremely productive. Thanks to everyone who has chimed in so far!!!
Better defaults and exposing “default fake user” settings in preferences would be a good solution, then if someone doesn’t want textures / materials being kept on by default they can disable them and return to old behaviour.
It looks like there is already an orphaned data panel. So that’s great! Heck yeah. So with minor tweaking that could be improved a bit. And then used in an optional (by default on) pre-close routine to show users what data is on the chopping block per their settings.
Just put in the function to when a “User” closes their Blender session. They are confronted with a prompt that will ask them “You have the following unsaved (materials, textures, nodes, animation, composite, scripts, etc.) in your scene. Would you like to save them to your scene? If Yes press OK, to delete press Cancel” button prompt. Simple as that. If they press “Yes” the data of their scene is saved to the file for use on next load. If Cancel, Blender purges all orphaned data and file paths and does what it does best. Imitates amnesia like it can’t remember it ever existed
Ok so the idea behavior outlined above is totally possible!
I worked up a very simple test script just to see what can be manipulated, and it works as a very basic proof of concept.
There’d have to be a lot more work done on it, and the proper preferences exposed in the main preference pane, but it’s totally possible. For instance, the ability to mark certain types of datablocks as protected / unprotected by default, the ability to track whether a user has explicitly overridden the default, and not auto protected those items when it runs next. Currently in its simplistic form, it loops through all the materials, and checks for if they’re unprotected, and protects them, every time a material updated, whether a new material has been created or not, and regardless if the user has explicitly turned it off for that item. So this would for sure want to be optimized, have the flexibility to serve any datablock type, and optionally display a filterable / collapsable summary of items that will be purged on close, so as to give the user a chance to protect those items before they’re deleted.
A couple of interesting things I noticed:
You can straight up delete items from the outliner, as opposed to only being able to unlink them from the object material interface.
You can mark materials (with the handler running) as non-protected from the outliner, and it doesn’t trigger the handler. Whereas you can’t unprotect it from the object material fake user button since it triggers the handler. Hence the need to add a custom property to all types protected to track if a user unprotects it, and therefore not re-protect it every time the handler runs.
I’ll keep working on it and get it working groovy.
What do y’all think?
There’s some really good points around team work and sharing files in there that make a good case for not having a centralized preference of auto protecting data. I’ve outlined my ideas over there in a followup post →
It’s true. leaving things alone and instead implementing a button that deletes items effectively without having to restart the application to make them truly disappear would be a great step towards a more “intuitive” user experience
It seems that the outliner does have an operator that actually deletes data in orphaned mode. I haven’t tested thoroughly yet, but it seems like it can be undone. Check out my proposal over in the developer task that talks about what I think could be a good solution that would have everyone feeling chummy. lol
I’m sorry, I use Blender as an artist myself and am rather unfamiliar with the technical side. so I can’t really understand what’s written in your proposal. thank you for contributing to improving blender ever more, though
That menu entry exists already. Under File > CleanUp > … are six commands to purge unused embeded or included data from the file. Mabye there is more data that is purged when closing the file, as well.
The Amaranth plugin also has a (potentially pretty dangerous) command that saves, closes and reopens the current file, effectively purging it from all unlinked and unused data.
