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