I’m sorry if there’s a bug tracking tool somewhere, but I can’t seem to find it.
LwglRenderer.setShader(null) appears to be designed to clear the current shader (glUseProgram(0)). However, it causes a NullPointerException in Statistics. This could be fixed simply by deleting line 996 of LwjglRenderer, as it makes little sense to track statistics of the null shader anyway.
java.lang.NullPointerException
at com.jme3.renderer.Statistics.onShaderUse(Statistics.java:108)
at com.jme3.renderer.lwjgl.LwjglRenderer.setShader(LwjglRenderer.java:996)
at com.getgosu.rts.core.TWLInterop.postFrame(TWLInterop.java:104)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:719)
at com.jme3.renderer.RenderManager.render(RenderManager.java:741)
at com.getgosu.rts.core.ApplicationBase.update(ApplicationBase.java:278)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:137)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:161)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:205)
at java.lang.Thread.run(Thread.java:662)
Thing is, you’re not supposed to be able to clear the shader at all. Because of the OpenGL2 requirement, it makes little sense not to use shaders, so their usage must be forced.
Now I made a clearer exception for that method.
It does make sense not to use shaders if you’re attempting to integrate with another 3D library that intends to make use of the raw LWJGL interface, and doesn’t use shaders itself.
For instance, I just integrated the TWL GUI library as a SceneProcessor and had the hardest time figuring out why it wouldn’t render after a JME scene had rendered. It turns out that it was because the RenderManager leaves the current GPU program set to whatever the last Geometry used–I assume because the next geometry is going to set up its shader anyway.
The workaround I discovered was simply to call “GL20.glUseProgram(0);” directly. I feel like that’s awful ugly and “un-java-like”, especially when the Renderer is already coded to support returning to the fixed pipeline. Not to mention that now the Renderer thinks that its boundShader is something other than what is actually bound.
I don’t see any reason that a perfectly consistent state (“use fixed function shading”) should be disabled for making “little sense” when it impacts the normal JME use case not in the slightest bit–and is already coded for.
I have added a method Renderer.invalidateState(), you should call it after all of your GL state modifications to ensure jME3 can restore the desired state. Note that you inflict a constant performance loss per frame by using this method …
The ideal solution to your problem is to implement the TWL rendering interface and do all rendering via jME3, this is how the Nifty GUI renderer works.