THREE.Geometry will be removed from core with r125


It’ll work.


What’ll happen to methods such as mergeVertices() or computeVertexNormals() ? I certainly wouldn’t mind you lot rolling them into THREE.BufferGeometry, rewriting them myself for Buffergeo would be nigh impossible I think

1 Like

What’ll happen to methods such as mergeVertices() or computeVertexNormals()

A mergeVertices function is available in the BufferGeometryUtils script in examples. Once vertices are merged you can generate vertex normals – they might not wind up being identical to what you see with Geometry.mergeVertices because the BufferGeometryUtils.mergeVertices function cannot merge vertices that do not share exact buffer attributes but it should give a similar result in most cases.

I just had a premonition that THREE.Face3 may meet the same fate.
“♫ oh no!, oh no!, oh no no no no no no no!”

See Raycaster: BufferGeometry with new Face3 - #4 by Mugen87


In 2016-2017 I had programmed my addon with Geometry. After a hint from @Mugen87 I realized the addon with indexed and non-indexed BufferGeometry. With such a somewhat extensive project one must make then nevertheless some adjustments, e.g. with the normals. I documented this at the time.

See Addon. Produces almost infinite many time-varying geometries with functions - #12 by hofk
Some more pictures on page 5 of the german forum.,html,js/3d-grafik-webgl-mit-three-js/?&pg=5

In the source code on Github you can compare the variants.

Does it possibly make sense to build a helper function that allows to emulate the behavior of Geometry at BufferGeometry 1 to 1?

May I ask how you are using THREE.Face3 in your code?

Like mentioned in the other thread, three.js still uses THREE.Face3 as a data structure in context of raycasting.

I wont be using it since r125.

But I will be curious of its usefulness in the raycaster after r125 is released. I will give it a try when it happens.

Out of curiosity, how will the SubdivisionModifier work after Geometry is removed? I’m using it right now, and it shows that it needs to convert to Geometry to work


Looks like the solution has been to remove it from the examples. Maybe they’d consider readding it if a proper subdivision modifier class can be provided for BufferGeometry?

1 Like

I think it’s better when a new modifier is added to a separate repository. Related: Examples: Remove SubdivisionModifier. by Mugen87 · Pull Request #21072 · mrdoob/three.js · GitHub


Perhaps someone could finish the work described by Porting a minimalist OpenSubDiv to JavaScript? · Issue #247 · PixarAnimationStudios/OpenSubdiv · GitHub and get OpenSubdiv compiled to WASM. That’s a robust subdivision implementation, and would be valuable to have available in the web ecosystem.


It’s guaranteed not to be done by the time THREE.Geometry shuts down, but I already have a concept and a start. Everything is not final yet and can be changed at any time.

There the draft: *
see BeginnerExample

Does the concept make sense? What should be changed? :thinking:

It should remain as manageable as possible. The 20 steps are no standard and easily adaptable.

What else should be included? I thought of

modified standard geometry
dynamic geometry
text / canvas text
calculation uv coordinates
camera movement
instanced mesh
video texture
simple shader

Suggestions are welcome.


not sure if this is a bug or not

my BufferGeometry does not have a clone() function i generate the input BufferGeometry for the
SimplifyModifier with:

const geometry = new THREE.BufferGeometry()
geometry.setAttribute( ‘position’, new THREE.BufferAttribute( result, 3 ) );
geometry.setAttribute( ‘uv’, geo.getAttribute( “uv” ) );
geometry.setIndex( indices );

removing the geometry.clone() from the SimplifyModifier.js#L404 do the trick

But a clone() method does exists for BufferGeometry:

Can you please demonstrate the issue with a live example?

1 Like

copy looks like there error comes from three.js/BufferGeometry.js at bd095516a119979c9e3684e9f577028506240136 · mrdoob/three.js · GitHub

It’s possible that the BufferGeometry contains interleaved attributes, and some old code is present in that demo from prior to our adding support for cloning interleaved attributes? This should probably be debugged in a new thread I think.


you are right the BufferGeometry have interleaved attributes from glb Model with meshopt

no the problem was undefined uv attribute, all works fine

I’m drawing lines and using TypeScript. Geometry was removed from the Three namespace so I can’t use the static methods on the class as you suggest in the migration section @Mugen87. Is this a bug in the type definitions or am I missing something?

Both methods were added to the d.ts file here: