-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PBR Lighting issue #2330
Comments
Thanks for investigating. When it comes time to solve this, instead of modifying the PBRLighting shaders (and potentially breaking many apps) I suggest defining a new PBR material with a new name. |
addresses this issue: jMonkeyEngine#2330 There were 2 apparent issues with our metallic calculation that were causing our PBR implementation to render different visual results compared to the khronos PBR standards: 1) fZero was being calculated incorrectly, as mentioned in the linked issue 2) the nonMetalSpec float constant was being set incorrectly. According to what I've read, it should always be 0.08 I also checked tested changes in my own app and it appears the rendering difference is more accurate now. But I'm not an expert in lighting math like this, so let me know if anything looks incorrect with the code.
Unfortunately the sphere tests renders wrong when i replace the fZero calculation. There is more to it. My guess is that jme counteracts the wrongness at some point. I am not yet at that point. Currently i am convertig the khronos reference shader to jme so it can be used as a direct replacement. Are the samples rendering correct on your end? |
Do you mean the varying shiny spheres example you posted the screenshot from? I tried finding that test to run and check, but I can't seem to find it. |
https://github.com/KhronosGroup/glTF-Sample-Models/tree/main/2.0 The models are MetalRoughSperes and the no texture variant |
To continue the discussion from:
https://hub.jmonkeyengine.org/t/zombiegirl-gltfloader-vs-monkeywrench/48007/15
Summary:
According to gltf specs, and on the reference viewers, the default value for metallic factor is 1. Jme's importers are setting the metallic factor to 0 to pass the test cases. The problematic line in my opinion is:
I have checked, a few other repositories, and i have not yet found that piece of math again. Additionally, the whole block:
is quite unique. F0 is in all other shaders defined as:
The text was updated successfully, but these errors were encountered: