Tag for Blender tasks related to datablocks, library linking, assets, overrides, and related topics
Sat, Feb 16
@Brecht Van Lommel (brecht) - You ask, You get.
Wed, Feb 13
I agree with @William Sitton (william) Reynish (billreynish) , a better user experience would be to manage everything from the asset manager.
Tue, Feb 12
@William Reynish (billreynish) Ton suggested me to read The Humane Interface 12 years ago: super, you got it right away!
Nice Jef Raskin quote.
"A computer shall not harm your work or, through inaction, allow your work to come to harm".
Mon, Feb 11
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.
'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 ;)
Likwise, when deleting any ID, also delete its animdata's Action if not used anywhere else.
Alright, I will wait and see how it works out in practice :)
Remember we are not talking about auto-purging, but manual purging inside the Outliner or Asset Browser.
@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.
Fri, Feb 8
@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).
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..
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.
@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.
Edited task description to add suggestions from @Brecht Van Lommel (brecht), and to reflect work already done on Purge operator.
Thu, Feb 7
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). :)
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:
@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.
Wed, Feb 6
Tue, Feb 5
Yes, the Orphaned Data in the Outliner is ok, but doesn't give very much information about who is using the data where.
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).
Good initiative to take a look at this. Here are my thoughts:
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.
Sat, Feb 2
You can just set the entire armature object to be invisible in in the Outliner using the viewport visibility toggle. No need to go to Armature -> Skeleton -> Layers, and no need to do anything with the mode.
To summarize because this wasn't apparent to me and maybe others:
- keep "Lock objects mode" on, which you might have turned off during weight painting
- toggle armature-visibility through the proxy (Armature -> Skeleton -> Layers)
Ah, didn't think such a coarse measure would be it. Okay, thanks for clarifying.
Ok, this is now the right file
If you set disable the Armature viewport visibility in your lib file, it won't be visible in the main file either.
Ugh, tried Armature layers once more shortly before posting. Can as well comment on that. Armature layer visibility is linked between library and proxy. And hiding it in the library before saving does not sound like a solution anyway
Wed, Jan 30
The assert is sort of harmless here, it simply means that material library is not flagged as 'directly linked' properly, when you duplicate the object (since this is making linked object local, so library used by that one become directly linked). Will check on it, but please do not call this 'a crash', crashing on asserts is not a good idea in Blender, we use them a lot a 'strong warning', not necessarily as deadly error.
@Bastien Montagne (mont29): thx for explanation
@Philipp Oeser (lichtwerk) that assert should for sure never be triggered, but in that case, it is caused by issue with brushes being saved in double or more (from userpref, iirc, @Campbell Barton (campbellbarton) knows the details and fixed the issue some days ago). So in that specific case, it is harmless, just means that the library reading code is only aware of one of the two brushes IDs sharing the same name… Re-saving the library with a recent build will fix that problem.
Tue, Jan 29
Can confirm now.
I tried to simplify the steps to reproduce by adding an instance of the collection in the same file like you suggested. Then blender crashes when I try to render the animation.
Yes, sorry I should have mentioned I linked in the collection.
I have not tried changing the link options. I have instance collections turned on.