Docs: Update comparison of BufferGeometry vs Geometry?

[donmccurdy]

Current language:

This class is an efficient alternative to Geometry, because it stores all data, including vertex positions, face indices, normals, colors, UVs, and custom attributes within buffers; this reduces the cost of passing all this data to the GPU.

This also makes BufferGeometry harder to work with than Geometry; rather than accessing position data as Vector3 objects, color data as Color objects, and so on, you have to access the raw data from the appropriate attribute buffer. This makes BufferGeometry best-suited for static objects where you don't need to manipulate the geometry much after instantiating it.

Is this still how we want to compare these, especially if we want to move toward putting Geometry in examples/js? The last paragraph particularly sounds to me like we're recommending Geometry for dynamic objects, and I don't think that's the case... perhaps we'd change to something like:

An efficient representation of mesh, line, or point geometry. Includes vertex positions, face indices, normals, colors, UVs, and custom attributes within buffers, reducing the cost of passing all this data to the GPU.

To read and edit data in BufferGeometry attributes, see BufferAttribute documentation.

For a less efficient but easier-to-use representation of geometry, see Geometry.

(context on Stack Overflow)

[Mugen87]

The last paragraph particularly sounds to me like we're recommending Geometry for dynamic objects, and I don't think that's the case.

Yes, the current wording is somewhat misleading. I like your suggestion since it's clear and compact.