Flickering Paint Lines in Hanger

[ShaneRoach]

Kerbal 1.3.0.1804, Arch Linux 64 bit,  Steam 
Nvidia GTX 980 with proprietary drivers
No Mods

Paint lines in the hanger bay flicker. I have tried this with anti-aliasing both on and off in both Kerbal and Nvidia settings. 

https://www.dropbox.com/s/hox6rgd84nr48p1/Player.log?dl=0 Player Log FWIW

About 23 seconds into this video

 

Edited June 17, 2017 by ShaneRoach

[DrLicor]

Hey, I've had the same with my flags etc. But the same flicker. 
You can try to open in in OpenGl mode or force it to open it with DX11

 

 

But since you have no mods, I would suggest to just make a backup of your save and to a total reinstall of the game and place the save folder bakcin afterwards. 

[ShaneRoach]

The OPenGL trick did not work. I'll check the rest in due time, but if anyone else has any ideas. In the meantime I have a Dwarf Fortress schedule to keep LOL!

Cheers, and thanks for the try. I will edit this post when I try the DirectX and reinstall, but this IS a fresh install already and I just have no real expectation of Direct X changes helping anything on a Linux box. 

[Kerbal101]

@ShaneRoach Hello sir.

 

Also,

my environment is closer to yours - KDE Neon x64 with opensource radeon (kernels 4.8, 4.10, 4.12 "dri-next").

With proprietary Nvidia driver on Linux (as well as outdated proprietary AMD driver Catalyst), the actual driver piece driving the hardware is loaded via  kernel module - its not part of Linux kernel.
Another part of the driver, a proprietary OpenGL library is also placed into /usr/lib/(cpu architecture)/.

In my case, with open driver - the hardware driver sits in kernel, and Mesa is the opengl library.

 

I also have the issue with these lines, but in different form:

1. When using newer (cutting edge) Mesa 17.x OpenGL library, these lines are not painted over with white "paint", but its as if these lines are transparent, so that the white sphere is seen below.
In addition, the game causes a hard hang  (SysRq+REISUB impossible as USB driver locks up) at some point. With graphically intense mods, this happens much earlier. This is Mesa issue - switching Kernels changes nothing.
The only game which also affected by this is ... Project Zomboid, which is written in Java+OpenGL.

2. If using "stable" Mesa (12.x currently, libradeon1 "hwe" version), the system is 100% stable. These lines are drawn with white paint, but look very "edged", and this is known issue.
Switching kernel (hardware driver) makes no difference - Mesa 12 stable with all release 4.x kernels.

 

Someone even tried proprietary (depricated) catalyst driver, which - while being very crash-prone on "non-standard" Xorg/glibc combinations, still possesses the most complete OpenGL stack compared to Mesa 12. And this driver caused freezes. However, when person switched to open driver (which from the date is Mesa 10?), the problem went away..  Also, the glitches dissapeared if "PPFX edge shaders" were deactivated in the settings. This could also be the source of shader problems.

 

From what I observe, the problem with VAB/SPH is about Unity incorrectly compiling shaders, or issuing incorrect OpenGL calls, or there is problem with DRI3 - to the point that application freezes the kernel.

If the PPFX trick does not help, could I ask you to run this script to gradually limit the Unity features:

and apply these options incrementally:

KSP_nv_preload="on",
KSP_unity_glcore="on",
KSP_unity_glcore="33",
KSP_unity_glthread="on"

In my case disabling DRI3 with Mesa17 did not change anything, but the Mesa 12 driver does not yet understand DRI3 - unlike Mesa 17, - and has no problems.
It can't be excluded that newer Nvidia proprietary driver also started taking advantage of DRI3, which still may have bugs.
 

 

Finally, if this does not help, then from logic standpoint - downgrading the nvidia driver (using previous versions) may resolve and help diagnose the problem. See:
https://devtalk.nvidia.com/default/topic/1008666/linux/-ubuntu-16-04-nvidia-381-showdow-problem-with-kerbal-space-program/

 

