Page MenuHome

Blender locks up almost instantly when starting to sculpt on a multires object.
Closed, DuplicatePublic

Description

System Information
OS - Windows 10 64 bit; CPU - Third-gen i7; GPU - ATI HD 7xxx; RAM - 24 gigs

Blender Version
Broken: Hash ede7429
Worked: Hash 2d8db0d (May 8)

Short description of error
Sculpting on a multires object will cause Blender to lock up while applying a stroke (when using a very recent build). There's no crash, Blender just freezes indefinitely.

Exact steps for others to reproduce the error
Open the .blend file and start sculpting on the object, Blender will lock up before you even finish the first stroke. The root cause of this may also be causing a bug where it's not possible to open a .blend file containing a multires object (Blender will lock up instead).

.blend

Details

Type
Bug

Event Timeline

Adam Friesen (ace_dragon) updated the task description. (Show Details)
Adam Friesen (ace_dragon) raised the priority of this task from to Needs Triage by Developer.
Adam Friesen (ace_dragon) set Type to Bug.

Cannot reproduce either, most likely related to T48437 (and probably T48422), can you please try to reproduce those too?

Just to place here...

Blender hash a83bc4f fixes the issue with some .blend files being unable to open, but the file I attached still causes Blender to lock up when sculpting.

I have found that the best way to reproduce the lockup would be to have a combination of brush size, mesh density, and zoom level conducive to pushing large numbers of faces on each update (because you won't see it happen with smaller numbers).

As an example. I have found that if you would open the .blend file again and set it to up to have parameters and a view equal to this...

I can tell you with that at least on Windows 10 and with today's buildbot build, doing so much as a single click (with no dragging) in this exact situation will lock Blender up 100 percent of the time.

Yep, but on linux it works without any problem, definitively something wrong with windows and our atomic ops here… will merge the three reports, since they are more than likely the same issue. :)