Incorrect normal export using Blender JSON exporter

[AndrewRayCode]

Description of the problem

Today I've been struggling with exporting a model from Blender to Three.js using the JSON exporter. I don't think the normals are getting exported correctly.

This error seems to happen with any Blender export to .json, but I've included a very simple .blend file containing only a sphere.

Download sphere.blend

I'm using a simple glow shader from ShaderFrog. If you click "edit" you can see the source. Here's how it looks applied to a vanilla Three.SphereGeometry:

The shader correctly applied to a vanilla Three sphere

And here's how it looks when applied to the sphere exported from Blender to JSON:

The shader incorrectly applied to a vanilla sphere exported from Blender

You can see that the shader only appears correct from one angle, but distorted from other angles. The shader is not correctly "sticking" to the edge of the object, as it should based on the normal calculation in the shader source code.

If, in Three.js, if I call mesh.geometry.computeVertexNormals(), which clobbers the normals exported from Blender, then the shader is correct again:

The same Blender exported sphere with normals recalculated by Three

Since normals are corrected and the shader works after calling computeVertexNormals(), I suspect there's a bug in the Blender exporter.

Issue #3221, "Blender Scene Exporter normals wrong" was opened 3 years ago by @willy-vvu. In the issue, he shows an older version(?) of the exporter that includes a "Flip YZ" option:

Not only is this option not available in the current Blender to Three python script (found here), but I can't find any history of the text "Flip YZ" in the git history for the folder containing those scripts. I'm not sure what happened here.

When exporting using Blender's native .obj exporter, and loaded into Three.js the normals are *fine.* Exporting to .obj and importing using the ObjLoader shows correct behavior with the above shader. Exporting the same object using the JSON exporter causes the normal error. Also note that Blender's default .obj exporter gives you an option for "forward" and "up" vectors:

I'm not sure if these are the reason that the .obj export works correctly, but it seems suspicious that flipping vectors was mentioned in an older ticket.

I do not currently have a live running version of the json export using the shader, but I can provide one if it's required for debugging.

Three.js version

• ✅ Dev
• ✅ r75

  Browser

• ✅ All of them

  OS

• ✅ All of them

[makc]

maybe try to split into tris before exporting, might help? although I don't see why would it suddenly start rotate along with the model.

[Scharnvirk]

I have a similar issue:

The left one is exported from Blender using JSON exporter and right one is a basic three BoxGeometry.

I've tried this approach:

mesh.geometry.computeVertexNormals();
mesh.geometry.normalsNeedUpdate = true;

...but it doesn't help with the left cube, instead, if applied to right one, it messes up its normals too, so both cubes look like the left one. I start to think that it is in fact blender export which got it right and BoxGeometry wrong? I am at total loss here.

[AndrewRayCode]

@Scharnvirk that's not related. In Blender you need to set up the normals correctly. Try selecting all faces and on the toolbar on the left, go to shading tab > "faces > flat"

[Scharnvirk]

Thanks. I'll look into that.

A quick test, however, tells me that changing that property in blender doesn't alter exported normals at all though, and I had it at "flat" anyway. And I've recalculated normals after changing the setting. We're talking about "Shading/UVs" tab in the menu available after pressing "T" in Edit Mode, right?

Also, I can show face normals vectors in Blender (they appear as little blue lines coming from the middle of faces) and they don't change at all when changing smooth/flat setting. Isn't it just a display setting in Blender which does not alter normals themselves?

Anyway yeah, "smooth" face setting in blender looks exactly like the exported cube as seen in Three.js. Almost as if blender was always exporting in Smooth mode?

EDIT: this is definitely blender side, so sorry.
I've imported the JSON in Clara.io and it is just as messed up as in three. It is even worse when I upload original .blend file.

[tschw]

And here's how it looks when applied to the sphere exported from Blender to JSON

Looks like a transform gone wrong, vertices got rotated but not the normals or the other way around...

[michaelitvin]

I'm seeing the normals issue again with Three.js r79 blender exporter with Blender 2.77. Reverting commit bb0ff5d solved the problem for me.

[tschw]

@michaelitvin
IIRC bb0ff5d was about solving the issue in other cases. It appears the required transform depends on the export settings. Could you share yours, please?

[dherben]

I've been seeing this issue with the blender exporter since r76. Reverting commit bb0ff5d does indeed fix it. It seems like such an obvious issue that I wonder how not more people are running into this.

I replicated the problem with a simple cube+light setup in blender, exported the scene with different versions of the blender exporter, and loaded with ObjectLoader in the simplest possible configuration.

Below is a screenshot of the result. Left is r74, Right r77. The light (with blue helper) is behind and on top of the cube. The client side version does not matter, only exporter version. Left is ok, right is fubar.

Export settings were the following:

Here are the generated jsons:
jsons.zip

And here is the blend file:
blendfile.zip

I put up a jsbin with the different versions available.

https://jsbin.com/kawaten/edit?html,output

Hope this is useful to someone. I have simply reverted the commit in my fork, and it seems to do everything right. I don't have any animations or bones/armatures stuff in my scenes, which is what prompted this commit in the first place.

[AndrewRayCode]

Blender exporter r80 currently exports all normals with Y and Z flipped. I'm not sure normals have ever been exporting correctly. Here's a script to fix the geometry after importing in Three.js:

            geometry.faces.forEach( face => {
                face.normal = new Vector3(
                    face.normal.x, -face.normal.z, face.normal.y
                );
                face.vertexNormals = face.vertexNormals.map(
                    vn => new Vector3( vn.x, -vn.z, vn.y )
                );
            });
            geometry.normalsNeedUpdate = true;
            geometry.verticesNeedUpdate = true;

[postolka]

JS & jQuery:

function fixNormal(vector) {
    var t = vector.y;
    vector.y = -vector.z;
    vector.z = t;
}
$.each(mesh.faces, function (i, face) {
    fixNormal(face.normal);
    $.each(face.vertexNormals, function (i, vertex) {
        if (!vertex.hasOwnProperty('fixed')) {
            fixNormal(vertex);
            vertex.fixed = true;
        }
    });
});
mesh.normalsNeedUpdate = true;
mesh.verticesNeedUpdate = true;

[feiss]

What I see is differences whether the scene checkbox is activated or not. Here is the default blender plane:

SCENE ON

{
    "materials":[],
    "images":[],
    "geometries":[{
        "type":"Geometry",
        "data":{
            "faces":[33,0,1,3,2,0,0,0,0],
            "uvs":[],
            "normals":[0,1,-0],
            "metadata":{
                "uvs":0,
                "generator":"io_three",
                "normals":1,
                "version":3,
                "faces":1,
                "vertices":4
            },
            "name":"PlaneGeometry.1",
            "vertices":[-1,-1,0,1,-1,0,-1,1,0,1,1,0]
        },
        "uuid":"AFF5F7EC-488A-44E8-BDD6-33C078E71AEE"
    }],
    "metadata":{
        "type":"Object",
        "generator":"io_three",
        "version":4.4
    },
    "textures":[],
    "object":{
        "type":"Scene",
        "children":[{
            "name":"Plane",
            "uuid":"BF37A9AA-BEC3-46CA-A82C-647FAD63807F",
            "matrix":[-1,0,0,0,0,0,1,0,0,1,0,0,0,0,0,1],
            "visible":true,
            "type":"Mesh",
            "castShadow":false,
            "receiveShadow":false,
            "geometry":"AFF5F7EC-488A-44E8-BDD6-33C078E71AEE"
        }],
        "uuid":"D0BD86CC-9DE4-4265-9464-7F47E5900083",
        "matrix":[1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1]
    },
    "animations":[{
        "tracks":[],
        "name":"default",
        "fps":24
    }]
}

SCENE OFF

{
    "faces":[33,0,1,3,2,0,0,0,0],
    "uvs":[],
    "normals":[0,-0,-1],
    "metadata":{
        "type":"Geometry",
        "uvs":0,
        "generator":"io_three",
        "normals":1,
        "version":3,
        "faces":1,
        "vertices":4
    },
    "name":"PlaneGeometry.2",
    "vertices":[-1,0,1,1,0,1,-1,-0,-1,1,-0,-1]
}

in the scene mode, vertices coordinates are not flipped, but normals are ok (0,1,-0). If scene is not checked, vertices coords are flipped, but normals are not. Is his the expected behaviour?

[mrdoob]

Is his the expected behaviour?

It definitely is not the expected behavior. It's now a long standing bug...
This observation probably makes it closer to get it finally fixed though!

[mrdoob]

Can you see the same behaviour when exporting as BufferGeometry instead of Geometry though?