0

I'm rewriting a legacy visualization built several years ago with an older version of Three.js. The visualization is ~20k 2D circles (nodes from a graph) drawn on a screen with positions and coloring already determined.

There's no animation involved other than when interaction occurs (zooming, clicking, etc). The previous author used sprites for the circles (nodes) to show different states (node selected: glowing effect, node hidden: transparent, etc)

I've been able to successfully reproduce much of the visualization using CircleBufferGeometry instead of a sprite.

I know this is potentially too vague a question, given it might be too specific to my use case, but I'm wondering if anyone has any insight into whether it's more performant to render ~20k sprites or ~20k CircleBufferGeometry with Three.js / webgl.

Thanks!

Patrick DeVivo
  • 755
  • 1
  • 9
  • 13
  • 1
    Try each in your specific use case, benchmark them, and compare them. – Adrian May 31 '17 at 18:42
  • @Adrian let's see how this stackoverflow question goes and then maybe I will! I'm hoping a Three.js expert or someone with prior knowledge could help me out before I go down that path... – Patrick DeVivo May 31 '17 at 18:55

1 Answers1

2

CircleBufferGeometry will have many more vertices per entity than a sprite would since sprites should be drawn with gl.POINTS ( one point == one vertex ). Your vertex shader would process more vertices with the circle than it would with a sprite.

pailhead
  • 5,162
  • 2
  • 25
  • 46
  • Adding to this, you can use `THREE.BufferGeometry` with `THREE.Points` and that is 1 point = 1 vertex. Using a `THREE.PointsMaterial` you can pass in a sprite with the `map` attribute. – Xander Luciano Jun 01 '17 at 02:45
  • 1
    `InstancedBufferGeometry` can also be used. Rendering 20k points in a single draw call would be orders of magnitude more performant than rendering 20k meshes in 20k calls. I wasn't thinking about the overhead here, was thinking about 20k calls each. Do you think the answer should be updated to clarify that? – pailhead Jun 01 '17 at 06:52
  • If the attributes remain the same across all points than instancing would be beneficial, however he did mention being able to change transparency and changing states, so I think he would need `BufferGeometry` to be able to modify individual points. Either way, i think it's worth clarifying that `CircleBufferGeometry` is not the ideal route to go here. – Xander Luciano Jun 01 '17 at 07:15
  • 1
    @XanderLuciano You can handle all those things through shader attributes, just like setting the position. ([A related yet cautionary tale regarding transparent `InstancedBufferGeometry`](https://stackoverflow.com/questions/43502415/transparency-within-instanced-shapes)) – TheJim01 Jun 01 '17 at 14:35
  • I did a "bootleg" test, sprites vs CircleBufferGeometry and sprites were noticeably faster for my implementation. Thanks @pailhead – Patrick DeVivo Jun 07 '17 at 17:57