Planet surfaces not rendering in angle mode

The issue remains as of beta 0.90.0.9954. Attached image of Saturn in Angle mode.

Works as of 0.90.0.9956 (trunk) on a Geforce 960M in ANGLE mode. Saturn is visible, no problem.
Maybe a logfile could help.

Attached log file from laptop on which issue was first observed (Mobile Intel Series 4 Express video chipset) in ANGLE mode. Behavior also seen on desktop with GeForce GTX 560 graphics with ANGLE. Started with beta 0.90.0.9852 and all since.

OK, there is a shader error reported in the logfile by your D3d9 shader compiler.
Is the Geforce 560 not compatible with DX11? Try with --angle-d3d11 please.

I still cannot reproduce this with Geforce 960 or Intel HD530.

The shader has not changed since May (r9387), i.e. 0.16.1 already came with it and should show the same issues. V0.90.0.9852 brought the first public beta with planet Nomenclature. Surprising if this causes a new shader bug?

The logfile is from the laptop with a Mobile Intel Series 4 Express video chipset and that requires ANGLE mode. Forcing DX11 fails the same way as the default DX9 ANGLE mode. I also tested on a GeForce 560 desktop for another data point. It works fine on DX11, but failed in the same way as the laptop when forced to simple ANGLE mode. I also tried a full un-install of 0.16.1 on the laptop (including manual deletion of any leftovers in Program Files and AppData), but planet rendering still failed after a fresh install of any beta since then. MESA mode works but is very slow. It's not a huge problem, I realize my hardware is old and is due for an upgrade. I can live with 0.16.1, but will keep tinkering and report any progress here.

Obvious fix has been added as revision 9958. This fix will be available for testing in next beta.

Please check version 0.90.0.9959 or later.

Thanks for your help. Unfortunately I'm still seeing the issue in ANGLE mode with version 0.90.0.9959 on both the Mobile Intel Series 4 Express and GeForce 560 chipsets.

Please show log from last beta

Sorry for the delay in posting my log file, the new beta came out just as I was leaving for work this morning.

I can confirm the issue on Windows in ANGLE mode only. It's interesting, but fragment shader cannot be compiled into D3D shader and planets are always in shadow.

Not in shadow, just not rendered without a valid shader.
I cannot replicate it on my systems. (Maybe somebody can prepare a VM image for Qemu or VirtualBox with emulated old Intel GPU?) Does it even occur without 3D planets and self-shadowing (which the error message points at), and without nomenclature (where the bug allegedly first appeared)?

I wonder why this problem was not already in V0.16.0 which introduced the current shader.
The error message complains about a non-constant index. I only see

sum += offset_lookup(sTex, coord, poissonDisk[index], zbias);

as possible candidate. This code should not be compiled when shadows are not active.

I tested on my older notebook (Geforce 580M): Indeed, v0.17.0 has this issue. Built from sources: no problem. And now I also see the issue on my Geforce 960M notebook. ( I have upgraded my Qt since November, cannot reproduce #2.)

It appears to me that ANGLE versions are responsible (see numbers in logfile), and Qt5.6.1 has a better version than Qt5.9:
v0.17.0 comes with Qt5.9 and ANGLE 2.1.0.8613.... --> Saturn not rendered, shader has error
I built on the Geforce 580 notebook with Qt5.6.1 which runs ANGLE 2.1.99f075... --> all fine.

Maybe distributions should revert to Qt5.6.2?

I suppose the error about non-constant index is due to the use of `gl_FragCoord.xyy` in the expression for `index`. See https://stackoverflow.com/a/19529963/673852 for description of what may be used as an index. `gl_FragCoord` is neither a constant-expression nor a loop index, so an expression containing it can't be a constant-index-expression.

Good find. I must admit my knowledge of GLSL is very limited, and the shader is not mine. Does the statement "random(vec4(gl_FragCoord.xyy,i))" return a float? Would some other mechanism to select a random int from [0..63] be applicable and deliver equal or better results?

> Does the statement "random(vec4(gl_FragCoord.xyy,i))" return a float?

Yes, the `random` function is defined to return `float`. But this by itself isn't a problem. The problem is the usage of `gl_FragCoord` inside the expression used to calculate `index`.

> Would some other mechanism to select a random int from [0..63] be applicable and deliver equal or better results?

I'm not sure what else limitations GLES/ANGLE has (I've only used desktop OpenGL), but a surefire method would be to convert `poissonDisk` from array to a `sampler2D`, and sample it as a texture instead of indexing. This will allow to achieve exactly the same results, provided the texture filter is set to `GL_NEAREST`.

Oh, I mean `sampler1D`, of course.

Yes, I understand gl_FragCoord cannot be used here. I just want to understand what this line does.

Again, do you have interest to help us here and do the required steps?

> Again, do you have interest to help us here and do the required steps?

I'm not so sure. First of all, I've now read the GLES specification a bit more, and it appears that an OpenGL ES 2.0 implementation _may_ support non-constant array indexing (see Appendix A, section 1 "Overview"). ANGLE is a GLES implementation AFAIU, and apparently, if I understand it correctly, it used to support this. So this does really look like a regression in ANGLE.

I'm not actually sure that Stellarium should change its shaders to fix this: maybe the problem should instead be reported to ANGLE (or Qt?..). There might be a legitimate reason why ANGLE stopped supporting this feature, but chances are that it's a bug.

I myself can't file such a bug report though, because I don't use Windows and thus am not affected by this problem.

The bug report was moved to https://github.com/Stellarium/stellarium/issues/387