Which provides better intuition: THREE.Geometry or THREE.BufferGeometry?

Question

THREE.js recently dropped support for THREE.Geometry in favor of exclusively THREE.BufferGeometry. I'm trying to decide which paradigm to teach in my computer graphics course to best provide students with an intuition for the field (I don't mind teaching using an old version of THREE.js if this provides a better understanding).

THREE.Geometry describes 3d geometry in terms of an array of vertices and an array of faces, where each face is a triple of indices into the array of vertices. So for instance, a tetrahedron could be represented as:

geometry.vertices.push(
    new THREE.Vector3(1, 1, 1),//a
    new THREE.Vector3(-1, -1, 1),//b
    new THREE.Vector3(-1, 1, -1),//c
    new THREE.Vector3(1, -1, -1)//d
)
geometry.faces.push(
    new THREE.Face3(2, 1, 0), 
    new THREE.Face3(0, 3, 2),
    new THREE.Face3(1, 3, 0), 
    new THREE.Face3(2, 3, 1)
)

(code from https://sbcode.net/threejs/geometry-to-buffergeometry/)

THREE.BufferGeometry describes 3d geometry as just an array of vertices, where vertices are grouped in threes and automatically turned into faces. If vertices are reused, they have to be listed again.

const points = [
    new THREE.Vector3(-1, 1, -1),//c
    new THREE.Vector3(-1, -1, 1),//b
    new THREE.Vector3(1, 1, 1),//a   

    new THREE.Vector3(1, 1, 1),//a    
    new THREE.Vector3(1, -1, -1),//d  
    new THREE.Vector3(-1, 1, -1),//c

    new THREE.Vector3(-1, -1, 1),//b
    new THREE.Vector3(1, -1, -1),//d  
    new THREE.Vector3(1, 1, 1),//a

    new THREE.Vector3(-1, 1, -1),//c
    new THREE.Vector3(1, -1, -1),//d    
    new THREE.Vector3(-1, -1, 1),//b
]

(code from https://sbcode.net/threejs/geometry-to-buffergeometry/)

Which paradigm is better for first coming to understand computer graphics? My understanding was that the faces-as-lists-of-vertex-indices was a common way of representing 3d geometry, but perhaps the lists-of-vertex-coordinates is more fundamental?

Answer 1

Note that BufferGeometry still supports both indexed and non-indexed meshes. It contains arrays of vertex attributes and indices, and works in non-indexed mode if the indices array is null. You can construct a mesh by setting the attributes and indices directly, as shown in this example.

The tutorial you linked is setting up a non-indexed mesh using a helper method, setFromPoints, but only so that it can obtain flat face normals using computeVertexNormals. If it used an indexed mesh with shared vertices, then it would end up with smoothed normals instead.

Indexed meshes are generally more efficient and are the preferred way of representing meshes in most cases, and I think it would still be important for your students to learn that. However, you could start with non-indexed meshes for pedagogical purposes, and introduce indices later.