ucupumar
High RAM usage followed by OOM crashes baking geonodes curve to mesh hair as "other object" layer
UCUPAINT Version
2.2.0
Describe The Bug
I'm using Ucupaint 2.2.0 on Blender 4.4.0 on a Linux system. It's a pretty neat addon, but I'm having issues when baking.
I have several curves going through a geometry nodes that turns them into meshes so they can be baked onto hair cards. I'm using a switch to only go through curve to mesh when rendering, keeping them as curves on the viewport for good performance.
Before baking anything RAM usage stays around 2 Gb. Once I bake a layer, and it can be a simple emission or normal or whatever, RAM usage spikes to 10 Gb, sometimes 20 Gb. Next time I try to bake a layer there's a high probability blender will hang for several minutes then crash. Often the UDIM checking message at the terminal will herald the crash, it'll spike from 1.29ms to 60ms, 200ms or higher.
I can tell it's likely not even trying to bake because the PC remains absolutely silent when it fails to bake then crashes.
It feels like the Blender+Ucupaint combo is not letting go from the render version of the mesh once baking, except I don't have that issue using vanilla baking, RAM doesn't even spike on the GUI, it's smooth and quick.
Applying the geonodes only makes performance worse, and it'll crash anyway. Because Blender doesn't have AA sometimes I'm forced to bake at 2x, 4x the target resolution because it's hair thus very thin silhouettes that look awful without AA, which further complicates everything.
The crashes tend to be segmentation faults: That's my system killing Blender to prevent a system-wide OOM freeze, so no logs. I have 24 Gb RAM + 30 Gb swap, and in this situation Blender will happily soak it up until killed. I'm using CPU baking. Disabling other third party addons didn't help. The only thing that works is using the clunkier vanilla baker.
To Reproduce
- Enable System Memory, Video Memory at Preferences > Interface > Status Bar and open your OS statistics app to keep an eye on used RAM and swap or virtual memory.
- Create a hair curves object with at least 30 strands and place it over a plane object. Create materials for both.
- Add a curve to mesh geonode modifier to the hair and keep it disabled for the viewport. No need to go crazy with the profile curve, you can use a quadrilateral, filleted once if you're feeling fancy, but set the source curves resolution high enough they could be conceivable used as high quality sources for hair cards.
- Select hair, plane, take a look at your ram usage, create the ucu node and bake an "Other Objects Emission" layer.
- Keep track of the RAM usage as you bake more Other Objects layers.
In the case of a crash or when relevant include the logs
No response
Can you upload the sample file?
I'm trying to put a file together that's light enough but still visibly triggers the issue.
Short version: I'm working on a file that's isn't huge but still lingers on RAM for as long as in my real case (it only lasts 15s or less in the sample file), and also reporting it on Blender's dev tracker. The core issue cascading into OOM crashes is a Blender issue, not ucupaint issue.
Didn't achieve it yet, but learned a lot about the problem.
--
- It doesn't seem specific to curves or geometry nodes, they just made it easy to create very heavy meshes that'll trigger the issue.
- A Blender bug or lack of optimization seems behind the initial RAM spike. It turns out Blender is computing all render-enabled objects when baking textures. All objects visible to rendering and their modifiers, everything that has no connection to the source and target meshes and materials being baked will get processed independently of the bake type being able to be affected by them or not. And it seems an old bug, I found a 7 year old report about subsurf that seems to be the same issue, but they thought it was about subsurf only and it remains unsolved. 2.1. The quickest way to work around that is to stuff everything you're not baking into a collection and disable the collection itself. The data will still take up RAM, but it'll not (noticeably at least) affect baking.
Which brings us to the vanilla and ucupaint divergence I'm trying to reproduce in a simpler file. If you do have a mesh related to the baking meshes inside the disabled collection Blender will solve that one mesh then release the RAM. Ucupaint also solves it but is slower to release the RAM. Sometimes that higher RAM window lasts long enough you try to rebake and will crash due lack of RAM.
Example: A source hairs curves object (hidden inside disabled collection) you're turning into a mesh using geonodes on a different object (source bake object) you then bake to the target bake object. The curves will get processed, consuming RAM as this happens, which is correct, but they might linger a little longer in memory if you use ucu.