Three.jsでスプライトやBufferedGeometryを使用する方がパフォーマンスは良いですか？

私はThree.jsの古いバージョンで数年前に構築された従来の視覚化を書き直しています。視覚化は、すでに決定された位置および色付けを有するスクリーン上に描画された約20kの2D円（グラフからのノード）である。Three.jsでスプライトやBufferedGeometryを使用する方がパフォーマンスは良いですか？

インタラクション（ズーム、クリックなど）以外のアニメーションはありません。以前の著者は、サークル（ノード）のスプライトを使用して、さまざまな状態（選択されたノード：グロー効果、ノード隠し：透明など）を表示しました。CircleBufferGeometryの代わりにCircleBufferGeometryを使って可視化の多くを正常に再現できました。スプライト

これは、私のユースケースにはあまりにも具体的であると考えられるので、あまりにも漠然とした質問ですが、20kスプライトまたは〜20k CircleBufferGeometryをレンダリングする方がパフォーマンスが良いかどうかについて誰かが洞察していますか？ Three.js/webgl。

ありがとうございます！

出典

2017-05-31 Patrick DeVivo

それぞれのケースでお試しいただき、ベンチマークして比較してください。 – Adrian

@Adrianこのスタックオーバーフローの問題がどのように進むのかを見てみましょう。私はThree.jsのエキスパートか事前知識を持っている人が、その道を行く前に私を助けてくれることを願っています... –

CircleBufferGeometryスプライトはgl.POINTS（1つのポイント== 1つの頂点）で描画する必要があるため、スプライトよりも多くの頂点を持つことになります。あなたの頂点シェーダは、円でスプライトよりも多くの頂点を処理します。

出典

2017-05-31 19:35:57 pailhead

これに加えて、THREE.BufferGeometryとTHREE.Pointsを使用すると1ポイント= 1頂点。 'THREE.PointsMaterial'を使うと' map'属性でスプライトを渡すことができます。 –

'InstancedBufferGeometry'も使用できます。 1回のドローコールで20kポイントをレンダリングすると、20kコールで20kメッシュをレンダリングするよりもはるかにパフォーマンスが向上します。私はここでオーバーヘッドについて考えていない、それぞれ20kコールについて考えていた。それを明確にするために答えを更新すべきだと思いますか？ – pailhead

属性がインスタンス化よりもすべての点で同じであれば、透明性や状態の変更が可能であることに言及したので、個々の点を変更できるようにするにはBufferGeometryが必要になると思います。いずれにせよ、CircleBufferGeometryは理想的なルートではないことを明確にする価値があると思います。 –

Three.jsでスプライトやBufferedGeometryを使用する方がパフォーマンスは良いですか？

答えて

関連する問題