Cannot reproduce. Which renderer is this?

Which renderer is this?

How I could detect which?

glxinfo

Renderer: Gallium 0.4 on ATI RS600

BTW, I has no such glitches with solid edges (style s005-#def-solid-edge) with SolveSpace 3.0~83a0a517

Sems like in latest SolveSpace faces partially overlap solid edges.

Think, need render solid edges as top layer (on top of all faces).

ATI RS600 is not a supported video card because it does not provide OpenGL 3.0. Glitches are expected. I will reopen this if it can be reproduced on an OpenGL 3 capable card.

Glitches are expected

But I has NO such glitches with SolveSpace 3.0~83a0a517, so solid edges glitches appeared after #377 fix.

Fixing a bug that hits everyone is more important than fixing a glitch that hits exactly one person with a 13 year old video card that doesn't support OpenGL 3. As I've told you before, SolveSpace should not actually run on it at all. The fact that it does start is a bug (in GTK or Mesa).

I can confirm this bug also happens for me:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 950M/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.77
OpenGL core profile shading language version string: 4.60 NVIDIA

I believe Symban9 is correct in that it is caused by z-fighting between the lines and the invisible faces that are drawn to hide the back-edges. The usual solution to this problem is to use glPolygonOffset(1,1) for drawing the edges. This command has been removed to fix #377, which explains why this bug was introduced by that fix.

Thanks! I will look into it. There is our own implementation of Z-offset that shouldn't cause this, let me write a patch.

Correction: glPolygonOffset(1,1) should be applied to the faces, not the edges. However, that is exactly what caused #377. I cannot think of an easy fix that solves both this bug and #377.

Hm, this should already be done here: https://github.com/solvespace/solvespace/blob/master/src/groupmesh.cpp#L574-L576.

But this ends up manipulating ssglDepthRange, which would be a different transformation from what glPolygonOffset does.

more important than fixing a glitch that hits exactly one person with a 13 year old video card that doesn't support OpenGL 3.

Please, always check my bug reports deeply. All bugs should be fixed, if possible.

That implementation is equivalent to using glPolygonOffset(0,-1) for the line segments, which does not work correctly for polygons that aren't parallel to the viewing plane. See https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glPolygonOffset.xhtml.

The solution I've come up with, is to apply glPolygonOffset(1,1) only for polygons and only when outlines or edges are drawn (which would then hide the back-faces bleeding through).

P.S. the lines are also drawn with glitches when I change the outside to be solid.

The solution I've come up with, is to apply glPolygonOffset(1,1) only for polygons and only when outlines or edges are drawn (which would then hide the back-faces bleeding through).

@bcmpinc Do you think you can implement this?

That shouldn't be problem, though I'm not sure that it will entirely fix this issue nor introduce other rendering bugs. I had already tried to implement a fix, but it didn't work, though I don't remember why.

I've come up with the following patch, but as you can see in the image below, the offset is not high enough to render properly on cylinders, yet it already causes the red back faces to bleed through.

diff --git a/src/render/rendergl3.cpp b/src/render/rendergl3.cpp
index 167ce03..7c786bf 100644
--- a/src/render/rendergl3.cpp
+++ b/src/render/rendergl3.cpp
@@ -886,11 +886,18 @@ public:
     }
 
     void Draw(OpenGl3Renderer *renderer) override {
+        // A hackish way to partially solve issues #377 and #379 simultaneously.
+        if (SS.GW.showEdges || SS.GW.showOutlines || SS.GW.showMesh) {
+            glEnable(GL_POLYGON_OFFSET_FILL);
+            // glPolygonOffset(a,b) offsets zdepth by a*fwidth + b
+            glPolygonOffset(SS.GW.showOutlines ? 2.0 : 1.0, 1.0);
+        }
         glEnable(GL_CULL_FACE);
         if(hasFillBack)
             DrawFace(renderer, GL_BACK, fillBack);
         DrawFace(renderer, GL_FRONT, fillFront);
         glDisable(GL_CULL_FACE);
+        glDisable(GL_POLYGON_OFFSET_FILL);
     }
 
     void Remove(OpenGl3Renderer *renderer) override {

@bcmpinc Yeah, I've had a few attempts to fix it with pretty much the same result as yours. Seems like an annoying problem.

Yeah. There's some other solutions I can think of, though none of them that I really like to pick up. For example:

1. Disable alpha based anti-aliasing and enable multi-sampling. This is still not a perfect solution though, and I don't like the increased performance cost.
2. Change the OpenGL shaders, such that the edges are drawn by the fragment shader as part of the triangles (I've done something like this in the past). This allows us to do without the zdepth offset trickery. However, considering we're working at edges, this might still give weird results as it requires fwidth, which is based on dfdx and dfdy.
3. Make the back faces render after drawing the outlines, to prevent the red bleeding through the alpha-based anti-aliasing. This unfortunately requires changes outside of the renderer and does not fix the line next to the cylinder.

2. Will not work since boundary edges (outline) can have different width (e.g 3 or 10 pix instead of 1).