Three.js: Slow TextGeometry creation

Created on 31 May 2017  路  5Comments  路  Source: mrdoob/three.js

Description of the problem

My script add many text to scene (look in sample). Time to create TextGeometry greatly increased compared to Three.js v.84

Code sample

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;

Three.js version
  • [ ] Dev
  • [x] r85
  • [ ] ...
Browser
  • [ ] All of them
  • [x] Chrome
  • [ ] Firefox
  • [ ] Internet Explorer
OS
  • [ ] All of them
  • [x] Windows
  • [ ] macOS
  • [ ] Linux
  • [ ] Android
  • [ ] iOS
Hardware Requirements (graphics card, VR Device, ...)

Most helpful comment

If users want to manipulate a geometry, THREE.Geometry is 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...

All 5 comments

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.Geometry is 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...

Was this page helpful?
0 / 5 - 0 ratings