Jump to content

When I change the library from 3.0 to 3.1, result of PBRMaterial becomes dark.


Recommended Posts

I tried changing the library version of PBRMaterial sample from 3.0 to 3.1.


Babylon.js v3.0 + PBR Sample: http://jsdo.it/cx20/ebAu

Babylon.js v3.1 + PBR Sample: http://jsdo.it/cx20/QfBY

If the usage has changed, can you tell me how to fix it?

    var light0 = new BABYLON.DirectionalLight("Dir0", new BABYLON.Vector3(0, 0, 1), scene);
    light0.diffuse = new BABYLON.Color3(1, 1, 1);
    light0.specular = new BABYLON.Color3(1, 1, 1);

    for(var r = 0.0; r <= 1.0; r += 0.25) {
        for(var m = 0.0; m <= 1.0; m += 0.25) {
            sphere = BABYLON.MeshBuilder.CreateSphere('sphere', {segments:24.0, diameter:1.0}, scene);
            sphere.position = new BABYLON.Vector3((r-0.5)*4, (m-0.5)*4, 0); 
            var pbr = new BABYLON.PBRMaterial("pbr", scene);
            pbr.baseColor = new BABYLON.Color3(1.0, 1.0, 1.0);
            pbr.metallic = m;
            pbr.roughness = r;
            sphere.material = pbr;


Link to comment
Share on other sites

Hello @cx20,

There were a lot of fixes inserted in the PBR Material between 3.0 and until 3.2. Most of them have been introduced while developing our GLTF loader and trying to be closer to the other engines out.

I would advise to directly migrate to 3.2 where we could check together the best migration strategy ?

Link to comment
Share on other sites

@Sebavan Thanks for the advice.

I tried PBR with Babylon.js v3.2 and v3.3, but it looks the same as v3.1.


Babylon.js v3.2 + PBR Sample: http://jsdo.it/cx20/e40a

Babylon.js v3.3 + PBR Sample: http://jsdo.it/cx20/45C3


Also, I made a glTF model with the same result as PBR sample and compared Three.js and Babylon.js. The result of Babylon.js looks dark.


Three.js r95 + PBR glTF sample: http://jsdo.it/cx20/mvgp

Babylon.js v3.2 + PBR glTF Sample: http://jsdo.it/cx20/eLqO


The following is reference information. I tried to compare with several other libraries. Because each library gave different results, I did not know where the correct answer was.


Link to comment
Share on other sites

I am quite reinsured considering the amount of fixes that went in before 3.2 that it is now stable. Now, about the diff, it all depends how the lighting equations are in the different engines.

Unfortunately, as long as the engines will not implement smthg like the gltf light extension you will have those kind of differencies. Nothing enforces a particular choice for the implementation and there are lot of ways to compute how the light response. The thread below is a nice highlight of some of the differences:


I double checked and the shader has been changed quite dramatically since 3.0 explaining the visual difference we can see here (most of the fixes improved our interoperability with other engines).

You should also try the same kind of render in Unity and Unreal to see how this would look. (you could also use a fully black hdr for IBL if you want to see only the directional light impact ? if there are no engine options to stop IBL)


Link to comment
Share on other sites

Hi, @cx20!

@Sebavan and I spent a lot of time working on the implementation of our IBL environments. We reworked how we generate the DDS prefiltered environments so that we aligned with what perceptual ray tracers and popular game engines like Unity and Unreal are doing with their IBL rendering. We are approximating a perceptual roughness model which drops what is perceived to be 50% rough falls in the middle of middle of the linear ramp for roughness. The GGX algorithm that we use for our lighting calculations has more of a linear roughness scale which loses clarity in reflections quickly (by around 0.3 roughness). We adjusted the falloff to mirror what happens in Arnold ray tracing, which is the renderer we chose as our ground truth for this work:


We were able to largely match the perceptual falloff from the Arnold ray tracer, while using a prefiltered MIP chain in the DDS ignoring the last two MIP levels. We have some deviation from the high roughness in the ray traced ground truth, but since fully rough materials don't really exist in the real world, there is no way to know if Arnold is right in these areas.

To look further into your scene, I recreated it with your code, while adding in the environment from the ground truth as well as our more neutral interior studio environment. I even turned off the directional light in your scene as you don't really need it anymore, at least not pointing directly at the spheres to light them. I also dropped in the glb of the test spheres from above in with your spheres with a slight modification to your spheres where we are only looking at two rows, one fully metallic and one fully dielectric. Looking at materials that are partially metallic and partially rough are confusing to the eye to determine what looks right, so simplifying it to the extremes for metallic allows us to concentrate only on roughness and values to ensure things look right. 

Here are the two environments with your setup (slightly modified):



You can see in these that the directional light is commented out so is not contributing to the scene. Ideally, you want to use an environment IBL to help ground your scene, but also to add more complex lighting without overloading the scene with analytical lights. You will still need the analytical lights for cast shadows, however. 

Here is the playground for you to experiment with: http://playground.babylonjs.com/#BGWI46 
It has both environment files referenced with one commented out so you can test both of them. Please let me know if you have any questions about anything.

Link to comment
Share on other sites

@Sebavan Thank you for teaching me a link to a wonderful thread. Since I do not have enough knowledge about PBR, I would like to study. I am also interested in PBR results in other applications, so I would like to investigate if possible. Blender, Unity, Unreal, Mixed Reality Viewer, Paint 3D, Windows 10 Explorer Preview, etc.

@PatrickRyan I am deeply moved by your wonderful work. I understood that the rendering of Babylon.js has about the same capability as a commercial rendering engine. I'm glad that you prepared sample code as well. I do not have much knowledge about IBL, so I'd like to try various things and study.

Link to comment
Share on other sites

@Deltakosh @Sebavan @PatrickRyan

Hi, Thank you for your kind response to my friend @cx20. I'm impressed that Babylon.js is doing a lot of efforts to verify the reflection model. Recently, I started to add support of PBR to my library (still only punctual light). 

Let's say that Cook-Torrance base is good for the model of specular reflection.
I was worried about which specific approximation formula is appropriate (Disney, Unreal Engine, Frostbite, Major companies, each best practice exists). Of course, I was also concerned about the handling of roughness etc.

I immediately looked at the Khronos official PBR sample, and I decided to make the implementation almost the same for the time being. I wanted to avoid the result of my library getting away from other libraries, so I expected each library to reference it as a reference.

But, according to cx20's comparison test (He is comparison test happy! :D), The results of each library seem to be very different. And, in actual use of glTF 2.0, differences in PBR results which can be seen even at amateur level among each library seems to cause people a lot of confusion. For the general public, there are no interests in internal mathematics, and the brightness and color taste of what they saw are all.

I think there are some key points of view.

* What is the renderer that each library refers to? (btw, I started to refer Arnold Renderer too. It's unbiased renderer, popular, and default solution in Autodesk DCCs. Of course those do not mean that all results are correct proof...)

* A case where the validity of energy conservation etc collapses as design and implementation become more complicated (such as clear coat support)

* Simply, careless mistake in handling gamma (recently, there was a thing in a major library)

* Difference in approximate expression to select (In a sensitive case, the difference in reflection lobes and spikes may appear in visual results. for example, In Unreal Engine etc, they started to use Height-Correlated Smith Masking and Shadowing function.)

* Difference of IBL implimentation

Even with local reflections, the results differ so much, so in the future, gIobal Illumination results will be more different between each library.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...