`r100`

has been mentioned as the target release for removing support for rendering `THREE.Geometry`

.

That means you can instantiate an instance of `THREE.Geometry`

, but you will have to convert it to `THREE.BufferGeometry`

prior to adding it to the scene.

~~By my notes, the remaining examples where ~~`Geometry`

is rendered are `webgl_materials.html`

and `svg_sandbox.html`

. I believe in all other examples where `Geometry`

is used, `Geometry`

is instantiated, but not rendered.

~~Also, to do is #14608 — an important one.~~

I would also suggest renaming `THREE.Geometry`

to `THREE.LegacyGeometry`

.

At some point, `THREE.BufferGeometry`

can become `THREE.Geometry`

, but that would be in the distant future.

`webgl_modifier_subdivision`

is another one^^. Fixing…We now have examples divided into two sections with different naming schemes. These don’t really make sense any more.

Actually they haven’t for a while since we’ve been updating lots of the

`geometry / xyz`

examples to use`BufferGeometry`

, but now is a good opportunity to unify these as well.My vote would be to call them all

`geometry / xyz`

## webgl

geometry / colors

geometry / colors / lookuptable

geometry / convex

.etc

## webgl / advanced

buffergeometry

buffergeometry / constructed / from / geometry

buffergeometry / custom / attributes / particles

buffergeometry / drawcalls

If breaking the links is something that people want to avoid, we should at least update the names.