Will Geometry be deprecated or maintained along BufferGeometry?

Hi there !

The more I use Three, the more I realize that I will not be able not to use Geometry for my use case, because I need indexed geometry. As I understood MrDoob prefers BufferGeometry because it has better performance, which is normal. As long as it’s possible to convert Geometry to BufferGeometry there is not problem for me, but if in the future the development of Geometry is stopped, I may be in trouble…

Do you have any clue what is the policy regarding Geometry and BufferGeometry ? Will Geometry still be maintained and updated ?

Is there a particular reason you want to keep using Geometry?

I don’t think anyone wants to delete Geometry, or at least not any time soon, so it will continue to be available. However, more features are going to require you to convert it to BufferGeometry before you can use it:

  • must convert before rendering
  • must convert for animation
  • etc.

Conversion to BufferGeometry is possible but it’s a little messy, and will likely give worse performance than using BufferGeometry directly. Geometry may also be moved out of the main library, in which case you’d have to include it in your project separately like the loaders and other things in examples/js. New features will not be added to Geometry.

So… I would recommend trying to use BufferGeometry if you can, and report issues if you have trouble. But if you need Geometry for some reason, it’s not going away any time soon.


That’s what I thought, Geometry support is not really continued…
But there may be something I didn’t grasp about BufferGeometry then.

Is there a way to do that with BufferGeometry ?

    let a = geometry.vertices[ geometry.faces[i]['a'] ];
	let b = geometry.vertices[ geometry.faces[i]['b'] ];
	let c = geometry.vertices[ geometry.faces[i]['c'] ];

You want the position of each vertex in a particular face, then? You’ll need to know whether the geometry is indexed, by checking if geometry.index exists.

indexed geometry

for ( var i = 0; i < geometry.index.count; i += 3 ) {

  var a = new THREE.Vector3(
    geometry.attributes.position.getX( geometry.index.getX( i ) ),
    geometry.attributes.position.getY( geometry.index.getX( i ) ),
    geometry.attributes.position.getZ( geometry.index.getX( i ) ),
  var b = new THREE.Vector3(
    geometry.attributes.position.getX( geometry.index.getX( i + 1 ) ),
    geometry.attributes.position.getY( geometry.index.getX( i + 1 ) ),
    geometry.attributes.position.getZ( geometry.index.getX( i + 1 ) ),
  var c = new THREE.Vector3(
    geometry.attributes.position.getX( geometry.index.getX( i + 2 ) ),
    geometry.attributes.position.getY( geometry.index.getX( i + 2 ) ),
    geometry.attributes.position.getZ( geometry.index.getX( i + 2 ) ),


non-indexed geometry

for ( var i = 0; i < geometry.attributes.position.count; i += 3 ) {

  var a = new THREE.Vector3(
    geometry.attributes.position.getX( i ),
    geometry.attributes.position.getY( i ),
    geometry.attributes.position.getZ( i ),
  var b = new THREE.Vector3(
    geometry.attributes.position.getX( i + 1 ),
    geometry.attributes.position.getY( i + 1 ),
    geometry.attributes.position.getZ( i + 1 ),
  var c = new THREE.Vector3(
    geometry.attributes.position.getX( i + 2 ),
    geometry.attributes.position.getY( i + 2 ),
    geometry.attributes.position.getZ( i + 2 ),


But note that creating so many Vector3 objects is not very efficient either (that’s part of why Geometry is deprecated…). It would be better to reuse the same Vector3 objects and call .set() on them, if you need to do this while rendering.

And all this is assuming you want the Vector3 objects at all. You can also access geometry.attributes.position directly, see BufferAttribute.


OK thanks, it’s more clear now.
It’s a little bit more complicated, but I suppose I should use it if it’s more efficient.

Also, take a look at .fromBufferAttribute() method.


Ow thanks ! I didn’t know this method, this is exactly what I need !

1 Like