Why the gltf2.0 model is darker than the gltf1.0?

[Frank-Chan]

Hi Everyone,
I use the following command-line tool to convert dae file to glTF 2.0.
E:\colla\collada2gltf2.1.1>collada2gltf-bin.exe -i E:\daexiangmihujiedao\4403040070061000002_17.dae -o E:\test\dae2gltf\gltf2.gltf
And the following command-line tool to convert dae file to glTF 1.0.
E:\colla\collada2gltf2.1.1>collada2gltf-bin.exe -i E:\daexiangmihujiedao\4403040070061000002_17.dae -o E:\test\dae2gltf\gltf1.gltf -v 1.0

The gltf1.0 and 2.0 file display in the Cesium are as follows

Fig.1 gltf1.0 result

Fig.2 gltf2.0 result
As you can see above, the gltf2.0 file is much darker than the 1.0 one. What's wrong with my command-line ? What should I do to highlight the gltf2.0 file or lighting the model? @lasalvavida @lilleyse

Best Regards,
Frank-Chan

[emackey]

I have a lighting fix in the works for Cesium, see CesiumGS/cesium#6430

[emackey]

Actually your model has a ton of validation errors, are you sure you're using the correct version of the COLLADA2GLTF tool? It doesn't look up to date.

[lasalvavida]

@emackey, the validation errors are from the generated BINORMAL and TANGENT semantics/accessors. The TANGENT accessors should be vec4, so that does need to fixed. It looks like BINORMAL isn't a valid semantic in 2.0?

@Frank-Chan, could you upload your COLLADA model? 2.0 materials are a lossy mapping since COLLADA materials aren't PBR which may explain the color difference, but I'd like to look into it more if you could provide your model.

[emackey]

@lasalvavida Correct, BINORMAL was a common misnomer anyway and should have been called BITANGENT, but no matter, it was removed from the spec and engines calculate it by crossing the TANGENT and NORMAL vectors, and then multiplying by TANGENT.w.

The TANGENT vectors have a 4th component that indicates handedness now. This component will always be 1.0 or -1.0, and can be used to flip the tbn matrix. In practice, the only use case I'm aware of so far happens when model geometry is intentionally mirrored and then flipped (in the modeling tool), resulting in polygons in UV space that wind clockwise instead of counter-clockwise or vice versa. This causes all the indentations to become bumps and vice-versa.

This first came to light (for me) on our DamagedHelmet model, which does not supply tangents, but only half of the helmet has textures. The other half is a mirror of the original geometry, with the normals flipped right-side-out. This means its normal map on the one half is essentially inside-out, with bumps becoming indentations. Later I made a test model "NormalTangentMirrorTest" that has some intentionally mirrored geometry in it, and indeed the tangents (as exported by the Blender exporter) show -1.0 values on the mirrored vertices.

[lasalvavida]

Make sense, thanks for the explanation @emackey.

I've opened up #174 and #175 for these issues.

[lasalvavida]

@Frank-Chan, looking briefly at your outputted glTF, if I had to guess I'd say the difference is due to the use of lights in your COLLADA model. glTF 1.0 had lights, but they were removed as part of 2.0 since it doesn't really make sense for lights to be part of your model; they should be part of your renderer/scene, and the model should just be geometry and materials.

If you really need to use glTF 2.0 with lights, you can try converting your model with -k, or --glsl to use the KHR_materials_common and KHR_technique_webgl extensions respectively.

⚠️ WARNING ⚠️: Please note, that the use of these extensions with 2.0 models is experimental as they are not fully drafted yet. As such, they may not work on any particular loader and generally I would discourage using them with glTF 2.0 until they are completed.

[donmccurdy]

...use the KHR_materials_common and KHR_technique_webgl extensions respectively.

KHR_materials_common is not being updated to glTF 2.0, and is not implemented in any engines. There will be a separate KHR_lights extension for lighting instead.

[lasalvavida]

KHR_materials_common is not being updated to glTF 2.0, and is not implemented in any engines.

