I would say itâs not exactly a matter of algorithm. Rendering is a thing, lighting is another.
Here in the Sandbox there is an Environment by default. Maybe when you do final usage of your mesh you will add another environment with another lighting intensity, maybe you will add some more lights or whatever. Here comparing the default scene (and its lights) of two viewers (BJS Sandbox, and ModelViewer) does not really make sense to me. At least I would say the difference comes from the lights, more than the rendering pipeline
There are multiple reasons why Babylon.js sandbox is different. The primary reason is because we donât follow the glTF spec for alpha coverage because almost everyone is trying to use it for glass. If itâs glass, Babylonâs rendering is more accurate to what should happen. If you want it to behave completely to spec, then you can use 3dcommerce.babylonjs.com. Newer models should use the KHR_materials_transmission to handle glass which should render consistently across implementations.
It is also brighter in Babylon.js because no tone mapping is applied by default whereas ModelViewer has a tone mapper on by default. You can enable it by clicking on Scene in the inspector and enabling the Khronos PBR Neutral tone mapper which is the same as ModelViewerâs default. We are probably going to enable this tone mapper by default in the 3dcommerce mode.
In the screenshot below, I also changed the background to white. This should look much closer to ModelViewerâs settings.
It depends. Emmett, the driver of the PBR Neutral tone mapper, has an article describing the use cases. This is a complex subject and depends on what you are trying to do.
After several months, I discovered the reason for the strong reflection of glass: the useRadianceOverAlpha attribute.
For the glass of my car, setting useRadianceOverAlpha to false would appear more normal Of course, other engines such as Threejs and PlanCanvas will not display such strong glass reflections BJS provides more options for adaptation, but familiarity with BJSâs PBRMaterial documentation is necessary to solve the problem.
Another question is why BJS defaults the useRadianceOverAlpha of PBRMaterial to true?
Indeed. But Iâm not sure having everything in the doc would really help. In the end, nobody would read it (I wouldnât). The versatility of the engine is an asset but does add complexity towards all what you can do and combine. Typically, in this case, I believe you could have âsolvedâ this high reflection using a number of other approaches and twists. Clone the reflection texture (or env) and change its levels. Part of it might also come from the light. Change directLight intensity. Add an emissiveTexture and change its color and levels⊠and likely many others.
Though, I would agree with you that (if by any means possible without removing the specificities, versatility and capacity of the engine) we would have a more ânormalizedâ default for I.E. PBR materials, would likely be a good thing (in my opinion). But thatâs likely quite a bit of work and a fair chance to face issues that will (again) require some sort of âcompromiseâ.
How often a material is used with transparency in PBR to not represent plastic/glass or a highly reflective surface which normally should use some kind of transmission ? I would think a lot of time but impossible to quantify.
In those case think about any bright reflection on a glass (help signal, tv on windowâŠ), you would not be able to see what is behind but only the reflection. This is why the mode is added by default as it is the most common one but I agree it might be hard to discover and I am game for anybody willing to improve the doc and make it more visible.
Using the 3dcommerce site will disable useRadianceOverAlpha so that it conforms to glTF spec. If you want to do this in your own code, you can set transparencyAsCoverage to true in the glTF loader.