Subdivision not displaying correctly in edit mode
Closed, ResolvedPublic
Actions

Description

System Information
Operating system: Linux Mint 19
Graphics card: nVidia GTX 970

Blender Version

Broken: Subdivision modifier not displaying in edit mode while using any other shading method save for material. While in solid, random, and texture, the object is displayed as the actual cage mesh/non-subdivided

Blender 2.8 Hash: 26d5a3625ed

Error as above. Additional info is that in order to get the proper display the adjust edit cage has to be toggled on then off again, but as stated above, this only works while using material shade mode.

Simple cube can be used.

Related Objects

Mentioned Here: rBa49fdbcc674f: Fix building w/o bullet
rB26d5a3625ed8: Texture Paint: fix artifacts when using masks with symmetry.

Event Timeline

Andrew Murrell (andrewjm) created this task.Dec 7 2018, 4:36 PM

I can reproduce this on the old version you are using, however this is not the case with a build from today. So I'm marking this as resolved

This error still exists with the build that I down loaded immediately after your reply.

I should have been more clear. I can not reproduce the error with a build I made for my self that day (with the latest changes). I still can not reproduce this on a build from today (that I again built myself).

Can you try a build from today and see if the issue is still there?
If it still is, then provide the build date and hash.

Now I get a crash when subdividing and then trying to enter edit mode

Terminal Message:
ead prefs: /home/andrew/.config/blender/2.80/config/userpref.blend
found bundled python: /home/andrew/Apps/blender-2.80-a49fdbcc674-linux-glibc224-x86_64/2.80/python
Writing: /tmp/blender.crash.txt
Segmentation fault (core dumped)

Crash Report:

Blender 2.80 (sub 36), Commit date: 2018-12-10 23:13, Hash a49fdbcc674

bpy.ops.object.subdivision_set(level=2, relative=False) # Operator
bpy.ops.object.editmode_toggle() # Operator

backtrace

./blender(BLI_system_backtrace+0x1d) [0x1b87c1d]
./blender() [0x1152f09]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fdb143cbf20]
./blender() [0x173c002]
./blender(DRW_mesh_batch_cache_create_requested+0x258) [0x1744a08]
./blender() [0x1748981]
./blender(DRW_draw_render_loop_ex+0x246) [0x1749ce6]
./blender(view3d_main_region_draw+0x77) [0x122ef17]
./blender(ED_region_do_draw+0x811) [0x144b001]
./blender(wm_draw_update+0x441) [0x1155761]
./blender(WM_main+0x30) [0x1153920]
./blender(main+0x31e) [0x10b95ae]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7fdb143aeb97]
./blender(_start+0x2a) [0x114f9ea]

Ok, the crash I can reproduce. But it is one of those fun crashes that doesn't happen with debug builds!

This is the backtrace I got:

Thread 1 "blender" received signal SIGSEGV, Segmentation fault.
0x00005555565f36b4 in mesh_render_data_create_ex ()
(gdb) bt
#0  0x00005555565f36b4 in mesh_render_data_create_ex ()
#1  0x00005555565fc407 in DRW_mesh_batch_cache_create_requested ()
#2  0x00005555566001f9 in drw_engines_cache_populate ()
#3  0x00005555566015eb in DRW_draw_render_loop_ex ()
#4  0x000055555615c037 in view3d_main_region_draw ()
#5  0x000055555637be49 in ED_region_do_draw ()
#6  0x000055555607f77b in wm_draw_update ()
#7  0x000055555607d930 in WM_main ()
#8  0x0000555556069a8b in main ()

In the debug builds I did manage to trigger some asserts when going into edit mode and toggling edit cage on the subdiv modifier in single color mode:

bmesh_mesh.h:109, BM_face_at_index(), at '(bm->elem_table_dirty & BM_FACE) == 0'

However, the edit cage is still updated correctly for me, so this is a new bug.

Sebastian Parborg (zeddb) merged a task: T59222: Blender 2.8 - Editing objects with modifiers enabled for edit mode crashes blender.Dec 12 2018, 2:04 PM

Sebastian Parborg (zeddb) added a subscriber: Carlo Andreacchio (candreacchio).

Please don't mix multiple bugs into one report. This is absolutely impossible to follow.

Is the original report solved?
The backtrace which goes to mesh_render_data_create_ex() sounds very similar to case discussed in IRC about edge normals overlay enabled. @Clément Foucault (fclem) is looking into this issue.
What's the assert in bmesh have to do with all this? What do you mean by "new bug" ?

Please, one report - one issue, and one issue - one report.

I just commited a fix for this assert. Should be in next build. Don't need to report.

Both bugs in here is solved for me with the latest commit. Sorry, @Sergey Sharybin (sergey) I should take a more hardline stance against adding multiple issues into the same ticket.

In defense of everybody, it was my fault for testing something specific, and felt it was related somehow, thus posting it into the same bug, for I intended on showing that with different geometry the original bug remained, however I had deleted that release and tested a new one. In my coding ignorance this seemed like a regression of some sort. I will post separate issues in separate reports in the future. I apologize for the confusion and greatly appreciate all of the hard work each and every one of you do. I wish I could contribute more, but I am limited to bug reporting. Thanks again, and continued support for making a fantastic product.

Great to hear it's fixed!

But no need to be defensive or anything, there was no an attack ;) Thing is, if related issues are all in one report, sooner or later one will be lost in the comments. And it's simple to miss some crucial bug and close report since some other things were addressed there.

When those issues are submitted as separate reports it's all clear: report is open - issue is still there, report is closed - issue is gone.

Even if the issues turns out to be caused by same root of the problem in the code, it's simple to merge two tasks. Or even define dependency between them.