I’m gonna try and take the route you mentioned
1 Like
Note, regarding GammaCorrectionFilter, it might be broken!!
Afaik, its shaders have been removed so you propably will get AssetNotFoundException.
2 Likes
Yeah. In the end, I wrote my own gamma filter, which is called ContrastAdjustmentFilter and included in the Heart library.
2 Likes
Yeah, I am already using ContrastAdjustmentFilter in my project. 
2 Likes
Gotcha! Much appreciated!
I added it to my dependencies, does it work like a Drop-In for GammaCorrectionFilter? And would it still work like @oxplay2 mentioned?
1 Like
Sorry, I don’t recall how compatible I made it with GammaCorrectionFilter. The source code is online, so you can see for yourself what it does.
1 Like
Gotcha, I’ll do some digging and come back here when I’m done. I think I’d like to end this thread off with a good explanation of ContrastAdjustmentFilter and it’s compatibility with GammaCorrectionFilter, along with some examples of replacing GammaCorrectionFilter with ContrastAdjustmentFilter . Give me a good couple of hours to integrate and write it all out
1 Like
Are you doing something non-standard with your classpath or libpath setup? Native Libraries being packed inside a .jar is not unusual…
1 Like
No. Well, not really. I have another project being crammed into this one’s jar, but that approach has never caused me issues.
I mentioned the dll being in the jar, because with lwjgl2, the dll is not in the jar, it’s in the project directory
It started out in the jar and then it was extracted the first time the application ran… which should also happen for lwjgl3 if you have it setup correctly.
1 Like
Gotcha. Well, it didn’t get extracted. Even though the setup is the exact same except for the lwjgl version in build.xml
I’ll try extracting the dll from lwjgl3 manually and see if that works. In the meantime, is there a
So, I think I know what the issue with lwjgl3 is. The lwjgl3 that gets bundled has x64 bit dll, and my machine is 32 bit.
Correct me if I’m wrong, but looking at the build.xml for lwjgl2 and lwjgl3 in jme3 (lwjgl2 and lwjgl3), it appears that lwjgl2 doesn’t specify natives, which leads me to believe all of them are included, whereas lwjgl3 explicitly requires x64 bit binaries.
So, I went to lwjgl website and tried to get the 32 bit version, and I found this nice little snippet:
import org.gradle.internal.os.OperatingSystem
project.ext.lwjglVersion = "3.2.3"
switch (OperatingSystem.current()) {
case OperatingSystem.WINDOWS:
project.ext.lwjglNatives = System.getProperty("os.arch").contains("64") ? "natives-windows" : "natives-windows-x86"
break
}
repositories {
mavenCentral()
}
dependencies {
implementation platform("org.lwjgl:lwjgl-bom:$lwjglVersion")
implementation "org.lwjgl:lwjgl"
runtimeOnly "org.lwjgl:lwjgl::$lwjglNatives"
}
Which would appear to fix my issue with lwjgl3.
Now, I can’t seem to figure out that import statement (gradle reports unable to resolve class org.gradle.internal.os.OperatingSystem), but this seems like something jme3 should do itself, as it seems the current setup just doesn’t support 32 bit arch.
I’ll try to figure out that gradle import in the meantime to provide a intermediate solution.
So, to keep two topics out of the same thread, I’m gonna start a new thread regarding lwjgl3 and windows 32
Edit: here is the new thread for lwjgl3 32 bit compatibility
@oxplay2 @sgold So, neither GammaCorrectionFilter nor ContrastAdjustmentFilter worker, both produced the same error as before.
The code:
//initializing settings
settings.setGammaCorrection(true);
//inside simpleInitApp
renderer.setMainFrameBufferSrgb(false);
fpp = new FilterPostProcessor(assetManager);
viewPort.addProcessor(fpp);
// caf = new ContrastAdjustmentFilter();
// fpp.addFilter(caf);
gcf = new GammaCorrectionFilter(1);
fpp.addFilter(gcf);
@oxplay2 I found the fix. For me, I followed your instructions but I had to disable gamma correction in the settings. I’m using ConstrastAdjustmentFilter
Bypassing most of the discussion here:
This is because of the assertions. Jme will swallow all OpenGL Errors without assertions and “crash” on the first one ´glGetError` returns when they are enabled.
Stephen has already hinted that, but I just wanted to point that out more clearly, in case someone is reading this in the future and is wondering why this works for some and not for others.
Also note that settings.setGraphicsDebugEnabled() or something should be available in more recent jme versions, so you don’t need to dig out the correct key and set a boolean.
2 Likes
I ended up using ContrastAdjustmentFilter from @sgold’s Heart library.
For lwjgl2, setting gamma correction to false, setting srgb to false, and adding ContrastAdjustmentFilter to a post-processor filter worked fine.
Btw, I had already tried with and without assertions enabled, to the same results, so assertions had no affect on this issue for me.
For me, the issue was, whatever jme3 considered “Gamma Correction” did not work, for me atleast, and that was not acceptable. So the solution was to disable jme3’s form of “Gamma Correction” and instead use something more stable, like @sgold’s Heart library, which provides ContrastAdjustmentFilter. which is a completely suitable replacement
The real point of setting gamma is so that lighting calculations are done in linear color space instead of srgb color space. So a post filter will let you adjust the contrast but it won’t fix the lighting gradient to look correct.
2 Likes
Well I’m at a loss then. Whatever I have with the post filter makes the game look so much better. But if it’s not proper then I’m leaving it at S.O.L. I’ve spent days on this single issue, and Its come down to either forget gamma correction exists entirely, or use whatever you would call this
As a side note, since this issue supposedly is fixed with lwjgl3, then maybe someone should fix the jme3-lwjgl3 package to include 32 bit binaries
See other thread where you asked that question and it was clearly explained that there ARE 32 bit binaries.