That actually isn't true. A glTF 2.0 model with 1.0 materials common should work in Cesium since 1.0 models are mapped to 2.0 in order to display them. This is not really a reliable solution, hence the warning.

There will be a separate KHR_lights extension for lighting instead.

I am aware of that, but since none of these things are ready, I was simply offering a workaround for what @Frank-Chan can do if he needs something that works right now.

[donmccurdy]

Ah I see — thanks for clarifying. Yes KHR_lights is not useable yet so your advice makes sense.

[Frank-Chan]

@lasalvavida This is my COLLADA model which is converted from 3dsMax.
daeghds.zip
By the way, this model is only one in millions of city buildings. All of my models with gltf1.0 are appear brighter in Cesium1.41, 2.0 are appear darker. And I am using the latest version of the COLLADA2GLTF tool(V2.1.1). @emackey

[Frank-Chan]

If you really need to use glTF 2.0 with lights, you can try converting your model with -k, or --glsl to use the KHR_materials_common and KHR_technique_webgl extensions respectively.

@lasalvavida There are no -k options in the command-line.

And I tried the command-line with --glsl, but the gltf model is lost textures in Cesium.

[lasalvavida]

@lasalvavida There are no -k options in the command-line.

My apologies, it's -m. It was -k in the legacy converter.

And I tried the command-line with --glsl, but the gltf model is lost textures in Cesium.

It would appear that Cesium doesn't support KHR_technique_webgl yet and so your model is displayed with the default material. I did warn you that trying to do this with glTF 2.0 may or may not work.

Is there a reason you can't use glTF 1.0 for now, or edit your materials so they look the way you want in unlit conditions for glTF 2.0?

Just to be clear this isn't a bug, the converter is behaving as expected.

[lasalvavida]

This question has been answered, and #174 and #175 address what needs to be fixed on the converter side. Closing. @Frank-Chan, feel free to re-open if you have any more questions.

[Frank-Chan]

Thanks a lot. Just want keep the models update to date.

[lasalvavida]

@Frank-Chan, understandable. It looks like @emackey's Cesium lighting changes which just merged in CesiumGS/cesium#6430 help with this substantially.

[emackey]

Thanks for posting this model BTW, in addition to helping test the lighting it also helped us track down a bounding sphere issue that could have otherwise been introduced to Cesium this month.

[Frank-Chan]

Thanks for your contribution. Yesterday, I downloaded your pbr-lighting branch, and copyed the Build file folder from Ceium V1.44 to your code, but the model is still darker. I'm not sure is this the right operation. @emackey

Fortunately, I find that your pbr-lighting branch has been merged into Cesium master in this morning. Is that mean the 3D tiles model which converted from glTF2.0 will have a brighter lingting just like the picture lasalvavida posted above in the coming new version of [Cesium V1.45]?(https://github.com/AnalyticalGraphicsInc/cesium/blob/master/CHANGES.md#fixes-wrench)

[emackey]

@Frank-Chan Yes, in Cesium v1.45, the model should look like what @lasalvavida posted above.

One caveat I'll point out is that Cesium makes users specify an actual location on the Earth to place the model, and an actual simulation date & time (that defaults to the browser's idea of "now"). If you've placed the model someplace on the planet and then try to view it while that place is in local nighttime, you won't get as much light on the model. In fact there's another change yet to come that makes this night much darker (as currently the models are lit from below, as if the Sun can shine up through the ground, but that light will eventually be turned off).

[Frank-Chan]

Thanks! @emackey
I tried the latest Cesium v1.45, the glTF2.0 model looks a little darker than the glTF1.0, but much brighter than the old Cesium version.

[emackey]

Yep. The glTF 1.0 version was un-lit, so the textures are shown at maximum brightness at all times. The 2.0 version has lighting calculations going on, which makes it a little darker during the day and much darker at night. Try running the Cesium clock fast-forward and back to see the day/night difference.

Keep an eye out for (planned) upcoming Cesium support of KHR_materials_unlit to turn off all the glTF 2.0 lighting, which should make the textures max out like your 1.0 model.