Ok, so the settings on the frame buffer are a little confusing but then your settings don’t make sense to me. Here is the javadoc for set gamma:
public void setGammaCorrection(boolean gammaCorrection)
Enable or disable gamma correction. If enabled, the main framebuffer
will be configured for sRGB colors, and sRGB images will be linearized.
Gamma correction requires a GPU that supports
GL_ARB_framebuffer_sRGB; otherwise this setting will be ignored.
The idea is that lighting cannot be properly interpolated in sRGB space… but most textures will be in sRGB space. So when you put JME into “gamma correction” mode, it will convert textures from sRGB to linear for the shaders, the shaders can do all of their math linearly, then the final image will be converted back to sRGB for display.
My understanding is that in sRGB space someColor * 0.5 is not really ‘half as bright’ but in linear space it is. So colors get converted to linear space so that color * 0.5 is “half as bright” and then get converted back to sRGB for the display.
I think “gamma correction” is so far overloaded of a term that it really was a poor choice for naming an app setting. Even if it’s “technically correct”.
BUT back on topic, I suppose if you are going to be treating the main framebuffer as linear anywhere in the process beyond the initial shading that the setMainFrameBufferSrgb(false) could make sense… but then somewhere at the end the app would have to convert back to sRGB or things get screwed up.
UNLESS, (as is most likely) JME is merely using that flag to control how the final frame buffer is displayed in the end. (I say most likely because I think the post processors get to still operate in linear space as well… which implies the conversion back to srgb must be very late.)
That’s right. PapaSpace uses a color correction filter near the end of the filter chain which is doing the final correction, including gamma, HDR, etc.
Alright here is the result of the gamma investigation.
All the docs i have found say that if srgb framebuffers are supported by your machine you should use them for the final framebuffer. Input color textures have to be linearized.
Now, if you disable srgb on the main framebuffer with the code apollo posted you have to manually gamma correct at some point. (I think it should also be the last operation regarding color manipulation)
//Gamma is kind of defined as 2.2
srgbColor= pow(linearColor, vec3(1.0 / gamma));
The results are nearly the same when using the above code with 2.2 and when using srgb mode.
At the same time different monitors output color differently so it is suggested to allow the use to gamma correct for the monitor.
For me, i go the route of using srgb mode and offer gamma correction for the monitor as part of the final hdr conversion pass. I opt for that route simply because if a user does decide to not add the final post processors the result will still be somewhat correct.
Still not really happy with the directional shadows. I am still wasting lots of precision and space in the shadowmap. (at least 1/2 of the space and god know how much precision).
But i got the basics working and have cascading shadow maps.
Turns out i might have dismissed better solutions but i was testing against a directionallight without having a light direction set. The default value is is (0,-1,0) and that **cks up the Camera.lookAtDirection(LightDirection,Unit.Y)
You can clearly see the transition for on to the next shadowmap in the roof shadow.
At least now i know that i have the shaders working. It was quite interesting since i am using a single shadow map and redraw for each cascade layer. I had to make sure that already shadowed areas do not get shadowed again.
Found a dirty hack how to swap out materials. So there might be a “one line i want to try this the dirty way” utility function.
Found a bug in the shadow checking. Fixing that allowed me to use pre blurred shadow maps and trough that the shadows have now smooth edges. To use the feature, set VSM_GF as shadow mode on the lights. Using VSM shadow mode still uses hard edges and unblurred shadow maps.
The directional light shadows produce “not horrible” results, but the shadows wobbles a bit and is not nice.
Feature wise, i am going to give the materials a bit of love. PBR is complete, PBR terrain is next, and then the same for the BlinnPhong materials (Lighting and Terrain). With the 4 main shaders beeing feature and naming equal a one click solution is possible if you use only those materials.
Internally i changed shadow map generation from front face culling and positive depthbiasing to back face culling and negative depthbiasing. Peter pan seems to have gone completely and lightbleeding is also not visible in my playground. Much better then previous versions. Here are some shots to show whats possible if you have one motivated guy with access to high quality assets.
IMHO artists should always make stuff solid. Only because you cannot see the door from behind does not imply you never have to render the door from behind.
