FBXLoader inverts geometry if Lcl Scaling is negative

[looeee]

I'm attempting to load a complex rigged model, and finding that some parts of the geometry appear to have flipped normals, as you can see here:

However, the normals on the flipped parts of the geometry are actually correct, and neither inverting them nor applying double sided material fixes the issue. Aside from this, I checked the model in Windows Paint3D and it loads correctly.

So, I isolated the two feet, and then took a single polygon from each, scaled them and rotated them to match and positioned them both at (0,0,0). At this point the only difference I can see in my modelling program are the pivots being oriented differently. But when I load them with the FBXLoader, I get this:

Polygon from left foot, displays correctly and is affected by lights

Polygon from right foot, has the same material, position, scaling, orientation etc but displays dark grey and is not affected by lights

The two FBX files, one polygon from each foot, are here
foot pieces.zip

And running them through a diff checker, the only important difference I can see is the line:

Left foot (correct)

P: "Lcl Scaling", "Lcl Scaling", "", "A",1.00000095367432,0.999999701976776,1.00000035762787

Right foot (incorrect)

P: "Lcl Scaling", "Lcl Scaling", "", "A",-1.00000107288361,-0.999999761581421,-1.00000035762787

Sure enough, removing the minus signs from this line causes the model to load correctly.

[looeee]

Applying the obvious fix to the FBXLoader:

if ( 'Lcl_Scaling' in node.properties ) {

      var scaleFactor = parseFloatArray( node.properties.Lcl_Scaling.value );

      scaleFactor[0] = Math.abs( scaleFactor[0] );
      scaleFactor[1] = Math.abs( scaleFactor[1] );
      scaleFactor[2] = Math.abs( scaleFactor[2] );

      model.scale.fromArray( scaleFactor );

    }

...fixes the inverted geometries. However now the foot the objects that were previously flipped inside out are flipped in other ways:

[WestLangley]

three.js does not support reflections in the object matrix; reflections leave the vertex normals and winding order in an inconsistent state. The normals will look correct, but the winding order is reversed.

[mrdoob]

What did you exported it with? In 3DMax there used to be an option called Reset XForm that fixed this kind of stuff.

[mrdoob]

Aside from this, I checked the model in Windows Paint3D and it loads correctly.

Hmm...

[looeee]

@WestLangley thanks - that explains the appearance.

So it appears that FBX uses reflections as a way of transforming geometry, and assumes that the rendering software will support it. Since it's not supported in three.js that puts us in a bit of bind here.

My trigonometry is a bit rusty, but I don't think there is any way of representing a reflection as a series of rotations or other operations. Can you see any kind of workaround here?

[looeee]

What did you exported it with? In 3DMax there used to be an option called Reset XForm that fixed this kind of stuff.

Yes, I'm exporting from 3ds max, and I've already tried the reset Xform trick. It doesn't fix this, unfortunately.

Also tried tried every other modifier I can think of as well as converting to editable poly or editable mesh before exporting.

[looeee]

Here are the feet in 3DS Max. It looks like the right foot was created by mirroring the left.

[WestLangley]

I believe in the official OBJ format -- for example -- the front face is determined by the face normal or vertex normals when specified. three.js/webGL uses the winding order to determine the front face.

After loading, you could try traversing your model and flip the winding order for all faces having matrixWorld with a negative determinant. But that is just a guess.

We should identify all loaders/formats from other vendors that handle this sort of thing (with examples) and figure out what technique they use.

[looeee]

OK, I have successfully loaded the model with the following software:

Paint3D

SketchFab (animations also play correctly here)

Clara.io (didn't test animations here)

I also tried loading it in Blender (latest version), but it's complete mess there no matter what settings I use.

[makc]

tried loading it in Blender

off topic, but nao robot has official blender file somewhere on github. here's one copy.

[looeee]

@makc thanks - that a much less detailed model though, and it's not rigged as far as I can see. I'm not very familiar with blender and learning how to set up rigging there in the time I have really won't be possible. I appreciate the suggestion though! 😄

[looeee]

Note: I deleted a previous version of this comment as there was an error in my code.

@WestLangley I implemented your suggestion to invert winding order for the geometry of meshes whose .matrixWorld determinant is negative, and it seems to work.

object.traverse( ( child ) => {

  if ( child instanceof THREE.Mesh ) {

    if ( child.matrixWorld.determinant() < 0 ) {

      const geom = new THREE.Geometry().fromBufferGeometry( child.geometry );

      for ( let i = 0; i < geom.faces.length; i++ ) {

        const face = geom.faces[i];

        const tempA = face.a;

        face.a = face.c;
        face.c = tempA;

        child.geometry = new THREE.BufferGeometry().fromGeometry( geom );


      }

    }

  }

} );

The results look pretty good, but there are a couple of issues - the first is that is's sloowww - around 26 seconds for the robot mesh.

Second is that it breaks smoothing.

I've tried fixing this by running .computeVertexNormals() and / or .computeFaceNormals() on the intermediate geometry. .computeVertexNormals() actually re-inverts the geometry (although unfortunately running it on it's own without reversing the winding order doesn't fix things).

[WestLangley]

First of all, don't instantiate new geometry; modify the existing geometry.

Second, if there are false positives, then that isn't the correct test.

[makc]

• what's the point of running this on all meshes, when you know exactly which ones have a problem?
• what's the point of converting to geometry? just swap evry 2nd and 3rd position and normal in BufferGeometry

it breaks smoothing

of course, you did not swap normals