I will be most thankful with feedback from your side.

[ShaneRoach]

The closest thing Kerbal seems to have now to the edge shaders setting is "Highlight FX". Toggling it does nothing for this issue on my end. I don't see me rolling back drivers just for Kerbal. I would however like to try your script. I'm going to have to get back to you on that script. though. I just ran up on the notification that I had a response here, and I am a little worn out. Hopefully tomorrow morning I'll be more motivated. 

It would seem a lot of people don't seem to be all that bothered by this bug, but it annoys the bejeezers out of me. LOL

P.S. Is it possible to just add those 4 entries into Steam in series? Or do I need to locate Kerbal in my .steam file and make the bash file to even use those? I ... didn't read the file. Sorry. Like I said, tired. 

Edited June 21, 2017 by ShaneRoach
Afterthought

[Kerbal101]

7 hours ago, ShaneRoach said:

The closest thing Kerbal seems to have now to the edge shaders setting is "Highlight FX". Toggling it does nothing for this issue on my end. I don't see me rolling back drivers just for Kerbal. I would however like to try your script. I'm going to have to get back to you on that script. though. I just ran up on the notification that I had a response here, and I am a little worn out. Hopefully tomorrow morning I'll be more motivated. 

It would seem a lot of people don't seem to be all that bothered by this bug, but it annoys the bejeezers out of me. LOL

P.S. Is it possible to just add those 4 entries into Steam in series? Or do I need to locate Kerbal in my .steam file and make the bash file to even use those? I ... didn't read the file. Sorry. Like I said, tired. 

Just because these shaders are not rendered properly and similar issue happens on Mac, means KSP uses some advanced shader code that either runs incorrectly or is incorrect from OpenGL standard.

Again, these lines are "shaded" incorrectly on:
- Linux open driver (radeon, intel)
- Linux closed driver (catalyst, nvidia)
- MacOSX closed driver

However, they are "shaded" right - yet have edgy borders on:
- (old) Linux open driver (radeon)

 

The root of this issue is exactly either in:
- Unity 5 shaders, or
- DRI portion of Linux userspace OpenGL stack (mechanism that sends draw calls from application - to kernel driver)

 

What its definitely NOT:
- video card problem
- driver problem (part of the driver that is responsible for actually "driving" the card)
 

If the script does not help and you don't want to experiment by changing the driver, then you can also install the mod, which replaces interiors of VAB/SPH and hence also the shader in these lines.

[Dalden]

I'm getting the same bug with flickering textures, the most obvious is the one in the VAB as per the screenshot in the first post, but there are other textures flickering as well, for example the exterior of the Admin building.

I'm using

• Linux Ubuntu 16.04
• NVIDIA GTX1070 Driver version 381.22
• Default settings in nvidia-settings
• KSP 1.3.0.1804 with default settings, no mods.
• Default Video settings in KSP

[Dalden]

On 22/06/2017 at 0:16 AM, Kerbal101 said:

and apply these options incrementally:

KSP_nv_preload="on",
KSP_unity_glcore="on",
KSP_unity_glcore="33",
KSP_unity_glthread="on"

I forgot to add, I did try these options incrementally with the KSP_launcher.sh script, but they did not make a difference.

[Kerbal101]

@Dalden This also happens only in 1st-level VAB and SPH, in career for you?

For me, it does not happen in 3rd level SPH/VAB, which is when doing sandbox, or when unlocking them in career.

[Dalden]

11 hours ago, Kerbal101 said:

@Dalden This also happens only in 1st-level VAB and SPH, in career for you?

For me, it does not happen in 3rd level SPH/VAB, which is when doing sandbox, or when unlocking them in career.

@Kerbal101 That is correct. I just tested with a new sandbox game and there is no flickering in the VAB.

There is still lots of flicker on the some of the buildings and flags: