My script add many text to scene (look in sample). Time to create TextGeometry greatly increased compared to Three.js v.84
var textGeometry = new THREE.TextGeometry(l, {font: this.defaultFont, size: '2', height: 0});
var text = new THREE.Mesh(textGeometry, this.textMaterial);
text.position.set((p1.x + p2.x) / 2, (p1.y + p2.y) / 2, 0);
return text;
Use TextBufferGeometry, instead.
@mrdoob @Mugen87
It might not be worth it, but In the TextGeometry constructor, for example, instead of this pattern,
this.fromBufferGeometry( new TextGeometry( text, parameters ) );
this.mergeVertices();
we could do this:
var bufferGeometry = new TextGeometry( text, parameters );
this.fromBufferGeometry( bufferGeometry );
this.mergeVertices();
this._bufferGeometry = bufferGeometry.toNonIndexed(); // apparently, non-indexed is expected
which would alleviate the creation of the same geometry three times.
Tempting... But I think I would rather deprecate Non-BufferGeometry code ASAP instead.
Not sure what the strategy for that should be... Maybe rename THREE.Geometry to THREE.LegacyGeometry...?
If users want to manipulate a geometry, THREE.Geometry is easier to use. Is this a not feature we want to retain? THREE.LegacyGeometry gives the impression it is something deprecated and should not be used anymore.
If users want to manipulate a geometry,
THREE.Geometryis easier to use. Is this a not feature we want to retain?
I don't think we can keep THREE.Geometry as it is. Was thinking of giving another try at an object that makes it easy to construct geometry but that maps better to THREE.BufferGeometry. A THREE.GeometryConstructor of sorts...
Most helpful comment
I don't think we can keep
THREE.Geometryas it is. Was thinking of giving another try at an object that makes it easy to construct geometry but that maps better toTHREE.BufferGeometry. ATHREE.GeometryConstructorof sorts...