問題タブ [directxmath]

EDIT：問題を解決しました、私自身の答えを見てください

最近、ピッキングを使用して地形を上げたり下げたりする 3D ワールド エディターに取り組んでいます。カメラの非投影とレイ キャスティングを使用して、マウス スクリーン座標のワールド位置を見つけています。

ただし、光線の軸が間違っているようです。私が覚えているように、unproject から出てくるはずの光線は、カメラからまっすぐ出てくるはずです。

現在の外観の例を次に示します。

私の質問は、Z 軸上にあるはずの光線が Y 軸上にあるのはなぜですか?

これは、非投影コードです..

で、これが私が使っている方法です

乾杯！

Directx 11 でスクリーン座標をワールド座標に変換したいのですが、 function で簡単にできることがわかりましたXMVector3Unproject。落とし穴が 1 つあります。独自の Z 座標を選択して、自分のポイントがカメラからどれだけ離れているかを関数に伝えたいのです (スクリーン座標は 2 次元、ワールド座標は 3 次元です)。私が観察したことから、深度バッファー上のポイントの位置を把握する必要があります。

私の深度バッファの範囲は 0.0 から 1.0 (通常の場合) です。私のニアプレーンは 0.1f で、ファープレーンは 1000.0f です。深度バッファの値が均一に分散されていないことを知っています。実際、私の設定では、20.0f はデプス バッファーで約 0.995 です (ニア プレーンに近いですが、デプス バッファーではほぼ完全に下がっています)。これらの値をどのように把握するのですか?

私は DirectXMath のドキュメントを読んでいて、次の文章に出くわしました:

new/delete をオーバーロードして C++ クラスでアライメントを直接強制する代わりに、pImpl イディオムを使用できます。Impl クラスが __aligned_malloc を介して内部的に整列されていることを確認すると、内部実装内で整列された型を自由に使用できます。これは、'public' クラスが Windows ランタイム ref クラスであるか、std::shared_ptr<> での使用を意図している場合に適したオプションです。

shared_ptr がアラインメント戦略を変更する方法がわかりません。ポインターしかなく、オブジェクトを割り当てません。

私は最近、XMFloat4x4 および XMVector 変換を処理するマトリックス クラスを作成しました。Windows 8 Metro アプリでは問題なく動作していましたが、 Win32 Windows アプリケーションに移植しようとすると、エラーが発生し始めました。

"error C2593: 'operator *' is ambiguous c:\program files (x86)\windows kits\8.1\include\um\DirectXMathMisc.inl" 、およびオーバーロードされた複数のインスタンスに関連するこれらのエラーの多くがありました関数 XMFunctions

「DirectXMath.h」をインクルードすると問題が発生する

何が悪いのか教えてください

MATRIX4X4.h

誰かがこのコードを人間が読める形式に翻訳してくれませんか?

基本的に、このアサーションは私のプログラムでは失敗しますが、100% の確率で (何も再コンパイルしなければ) 失敗するわけではなく、かなり奇妙です。

完全なXMLoadFloat4A関数は (行 #697 - DirectXMathConvert.inl):

使用例 :

このアサーションが失敗するのはなぜですか? そして、なぜ100%ではないのでしょうか?

DirectXTK を使用し、ビルボードに関する記事に従って (50,0,0) に「X」を表示したいと考えていました。しかし、私はそれを正しく持っていないようです。誰かが私を助けてくれませんか。

これは有望に見える

DirectXMath ライブラリのソース コードを読んだところ、 と の実装XMVectorSetByIndexがXMVectorSetXまったく異なることがわかりました。単純に(index = 0)XMVectorSetXを返さないのはなぜですか?XMVectorSetByIndex

私は DirectXMath (または XNAMath) ライブラリ (Windows SDK の DirectXMath.h ヘッダーで定義されている) を使用しています。これは、非常にパフォーマンスが高く、物理とレンダリングに必要なすべてのものを提供しているようです。ただし、非常に冗長であることがわかりました (XMStoreFloatX と XMLloadFloatX をどこでも使用するのは面倒です)。

操作を少し簡単にしようとしていて、代入演算子/変換演算子でストア/ロードを非表示にするというアイデアを思いつきました。これらは両方ともメンバー関数である必要があるため、例として次のコードを思いつきました。

ご覧のとおり、XMFLOAT2 のパブリック インターフェイスをレプリケートし、コンストラクター、代入演算子、および DirectXMath が計算に使用する SIMD 型である XMVECTOR の変換を追加します。DirectXMath が提供するすべてのストレージ構造体に対してこれを行うつもりです。

パフォーマンスは数学ライブラリにとって非常に重要な要素であるため、私の質問は次のとおりです。そのような継承のパフォーマンスへの影響は何ですか? ライブラリの通常の使用と比較して、生成される追加のコードはありますか (もちろん、完全な最適化を前提としています)。

基本的に構造体と関数の名前を変更しているだけなので、直感的に、生成されたコードは、これらの便利な演算子を使用せずに冗長バリアントを使用している場合とまったく同じになるはずです。でも、もしかしたら私が知らない面もあるのでは？

PS 追加のコードが追加されるため、代入演算子の戻り値の型について少し心配です。参照を省略して最適化するのは良い考えでしょうか?