Graphical glitch on some two-sided parts

[penduin]

KSP 1.0 and 1.0.1, Linux 64-bit non-Steam

The graphics glitch out when rendering some of the new parts:

- Airstream Protective Shell (all sizes)

- Service Bay (both sizes)

It looks as though the meshes have incorrect normals or are not manifold. The error happens inconsistently per frame, leading to an odd shimmering effect. You can see such an effect here:

https://youtu.be/P01UvBOix3w?t=30m46s

(That's not me, and it's an older KSP with mods, but the glitched-mesh effect on the clouds looks very similar.)

The glitched rendering does not happen on the mouseover thumbnail, only in the assembly area (attached or not).

I run 64-bit Slackware 14.1 on an AMD64 with graphics on a Radeon HD 5450 using the stock open-source radeon driver.

hardinfo output:

http://penduin.net/media/hardinfo_report.html

EDIT: This also happens with the fairings that get added when stacking a part below a heat shield.

Edited May 1, 2015 by penduin
additional detail

[penduin]

Since these are all parts with both inside and outside surfaces, I wonder if the geometries are overlapping themselves. Rendering the "back" of a surface would appear as transparent, and the glitched area which is visible/invisible could be floating point precision rounding where an inside surface is in the same location as an outside one.

I've seen this in other games too, where the meshes had duplicated vertices or other problems. Unity and my GL setup don't correct for such data, but I'm guessing most newer/better video cards do. All other parts, including radial docking ports and other open-able bays, render correctly, so there seems to be something fishy going on specifically with these models.

Unfortunately, that includes the custom-editable fairings, which are some of the most awesome new parts! :^) I'm guessing those will be trickier to fix up than the static service bays...

[Claw]

What it actually looks like to me is that there are two copies overlaid on top of each other. There are some instances where 2x or higher symmetry modes will overlay two parts on the same node, instead of a single part.

