10

As I understood using buffer geometries will increase performance and decrease memory usage because it reduces the cost of passing all this data to the GPU.

And as I understood from @WestLangley his post here:

THREE.BufferGeometry is slowly replacing THREE.Geometry as it is computationally more efficient.

I am currently using three.js - r72.
When I draw my geometries make meshes and add them to the scene I see that there are two properties inside my geomtries __directGeometry and _bufferGeometry.

Here in a THREE.BoxGeometry:

enter image description here

Here in a THREE.Geometry:

enter image description here

Here in a THREE.ShapeGeometry:

enter image description here

My questions:

  1. What is a THREE.DirectGeometry and what does it do? (I cannot seem to find any documentation on this)
  2. Is this THREE.BufferGeometry stored in _bufferGeometry already automatically used? If not, can I simply use it instead of my geometry to boost performance?
  3. There are conversion methods: THREE.BufferGeometry has toGeometry and THREE.Geometry has toBufferGeometry. If I convert all my normal geometries to buffer geometries using this method, will it give me the same performance increase compared to drawing them as a THREE.BufferGeometry from the start?
  4. How and when should I use THREE.BufferGeometry?
  5. When will three.js stop supporting THREE.Geometry in favor of THREE.BufferGeometry?

NOTE: I couldn't find detailed information on when and how to use buffer geometries or when it is going to be replacing THREE.Geometry. But if someone has a good source or reference please leave a comment.

Community
  • 1
  • 1
Wilt
  • 41,477
  • 12
  • 152
  • 203

1 Answers1

9
  1. __directGeometry is an internal data structure used to transition between THREE.Geometry and THREE.BufferGeometry. Do not mess with it.
  2. THREE.BufferGeometry.toGeometry() and THREE.Geometry.toBufferGeometry() are convenience methods. The first one is helpful if your model loads as BufferGeometry and you feel more comfortable manipulating Geometry. If you want answers regarding performance, you need to do a test. Buffer geometries definitely load faster.
  3. There are many examples showing the use of BufferGeometry. It would be wise if you understood the difference between "indexed" and "non-indexed" BufferGeometry. BufferGeometry with the index attribute defined allows for the sharing of vertices. Non-Indexed BufferGeometry is what we call "triangle soup".
  4. THREE.Geometry will remain for the foreseeable future.

three.js r.73

WestLangley
  • 102,557
  • 10
  • 276
  • 276
  • Thanks for your answer. Could you still elaborate a bit on this part: *If I convert all my normal geometries to buffer geometries using this method, will it give me the same performance increase compared to drawing them as a THREE.BufferGeometryfrom the start?* because I am still not sure if I should redraw my geometries as buffer geometries to get max performance... – Wilt Jan 29 '16 at 07:23
  • One more... Is there a performance difference between indexed an not indexed buffer geometries? – Wilt Jan 29 '16 at 07:24
  • 2
    (1) As I said in #3. above, if you want answers regarding performance, you need to do a test of your specific application. (2) The renderer converts your normal geometries to buffer geometry anyway, so there should be no reason for you to do the conversion manually. It might be a good learning experience, however. (3) Indexed and non-indexed `BufferGeometry` may, or may not, have _significant_ performance differences. It would depend on the geometry. – WestLangley Jan 29 '16 at 16:22