2

私は現在、サイズが10〜1000000の範囲のオブジェクトを含むシーンでの作業を含むプロジェクトに取り組んでいます。これらのサイズの広い範囲にいると、オブジェクトが「きらめき」始めます。これは、オブジェクトが交差するときにのみ発生し、カメラがオブジェクトから離れるにつれて、ますます「暴力的」になります。 。

問題の画像をここにアップロードしました：http：//imgur.com/SOeemng

何が原因であるかはわかりませんが、何が原因であるかについて考えられるアイデアがいくつかあります。

まず、私はthree.js /webglには大きすぎるサイズで作業しているだけですか？

私が問題になる可能性があると考えていた2番目の可能性は、以下のように私が作成したカメラコントロールの使用です。

    if(mouseIsDown == true){
        if(this.movementSpeed < this.maxSpeed){
            this.movementSpeed += this.acceleration
        }else{
            this.movementSpeed = this.maxSpeed
        }

    }else{
        if(this.movementSpeed > this.minSpeed){
            this.movementSpeed = this.movementSpeed/this.deceleration
        }else{
            this.movementSpeed = this.minSpeed  
        }

    }

this.minSpeed = 0であり、this.movementSpeedは、次のようにカメラを移動するために使用されます。

var actualSpeed = delta * this.movementSpeed;
this.object.translateZ( -actualSpeed * forwardOrAuto );
this.object.translateX( actualSpeed * sideSpeed );
this.object.translateY( actualSpeed * upSpeed );

これが問題になるとは思いませんでしたが、移動速度が実際にゼロになることはないので、問題になる可能性があります。移動速度が10^-20または-30の場合でも、きらめきは発生します。

それが問題なら、私もr.55にいます。

4

3 に答える 3

13

精度の問題のように聞こえます。動きは、丸め誤差の影響を増幅する可能性があります。three.jsで太陽系のモデル（uom：メートル）を操作しているときに、自分で「ちらつき」テクスチャ/モデルに関する多くの問題に遭遇しました。gaitatは、Zバッファの深さの精度の問題が発生していることは絶対に正しいです。私のパートナーと私がそれに対処したいくつかの方法があります。

Zバッファは線形ではありません。gaitatが言及したsjbakerのサイトは、数か月前の私と同じように、それを非常に明確にします。ほとんどのZバッファの精度は、近くにあります。オブジェクトのサイズが最大1000000単位の場合、オブジェクト自体は、オブジェクト間のスペースは言うまでもなく、すでに有効な精度の範囲外にあります。世の中にある多くのビデオゲームで使用されている解決策の1つは、プレーヤー（カメラ）を移動しますが、代わりに世界を移動します。このように、何かがカメラに近づくにつれて、その精度は向上します。これは、遠くにある大きな重なり合うオブジェクトのテクスチャ（ちらつき/オクルージョン）、または軸方向の原点から遠く離れた小さなメッシュの場合に最も重要です。この場合、丸みの問題が深刻になり、メッシュが見えなくなります。ただし、プレーヤーに関してすべてを移動するために「ジャストインタイム」の計算を行う必要がある（それでも丸め誤差が発生する）か、より洗練された解決策を考え出す必要があるため、言うのは間違いなく簡単です。

遠方の数値が非常に高い場合、近方の精度はほとんど失われませんが、近方の数値がわずかに大きい場合、中域ではかなりの精度が得られます。使用しているメッシュが10ユニットほど小さい場合でも、カメラに近い設定を10または100にすると、多少のたるみが生じる可能性があります。Zバッファを処理する方法は、カメラの設定だけではありません。

pornOffset-どのもの（メッシュ上のマテリアル）が一番上にあるかをZバッファに効果的に伝えます。ただし、解決するのと同じくらい多くの問題が発生する可能性があり、かなりの調整が必要になる可能性があります。これはcssのz-indexに似ていますが、もう少し気まぐれです。1つのマテリアルのオフセットを増やして、遠くの何かの上に確実にレンダリングされるようにすると、近くの何かの上にレンダリングされる可能性があります。雪だるま式になり、ほとんどのオブジェクトにオフセットを設定する必要があります。係数と単位の数は、polygonOffsetの場合は通常-1.0から1.0の間であり、いじる必要がある場合があります。

デプスライト=false-これは「デプスバッファに書き込まない」ことを意味し、常にすべての「背後」にレンダリングされる必要があるマテリアルに最適です。良い例はスカイボックスと背景です。

私たちのプロジェクトは、上記のすべての方法を使用しましたが、メートル単位で40天文単位（冥王星）の数を扱っていましたが、それでも平凡な結果が得られました。

「彼ら」はそれを「Zファイティング」と呼んでいるので、良い戦いをしてください！

于 2013-02-08T01:29:12.807 に答える
4

範囲がこれほど大きいため、カメラを0に近い平面に近づけ、遠い平面を1000000に近づける必要があります。ただし、十分なz解像度がありません。詳細については、 http：//www.sjbaker.org/steve/omniv/love_your_z_buffer.htmlを参照してください。

于 2013-02-07T23:10:07.137 に答える
0

実装方法はわかりませんが、おそらく機能する可能性のある解決策は、2つのシーンと2つのカメラを使用することです。

1つのシーンは近いもの用で、もう1つは遠いもの用です。各シーンは、必要なものに適したzNearとzFarを備えたカメラを使用してレンダリングされます。つまり、近いシーンにはzNear=0.1およびzFar=10,000のカメラがあり、遠いシーンにはzNear=10,000およびzFar=6,000,000のカメラがあります

難しいのは、シーンを同期するためにTrackballControlsを両方のカメラに接続することです。

于 2015-06-29T19:19:03.243 に答える