Oh I see, let me try to render it in Filament which is pretty close from the gltf spec rendering wise.
Here it is in Filament
So similar to unity no white on top but better contrast in the fully diffuse case, I ll try to see whether I can find something wrong in our harmonics computation.
Both renders can be made pretty close by only touching the camera setup exposure to 2 to fit with filament setup and applying ACES like there:
There is a roughness issue as the map would require to be preprocess in Lys to ensure the correct ramp following a log2 increase but the diffuse is similar and similar with Unity.
I ll continue to dig in but not finding anything at the moment
@echadwick-artist, I dug into what is happening and found a few things. We use Arnold as our ground truth for rendering, a decision we made a while back because we needed to choose how we would approach a perceptual roughness model. We referenced Disney’s principled reflectance model because that is the same model that Allegorithmic uses for Substance. The tools we use all fell within the same confines with the way they approached PBR rendering, so using Arnold made a lot of sense for us.
To that end, I grabbed your assets and made some comparison renders. The first thing I noticed with the doge environment cube was that it looked like it was made in IBLBaker. The Schlick and Smith BRDFs that IBLBaker uses don’t match with the GGX BRDFs that we use, so I rebaked the environment cube in Lys. doge2_cube_specular.zip (1.4 MB) The other issue I have with IBLBaker is that the seaming of the cube at the smaller mips isn’t very good and you can see the seams fairly easily in reflective surfaces.
For the comparison, I did a render from the Reference Renderer, from Arnold, and from Babylon with the same settings and background so that we can compare as close to apples to apples as we can.
The background for all is 128, 128, 128 so that we have a neutral background to help us see any issues. I do see a couple of issues with the 0.75 roughness and 1.0 roughness spheres in the tones they are reflecting. I wouldn’t expect a white base color on an object in this environment IBL to come near the white in the emissive reference chip. At a roughness for the two spheres in question, this is what the Lys environment map looks like:
The type at the top of each mip image is in white, so you can see how far off of white we are. This is the light that is hitting your white material so there’s no way it could get any closer to white than it is. In the reference renderer, you get a hot white rim on the top of the rough spheres reaching around 0.9, 0.9, 0.9 at the very top which does not align with my expectations from the maps I baked. Energy conservation would seem to be off there because we are reflecting more light than is there. The reason that the sky color at that roughness is that dark when the sky is around 1.1, 1.1, 1.1 is because the specular lobe is so broad that that point, we should be sampling more than the sky and would be averaging in colors from the tops of the buildings. However, what I am seeing with the maps generated by IBLBaker is that the environment has some artifacts that cause the hot spot at the top and the dark at the bottom:
This is the mip for roughness 1.0 and you can clearly see that there is a strange star shape at the top and bottom center of the cube. At the top, the color is 1.0, 1.0, 1.0 which accounts for the bright white rim and hotter tones at the top of the spheres that you see in the reference renderer. At the bottom the color is around 0.15, 0.15, 0.15 which accounts for the dark spot on the bottom of the spheres.
I also see a couple of artifacts in the rendering in the Reference Renderer. The below image shows the seams you get from IBLBaker at higher roughness. There is also some sort of banding artifact that I can’t determine a cause for but may be coming directly from the IBLBaker texture which does seem full of banding:
For comparison’s sake, here’s the doge environment rendered on your asset in Arnold:
I rendered this with no bounce and no shadow so that we could compare with our real-time rendering accurately. You can see that the energy conservation in this render is accurate for the rough spheres. Though one thing I don’t like about Arnold is that it seems to go off the rails with energy conservation when rendering rough metallic materials.
This is the same setup with Babylon:
It does look like we may be a little off in our spherical harmonics as we are losing a little energy in the rough dielectric materials. I will work with Seb to see if we can fix this quickly.
I suspect another discrepancy in lighting may be due to the mismatch between the IBLBaker BRDF options of Schlick or Smith versus what the Reference Renderer is using which is the Cook-Torrance model for their BRDF. Here are the differences in the BRDFs:
When calculating the prefiltered environment map the BRDF is used to create scattered sample vectors which are used to determine the final blurring in the mip. I’m guessing that since the renderer is using Cook-Torrance that creating your environment with Schlick or Smith won’t produce prefiltered results that jive with what Cook-Torrance would be expecting.
I hope some of this helps and we will look into our dielectrics but the main difference here seems to be caused by IBLBaker.
4 Likes
@echadwick-artist so it comes from our conversion from harmonics to polynomials and it will be fix by Monday. This will still not appear white at the top but here is how it now looks into babylon:
Which is pretty close from the Ray traced render we consider to be the ground truth.
2 Likes
It has been all deployed, you can now test in the sandbox and compare before after in the inspector:
By toggling the Spherical Harmonics button on and off.
1 Like
Excellent sleuthing! And thanks for all the hard work on this.
This makes me wonder if we should have a default IBL for the Sandbox with a balanced and full range of lighting information, while also not adding color into the ambient lighting.
We want to be able to judge the quality of glTF materials without them appearing under-lit and without a significant color cast.
It’s nice to be able to drag-n-drop a DDS in, but it’s an annoyance to have to do when iterating. Especially since with Max2Bablyon we have Export&Run.
1 Like
@PatrickRyan I guess we could found another Default Environment, just wondering if we should use the studio one instead ?
I leave those choices to you as I totally suck coming down to artistic decisions 
A studio would be ideal for a default environment. I think most of us are showcasing products or single items for the most part in scenes and those that are not can import a more appropriate environment.
Just a ring light and a forward light or something would be perfect for most environments.
1 Like
I can certainly provide our studio environment for people to test out and see if they want to make it the default environment. The main issue with this environment is that using it as the skybox as well is very distracting, so we would need to make a second skybox that matches the light without being so high in contrast. Right now when I use it to render, I usually disable the skybox and set a clear color which is faster, but wouldn’t be as quick if you wanted to export and run.
I’ll start another thread where we can talk about the default environment as a community and get everyone’s feedback. I’ll post the studio environment that we use, which is a Maya render so I can easily make changes to the environment or add multiples to use.
Here is the studio environment we use for our PBR videos:
And it used on an asset:
And the env file for you to use: Studio_Softbox_2Umbrellas_cube_specular.zip (1.5 MB)
I’ll go start the other thread now so please pop over and give your thoughts.
2 Likes
Nice post by @sebavan about this bug
1 Like
Thanks for the addtion of the point light!
Can this be a directional light instead by default, pointing straight down? I think that would be more helpful as an evaluation tool, since it would light assets in a more predictable manner.
Multi-step process to move it upwards, can’t get a consistent result between loads, etc.
Well I can add also an option to create a directional light as well (but pointing down is weird)
Maybe more an hemispheric light?
Hemisphere is not as good as directional for judging model shapes.
I was thinking straight down could be the most universal. But a more aesthetically-pleasing angle would be better… coming from upper left and behind the camera for example.
Here’s a test using point light to simulate a directional, by moving it far away and increasing the intensity. Still not ideal, but this kind of angle would be great.
Ok do you mind adding an issue for it on the repo?
We are in code lock for 4.0 release (this tuesday) but I will add it right after
I guess I can easily add a new option without regression actually
what about a directional light to (1, -1, 1) ?
If you think that angle works OK, then I’m ok with it. I couldn’t figure out BabylonJS rotation values. Filed a bug here: Sandbox rotation type-in weirdness
It will in 4.0-rc2
