Regression: Switching to edit/sculpt mode loads Asset Libraries into memory #115372
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
11 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#115372
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Blender Version
Broken: version: 4.0.0 and 4.0.2 Release Candidate
Worked: version: 3.6.2
Short description of error
When leaving object mode from the default cube to edit/sculp, it seems that the asset libraries are loaded into memory
Exact steps for others to reproduce the error
Start with default settings
Add an asset path
Enter edit mode with the default cube
Memory seems to loads every library in the asset path
Example with 4.0.2 (Factory Settings) and 3.6.2
Hi, thanks for the report. Can confirm the increase in memory usage.
After going into edit/sculp mode all Asset Libraries are loaded into memoryto Regression: Switching to edit/sculpt mode loads Asset Libraries into memorySome change between
86a0d0015ac7 - 690a3ddf7eaacaused this, bisecting.git bisect points to
1a7527b1df@HooglyBoogly ^
Thanks for the report, this isn't really a bug though. The asset libraries need to be indexed for node tools. I'm sure that could be more efficient, but I didn't write that code so I'm not sure where the places for improvement are.
In connection with the asset indexing, adjusting last operation from a node tool in library reloads the assets every update.
Well I'm glad the issue has been identified!
I don't see why it needs to be the whole asset library though. It makes more sense to choose specific library folders to include for node tools. It's just crazy for all my kitbash kits and photoscans to be constantly getting indexed when most of my nodes are in a handful of much smaller directories.
I can confirm, it’s a asset browser problem. Loading the libraries is not the problem, the problem with the editing mode
starts when i have to many and to large libraries linked.
I can confirm that, as soon as i start linking libraries the cpu usage in editing mode is going up. 1_4 small libraries are OK, but as soon as i link 1 large library the cpu is at 100% / freeze and i have to shut blender down manually.
Agreed. But as far as I know, Blender can't know where the node tool assets are until everything is indexed. I think there must be some way to improve this situation, but I don't know much about the asset indexing system.
I'm very confused as to why it would need to continually index. Why wouldn't it just do it once at startup and on a manual refresh? More a hypothetical question screamed toward the sky than one expecting an answer. 😩
Ah, I'm not sure. That does sound problematic, and more like a bug. I think I misunderstood the description a bit.
This problem persists in "blender-4.0.2-stable+v40.9be62e85b727-windows.amd64-release" just tested.
This problem persists in "blender-4.0.3-candidate+v40.c40f63bb98b9-windows.amd64-release" just tested.
@Squigglyman hi, thanks for the testing. We're aware that this hasn't been fixed/improved yet.
Gerstmann Bradley referenced this issue2023-12-18 23:22:21 +01:00
Assets: Don't load previews when fetching asset list for menus might solve this. At least it should avoid quite some overhead. Test builds are available there, could somebody try them? @HooglyBoogly could you also test this to confirm all assets show up as before?
Let me clear things up a bit here:
There are various improvements I'd like to do, e.g. see Asset System & UI: Improve memory management for assets and previews. I find that quite important but lack the time to work on it currently.
Just tested with the latest build : blender-4.0.3-candidate+v40.88559c00cd36-windows.amd64-release
Still get 100% CPU usage when in edit mode. Notably when adjusting the last edit via the F9 menu brings Blender to its knees. The asset browser is not open.
blender-4.1.0-alpha+main-PR116987.393b7470845f-windows.amd64-release
The change alleviates the memory load of libraries and also helps with addons based on materials/assets. The one related problem that still persists is with node tools from external assets, using the "Adjust last operation panel" keeps reloading assets with every UI update (Still works a lot better since it only reloads a part of the assets).
(Video illustrating the problem in previous version)
This also causes performance problems on undo/redo, reported as #115091.
From what I can see node-tools are expanding top-level menus into the header which is refreshes assets on each redraw while dragging the slider.
This is a stack-trace from a debug build when Blender was hanging while dragging the bevel slider:
https://projects.blender.org/attachments/5db30737-09bf-4599-8ec4-1ae948f06773
This build doesn't contain the suggested fix, could you test a build from here? https://builder.blender.org/download/patch/PR116987/
This is a known issue I'm afraid, it happens in object mode too for example. And it's not a recent regression. Could you confirm this is the same behavior you see happening in older versions too (e.g. when using Adjust Last Operation in object mode).
The file browser backend (which the asset system currently uses still) is overly aggressive with clearing previews, and changing that is tricky. A better system to handle previews is needed, like proposed in #109234.
Looking at the report and stack trace, this should be solved with #116987. Can you confirm this (builds in the PR)?
As far as I can tell its the same behavior in 4.0.2 and the 4.1 fix. If the asset browser is visible in object mode then the previews will be refreshes every time a value is changed in the redo panel.
Strangely I don't have the redo panel problem with the libraries in edit mode (4.0.2) and on the other hand the redo panel with node tools seems more aggressive since it reloads assets without even changing values.
Confirmed #116987 resolves #115091, thanks!
That’s expected, since edit mode has its own undo system and doesn’t need to trigger the kind of refresh that the causes previews to be cleared. Not sure what node tools do different in edit mode but I’m not surprised it behaves different.
In Blender 4.0.2, entering edit mode hangs Blender. Often resulting in a (Not Responding) application crash.
RTX 3070, Intel Core I9, 32gb of RAM, Windows 11. This is a problem that has recently started occurring despite no updates to my addons.
Please test with a daily build and report a separate issue if it still occurs.
I don’t think this fix is in the 4.0.2 release, that one was released in December already. And unfortunately there won’t be a 4.0.3 release.
I hope the issue is not present in the 4.1 release then, or some of us will be stuck.
@phoenixart @DeGrey hi, you can try 4.1 buildbot build: https://builder.blender.org/download/daily/
If problem persists, core devs will fix them prior to actual release.
The latest 4.1 build has been behaving the last few hours of working. Going in and out of edit mode no longer hangs the system.
I can't use 4.1 just yet, I believe several add-ons will not work properly (for instance due to the new auto-smooth system), but it's good to hear that the issue appears to be gone.
Nice that there's a fix, but what good is it if it's only available in a still alpha Blender 4.1? It would be a lot more helpful if it were made available in a more stable version where content creators could actually use it with some sense of confidence it won't cause problems.
This forces me (and I'm sure I'm not the only one) to stick with v3.6.8 until either 4.0.2 is updated with the fix or 4.1 is officially released.
I'm in the same position. I installed v4 and the updates with the idea of leaving 3.6 behind, but v4 it's unusable for me.
Also, I'm confused as to why there won't be a 4.0.3, especially if there's a fix. If I'm not mistaken, 4.1 will be released in March, and I don't think all the external add-ons will be ready right away.
It seems we're stuck with 3.6 for a little longer.
Agreed. 4.1 Alpha is not a viable solution for production work at this point. It fixes the "edit mode" issue but introduces new ones that make it unworkable at least for my workflow. (Inability to set keyframes with the keyboard shortcut in pose mode being one hurdle.)
I'm bouncing back and forth between 4.0 and 4.1. Doing work in one that is broken in the other. At this stage, the most reliable option seems to be reverting back to the 3.6 version.
This is the first time I've felt that the current release version of Blender is not stable enough for production. Normally I would update with confidence and just keep working away. Version 4 has caused me to feel uncertain about doing that again in the future.
Not complaining. Blender is free and supported by awesome devs and contributors. Having such a massive usability issue in a "stable" version is really a bummer though.
Hi, 4.0 is not a LTS version so it won't be maintained any further. Also, 4.1 release is scheduled in march (beta version in few weeks): https://projects.blender.org/blender/blender/milestone/18
Yes, you're right. I'm ok with sticking to 3.6.8 for now, just didn't understand why not provide the fix being that 4.0.2 is the official release, yet it has a pretty mayor issue with it. But I get it. Guess people that are affected will just need to wait for v4.1 to go beta or RC.