オクトリー部門

私は内部にハイポリウサギがいるオクツリーと12ポリゴンプラットフォームを持っています。

取引はこれです。あなたはうさぎに光線を発射しています。もちろん彼はかわす（またはあなたが逃す）。

黄色のビームはあなたの死のレーザーです。

ヒットした八分木の一部のために選択された「候補」の三角形は、紫色で表示されます。

ルートノードがヒットしたため、ルートノードのポリゴンをテストしてしまいました。そして、octreeサブディビジョンの境界にあるポリゴンは、最終的にルートノードになり、使用しているサブディビジョンアルゴリズムが適用されます。

ルートノードのポリゴン数を減らしたいのですが。

バニーを角に移動するだけで

隅にバニーがいる場合、シーン全体のレイトレーシングにかかる​​時間は3分の1になります（バニーが中央にいる場合は35秒と95秒）。これは、バニーの三角形のルートにあるものが少なく、ルートのみのoctreeヒットでチェックされるポリゴンが少ないためです。

パフォーマンスを改善する方法を調査しています。基本的には、トリスをツリーのできるだけ下に押して、オブジェクトが主に葉にあるようにします。

私はこれを素朴にやってみました、そして私が作ったこの細分化アルゴリズムを使いました：

split root into 8 CANDIDATE CHILDREN
foreach TRI in root:
  foreach of the 8 CANDIDATE CHILDREN
    if the CANDIDATE CHILD partially contains TRI (at least one vertex of TRI)
      add TRI to CANDIDATE CHILD
CLEAR tris in root

これにより、三角形が階層を下ってリーフノードにプッシュされます。しかし、私は特定の角度から穴を開けますが、奇妙なミスパターンがあります。

（予想）

1つの角度からの穴：

同じシーン、異なる角度：

根を片付けているからだと思います。（ルートをクリアしないと、すべての角度でレイトレーシングが正しく機能するため）

ポリゴンをツリーに「プッシュ」しましたか？なぜ私が穴を持っているのか誰でも推測できますか？

オクツリーのパフォーマンスをどのように改善しますか？

三角形を分割する必要がありますか？私はそれを避けようとしているので、私は必要以上に薄くて薄い三角形を取得したり、シーンジオメトリを乗算したりしません。

また、KDツリーはoctreeよりもパフォーマンスが優れていることを認識していますが、それらもポリ分割を必要とするため、ここで実際にoctreeを改善する方法を探しています。

なぜ私は穴を開けるのか理解しました。私は悪いAABB-三角形の部分的な包含スキームを使用しています。AABBが三角形の頂点を少なくとも1つ含んでいた場合、AABBは三角形を「部分的に含んだ」のです。

Eは「空」で、「AABBBに部分的に三角形」の悪い検出スキームによると。

これは、すべてをリーフノードにプッシュしたい場合は、三角形を分割する必要があることを意味していると思います。