Can you confirm if you had symmetry 2x on or not? (it's on in the pic)

Cheers,

~Claw

[Orion2020]

I confirm this glitch to appear in 1.0.2 on my Fedora 20 with radeon graphics drivers. 2x symmetry has nothing to do with that: it was disabled and aside of that the physics worked normally (i. e. the ship would explode if two parts were at the same place, but it didn't).

[penduin]

Thanks for the tip, Claw, but Orion2020 is right, symmetry or overlapping parts aren't the culprit. (Good catch seeing I had symmetry on in the screenshot, but I've tried again making sure it was off and the effect is the same.)

This happens with some specific new-in-1.0 parts, and seems to be related to their mesh and/or texture data. My guess is that something _is_ overlapping to cause the bad rendering, but down at the normal or vertex level, not my part placement.

I've seen some other threads on what looks to be this same issue. Some have had success by switching to the binary blob driver, but I'd love an actual fix instead. (My card's good enough to display every other model in the game without problems.) I'd rather run with a few glitchy-looking parts than use the non-open driver.

[sal_vager]

This has been reported several times now, AMD cards are having trouble with these and a few other parts, I don't know how to fix it yet.

This may be too low level to fix, or a fault in the driver as the open driver just does not have all the features of the proprietary driver.

[penduin]

Some other drivers/cards don't exhibit this problem, but I still would bet there's something wrong (or at least different) with the specific models in question. Could be as simple as duplicate vertices (Blender has easy tools for removing those; I assume any other modeling software would too) or something a little more involved with normals or alignment, but I think it's more to do with that data than with any KSP code. The fact that many diver/card combinations render that data without artifacts doesn't mean there's not still something strange about it.

As I say, it's not a big deal - I can live with some flickering parts, but it's obnoxious since every other visual element of the game displays flawlessly. It's not as though these parts are meant to have some wild new shader or fancy effects. (Or am I wrong about that?)

[kolAflash]

Having this issue too. Everyone, let's report some system details so the Squad support can start fixing this.

By the way:

Anyone from Squad reading this?

Is there already a bug report here?

http://bugs.kerbalspaceprogram.com

If further information is needed, please tell me!

I'm experiencing the bug on the following system, running "Launcher.x86_64".

OS: Linux

# uname -a

Linux Trada 3.16.7-24-desktop #1 SMP PREEMPT Mon Aug 3 14:37:06 UTC 2015 (ec183cc) x86_64 x86_64 x86_64 GNU/Linux

# cat /etc/issue

Welcome to openSUSE 13.2 "Harlequin" - Kernel \r (\l).

CPU:

# grep 'model name' /proc/cpuinfo | uniq -c

4 model name : AMD Phenom II X4 955 Processor

GPU:

# /sbin/lspci | grep VGA

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]

GPU drivers:

# lsmod | grep drm

drm_kms_helper 65670 1 radeon

drm 335594 7 ttm,drm_kms_helper,radeon

# glxinfo | grep -E 'direct rendering|OpenGL version string'

direct rendering: Yes

OpenGL version string: 3.0 Mesa 10.3.7

RAM:

# free -m

total used free shared buffers cached

Mem: 12037 9530 2507 52 429 6214

-/+ buffers/cache: 2886 9151

Swap: 10239 20 10219

[sal_vager]

Hi kolAflash, do you also see this effect with the proprietary driver?

[kolAflash]

I don't use the proprietary driver and I really would like not to install it. Every time I had to use the proprietary driver since ever, it broke my X-Server configuration in some way.

But I tried to use the newest Mesa3D library. Sadly it didn't helped.

On the other hand, on my notebook (running same OS + software) everything is fine. But the notebook has an Intel GPU instead of a Radeon GPU.

For details, please see this bug report:

http://bugs.kerbalspaceprogram.com/issues/4787#note-2

P.S.

If it might help you to find the bug with the Opensource Radeon driver, I might give the proprietary driver a try and tell you if it shows the same bug. But I don't like to use the proprietary driver normally. Because usually the Opensource driver does a really fine job on my system.

Edited September 14, 2015 by kolAflash

[sal_vager]

Hi again KolAflash, can you please upload your KSP.log and Player.log to a file share site and post them here.

[kolAflash]

Used a fresh KSP installation from Steam.

start command:

env LC_ALL=C LANG=C vblank_mode=0 force_s3tc_enable=true ./Launcher.x86_64

Build a Mk1-2 Command Pod with a small tank and 2,5m fairings,

encapsulating the tank. Put the vehicle on the launch pad.

Bug appeared in the building facility and on the launch pad.

KSP.log

http://pastebin.ca/3165019

~/.config/unity3d/Squad/Kerbal Space Program/Player.log

http://pastebin.ca/3165021

[sal_vager]

Does this still happen when you run the KSP.x86_64 without additional commands?

[kolAflash]

I already tried starting Kerbal like this, but it didn't helped:

env LC_ALL=C LANG=C vblank_mode=0 force_s3tc_enable=true ./Launcher.x86_64

env LC_ALL=C LANG=C vblank_mode=1 force_s3tc_enable=false ./Launcher.x86_64

env LC_ALL=C LANG=C ./Launcher.x86_64

./Launcher.x86_64

I also tried setting the graphics (in the launcher) to maximum and to minimum.

And I tried using KSP.x86 (my Launcher usually starts KSP.x86_64).

And I tried enabling and disabling the 3D acceleration of my window manager (KDE - KWin).

Nevertheless, I think we have to search for the problem in 2 places:

1. The graphics driver. At least about me I can say, that I have 2 computers with EXACTLY the same Linux installation. openSUSE 13.2, KDE, all updates/patches installed. But the bug only appears on the one with and AMD CPU and Radeon GPU. On the notebook with the Intel i7 CPU and GPU, everything is fine!

2. The developers should have a look about what they did different when programming those "modern" parts like "Airstream Protective Shell". There must have been some difference in the development process (different tools used, different kind of texture format, ...) which causes those parts to graphically fail but all other parts to be displayed correctly.

Regarding this post of you:

http://forum.kerbalspaceprogram.com/threads/117130-Service-bays-and-fairings-z-fighting?p=2202418&viewfull=1#post2202418

Installing Mate would be pretty much effort. I got GNOME 3 installed and could use it for testing. But I really don't think that this would make a difference. Also, because my Intel-GPU notebook is using KDE and KWin too.

[sal_vager]

Well it's pretty visibly clear that the fairings have an inner and an outer texture, the issue is that the driver is trying to draw them both which should not occur because usually the rear of a polygon is not rendered, the internal texture should not be drawn unless the camera is inside the fairing.

But because we can see it with some drivers and hardware suggests that the polygons of the model are being drawn incorrectly, so the texture is applied to the side facing the camera at all times, and because there is no appreciable gap in the meshes (no wall thickness) we see a Z order rendering conflict.

Can you move your view inside the fairing and get a screenshot, I think it will be untextured.

[kolAflash]

Here's a screenshot from inside a fairing, while standing on the launch-pad. It has textures, but it also has the bug.

http://postimg.org/image/4hm3z9irl/

http://postimg.org/image/4hm3z9irl/91967292/

Regarding this other post of you (sal_vager).

http://forum.kerbalspaceprogram.com/threads/117130-Service-bays-and-fairings-z-fighting?p=2202294&viewfull=1#post2202294

I tried the new graphics drivers from:

http://download.opensuse.org/repositories/home:/pontostroy:/X11/openSUSE_13.2/

(snapshot)

https://web.archive.org/web/20150919024231/http://download.opensuse.org/repositories/home:/pontostroy:/X11/openSUSE_13.2/x86_64/

Replaced all installed system packages by the ones from that repo. Including:

Mesa-11.1~git20150917-1.1.x86_64.rpm

libX11-6-1.6.3-40.1.x86_64.rpm

xf86-video-ati-7.99.99~git20150822-1.2.x86_64.rpm

KSP.log

http://pastebin.ca/3165739

~/.config/unity3d/Squad/Kerbal Space Program/Player.log

http://pastebin.ca/3165740

Sadly it didn't helped at all :-/

Regarding this post of you.

http://forum.kerbalspaceprogram.com/threads/117130-Service-bays-and-fairings-z-fighting?p=2202418&viewfull=1#post2202418

I really don't think changing the display manager will help. But I tried logging in graphically with an empty session (without any desktop environment). Then I started metacity (the old Gnome2/Mate window manager) and tried KSP. Still the same bug :-/

I also tested the AMD/Radeon proprietary drivers. They actually fixed the bug. But on the opposite they completely broke my display setup (luckily I back-upped it before) and actually gave me a worse performance than the open-source drivers. So I went back to the open-source drivers.

But: Now we know it's definitely the drivers!

Maybe we should get in contact with the driver developers.

https://wiki.freedesktop.org/xorg/radeon/

Edited September 19, 2015 by kolAflash

[sal_vager]

We're getting closer to figuring this out I think.

Rather than displaying the mesh inside-out it looks to be drawing the back side of the mesh, these are untextured and they don't even have a material so they are just black.

Normally any polygon facing away from the camera is not drawn, this is called back face culling, but the Wikipedia page does say "In scenes containing transparent polygons, rear facing polygons may become visible through the process of alpha composition".

I know all the KSP textures have an alpha channel, and fairings do use alpha blending to show semi-transparency in the editor.

[kolAflash]

@sal_vager

Any progress on this?

Maybe "Unity Technologies" can help.

Did you try to make contact with the Xorg-Radeon driver developers? (I can do so if you wish)

[sal_vager]

Nothing yet unfortunately, but be my guest.

[kolAflash]

I just opened a bug report for the Radeon open source Linux driver. Let's see what the Radeon driver developers say about this.

https://bugs.freedesktop.org/show_bug.cgi?id=92101

They'll probably need some way to test this. Unfortunately the KSP demo doesn't seem to have fairings, so one of the driver developers may need a full version of KSP.