Strange normals/faces when rendering in three.js

[nmattia]

Hi,

I'm trying to use this project to perform boolean operations on 3D models rendered in three.js. The boolean operations work perfectly, it's absolutely great!

I've tried to follow the three.js example (and the editor) and I've got to the point where I can render models but the lighting is off, and I suspect something is wrong in the way I convert the manifold mesh to the three.js geometry. Here's an example, where the cube on the right is from a BoxGeometry (three.js) and the cube on the left is a cube from manifold-3d:

Screen.Recording.2024-03-19.at.23.24.09.mov

The light points to the origin (between the cube) from the above. This is the code I'm using:

const material = new THREE.MeshLambertMaterial({
  color: 0x00ddff,
});

const { Manifold: { cube } } = await ManifoldModule;

const geom1 = mesh2geometry(cube(20));
geom1.computeVertexNormals();
const mesh1 = new THREE.Mesh(geom1, material);
mesh1.position.x = -20;
scene.add(mesh1);

const geom2 = new THREE.BoxGeometry( 20, 20, 20 );
const mesh2 = new THREE.Mesh(geom2, material);
mesh2.position.x = 20;
mesh2.position.y = 10;
mesh2.position.z = 10;
scene.add(mesh2);

The mesh.position stuff is just to align the cubes. Without recomputing the normals on geom1 (the cube from manifold-3d) the cube is completely black. When recomputing the normals (geom1.computeVertexNormals() above) I get this odd light reflection on the sides. The example code uses a different material (MeshNormalMaterial) but for sanity checking I decided to try to reproduce the basic three.js cube with the basic three.js material.

This is the translation code I stole from one of the examples but I suspect something got lost in translation:

export function mesh2geometry(manifold: Manifold): THREE.BufferGeometry {
  const mesh = manifold.getMesh();
  const geometry = new THREE.BufferGeometry();
  geometry.setAttribute(
    "position",
    new THREE.BufferAttribute(mesh.vertProperties, 3),
  );
  geometry.setIndex(new THREE.BufferAttribute(mesh.triVerts, 1));
  return geometry;
}

I'm pretty sure I fixed this exact issue many times in OpenGL many years ago which is terribly frustrating!

[elalish]

I'm not sure what Three's computeVertexNormals is doing, but it's probably not what you want - I'd guess they're just computing average normals for each vert, thus giving a weirdly smoothed appearance.

As for the translation code, you'll notice that it doesn't save normals at all - hence black. I'm just in the process of building some APIs into Manifold to help handle normals, see ComputeNormals() in #771. You'll need to use our properties API, which is agnostic to what kind of data you store in it, so you'll need to choose some channels for normals and then read them into Three.js. You can also copy normals from Three.js into a mesh to pass to Manifold.

[nmattia]

And here are the same cubes with a VertexNormalHelper:

[nmattia]

Actually I realized that with one small change to mesh2geometry I can trade some space for automatic normals with .computeVertexNormals():

export function mesh2geometry(manifold: Manifold): THREE.BufferGeometry {
  const mesh = manifold.getMesh();
  const geometry = new THREE.BufferGeometry();
  const verts: Float32Array = new Float32Array(3 * mesh.triVerts.length);

  mesh.triVerts.forEach((ix, i) => {
    verts[3 * i + 0] = mesh.vertProperties[3 * ix + 0];
    verts[3 * i + 1] = mesh.vertProperties[3 * ix + 1];
    verts[3 * i + 2] = mesh.vertProperties[3 * ix + 2];
  });

  geometry.setAttribute("position", new THREE.BufferAttribute(verts, 3));
  return geometry;
}

[elalish]

I'd strongly recommend against that approach - that's STL-style, where every vert is duplicated - on average 6 times. Takes more memory, slower to render. As I say, with this approach you're not making use of normals anyway - you're doing flat shading. There is a much more efficient shader for that that doesn't use normals at all - see https://threejs.org/docs/index.html?q=mater#api/en/materials/MeshStandardMaterial.flatShading

[hrgdavor]

I am glad personally this discussion is happening here.

I am learning some nice details about threejs related to what I need for CAD. My current solution for integrating manifold was to calculate normals. It is great to know there is a better way :)

[nmattia]

I am learning some nice details about threejs related to what I need for CAD.

Same here!!

I'd strongly recommend against that approach

I'll definitely switch over to CalculateNormals once it's released -- again, happy to do some beta testing if you'd like! In the meantime that means I'm unblocked and can experiment with all materials.

you're doing flat shading. There is a much more efficient shader for that that doesn't use normals at all

Ah, so that's what flat shading means. Thank you!

[nmattia]

Thank you for the quick answer!

the translation code [...] doesn't save normals at all - hence black.

Yup, makes sense!

I'm just in the process of building some APIs into Manifold to help handle normals

That's a weird coincidence, but I'll take it! Is this ready to use or should I wait a bit for further work/polishing/release? I'm happy to do some alpha testing if necessary if you give me the nix invocations to get a library I can just npm install.

You can also copy normals from Three.js into a mesh to pass to Manifold.

Here I get a bit lost. Would I not be using this new API you are developing to compute normals in Manifold to then pass to Three.js (i.e. the other way around)?

And out of curiosity, what is the fundamental difference between what I'm doing here and these beautiful normals you got going in the editor? Even when using MeshNormalMaterial I didn't get anything this nice.

[elalish]

Ah, if what you want is the look in our Editor, then you don't want any normals at all. Note that it's all faceted - no smooth interpolation. I just use the Three.js GLTFLoader with no normals and this is what comes out. That's all meshPhysicalMaterial, so give that a try with an environment light.