2.8x, unreliable GL_LINE_SMOOTH / GL_POLYGON_SMOOTH behavior
Open, ConfirmedPublic

Description

For some graphics cards in 2.8x (more information needed), smoothing is ignored. This task is to gather more information and see if it can be resolved.

See: T54723#548752 and replies.


Edit, it seems some graphics cards simply ignore the smooth setting.

Details

Type
Design

Can confirm anti-alias works fine (and has been since the beginning) in the following setup:

OS: Ubuntu 17.10
Graphics Card: Nvidia GTX 1050
Resolution: 2560x1440
Blender UI Line Width: Auto (picks "Thin")

Lapineige added a subscriber: Lapineige.EditedFri, Nov 2, 10:02 AM

It works fine on my setup too.
OS: Ubuntu 18.10
Graphics Card: Nvidia GTX 880m (Nvidia Drivers used)
Resolution: 1920*1080 (17" screen, not HDPi)
Blender UI Line Width: Auto (picks "Thin")

@Campbell Barton (campbellbarton) , this is a misuse of core profile from Blender side. Not sure where exactly this gizmo is being drawn, but from quick grep in the source shows two common mistakes:

  • glLineWidth() with values greater that 1.0. As per specification this INVALID_VALUE.
  • Smooth lines shouldn't be used nowadays either. I cant' find exact spec entry for them, but Khronos lists this as deprecated/removed in the "Common Mistakes" section. But even if it's still part of the spec, the rest of the intenet agrees that quality of smooth lines is rather poor.

I am a strong believer in theory that in 2.8 we should not use deprecated/known-to-behave-bad OpenGL features. With Core profile we've got flexibility of programmable render pipeline, where we can implement smooth line which will be guaranteed to work the way we want on all the hardware.

P.S. Maybe @Clément Foucault (fclem) can drop his knowledge here as well.

glLineWidth() with values greater that 1.0. As per specification this INVALID_VALUE.

Well this is partially true. The values supported are implementation dependent.

Smooth lines shouldn't be used nowadays either. I cant' find exact spec entry for them, but Khronos lists this as deprecated/removed in the "Common Mistakes" section. But even if it's still part of the spec, the rest of the intenet agrees that quality of smooth lines is rather poor.

I was the one who added line smoothing to gizmos because the aliasing caused by wide lines was terrible. So it's better than nothing.

Correctly implementing smooth wide lines needs to have a dedicated shader for it that just mimics the behavior of old GL_LINE_SMOOTH. This shouldn't be too hard but I don't know how feasible it is for 2.80.

As for GL_POLYGON_SMOOTH this is even more tricky. Since it's mostly for UI stuff, I would suggest to just draw alpha blended shapes with manual added geometry on the contours of the shape and just make the outer ring alpha = 0.0 so that vertex color interpolation make some kind of smoothing.

If it is large points that you want to draw (larger than max gl point size), we can make a shader variation that draws a AA point and you just have to submit a quad.

Could we have a general solution for this?

We want add-on authors to be able to make their own gizmos, so if they need to be aware of special shader internals - it could make the API hard to use (maybe this can be hidden from the developer?).

Possible alternatives...

  • Render all gizmos to over-sampled off-screen buffer (advantage of not having artifacts - especially regarding GL_POLYGON_SMOOTH when alpha < 1.0), disadvantage of having to use multi-sample buffer which needs special handling (perhaps this isn't practical if we want to occlude gizmos by other elements in the scene).
  • Don't use GL_LINE_SMOOTH / GL_POLYGON_SMOOTH at all.

    Occasions where we want smoothing have to be handled by each gizmo's drawing code (which can include specialized shader for eg).

    We'll try make them look OK without smoothing (transform looks OK IMHO)... if it's important to do some AA tricks, each gizmo's drawing code can handle that it's self (with policy of not using GL_*_SMOOTH).
Campbell Barton (campbellbarton) triaged this task as Confirmed priority.Wed, Nov 7, 3:12 AM
Campbell Barton (campbellbarton) changed Type from Bug to Design.