OSDN Ticket Archive

原因

波紋を同一平面上に描画しているため、波紋が重なるとZファイティングにより描画がちらつく。 GPUによっては、かすれて描画されることがある。

もともと波紋は、再生平面から0.01fだけ浮かせて描画しており、再生平面と干渉してちらつくことは回避している。 しかし波紋同士の干渉は回避されていなかった。

対策

波紋ごとに再生平面との距離を変え、波紋同士が同一平面上に描画されないようにする。

• 1個目の波紋は再生平面から0.002浮かせる。
• 2個目の波紋は再生平面から0.004浮かせる。
• ・・・

0.002刻みにした理由は、floatの有効桁数に起因する。 また実験により最適と思われる値を探した結果である。

現状、波紋は最大100個まで描画している。 よって再生平面から最大0.2まで浮く可能性がある。 これはデフォルトのノートボックスの縦横サイズ0.1より大きいが、 再生面に極端に近づかない限りは、気づかないレベルの距離である。 また、100個まで波紋を描画することはほとんどない。

備考

本件は暫定対策である。 極端に長い曲では、曲の終端に近づくにつれて、波紋のちらつきが発生する可能性がある。

MIDITrailは、四分音符の長さをデフォルトで1.0と定義している。 4/4拍子で300小節を超える長い曲では、曲の終端は原点から 1.0 * 4 * 300 = 1200.0 離れることになる。

一方、DirectXはすべての座標をfloatで処理する。floatは10進数で6～7桁の精度しか期待できない。 これは次のような計算精度の問題を発生させることになる。

• 原点付近では0.002と0.004を比較できる。
• しかし原点から10000.0離れると、10000.002と10000.004を比較できない。

なぜならfloatで10000.002と10000.004は表現できず、どちらも10000.00に桁落ちするからである。

先ほどの300小節のケースでは、曲の終端は原点から1200.0離れる。 この場合、floatで1200.002と1200.004はぎりぎり識別できるが、 GPUの計算方式によっては有効桁数（6～7桁）が維持できない場合があり得る（と推測される）。

現状のMIDITrailは、ピアノロールは固定して、カメラを移動させる設計になっている。 真面目に対策するには、この基本設計を変える必要があるかもしれない。