jmonkeyengine: PBR: Shader Compilation Error on Mac OS (GLSL110)

So when running on Mac OS X in the default mode, you only get the compability profile and thus OpenGL 2.0 and GLSL110. According to the source code, this should not be a problem for PBR, we have our GLSLCompat.glsllib and we have the “Language Switch Statements”.

In this case it seems the latter has gone wrong and I need to investigate why. I might open another issue to track the exact issue, this is mainly to track the defect as is and make it more prominent for searches.

Do note that this also affects the SDK in it’s current state and basically all PBR on Mac OS X and probably also every shader wanting to use GLSL120+ language features.

com.jme3.renderer.RendererException: compile error in: ShaderSource[name=Common/MatDefs/Light/PBRLighting.frag, defines, type=Fragment, language=GLSL110]
ERROR: 0:200: GLSL 110 does not allow sub- or super-matrix constructors
ERROR: 0:201: Use of undeclared identifier 'wToLocalRot'
ERROR: 0:201: Use of undeclared identifier 'wToLocalRot'
ERROR: 0:214: Use of undeclared identifier 'wToLocalRot'
ERROR: 0:215: Use of undeclared identifier 'rayLs'
ERROR: 0:218: Use of undeclared identifier 'wToLocalRot'
ERROR: 0:222: Use of undeclared identifier 'rayLs'
ERROR: 0:223: Use of undeclared identifier 'rayLs'
ERROR: 0:224: Use of undeclared identifier 'firstPlaneIntersect'
ERROR: 0:224: Use of undeclared identifier 'secondPlaneIntersect'
ERROR: 0:225: Use of undeclared identifier 'furthestPlane'
ERROR: 0:225: Use of undeclared identifier 'furthestPlane'
ERROR: 0:225: Use of undeclared identifier 'furthestPlane'
ERROR: 0:227: Attempt to use 'distance' as a variable
ERROR: 0:228: Use of undeclared identifier 'intersectPositionWs'

	at com.jme3.renderer.opengl.GLRenderer.updateShaderSourceData(GLRenderer.java:1476)
	at com.jme3.renderer.opengl.GLRenderer.updateShaderData(GLRenderer.java:1503)
	at com.jme3.renderer.opengl.GLRenderer.setShader(GLRenderer.java:1567)
	at com.jme3.material.logic.SinglePassAndImageBasedLightingLogic.render(SinglePassAndImageBasedLightingLogic.java:259)
	at com.jme3.material.Technique.render(Technique.java:166)
	at com.jme3.material.Material.render(Material.java:1026)
	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:272)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
	at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:197)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:232)
	... 1 more

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 18 (18 by maintainers)

Commits related to this issue

Most upvoted comments

That would work, yes. I would’ve accessed every single value of the matrix, but this is much more effective. I’ll see if I can come up with a PR