-
-
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. |
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 |
Hi @zzuegg I'm curious if you managed to test this in the latest alpha release to see if you think the fixed fZero calculation is okay? Or do you think there still may be a chance that the strange fZero calcualtion was necessary to account for something else that is unique in jme's pbr implementation? I also just realized I didn't apply the new fZero calculation to the specGloss pipeilne, and it still uses the old calculation here: Line 477 in b846c6a
Should I also apply these changes there, or do you think specGloss needs a different fZero calculation? I could try to test and see the difference, but unfortunately I only have 1 specGloss model in my game so its not as easy for me to spot the rendering differences with specGloss like I was able to when I changed things for the metallicRoughness pipeline. Thanks! |
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: