Page MenuHome

Blender 2.8 viewport bug
Closed, ResolvedPublic

Description

Windows 10 home
AMd HD 5450
All Blender 2.8 versions

Mesh looks triangulated like edges generated from one vertices in edit mode.All version of blender 2.8 has this same problem for me.but the same mesh looks fine on 2.79 version.Even default cube looks triangulated too.sorry for the bad english


Event Timeline

Hi, add an example .blend, please.
It is much easier to test and fix with the original file.

Cheers, mib

Philipp Oeser (lichtwerk) triaged this task as Needs Information from User priority.

Marking as incomplete until we have an example .blend

happens with any file in edit mode, I have the same problem too
for the AMD Radeon HD 7670M
https://www.techpowerup.com/gpudb/380/radeon-hd-7670m

Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Normal.

Most certainly a driver issue, not sure we can do much here? @Clément Foucault (fclem) might know better though.

@noki paike (amonpaike) @padma kumaran (kumaran7) Does it happen when rotating the view around the objects?

@noki paike (amonpaike) @padma kumaran (kumaran7) Does it happen when rotating the view around the objects?

this problem appears in particular with the drivers Non-WHQL-64Bit-NIEG-Radeon-Crimson-16.2.1-Win10-Win8.1-Win7-Feb27 which are also the last legacy drivers that amd has released for this generation of video cards ... in another bug report, a user pointed out that by installing a previous version of the drivers this problem vanishes ... answering your question:
when the view is rotated the segments appear and disappear randomly

It´s also happening on my Radeon HD 6570 with an older version of the driver.

I should add that it works fine on 2.79b (so it should be fixable? After all it's just edge drawing and not some sophisticated rendering pipeline)

I should add that it works fine on 2.79b (so it should be fixable? After all it's just edge drawing and not some sophisticated rendering pipeline)

In fact the edit mode wireframe shader is one of the most complex shader (eevee excluded) and is drawing nothing like 2.79.

I have the exact same problem with a Radeon HD 5770 with drivers up to date.

I have the exact same problem with AMD Radeon HD 7610M.

Can you try the new build and see if it makes any difference for you?

Can you try the new build and see if it makes any difference for you?

blender-2.80-fcc88a6bf04-win64.zip Oct 12 2018 00:35:18
the last build has the same problem.

mmhhh seems not updated wait for tomorrow then. (I just kicked the buildbot it should be ready in a few minutes)

Are you sure the triangulated cube is part of the original bug? You guys might want to click File> Load Factory settings. I remember that the default cube was triangulated by accident on new files, until it was fixed more recently

I'll try the new build ASAP.

@Wo!262 (wo262) This happens on all meshes.

@Clément Foucault (fclem) I just tried blender-2.80-2677e992170-win64.zip Oct 12 2018 18:04:20 and it's still not working.

guys I do not know if this should be considered a definitive or temporary solution to this problem for this generation of AMD gpu, but with this version dll the problem is solved.
Just put this dll in the folder of the executable of blender 2.8


@Clément Foucault (fclem) Interestingily enough, I just realized that a static wireframe is corrupted, but while actively rotating (for example) it works alright.

This behaviour is new.

guys I do not know if this should be considered a definitive or temporary solution to this problem for this generation of AMD gpu, but with this version dll the problem is solved.
Just put this dll in the folder of the executable of blender 2.8

Thank you, DLL fixed the problem but it is not a solution to the problem but a crutch. You think the problem is in the driver, but why the version 2.79 is then working fine?

The problem is clearly in the driver.
It is not happening in 2.79 because we changed the way our wireframes are drawn.

To expose the problem:
This, exhibits no issue.

for (int v = 0; v < 3; ++v) {
	doVertex(v);
}

But doing this (which is EXACTLY the same thing):

doVertex(0);
doVertex(1);
doVertex(2);

result in triangle soup.

We are working with @Germano Cavalcante (mano-wii) (who is also affected by this bug) to try to find a solution but this is really getting old.

@Ruslan (Loner)
the logic in this case would like to launch a petition for AMD to release drivers working well for these gpu, threatening that if they do not fix this bug, the next gpu, since these gpu are old enough .. will be NVIDIA
hehehe

hi @Clément Foucault (fclem) i also found a related bug but on windows 10 with GTX 1050 ti, it's reproducible each time in edit mode ,even if you just transform one face it will switch from solid to wireframes when the mesh is off screen, especially going south and adding operations the 4 directions start to show the same effect...here is a quick demonstration.

Ruslan (Loner) added a comment.EditedOct 14 2018, 10:15 AM

@Ruslan (Loner)
the logic in this case would like to launch a petition for AMD to release drivers working well for these gpu, threatening that if they do not fix this bug, the next gpu, since these gpu are old enough .. will be NVIDIA
hehehe

Agree.

hi @Clément Foucault (fclem) i also found a related bug but on windows 10 with GTX 1050 ti, it's reproducible each time in edit mode ,even if you just transform one face it will switch from solid to wireframes when the mesh is off screen, especially going south and adding operations the 4 directions start to show the same effect...here is a quick demonstration.

This has nothing to do with the driver or this report. Please create another report, I know what's happening here.

I wrote in support of AMD. Pointed out about the problem and asked if they will update the driver. As soon as they answer, I'll add their answer here.

I have some theories, but I'm not sure why the compiler is buggy in this driver.
Here is the solution I have found:

1diff --git a/source/blender/draw/modes/shaders/edit_mesh_overlay_geom_tri.glsl b/source/blender/draw/modes/shaders/edit_mesh_overlay_geom_tri.glsl
2index 61f3e818020..3b7af9108e2 100644
3--- a/source/blender/draw/modes/shaders/edit_mesh_overlay_geom_tri.glsl
4+++ b/source/blender/draw/modes/shaders/edit_mesh_overlay_geom_tri.glsl
5@@ -48,14 +48,22 @@ vec2 proj(vec4 pos)
6 return (0.5 * (pos.xy / pos.w) + 0.5) * viewportSize;
7 }
8
9+#ifdef VERTEX_SELECTION
10+vec3 vertex_color[3];
11+#endif
12+
13+#ifdef VERTEX_FACING
14+float v_facing[3];
15+#endif
16+
17 void doVertex(int v)
18 {
19 #ifdef VERTEX_SELECTION
20- vertexColor = EDIT_MESH_vertex_color(vData[v].x).rgb;
21+ vertexColor = vertex_color[v];
22 #endif
23
24 #ifdef VERTEX_FACING
25- facing = vFacing[v];
26+ facing = v_facing[v];
27 #endif
28 gl_Position = pPos[v];
29
30@@ -65,11 +73,11 @@ void doVertex(int v)
31 void doVertexOfs(int v, vec2 fixvec)
32 {
33 #ifdef VERTEX_SELECTION
34- vertexColor = EDIT_MESH_vertex_color(vData[v].x).rgb;
35+ vertexColor = vertex_color[v];
36 #endif
37
38 #ifdef VERTEX_FACING
39- facing = vFacing[v];
40+ facing = v_facing[v];
41 #endif
42 gl_Position = pPos[v];
43
44@@ -162,6 +170,18 @@ void main()
45 }
46 }
47
48+#ifdef VERTEX_SELECTION
49+ vertex_color[0] = EDIT_MESH_vertex_color(vData[0].x).rgb;
50+ vertex_color[1] = EDIT_MESH_vertex_color(vData[1].x).rgb;
51+ vertex_color[2] = EDIT_MESH_vertex_color(vData[2].x).rgb;
52+#endif
53+
54+#ifdef VERTEX_FACING
55+ v_facing[0] = vFacing[0];
56+ v_facing[1] = vFacing[1];
57+ v_facing[2] = vFacing[2];
58+#endif
59+
60 /* Remember that we are assuming the last vertex
61 * of a triangle is the provoking vertex (decide what flat attribs are). */
62

We still need to benchmark (and do other tests).

@Germano Cavalcante (mano-wii)

I'm not familiar at all with the blender source code, but it appears your fix involves copying the data to a small local buffer in a place where the compiler won't screw up (or by using literals), and then using that buffer everywhere else. Am I right?

Asking because I am curious about it and interested in possibly contributing down the line.

Let me know when it's available for download and I'll try it out.

I'm not familiar at all with the blender source code, but it appears your fix involves copying the data to a small local buffer in a place where the compiler won't screw up (or by using literals), and then using that buffer everywhere else. Am I right?

Nor do I know for sure why it solves. It has something to do with varying alignment + multithread. It's all guess.

(...)
Let me know when it's available for download and I'll try it out.

At the latest, in tomorrow's build ;)

And so it was that the valiant Knights Companions of Adventures, after months and months of mysterious apparitions of an epileptic phantom, managed to find, trick and finally trap and tear down the mysterious monster that hid insidious in the caves now abandoned by Advanced Monster Devices.

At the latest, in tomorrow's build ;)

blender-2.80-55e3c17ccc1-win64.zip - checked.
The problem remained. Only with the help a crutch that proposed noki paike (amonpaike) works. AMD hasn't responded to my update request yet. Maybe Sebastian Ferreyra (Saabi) will work.

@Ruslan (Loner) This is an older build from the 13th.

@Ruslan (Loner) This is an older build from the 13th.

build - blender-2.80-eba1b0487c8-win64
For my part, I confirm that the problem is solved.

blender-2.80.0-git.3f3eae675aa-windows64 is working for me as well.

build - blender-2.80.0-git.a30c9f710a6-windows64

problem solved on HD5770 !