Wed, Dec 12
Mon, Dec 10
I totally agree with this. I saw many users losing their work since blender does not automatically pack or save generated images inside Blender.
Blender's Automatically Pack Into .blend option is super cool, but it should also apply to generated images as well, not only external images.
Sun, Dec 9
Fri, Dec 7
Thu, Dec 6
Wed, Dec 5
Yes, you are correct. I guess the previous CL that I thought fixed things just moved the problem around.
I'll continue to look into this.
Seems like it is actually working behind the scenes (I am getting to correct [rotated] result on the mesh when actually sculpting strokes).
But the UI isnt updating the texture in the brush circle correctly.
I also noticed, that if the brush size is much smaller, then the issue disappears, or even with larger brush the lag is not so bad. the worst lag is with medium size brush..
Doesn't working for the - 2.80, 1fa527bfa3a, 2018-12-05
I'm really sorry to say that after downloading the blender-2.80-baf599610a4-win64 commit and testing,
it crashes again! Just like before. Just a simple cube with bevel modifier, and using the grab brush in
Tue, Dec 4
Cannot reproduce here (mesh showing fine in low resolution while orbiting..., linux, 970m)
@Daniel Cañizares (dacanizares) no idea, sorry.
Mon, Dec 3
@Caetano (Caetano) Thanks! Any idea if this is going to be solved for 2.8?
Yes, this seems to have been fixed by commit rB18f0618677 (found by bisecting commits). I'll close this bug.
I downloaded the latest build of Blender 2.8 and it doesn't crash anymore when doing the exact thing I tried before.
Neither will switching brushes.
I don't know if this it's related with this kind of errors: https://imgur.com/a/3g9IuMe
Sun, Dec 2
same as T58005
Sat, Dec 1
Fri, Nov 30
Working here as well, closing then
It's seems, that's in latest build of Blender (version: 2.80 (sub 35), branch: blender2.8, commit date: 2018-11-30 00:46, hash: 4c31bed6b46) this issue is fixed.
Somehow the memory allocator data structures got corrupted so that it returned the same value for both the edge pool and the loop pool allocations (!).
I'll have to did deeper to understand which code is doing the corrupting. I tried Valgrind, but no luck.
It was getting the evaluated mesh from the original instance, which isn't really supposed to happen.
The problem is that the BKE_mesh_to_bmesh_ex() appears not to have created a bm->epool with the BLI_MEMPOOL_ALLOW_ITER flag set. I'll dig into why...
Hitting various asserts each time trying... (added file to the task description for convenience)
@Sergey Sharybin (sergey) Am gonna need your lights here… Backtrace from ASAN clearly shows that second 'stroke start' call gets same evaluated mesh (from object) as first one, even though we got through EditMode in between, which invalidated/replaced all data inside of the orig mesh (ob->data one).
Sorry, but I spoke too soon. It still crashes with other objects (maybe default cube is not complex enough). It still crashes with my own project, or monkey head mesh.
Have attached blend file for referance.
- with "Face selection masking" enabled go to edit mode select few faces
- go back to paint mode, and do couple of strokes
- go back to edit mode and select other few faces
- go back to paint mode, and do couple of strokes and it will crash
It always crashes on the second time.
Issue was resolved with the latest build. Thanks!