Matching renders in Blender and Hubs

[rawnsley]

I am trying to match Blender Cycles renders in Hubs as closely as possible and specifically to make sure that lightmaps are being applied correctly and consistently between material types. To this end I thought it might be useful to establish a "ground-truth" Blender project to compare so we can decide what we would expect to see in Hubs vs what we currently see.

Assumptions

Consider a simple scene where the light source is an environment map of a band of light at the horizon:

There is a stack of eight cubes with different material combinations of lightmaps, lit vs unlit, and gray vs white. You can sort of see the arrangement here:

A black bar is positioned in front of the lower row to provide a shadow and some contrast for the lightmap.

The intensity of the pixels in the environment map has been adjusted carefully in Blender such that the lit cube faces are nearly exactly the same color as the the unlit ones, i.e. the env map is providing a unit level of irradiance to the cube faces. This is corroborated by the lightmap, which has a value of 1.0 anywhere outside of the shadow.

Expectations

We would expect all the gray cubes to be the same color and all the white cubes to be the same color. What we see when using the master branch (at time of writing) is this:

Observations

1. The gray cubes in the top row do not match. This is probably due to the MeshStandardMaterial being PBR and including specular contributions even when the roughness is 100% and the material is black. You can see the same in the supposedly jet black shadow bar and you can reproduce this situation in this example.
2. The lit lightmapped materials are significantly darker than the unlit ones. I think this is because the PI multiplier needs to be applied to correct for the rendering pipeline issues discussed at length elsewhere. It has been applied to the MeshBasicMaterial already here.
3. The environment map background should be pure white. The pixel intensity is over 15 and I suspect something is clipping this back to the range 0..1 before the tone mapping is applied.

Source Files

Blender and GLB files
Hubs Scene

[netpro2k]

1. The gray cubes in the top row do not match.

Your observation and reasoning i'm pretty sure is correct, I think I cam to the same conclusion at some point: https://discord.com/channels/498741086295031808/535638871392649226/897564844444749914

I think I tested setting this to 0 and that made them look the same https://github.com/mrdoob/three.js/blob/dev/src/renderers/shaders/ShaderChunk/lights_physical_fragment.glsl.js#L45

Not 100% sure why this fudge factor exists which makes me a bit reluctant to just remove it. I need to look into options.

2. The lit lightmapped materials are significantly darker than the unlit ones.

This I am definitely aware of, its basically impossible right now to create a lightmap that looks the same in low/high quality mode. The ThreeJS patch (which I proposed) made it so that they are at least both the same (which we inverted again in Hubs in #5566 to retain backwards compat with existing scenes). What we actually want now after this ThreeJS patch is for both to be multiplied by pi for the lighmaps we get out of Blender. I think my planned fix is still going to be to only automatically apply pi to PBR materials exported after some particular (new) release of the Blender addon, so that old scenes don't suddenly become blown out after the artist already compensated for it.

3. The environment map background should be pure white

Not following this one can you explain a bit further?

[rawnsley]

1. Ah yes! I remember that conversation and it fits the facts; my guess is that this behaviour is canonical PBR in which case probably best left as is. I might hack it out temporarily to check and expose any other factors.
2. Good idea about the version detection. I think that’s the last piece of the light map puzzle.
3. I’ll confess a limited understanding of tone mapping. I can understand that a pixel with intensity 1 might be scaled down for aesthetic purposes, but if the pixel intensity is far brighter than that (15 in this case) then you want the eventual screen pixel to be the maximum possible value in a best-effort attempt to convey this extreme brightness despite the limitations of the monitor. The tone map function should turn that 15 to a 12 (say) and then it’s clipped to 1 for output. I think the clipping is happening before it’s sent to the tone mapping stage and so 15 becomes 1 and then that is mapped to something like 0.8.