I have the same problem with Intel HD Graphics 4600 and Mesa 12.0.0-rc1. The problem seems to affect other Mesa drivers too, as reported on various forums:

https://forum.paradoxplaza.com/forum/index.php?threads/borders-empire-colors-not-visible.927717/
https://steamcommunity.com/app/281990/discussions/0/357285562492711302/

The known workaround is to open game console (in Ironman mode it needs to be done in the main menu, before creating/loading the game) with '~' and enter:

tweakergui borders.usemesh

Then click the checkbox in the window that apperas and close both the window and the console. This needs to be repeated each time Stellaris is started.

My mistake, I have not actually tested it on Mesa 12.0.0-rc1, as I have not noticed Stellaris is 32-bit and my 32-bit Mesa libraries were older.

I have now tested it with 32-bit Mesa 12.0.0-rc2 and the borders are displayed properly.

It seems the problem is fixed for Mesa 12.0.

Can you give more details on what you did? I just installed the rc2 and my borders look the same. I have checked and I have the libgl from mesa for both 32 and 64 bit as 12.0-rc2. Was the mesa code all you changed?

Nevermind, I have no idea what I witnessed before. After doing nothing but leave the computer on for an hour, booting the game back up shows borders.(did it have to recompile shaders or something the first time?)

Also to note: my original trace was from before a big patch(1.1). In that trace, I still don't see borders on, but the current game does have them.

I'll mark this as resolved unless I come across something I missed.

For me the upgrade to 12.0.0-rc2 fixed the problem on my Haswell laptop, but when I did the same on my daughter's PC (Skylake) it didn't work – the borders are there, but all grey and hardly visible.

There is still something wrong, within the game or the driver.

I tried to force OpenGL 4.3 on Haswell and OpenGL 3.3 on Skylake (to make sure I test with the same version), but in both cases setting the MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE environment variables caused the game to crash on startup.

Confirmed broken on my Haswell as of mesa g5921f37. I likewise have a trace at https://cooperteam.net/stellaris.trace ; this plays back correctly on radeon and llvmpipe but doesn't show the empire colours on my Iris Pro 5200 i965.

(In reply to Jacek Konieczny from comment #6)
> For me the upgrade to 12.0.0-rc2 fixed the problem on my Haswell laptop, but
> when I did the same on my daughter's PC (Skylake) it didn't work – the
> borders are there, but all grey and hardly visible.
> 
> There is still something wrong, within the game or the driver.
> 
> I tried to force OpenGL 4.3 on Haswell and OpenGL 3.3 on Skylake (to make
> sure I test with the same version), but in both cases setting the
> MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE environment
> variables caused the game to crash on startup.

The game is using OpenGL 2.1:ish according to the developers, so forcing to anything above OpenGL 3.1 will result in the creation of a core profile, which is incompatible with OpenGL <= 3.0.

Tested with Mesa 13.0.0, 13.0.1 and bf75ef3: I can’t seem to reproduce the error when running the game, even if I was able to 10 days ago (on an Haswell Iris Pro 5200). I reverted back to the version of Mesa and Stellaris I assume I was running at the time, but it still worked. Replaying both traces linked to this bug report do produce the artefacts, even with the latest HEAD (bf75ef3).

(In reply to Christopher James Halse Rogers from comment #7)
> Confirmed broken on my Haswell as of mesa g5921f37. I likewise have a trace
> at https://cooperteam.net/stellaris.trace ; this plays back correctly on
> radeon and llvmpipe but doesn't show the empire colours on my Iris Pro 5200
> i965.

Does it still happen with Mesa 12.x or 13.0.x?

We are working on this issue at StreamComputing. The issue still occurs on i965 driver (using the recent Mesa version from git). Other Mesa drivers (llvmpipe and radeonsi) work correctly.

Any update on this? do mesa 17.1 help in anyway?

Sectors have "noisy" borders and very low transparency on i965 driver (Mesa 17.1.0-devel (git-d5ee55f)). Other Mesa drivers (llvmpipe and radeonsi) work correctly.

How it looks like on i965:
https://drive.google.com/open?id=0B1fY17pW39ZeWUoxVXJWUU42dFk

How it should:
https://drive.google.com/open?id=0B1fY17pW39ZeUGhQdmRTUS1UVWc

These overlays are rendered using render-to-texture in the call 2149486:
https://drive.google.com/open?id=0B1fY17pW39ZedlFDREwwSFB6Nzg

The program 706 (a fragment shader 708, created in 911931) uses two textures with

glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_NEAREST)
glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)

These textures also have GL_TEXTURE_MAX_ANISOTROPY_EXT set to 16:

glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAX_ANISOTROPY_EXT, param = 16)

Setting GL_TEXTURE_MAX_ANISOTROPY_EXT to 1 for both textures fixes the issue:
https://drive.google.com/open?id=0B1fY17pW39Zec2pMa3dIN0Nobjg

I.e., GL_TEXTURE_MAX_ANISOTROPY_EXT disables GL_NEAREST, and because the shader highly depends on exact texel values (it calculates sums, maximum of values of the first texture, uses the second texture as a look-up table), the results have such a big difference.

Here the code that disables GL_NEAREST in this case:
https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_sampler_state.c#n454

We've found one issue with a proposed patch here: https://bugs.freedesktop.org/show_bug.cgi?id=91786

The patched driver produces correct results for both traces.

Kind regards,
Stream HPC Team
https://streamhpc.com/

I have verified the patch above and sent it to the list:
https://patchwork.freedesktop.org/patch/162171/

fixed by 6a7c5257cac23cd9767aa4bc8fdab68925b11157