Gltf-blender-io: Normal export seems incorrect (Blender 2.79 and 2.8)
Importing a gltf file exported from Blender 2.79 or 2.8, normals do not conform to the one of the created object.
On the left the object created in Blender, on the right the same object exported and reimported.
Same result imported into Godot: normals are not correct.
It seems that the vertex and face normals are ok, but not the edge normals.
Attached the blend file and the gltf file.
TheMoye
All 8 comments
If one solves the autosmooth manually, the export is correct.
At the moment, the exporter is not automatically "solving" the autosmooth.
UX3D-nopper
on 17 Jan 2019
Is it a problem with autosmooth? If so, it might be relevant that autosmooth was ignored when exporting until 85d2490c7ca97ed2a5aacd3359d8208d3dcb88e7 (merged in f97ae8220fbbdd465e2008980115e45d8fddd151).
Cyp
on 18 Jan 2019
Indeed, I just looked at 2.8, no matter if the autosmooth is checked or not when exporting, it is checked for import.
The angle value is also not kept.
The "Shade Smooth" or "Shade Flat" option seems to be respected.
But in addition to autosmooth, normals always seem to have a problem: if I export two models with the "shade smooth" and Autosmooth (30掳) options enabled, and one of them has normal customs (with the Weighted Normal modifier, applied before export), when importing the model with normal customs has different normals from the exported model. While the one without normal customs has the same normal before and after import.
Another strange thing: there seems to be an automatic triangulation of the faces, without any option during import or export (export from Blender 2.8 and 2.79, import into 2.8). Maybe when importing into 2.8 (only for the latest builds, I didn't notice this behavior when I created this thread)?
edit: triangulation seems to be done on export, my object is triangulated when I import it into Godot
edit 2: looking at the images I posted above, the triangulation seemed already present, I just had to ignore it :D
TheMoye
on 18 Jan 2019
Hey,
I just wanted to know if there are any plans to solve this issue? The only workaround our studio found is exporting model as FBX and convert it to GLTF using Clay Viewer (https://github.com/pissang/clay-viewer).
JohnnieWooker
on 21 Jan 2019
I've been researching this. Blender doesn't make this simple, but, there are things we need to fix in the exporter to get this working better.
Let's start with a quick refresher on the intentions of the glTF format: It's a delivery format, not an asset interchange format. The internal structure of glTF, particularly of its binary section, is as close as possible to typical GPU data, ready-to-render. This means there are no quads or Ngons in glTF, only triangles, as graphics hardware under the hood only renders triangles. The triangles come from a pool of vertices, and each vertex can have "vertex attribute" data associated with it, such as one normal vector, one tangent vector, one UV per UV map in the material, etc. There's an implication here about what Blender users would consider "shared" vertices. Blender, like most 3D tools, has a concept of per-vertex-per-face normal vectors (where a single vertex appears to have different normals on different adjoining faces). Blender likewise can show different UVs _from the same UV map_ on a per-vertex-per-face basis. This is needed for example by cylindrical UV mapping, where one edge is the "seam" that has the 1-to-0 discontinuity down one side. This whole concept of "per vertex per face" is just at the application level though, the underlying graphics hardware has no such concept, and so neither does glTF (by design, it mirrors what the underlying hardware needs to render). Preserving the "per face" aspect is done in glTF the same way it's done for hardware, by splitting into separate vertices under the hood.
Try importing the Water Bottle sample into Blender 2.80. The texture is like a cylinder, and the Blender +Y side hides a seam where the vertices have been split to allow for discontinuous UVs along the edge of the texture. But we don't see a seam in Eevee or Cycles, why not? The glTF model includes normal vectors that define smooth shading everywhere, including along the seam, and the Blender Importer has brought these normals in as "Custom Split Normals Data."
Blender thinks of these as user-defined normal data. They obviously don't match flat shading, but interestingly they don't match smooth shading either, because those vertices along the edge really are duplicated as a result of the lack of per-vertex-per-face data. If you clear the custom normals, you'll see a tiny bit of flat shading appear, along one edge loop running down the +Y side of the bottle where the vertices are duplicated. Actually if you "remove double vertices" you'll see the seam vanish as Blender reinstates the per-vertex-per-face UV mapping, but of course this only moves us a step farther from how the data needs to be stored in glTF.
There's a quirk of Blender at play here as well: Blender's "Custom Split Normals Data" (ie, customized or user-edited normals) are only visible when the "Auto smooth" checkbox is enabled, and on top of that, the angle setting that normally governs the "auto" portion of auto-smooth is darker gray because it's being overridden by the custom normals. Blender actually offers a whole menu in edit mode, under Mesh->Normals with things like rotate, point to target, etc., for hand-editing of individual normal vectors, but these options only work when "Auto smooth" is checked, because these options all operate in the custom normal data (and will create that data if it doesn't exist).
Long story short, the Blender importer is doing the "correct" thing, as best it can, taking vertex normals from glTF, applying them as Blender's custom normal data, and turning on Auto smooth not for the sake of automatically calculating anything, but merely as a prerequisite for Blender to enable the custom normal data. So the glTF normals are previewed and rendered in Blender.
The exporter, however, doesn't appear to be storing custom normal data in the output glTF. To make matters worse, the custom data has the ability to be per-vertex-per-face, meaning the exporter would need to be smart enough to split these vertices in the glTF for any that differed per-face. I need to check if the exporter is already doing that for per-vertex-per-face UVs, because if so, some similar functionality could probably be used for the normals (and tangents).
emackey
on 26 Jan 2019
Because I needed custom normals for a project, I tested different glTF exporters for Blender 2.79.
This one https://github.com/Kupoman/blendergltf exported them correctly.
Maybe it could be some inspiration.
Testfile: https://github.com/aframevr/assets/blob/gh-pages/controllers/microsoft/default/right.glb
marcatec
on 11 Mar 2019
Thanks to @pjoe this problem seems to be fixed in #414.
My tests with the mentioned glTF file result in correctly exported custom normals.
marcatec
on 10 Apr 2019
export obj file instead fbx worked for me , but fbx export still wrongly export vertex normal
MunoDevelop
on 5 Oct 2020
Related issues
UX3D-nopper
路
3Comments
viperscape
路
3Comments
scurest
路
4Comments
rainclaws
路
3Comments
spiraloid
路
5Comments
Most helpful comment
I've been researching this. Blender doesn't make this simple, but, there are things we need to fix in the exporter to get this working better.
Let's start with a quick refresher on the intentions of the glTF format: It's a delivery format, not an asset interchange format. The internal structure of glTF, particularly of its binary section, is as close as possible to typical GPU data, ready-to-render. This means there are no quads or Ngons in glTF, only triangles, as graphics hardware under the hood only renders triangles. The triangles come from a pool of vertices, and each vertex can have "vertex attribute" data associated with it, such as one normal vector, one tangent vector, one UV per UV map in the material, etc. There's an implication here about what Blender users would consider "shared" vertices. Blender, like most 3D tools, has a concept of per-vertex-per-face normal vectors (where a single vertex appears to have different normals on different adjoining faces). Blender likewise can show different UVs _from the same UV map_ on a per-vertex-per-face basis. This is needed for example by cylindrical UV mapping, where one edge is the "seam" that has the 1-to-0 discontinuity down one side. This whole concept of "per vertex per face" is just at the application level though, the underlying graphics hardware has no such concept, and so neither does glTF (by design, it mirrors what the underlying hardware needs to render). Preserving the "per face" aspect is done in glTF the same way it's done for hardware, by splitting into separate vertices under the hood.
Try importing the Water Bottle sample into Blender 2.80. The texture is like a cylinder, and the Blender +Y side hides a seam where the vertices have been split to allow for discontinuous UVs along the edge of the texture. But we don't see a seam in Eevee or Cycles, why not? The glTF model includes normal vectors that define smooth shading everywhere, including along the seam, and the Blender Importer has brought these normals in as "Custom Split Normals Data."
Blender thinks of these as user-defined normal data. They obviously don't match flat shading, but interestingly they don't match smooth shading either, because those vertices along the edge really are duplicated as a result of the lack of per-vertex-per-face data. If you clear the custom normals, you'll see a tiny bit of flat shading appear, along one edge loop running down the +Y side of the bottle where the vertices are duplicated. Actually if you "remove double vertices" you'll see the seam vanish as Blender reinstates the per-vertex-per-face UV mapping, but of course this only moves us a step farther from how the data needs to be stored in glTF.
There's a quirk of Blender at play here as well: Blender's "Custom Split Normals Data" (ie, customized or user-edited normals) are only visible when the "Auto smooth" checkbox is enabled, and on top of that, the angle setting that normally governs the "auto" portion of auto-smooth is darker gray because it's being overridden by the custom normals. Blender actually offers a whole menu in edit mode, under Mesh->Normals with things like rotate, point to target, etc., for hand-editing of individual normal vectors, but these options only work when "Auto smooth" is checked, because these options all operate in the custom normal data (and will create that data if it doesn't exist).
Long story short, the Blender importer is doing the "correct" thing, as best it can, taking vertex normals from glTF, applying them as Blender's custom normal data, and turning on Auto smooth not for the sake of automatically calculating anything, but merely as a prerequisite for Blender to enable the custom normal data. So the glTF normals are previewed and rendered in Blender.
The exporter, however, doesn't appear to be storing custom normal data in the output glTF. To make matters worse, the custom data has the ability to be per-vertex-per-face, meaning the exporter would need to be smart enough to split these vertices in the glTF for any that differed per-face. I need to check if the exporter is already doing that for per-vertex-per-face UVs, because if so, some similar functionality could probably be used for the normals (and tangents).