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.

4 Likes

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.

2 Likes

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.

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

1 Like