【C++】 DirectX初心者質問ｽﾚ Part40 【C】©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
回答する人も、質問する人も必ず読んでください
これらに当てはまる人のための質問スレです。
１．C/C++は多少理解している。
２．最近DirectXを始めたばかり
３．SDKを見ても、Googleで検索しても、いまいち理解できない人
４．余計な雑談は不要ですよ
【 回答してくださる方 】
・ できるだけ優しく質問に答えてあげてください。
・ 優しく教えるのが嫌でしたら、解決するためのヒントだけでも結構です。
「ググれ」「SDK見れ」以外の回答でおながいします。
・ 神ですら理解不能な質問は無視して下さい。
【 質問する方 】
・ どんな事で躓いているのか明確にしよう。
・ 長くならないなら躓いている部分のコードを晒してみれ。
・ 解決した場合、お礼を言うのは当然だが、何をどうしたら解決したかを明確に書こう。
・ 回答して貰ったら、出来るだけお礼もしよう。
前
【C++】 DirectX初心者質問ｽﾚ Part39 【C】
http://echo.2ch.net/test/read.cgi/tech/1418438785/
>>2リンク >>736
ウェーブフロントobj、fbx、max辺りじゃないかな。
今後、コンシューマ向けで主流になりそうなのは「3mf」、大人の事情だと「COLADA」、まれにあるのが泣く子もだまる「csv」大人も泣いた。
あくまでモデリングの話。 簡単なオブジェクトなら.objが鉄板だなぁ。
スキニングまで考えると何だろう？ 趣味グラマの俺はフリー素材多そうなx、pmd、pmx、fbxに対応 スキンまでならobjの独自拡張が一番扱いやすそう。
fbxは構造が洗練されているが、マテリアルとテクスチャがイライラする。
そこにあるのを今すぐ寄越せと思う所を、あなたが望むのは、この緑のフォルダにある緑のテクスチャですか？
それともネズミのテクスチャですか？
では、そのテクスチャは、マルチですか？それとも単レイヤですか？
では、次の質問です。そのテクスチャは…
みたいな構造。
いいから、名前で紐付けたそれを画素とプロパティだけよこせ、と。 >>738
D3D11DeviceをReleaseをしなければそのまま10_0レベルで
SwapChainやBufferも作れて4.0シェーダも動いて
ふつーにBegin～Draw～Presentできてしまうのです・・・
とりあえずドライバがウ○コということで７にするまで無視しときます。
ありがとうございました。 >>745
ちゃんと破棄しきれていないだけのように見える >>746
最初そう思ってコードの切り分けをしてたら、
>>731 の3行だけのコードで落ちることが判明したのです・・・ リリースノートを漁る気もないが、
たぶん悪いのはビスタちゃんのDXレイヤーだと思う。
10しか対応してない。と返されて11のAPIを動かすのが色々おかしい。
ただ、この場合、ドライバが未対応なのに11をハードウェアで動かすのが間違いでもある。
でも機能レベルが低いと言われてデバイス解放しようとするにも落ちるから、やっぱりビスタちゃんに非があるように見えるが、
まあサポート終了していたはずだから、訴えても無理かもね。 話は変わって、機能から色々と物理ベースシェーディングの計算式を検討しているンだけど、ウェブの日本語情報は、ピンきりだね。
違和感がかなりある。説明が無かったり、難解な部分から逃げていたり、抜けていたりね。
本屋も回ったが流石に書籍はない。
まさか原文の論文読むことになるとは思わなかった。
BRDFは、Biinn-Phongも含む。 その辺はかなり面白いよな
まともにレイトレースやGIしようものなら遅すぎて動くはずもないから
適当にインチキしつつ、なおかつ視覚的に効果があるように
さらに汎用性も欲しい
テクスチャ書き込む職人芸は個人では無理だから
出来るだけパラメータだけで色々な素材を表現したいところ
GI、影、反射、半透明
やっぱこの辺だよなぁ、しかもどれも重い >>747
そりゃ731のコードの通りだったら駄目だろう。
gpDeviceContextとgpDeviceはどこから湧いてきたんだよ。 今のGPUならPRT方式(事前計算、レイトレース)でテクスチャに書き込むのは可能に見えた。
2010のアンリアルの数式によれば、
鏡面反射は、マテリアルのラフネスを正規分布関数で粗さの確率で計算するようだが、材質(ラフネス)が均一となっている。
ここを事前計算ってのは直ぐに思い付く。
粗さをテクスチャマップする要領。
幾何減衰は複雑な式だが、視点と法線、光源と法線の内積、ラフネスで減衰割合を計算している。ここも似たことができそう。
材質の表面密度みたいなテクスチャな この存在を初めて知った。教材に良さそう。
しかし、なぜtransmissionなんだろう
exchangeでなく 例えば炎の画像を用意して炎以外の部分が黒でも
加算アルファすると綺麗な自然な半透明になりますが
あんな感じで加算みたいにピカピカせずに自然に半透明にする方法はないでしょうか？
ブレンディングの計算方法はどうなりますか？ github.com 落ちてる
llvm.org も落ちてる >>757
サイトが落ちてるわけじゃねぇよ
ネットを疑え、特にOCN系だよ、アホが ＿＿＿
/ ||￣￣|| ∧∧
| ||＿＿|| （ ）
|￣￣＼三⊂/￣￣￣/
| | ( ./ /
＿＿＿ ｺﾞｷｯ
/ ||￣￣|| ＜⌒ヽ ))
| ||＿＿|| ＜ 丿
|￣￣＼三⊂/￣￣￣/
| | ( ./ / >>761
おまえが無知なのはよくわかったｗ
新しいPC買えよ、貧乏人 osに対応してないってことでしょうか？
外部デバイスつけたりして対応さす方法ないですか？ >>762
ﾜﾛﾀw
>>761
GPUが対応してないんじゃね? >>761
原因:GPUがDX10までに対応
Nehalem(第一世代icore)の内臓グラフィック機能の製品規格が10まで
対処:グラボを繋げるて機能拡張する、プロセッサとチップセットを交換、マザボを交換、ラズパイに窓10をいれてそれを使う
とか色々な選択肢があるが、
ノートだと思うので、中古のデスクトップにグラボ指すのが早い。
尚、高いグラボを買う必要はない。
DDR5を載せた一番安く、パソコン筐体に差せる奴を使う。
ファンが邪魔で刺さらない、奥行き長くて閉まらない、電源ケーブルがない、足りない、コネクター形状が違う、電圧が過不足
そんな話になる。
いずれにせよ、そのパソコンには11の規格を満たしたハードウェアがない。 PBR実装、テスト一段落記念カキコ
フレネル項がカッコいい。
メッシュが単純なピラミッドだから、他はあんま印象がない。 >>768
おめ!
PBR実装は現代グラフィックスプログラマーの登竜門やね どこまで実装すればpbrを実装したと言えるのか？
ガンマ補正したから？
エネルギー保存を満たすBRDFなら？
Beckmann分布やGGX分布と、Smithのshadowmaskingあたりを使えば？
ラフネス-メタリックのパラレータ化ができたから？
はたまたIBLがあれば？
BTDFまで考慮してBSDFとして扱ってエネルギー保存しているから？
VCTとかでGI近似をしたなら？
16bit,floatとかで計算してトーンマッピングしているから？ PBRの目的は、マテリアルパラメータの具象化
物理ベースって言葉は「本格推理RPG」の「本格」と同じ類いの言葉で玉虫色に受けてによって印象が変化する商材。
まあなんだ。ツールと目的を取り違えるな あとあれだ。
クックトーランスモデルは、金属の反射に適した(或いは特化した)光反射モデル
それを特徴付けるのは正規分布関数とフレネル反射。
瞳や肌なんかの半透明材質にクックトーランスモデルは適さない。
昨日実装して気づいた印象だが。 PBRを実装すれば、全ての物質をパラメータだけで表現可能になるの? いやそりゃ、テクスチャ要るでしょ
今まで、拡散光、反射光、環境光、とかやってたのが
別の名前のパラメータと計算式になるだけで
確かにリアルになるだろうが
圧倒的に作業量が減る、というわけじゃないでしょ
どちらにしてもテクスチャ作るのが一番大変な作業だし
一番見た目への効果も大きいから・・・
テクスチャの自動生成の技術の方が作業量的には効果ある UE4でマテリアル作成とかやり始めるとメリットというかコンセプトが学びやすいやね 確かに。今のテクスチャって頂点から参照する外部配列と言われている様だし、実際メッシュをマスターテーブルと見立てたとき、テクスチャは、参照テーブルみたいなものだと思う。
これも俺たちのトライエース社長の言葉だそうだが、テクスチャに光反射を事前計算した結果を入れてよりリアルにかつ計算速度を合理化しようって考え方がある。
テクスチャは、メッシュの一部。
ハイポリゴンを放線マップでベイクするように、材質もテクスチャにベイクすることが、物理ベースの潮流じゃないかと理解している。
材質が彩る陰影をPBR(クックトーランスモデル)一つだけで解決する万能関数がPBR！
なんてことにはなりえない。
配色、彩飾が映像芸術の特徴要素であるシーンでPBRを使うのは不適切。(材質を選択したくない、色を指定したい場面ね)
他にも自己発光する材質とかもPBRのマテリアルパラメータでは指定できない。
メソッドの一つ。 というか、PBRが尊ばれるのは、どうみてもCAD応用分野に適しているからじゃないかと。
自動車、航空機、重工業製品の製品設計には、最適な材質パラメータだし。 defferedの影響でレンダリングが分離して、
いろんなマテリアルを共通のパラメータで扱おうとして便利に使われてるのがpbrという理解だった。 ところで正規分布関数を見ると無性に苛立ちませんか？ directx11で点光源を実装しようとしているんですが光源の座標がなぜかワールド変換行列
をかけた状態になっていしまいます
cbuffer PointLight : register(b0) {
float4 lightPos[4];
float4 lightColor[4];
float lightDis[4];
};
struct PixelInput {
float4 pos : SV_POSITION;
float3 nor : NORMAL;
float3 wpos : TEXCOORD;
};
float4 ps_main(PixelInput In) {
float3 color(0.3f, 0.3f, 0.3f);
float3 lightDir;
float intensity;
float lightDir;
float atten;
for(int i = 0; i < 4; i++) {
lightDir = (lightPos[i].xyz - input.wpos) / lightDis[4];
atten = saturate(1.0f - dot(lightDir, lightDir));
intensity = saturate(dot(input.nor, lightDir));
color+=lightColor[i] * intensity * atten;
}
color = saturate(color);
return float4(color, 1.0f);
} 「ワールド変換行列をかけた状態になって」
逆に聴くと、どういった原点を持つ座標系であって欲しいのか？
wposは、どういった原点を持つ座標系にあるのか？
ここを理解すれば解決するような。 なんか専門学校の課題みたいだ。
モチベーションをあげるモデルが欲しければ、XPSがオススメ ますます分からなくなってきました・・・
lightPosもwposもワールド空間の中心を原点に持つ座標という認識なんですが間違っているんでしょうか
http://imgur.com/a/Kqpjc
http://imgur.com/a/epVLv
上が光源の座標をそのまま渡した状態で、下が逆行列をかけて渡した状態です どちらもワールド座標系なら、実装したコードに問題は見当たらない。
光の当たり具合、期待する陰影がでない。
ここが疑問点なら、後は入力したメッシュ、法線に問題があるような。
六面体でありがちなのは、頂点を共有した面を構成しているメッシュで、面法線、頂点法線の計算を誤解しているとか。
面でシェーディングしたいなら、面の法線が各頂点になければならない。
いいかえると、六面体ならば、頂点情報は8では足りない DXGI_SWAP_CHAIN_DESCのBufferCountについて質問なんだが、
多くの解説サイトではバックバッファーの数、通常は1って書いてあるけど、MSDN読むと
スワップ チェーンのバッファー数を表す値です。フロント バッファーを含みます。
って書いてあるんだが、ダブルバッファにしたい場合ってここ1にすればいいの？
それとも2にすればいいの？
ちなみにDirectX11な >>787
1でいいよ。
実装にもよるが、スワップチェインからレンダリングターゲットを複数取り出すなんてことはしないような気がする。 とりあえず、presentを非同期処理しない限りは、スワップチェインは1でよいと思うの。
複数確保しても、presentがv-syncなりなんなりと動悸とって後続処理に続かない(ブロックする)し、マルチスレッドにコンテキストを操作すると拒絶される。
コンテキストは、コマンドリストだから、複数のコンテキスト作ればいけるように思うが、
真面目にフレーム単位で描画するフレーム毎のオブジェクトの姿勢を決めるパラメータをきちんと計算して絵をだすなんてしないと思う。
同じ絵になることを許容して、先行描画することでフレームレートを稼ぐとかはあるだろうが、この質問時点でそんなん気にしなくてもよいかと。
つまり、1でよろしい。 なるほど、とりあえず1にしたわ
ちなみにBufferCountを2にしてバックバッファを1枚取り出す場合でも普通に動いてた
presentを非同期処理っていうのはpresent(0, 0)での呼び出しかな？
今はpresent(1, 0)で呼び出してる >>791
英語で表示して、Google翻訳にかけた方がずっとましな日本語なる。
ただし、サイト全体を翻訳にかけると中身違うのか駄目。 MSDNのサイトは、もう死んでるような。
HLSLのリファレンスみると、もう英文ですら何も書いてない。
ヘッダーファイルを読んだ方がマシなレベル >>792
（100～120fpsを割った頃にまた来てね？） MSDNとTechNetは捨てて、docs.microsoft.comに移行するらしいし。 まあ、HLSLのリファレンスは、英文よりも数式、計算式を書いてくれた方が有り難い。 >>796
そうなんだ。
何度も移転しているから、あんまどうでもいいが、取り敢えず、英文でよいから充実させてくれ。。。
dot(x, y)
Returns the dot product of two vectors.
…その通りなんだが、知りたいのは、そこじゃない、と。
「cos(θ)」の一文の方がまだマシ。
これが数式で表されていたら、かなり印象が違う。 保守としてドキュメントのスナップショットが必要なんだけどなぁ。
昔のようにパックしたMSDNライブラリを定期的に提供してくれないと。 なんだ。結構いるんだな。 過疎だから来週までコメント付かないと思ったのに…
「cos(θ) = dot(x, y); ではない」という指摘は巧く呑み込めないが、
説明文 1) cos(θ) = dot(x, y);
説明文 2) Returns the dot product of two vectors.
説明分 3) retirm = |x| |y| cos θ
説明文 4) とりま、おまえらレベルだとベクトルの近しさを計算するだけなんで、ざっくりベクトルの近似を指数で返してやんよ。 0.0～+1.0だけ使って、あとは勝手にクランプしろ。 黙って使え
の場合、どれがいい？みたいな表現（＝プログラマ エクスペリエンス）の議論かな ああ、太刀持ちバルバトスとリックⅡは同盟戦コンテナ報酬か
どうせ出ないけど dot(a,b) -> a.x*b.x + a.y*b.y + a.z*b.z … "dot" ってのは
a・b
↑ この鼻くそ記号のことだぞ
ちなみに "cross" は
a×b
↑ このバッテンな dot(a,b) = |a||b|cosθ = a.x*b.x+a.y*b.y+a.z*b.z+…
いくつか利用例も書いてくれると嬉しいけど
ドキュメント作成者が過労死しかねない >>798
>dot(x, y)
>Returns the dot product of two vectors.
>…その通りなんだが、知りたいのは、そこじゃない、と。
add(x, y)
Returns the sum of two vectors.
これでも「知りたいのはそこじゃない」とか言うか？ >>809
lerp(x,y,a)
観ると不信感を感じるけどな 左の一覧と詳細表示の右側が区分がないフラットデザインなのがむかつく。
そして、改善する気がないのに「Is This page helpful?」って聞いてくるのがうざい。 最近、深層学習(語感がカッコいい)の本を眺め始めた。
今読んでいる本の事例だとザッくり描画パイプラインのベクトルと深層学習のベクトルは別物だな、と感じた。
前者は4成分のベクトルだが、深層学習のベクトルはアホみたいな次元(たぶん、シェーダでいう成分の意味)を使うそうな。
つまり、ベクトルというよりもベクターな印象。 >>814
意味が違っても数学的には同じことなら道具として利用可能 >>814
DirectXの出番はありそう?
DirectCompute使えるかな? ざっくり、成分数が全く違う。
認識を入れ換えないとダメっぽい
「頂点配列を成分」とみたて
「4成分レジスタ」を「32bitx1成分レジスタ」と扱う。
こんなことをするみたい。
まだ確度が低いから参考程度に。
計算シェーダは使えるが、性能だすなら頂点やピクセルシェーダと似た認識でコーティングする観点は忘れちゃダメ。
おれ最近、俺の配色、グラフィックスデザイン、紋様なんかの幾何学的な美しさを発想する感性に哭きたくなるようなセンスのなさを実感したから、深層学習に生きるわ。
みんな駄文に寛容でいてくれて、ありがとうね！ 駄文にも程があるだろ……
最低限ゼロから作るDeep Learningでも読破してから高説垂れれば良いのに 突き放すのもなんだからと、俺が知ってる中で一番馬鹿でも読めそうなの書いといてやったのに。
人の親切になんてこと言うんだ ニューラルネットを関数近似と捉えて、構文解析や単語の関係評価をそれぞれ別々のニューラルネットと構成する事で、従来のやり方に近いことが出来るニューラルネットが実現出来たということが書いてあった。
かなり刺激的。
適切なタスク設定と損失関数選定が肝だろうが、これは面白い そんな本を読むより、まずはスレ違いな落書きを垂れ流さないという常識から身につけようか。 FBX SDKってスレッドセーフじゃないんですね・・ >>829
おまえが現状を認識してないアホなだけやんｗ 特定分野のAPIと言語を比べてるあたり知識以前に知能が足りて無さそう 何か面白い話題は無い訳？
みんなでさぁー盛り上げていかないとさぁー
分かってるわけえー？
頼むよまったくさぁー！？
俺？俺は別に無いけど OpenCV使わないでDirectXだけでカメラからの動画をキャプチャーする方法を教えてください >>836
ググれない馬鹿にはどうせ理解できないよ ■ このスレッドは過去ログ倉庫に格納されています
