MESA: TestPBRLighting/reflective shader node broken

[MeFisto94]

On Discord we got an error report about PBRLight being broken and there also was a forum post from nehon back then.
Basically the problem is that shader nodes go wrong quite a bit, specifically it does not include GLSLCompat.glsllib but instead manually replicates a few things, this could be part of the problem.

Also the language seems to be GLSL100 whereas #version 110 is defined in the compiled shader.
For some reason MESA stills doesn't accept textureCubeLod, which seems to be gone or renamed only in versions PAST 110.

Apr 06, 2020 4:20:03 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,6,main]
com.jme3.renderer.RendererException: compile error in: ShaderSource[name=Default.frag, defines, type=Fragment, language=GLSL100]
0:28(21): error: no function with name 'textureCubeLod'

        at com.jme3.renderer.opengl.GLRenderer.updateShaderSourceData(GLRenderer.java:1498)
        at com.jme3.renderer.opengl.GLRenderer.updateShaderData(GLRenderer.java:1525)
        at com.jme3.renderer.opengl.GLRenderer.setShader(GLRenderer.java:1590)
        at com.jme3.material.logic.DefaultTechniqueDefLogic.render(DefaultTechniqueDefLogic.java:94)
        at com.jme3.material.Technique.render(Technique.java:166)
        at com.jme3.material.Material.render(Material.java:1028)
        at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:614)
        at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:266)
        at com.jme3.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:305)
        at com.jme3.renderer.RenderManager.renderViewPortQueues(RenderManager.java:877)
        at com.jme3.renderer.RenderManager.flushQueue(RenderManager.java:779)
        at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1108)
        at com.jme3.renderer.RenderManager.render(RenderManager.java:1158)
        at com.jme3.app.SimpleApplication.update(SimpleApplication.java:273)
        at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:157)
        at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:196)
        at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:239)
        at java.base/java.lang.Thread.run(Thread.java:834)

[pspeed42]

re: "Also the language seems to be GLSL100 whereas #version 110"

This is on purpose. GLSL100 = version 110 on desktop. It = something else on Android. There is no such real GLSL version as "100". 1.10 was the first real version of GLSL.

To me, if the shader specifies #version 110 at the top then it shouldn't fail because of a function that exists only in 110 unless the display driver is busted. So Mesa seems broken to me.

[MeFisto94]

See https://hub.jmonkeyengine.org/t/error-no-function-texturecubelod-when-running-testpbrlighting-on-intel-hd4000-solved/36331/10 for the forum thread.

Solution was setting the core profile, which is wrong, because it just hides the issue. We have this define in GLSLCompat

[rvandoosselaer]

The issue is also present on mac when running on the default OpenGL2 renderer.

It should be available according to the language spec:
https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.1.10.pdf

[rvandoosselaer]

Found some related bug reports and fixes:

• ioquake/ioq3@9b4dcc8
• https://salsa.debian.org/games-team/ioquake3/commit/15f912f630806ca99edf1768a8c675504f7c6586

[MeFisto94]

The problem is we cannot check if a method is defined, otherwise GLSLCompat could just define it whenever it's needed.