In the example of the glb model you provided, my shader runs fine and the output is the expected result. This confuses me.
lol yeah! I’m glad you mentioned it 
I was like: well, this is working
Look with the scifi helmet: glTF Loader Demo | Babylon.js Playground
My account has reached the limit of posts, so I changed an account to reply to you.As you modified this example, some parts that should be concave look like convex in the example, which is what I encountered in the demo，
Especially the bullet hole on the side of the helmet, which should be concave in the real world.
you mean in my example it is already not working? else please link the updated PG
You can check out the screenshot of threejs I provided, there are bullet marks on the side of the helmet position, and in the example you provided, the bullet marks look bulging outwards, I don’t know how to fix it. This is why I opened the posting of this topic.
In the previous example of glb, the color bumps and the actual bumps of the normal map correspond to the actual bumps, but it does not match in the example of gltf, which is what makes me confused.
Adding @PatrickRyan and @Evgeni_Popov for a second opinion
Is it us who are having an issue or is it three?
@Deltakosh and @More, I don’t think either Babylon or Three are having issues, but I think that the issue centers around the expected OpenGL, DX normal map formatting which will invert the surface direction (concave vs convex) if it is not corrected for. For example, here is the normal texture rendered on the mesh in the sandbox:
Note that the glTF standard is to author as OpenGL for normal textures which will place lighter values on surfaces pointing up. As you can see the lower edge of the damage is lighter, meaning it is pointing up in the OpenGL orientation. If you look at the texture as authored, it is a little misleading because that part of the model is mapped upside down in UV space. In the left is the authored texture and on the right is the texture wrapped on the model which turns it upright:
But since Babylon uses the DX convention, the green channel of this texture needs to be inverted so it works correctly. We handle that in our shaders because we know the normal texture Y vector will be inverted when loaded from glTF. To fix your render, you simply need to do the same in your shader when reading an OpenGL normal texture in Babylon which expects DX:
Hope this helps to explain it.
Thanks for your explanation. Now I finally understand the reason and solution of the difference.