glTF 2.0 models appear dark

[lilleyse]

Compared to other glTF viewers out there our models usually appear darker. We should experiment with either:

• Increase the sun/environment lighting brightness
  • Make it configurable?
• Tweak the PBR shader. I believe https://github.com/KhronosGroup/glTF-WebGL-PBR performs all lighting in linear space and outputs in sRGB space, whereas we do everything in sRGB space.

[pjcozzi]

I also think IBL will help here.

Cesium does look much darker, so I am keen on a quick workaround in the meantime.

For example, compare Cesium to the other engines here: KhronosGroup/glTF-Sample-Models#154 (comment)

Perhaps @emackey has a few minutes to spare to work on this? 😄

[cx20]

I tried displaying Polly.gltf in the following version. It seems that it is dark when it is the latest version (v1.44).

Cesium.js v1.43 + Polly.gltf result:

Cesium.js v1.44 + Polly.gltf result:

[pjcozzi]

@lilleyse @cx20 perhaps related to #3737 as well?

[emackey]

The Polly model there (the dog alone) isn't just dark, it's pitch black, even the emissive green lights on the dog have gone out.

git bisect blames my tangent vector fix, 2990c50. It's possible that tangent vectors and skinned animations aren't compatible in Cesium's current implementation, newly broken by adding support for tangent vectors. I'll dig into this.

Other (non-skinned) models look the same as they have before, so I think the Polly/skinned model bug is separate from the general lighting concerns.

EDIT: Cesium (and gltf-pipeline) use a single hasTangents Boolean, that gets set to true if any primitive inside a glTF has tangents. This is a bad assumption for Polly. Polly supplies tangents for everything except the dog (ie the floor, the box, the sign, etc). The dog itself supplies no tangents, and relies on auto-computed tangents for lighting. Cesium won't auto-compute them, now that in 1.44 the supplied tangents are respected, because it sees other tangents elsewhere in the model. Cesium ends up normalizing a zero vector in GLSL, and the fragments turn black.

In addition to hasTangents, Cesium also has a hasMorphTargets Boolean flag, that is likewise globally true for any glTF that contains any morph targets.

It also has a hasNormals flag that is simply hard-coded to true. It is tested several times, but there is no code path that would ever set it to anything other than its initial value of true.

[emackey]

Turns out, Polly actually has a material (named "Head" at index 0) that is used for the eyes, which supply tangents, and the rest of the head, which does not supply tangents. As such, a single shader must handle both cases, or we need to move to per-primitive materials. Or, we use the supplied tangents only when ALL of the affected meshes supply tangents, and ignore supplied tangents otherwise. That last option is the least destructive change, I'll try it first.

[lilleyse]

We already split materials used by multiple primitives by skinning/vertex colors, so it shouldn't be too bad to also split by tangents.

[JackD83]

It seems that this bug has returned between 1.96 and 1.97 till the current 1.101. I have multiple 3DTiles sets that are now completely black.

Polly now looks like this:

[cx20]

@JackD83 Perhaps the reason why it looks dark is that the time of the area displayed by Cesium.js was night.
Below is an online demo using Cesium.js.
https://cx20.github.io/gltf-test/examples/cesium/index.html?url=https://rawcdn.githack.com/KhronosGroup/glTF-Blender-Exporter/dd7a3dbd8f43a79d572e7c45f4215f770bb92a37/polly/project_polly.gltf

BTW, I think the antenna-like things coming out of Polly's ears are artifacts.

[ggetz]

@JackD83 Would you be able to include a Sandcastle example that replicates the issue? That would help us give us more context to determine the issue. Thanks!

[JackD83]

@JackD83 Perhaps the reason why it looks dark is that the time of the area displayed by Cesium.js was night.

You where right (and I feel stupid) . That means polly is fine and its only my own gltf models that are black. I dug a little deeper and the models in question where converted from gltf 1.0 to 2.0 using a custom script. The script set the single texture as emissiveTexture:

"emissiveTexture": { "index": 0, "texCoord": 0 }

This worked up to Cesium 1.96 and results now in a black model.

Using
"baseColorTexture":{ "index": 0, "texCoord": 0 },

inside pbrMetallicRoughness is working.

emissiveTexture probably was wrong from the beginning, but should work nonetheless. The windows gltf viewer and others have no problem with it. We have large datasets and I would rather not have them repacked and redistributed.

You can find a sandcastle with the models here