3.2 Core profile renders some PBR materials darker than Compatibility profile

[stephengold]

I recently discovered this issue recently in JME 3.6.0-alpha1 and created a test case.
Here's how it renders with the 3.2 Core profile:

Here's how it renders with Compatibility profile:

Here's the test-case java:

/**
 * Reproduces an issue where PBR materials render much darker with the Core 3.2
 * profile than with the Compatibility profile.
 *
 * <p>
 * This test also uses 4 textures (AO, Diffuse, GL Normal, and Rough), all at 2K
 * resolution in PNG format, which can be downloaded from
 * https://polyhaven.com/a/marble_01 and unpacked to the
 * src/main/resources/marble_01/textures directory.
 *
 * <p>
 * This test also uses a precomputed light probe which can be obtained from
 * https://github.com/stephengold/jme-vehicles/blob/master/MavCommon/src/main/resources/Textures/skies/moon/probe-day.j3o
 * and saved to the src/main/resources directory.
 */
public class TestIssue extends SimpleApplication {

    public static void main(String[] args) {
        boolean loadDefaults = true;
        AppSettings appSettings = new AppSettings(loadDefaults);
        appSettings.setGammaCorrection(true);
//        appSettings.setRenderer(AppSettings.LWJGL_OPENGL2); // to test Compatibility profile
        appSettings.setRenderer(AppSettings.LWJGL_OPENGL32); // to test Core 3.2 profile

        TestIssue application = new TestIssue();
        application.setSettings(appSettings);
        application.start();
    }

    @Override
    public void simpleInitApp() {
        flyCam.setDragToRotate(true);

        // Attach a 9x9 quad at the origin.
        Mesh mesh = new CenterQuad(9f, 9f);
        Geometry quad = new Geometry("quad", mesh);
        rootNode.attachChild(quad);

        // Apply a PBR material to the quad.
        String materialAssetPath = "marble_01.j3m";
        Material material = assetManager.loadMaterial(materialAssetPath);
        quad.setMaterial(material);

        // Add a LightProbe.
        String probeAssetPath = "probe-day.j3o";
        LightProbe probe = (LightProbe) assetManager.loadAsset(probeAssetPath);
        rootNode.addLight(probe);
    }
}

Here's the "marble_01.j3m" material for the test case:

Material marble_01: /Common/MatDefs/Light/PBRLighting.j3md {
    MaterialParameters {
        BaseColor: 1.4 1.4 1.4 1
        BaseColorMap: Repeat marble_01/textures/marble_01_diff_2k.png
        LightMap: Repeat marble_01/textures/marble_01_ao_2k.png
        LightMapAsAOMap: true
        Metallic: 0.01
        NormalMap: Repeat marble_01/textures/marble_01_nor_gl_2k.png
        NormalType: 1
        RoughnessMap: Repeat marble_01/textures/marble_01_rough_2k.png
    }
    AdditionalRenderState {
        FaceCull Off
    }
}

My configuration: x86_64 Mint Linux 21.1 (Ubuntu 5.15.0-57-generic) single monitor

Jan 10, 2023 11:18:25 AM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.6.0-SNAPSHOT
 * Branch: master
 * Git Hash: b0bd1a5
 * Build Date: 2023-01-10
Jan 10, 2023 11:18:26 AM com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: LWJGL 2.9.3 context running on thread jME3 Main
 * Graphics Adapter: null
 * Driver Version: null
 * Scaling Factor: 1
Jan 10, 2023 11:18:26 AM com.jme3.renderer.opengl.GLRenderer loadCapabilitiesCommon
INFO: OpenGL Renderer Information
 * Vendor: NVIDIA Corporation
 * Renderer: GeForce GT 545/PCIe/SSE2
 * OpenGL Version: 3.2.0 NVIDIA 390.157
 * GLSL Version: 1.50 NVIDIA via Cg compiler

[stephengold]

I reproduced this issue using JME v3.5.2-stable, so I don't consider it a regression. However, due to PR #1752, we'll soon have a lot more developers using the OpenGL 3.2 Core profile.

Further effort to characterize the issue:

• I failed to reproduce the issue using a textureless PBR material ("jme3test/light/pbr/pbrMat.j3m")
• I reproduced the issue without "BaseColor: 1.4 1.4 1.4 1" (deleted the line from "marble_01.j3m")
• I reproduced the issue without "BaseColorMap"
• I reproduced the issue without "LightMap"
• Without "LightMapAsAOMap" the differences between profiles are more subtle: Compatibility profile renders some areas with a slight greenish cast, while 3.2 Core renders similar brightness but without the greenish cast.

[Ali-RS]

Are you using assets from test data? I can not find probe-day.j3o and textures used in marble_01.j3m.

[stephengold]

/**
 * This test also uses 4 textures (AO, Diffuse, GL Normal, and Rough), all at 2K
 * resolution in PNG format, which can be downloaded from
 * https://polyhaven.com/a/marble_01 and unpacked to the
 * src/main/resources/marble_01/textures directory.
 *
 * <p>
 * This test also uses a precomputed light probe which can be obtained from
 * https://github.com/stephengold/jme-vehicles/blob/master/MavCommon/src/main/resources/Textures/skies/moon/probe-day.j3o
 * and saved to the src/main/resources directory.
 */

[zzuegg]

As far i remember i stumbled also on this when switching to core profile. Not sure and not at the pc to test but i think adding a a post processor fixed it. Without tracking the issue further down and without checking the specs i kind of assumed additive blending is not allowed in core profile on the 0 framebuffer. imho not an issue since most games beside test projects use a postprocessor and in a hdr pipeline it is kind of required.

As a note. All scenes with multiple lights render also wrong without fpp (core profile only)

[Ali-RS]

Downloaded texture from the said URL but there were no marble_01_ao_2k.png in there so I removed LightMap param from the material file also except marble_01_disp_2k.png the others were not in png format so I converted them to png using gimp.

In my case, the output is the same in both LWJGL_OPENGL2 and LWJGL_OPENGL32.

[Ali-RS]

Can you please also try TestPBRLighting with both core and compatibility profiles?

[stephengold]

Downloaded texture from the said URL but there were no marble_01_ao_2k.png

Sorry! Poly Haven uses a fancy download interface which requires you to specify the textures/formats you want. In the right sidebar, specify 2K resolution and ZIP archive, then open the hamburger menu button and tick the checkboxes for the 4 textures in PNG format.

[stephengold]

Can you please also try TestPBRLighting with both core and compatibility profiles?

I tried this and didn't see any difference between the 2 profiles.

[Ali-RS]

Sorry! Poly Haven uses a fancy download interface which requires you to specify the textures/formats you want. In the right sidebar, specify 2K resolution and ZIP archive, then open the hamburger menu button and tick the checkboxes for the 4 textures in PNG format.

Ok, grabbed the textures as you explained above.

In my case, the output is still the same in both profiles. They both look dark.

[stephengold]

In my case, the output is still the same in both profiles. They both look dark.
Not what I expected!

I continue to investigate...

• I reproduced the issue without "Metallic"
• I failed to reproduce the issue without "NormalMap"
• I reproduced the issue without "NormalType"
• Without "RoughnessMap", the differences between profiles are increased: 3.2 Core renders even darker than with the original material parameters.
• I reproduced the issue without "AdditionalRenderState"

On my system, the following J3M file is sufficient to reproduce the issue:

Material TestIssue1903: Common/MatDefs/Light/PBRLighting.j3md {
    MaterialParameters {
        Metallic: 0.01
        NormalMap: Repeat marble_01/textures/marble_01_nor_gl_2k.png
    }
}

Increasing "Metallic" reduces the difference between the render output of the 2 profiles.
I therefore suspect that the issue is connected with how PBR uses normals in non-metallic materials.

[zzuegg]

I cant reproduce this. Could you test if this happens with other light types then a light probe too?

Actually since you mentioned it. If increasing metallic reduces the issue it might be a mipmap issue.

[pspeed42]

Random thought... this reminds me of the cases where things that the material requires are left unset. Then it becomes up to the specific graphics card + driver to decide what values to stick there (or leave garbage or whatever). Like leaving a tangent buffer out when using normal maps will look odd but work on some cards and be totally black on others.

I haven't been following closely enough to know if that's the case in these examples.