OpenGL/Vulkanスレ Part22©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
クロスプラットフォームの3D API OpenGL 及び次世代のローレベルAPI Vulkan に関する話題を扱うスレッド。
現在の最新バージョンは4.5
https://www.opengl.org/
https://www.khronos.org/vulkan
== OpenGLと一緒に使われるツール＆ライブラリ ==
苦労したくなかったらとりあえず入れとけ。
・glx: XからOpenGLを使うためのライブラリ。普通は直接は使わず意識する事はない
・glut: クロスプラットフォームなツールキット。でもさすがに古くさい
・GLFW より新しいマルチプラットフォームなツールキット
・glew: これを入れないと拡張機能が使えないor使いにくい
・glxgears: 歯車が回るベンチマーク。-infoでOpenGLのバージョンが見られる。OpenGLの動作確認はこれで
・glxinfo: 自分の使っているカードのOpenGLの機能が全てリストアップされる。
・OpenTK C#からOpenGLを簡単に使えるようになる。VC#の強力なIntellisenseとあわせてサクサク開発可能。
・OpenSceneGraph: OpenGL を高度に抽象化し、利便性を高めたラッパー。C++ ライブラリ
・OpenGL Mathematics (GLM): GLSL 文法ライクの C++ 数学ライブラリ
== チュートリアルサイト ==
床井研究室: http://marina.sys.wakayama-u.ac.jp/~tokoi/oglarticles.html
OpenGL de プログラミング: http://wiki.livedoor.jp/mikk_ni3_92/
NeHe: http://nehe.gamedev.net/
Tutorials for OpenGL 3.3 and later http://www.opengl-tutorial.org/
Learning Modern 3D Graphics Programming http://www.arcsynthesis.org/gltut/
== 前スレ ==
OpenGLスレ Part21
http://peace.2ch.net/test/read.cgi/tech/1409581958/
== 関連スレ ==
【O3D】HTML5用 3D API WebGL 【Canvas:3D】
http://peace.2ch.net/test/read.cgi/tech/1308761577/
OpenGL 2.0 専用スレ
http://peace.2ch.net/test/read.cgi/tech/1126268759/ >>523
それアプリ側でglGetError使うかどうかって話じゃないの？
もしかしたらglGetErrorが使われるかもしれないし
エラー発生時もGPUによって違う結果になったりしないように
OpenGLドライバは常にエラーチェックをしてる
そのせいでオーバーヘッドが大きいとか聞く
これ無視してエラーチェックの無いOpenGL実装を作ったら
それはもはや規格外OpenGLだと思う 将来的にGPUメーカーの提供するドライバーがVulkanのみになってOpenGLを切り捨てるとかにならない限り
Vulkanで実装したOpenGL APIとか作っても無意味そうだよね >>525
GPUメーカーがそれを使えばドライバーがまともになる それはVulkanドライバーがまともならって前提だな https://www.khronos.org/vulkan/faq#web-vulkan
WebVulkanは出ないけど
Vulkanっぽい機能を追加したWebGL3は有り得る感じ？ >>524
話の前提が違ってるな
>>519はゲームエンジンはOpenGLを呼ぶように設計されてるからVulkanにしたところで速くならないみたいなことでしょ
で、OpenGLのエラーチェックは開発時だけに必要な機能だからそれをバッサリやらなければ速くなると言ったんだ >>527
Vulkanドライバーは薄いレイヤーだしコンフォーマンステストも充実してるからドライバーの質が良い可能性は高い
ちなみにOpenGL on Vulkanは既にあるぞ
Khronos謹製じゃないがな OpenGLをMFCのシングルフォームビューで使用しています。
ピクチャーコントロールをOpenGLで描画しているのですが、他のウィンドウがかぶっていると描画されません。
何か解決策ないでしょうか？ >>529
WebGL3があるならES4.0が実装されるはずだけどそもそもリリースされるのかね？
もはやES3.2で完成してんじゃないかとすら思えるけどね >>533
OpenGLそのままでもVulkanそのままでも無い何かが作られるなら
WebGL3って言い方は適切じゃなかったな
実装にはVulkan使えば良いだろう >>534
それ言ったらWindows版ブラウザのWebGL実装は全部DirectXを呼び出してるよ
それがVulkanになるのは時間の問題だろうね
WebGL→DirectXは右手系左手系とかシェーダーの違いとか苦労してるみたいだからVulkanの方が親和性は高いはず
上っ面のAPIはずっとWebGLのままだと思う そろそろデフォで有効になるWebGL2はPS3以上PS4未満の能力があるから、それで十分だと思うけどね
限界までパフォーマンスを追求するようなプラットフォームじゃないし http://floooh.github.io/2016/08/13/webgl-next.html
VulkanをそのままWebに持っていけない理由が色々挙げられてる
セキュリティとか性能の問題とかAPIの複雑さとか色々
それでもWebGLは普通にOpenGLを使うのと比べて遥かにオーバーヘッドがでかいようなので
その辺を改善した後継は出るんなら欲しい
この人によると良くできたOpenGLドライバでネイティブだと60fpsで100kのドローコールが出来るけど
WebGLだと60fpsで出来るのは5,000程度らしい
オンボードのGPU(Intel？)の出来の悪いドライバだと10k程度 Javascriptとかwebassemblyがネイティブコード並に速くならないとwebvulkanがあってもJavascriptの実行自体がボトルネックになって速くならない。
セキュリティチェックが必要だからネイティブコード並に早くするのは無理。
なのでAPI呼び出しを減らせるようにwebglを設計しようということか。 >>532
今時MFC？
ウィンドウ被ったら描画されないってWM_PAINTイベントで描画してないとか？
でも最近のWindowsってウィンドウが被っていても消えたりしないよな
デスクトップコンポジションがあるから >>538
JavaScriptとWebAssemblyは同じじゃない
WebAssemblyは遅くてもせいぜいネイティブコードの1.5倍以内の遅さに収まってる
いずれオンゲーはWebAssembly+WebGL2な環境で動かすのが普通になるだろうね そもそもJSじゃ速度が測定時の状況でかなり変わるし
C++じゃ実行時にプロファイリングして得た情報で高速化なんて出来ないし
参照カウントとかで手動でメモリ管理する方がGCより速いとも言えないらしい
APIコールには一定のオーバーヘッドがあるので
それはC++より不利 >>542
手動でメモリ管理するのは速度の為じゃなくて、適切なタイミングでメモリの取得解放を行う為だ
あとプロファイリングは開発時に散々してチューニングすれば問題無い
実行時にプロファイリングしてC++よりも高速なコードを生成するなんてほとんど幻想に近いが有り得ないことはない
ただそれもあてにならないわけだし、安定したフレームレートが必要なゲームには全く向かない そもそも実行時プロファイリングは最適化に手間(実行時間)をかける価値のある部分を見つけるためのものだよね？
本当なら全部を最適化をしたいけど、実行時コンパイルでそれやると最適化にかかる時間でかえって遅くなるから最適化処理を必要最小限にしたい
→もっとも効果がある部分をプロファイリングで探す…って
C/C++はピックアップせず全てを最適化するからプロファイリングは不要だし
最適化にかかる時間をプログラムの実行時間外（事前）にまわせるから
これより速く動作させる事なんて不可能でしょ そういうベンチ結果ならあるから絶対ないって事は無いだろう
実際にどんなパターンで実行されるかって情報だけはAOTじゃ分からないからな
それを加味して最適化するとデメリットがメリットが上回り速くなることは有り得る
あまり頻繁に実行しない部分を時間を掛けて最適化してもあまり速度は速くならないし
https://en.wikipedia.org/wiki/Adaptive_optimization 実行結果から最適化した方が良いコードを生成できる可能性高いしな。
エラー処理とかまず通らないコードをインライン展開してもコード密度悪くなって逆に性能悪くなるし。
(コンパイラ拡張で最適化のために殆ど通らないって属性付け出来たりするけど)
VC++2017には実行した結果から最適化させる機能が入った
https://msdn.microsoft.com/ja-jp/library/e7k32f4k.aspx 「Rubyのしくみ」に載っているベンチマークでは、
JRubyのループ回数が10万回(0.3秒)から、100万回でも0.3秒なんだよね。
このタイミングでさらに、コンパイルして加速していく
最終的には、1,000万回(1秒)で、CRubyよりも速くなる。
CPUセントリックな処理、つまりI/Oが無い場合、
予測分岐とか最適化技術では、Javaが、Cよりも勝る プロファイルベースの最適化は開発時にプロファイリングして
AOTコンパイル時のヒントとするやり方はかなり効果あるだろう
実際chromeが起動時間が20%速くなったとかあったな
それとJITコンパイラする実行しながらプロファイリングするのと一緒にしてはいけない DX11はDX12の機能ほしくなる
あとはいまだにCPUにフレームレート引っ張られるのがいらっとくる glmapbufferrangeってglbindsubdataで代用できるよね？ >>535
横からだが、座標系の違いはシェーダ時代だと存在自体がユーザの好みじゃないかな
GLとXの座標系の違いは固定機能が原因で、
シェーダだと座標系変換行列が吸収する。
少なくとも、俺が書いたDirectXのシェーダは、右手座標のモデルを入力して実現できている。 変換行列は一緒だぞ
右座標だろうが左座標だろうが関係ない Zを+にするか-にするかはアプリがどういう行列を作るかで決めることでグラフィックのAPIレベルでは関係ないぞ。
実際にUnityはGL、Metal、DirectXのどれを使っても左手座標だぞっと。 多分固定機能時代はそれぞれが内部的に決まってたからそういう風に思ってる人が多いんだと思うが でもzの範囲の問題でprojectionは互換なかったりするよね？ >>560
それはプロジェクション行列に下駄はかせるか頂点シェーダーで変換すればいいし、右左とは関係ないわな。 ttp://glslsandbox.com/
ここにglslのサンプルがいっぱいあるけど
ここのglslをコピペして自分のpcで動かしたいけどそういうのってできます？ DirectXは左手系と言ってるみたいだけど、多分サンプルとかがそういう風に
実装されてるだけで、実際にはアプリが自由に決めていい
ただANGLEの実装ドキュメントによると最後のウィンドウ座標だけはY軸の向きが
OpenGLとDirectXで逆になってて変換する必要があると書いてあった
Y軸逆なのはテクスチャ座標もそうだな 同じ座標指定したら右手と左手じゃおかれる位置が明らかに変わるんだから
自由じゃない >>542
jsみたいな高級言語だと、言語自体に予め遊びをいれておき、そこから適切なアルゴリズムを内側で変更するってことは可能じゃないかな
例えば、配列の探索。
シーケンシャルに読むコードであれば、ワークスレッドに分散して速度を稼ぐといった高速化ができる余地がある。
言語にスレッドがないからね
これはcでも可能だが、最適化より予めOpenCLだったかの言語拡張で教え込むことができるから、そのプロファイル自体が要らない。
JavaScriptはよく知らんが、GCと同じでプロセスが落ちたら最適解を忘れそう てか、配列探索の説明になってなかった。
配列の場合、言語では配列にみせるが、アクセスがシーケンシャルかインデックス単一要素アクセスのどちらが多いか、要素の削除やクリアの頻度を計るとかがあるような。
それによって内部の変数管理をリストに変更したりベクターにしたりという最適化があり得そう。
だが、実際は予めデザインで決定出来るのだが、そこをダイナミックオプティマイズで設計時間省略！てかはできるかな。
特に素人や頻繁にコードを変えるシーンだと好まれるかもしれない。
スレ違いすまん。 >>565
お前は…
カメラの位置とかデータの内容が全て左手系や右手系を前提に構築されてれば
まったく同じ見栄えのゲームが作れんだよ
だからどっちを選択するのかはアプリの自由という事が理解できないのか？ レンダリングエンジンを抽象化するという発想がないんでしょ 座標データのZのプラスマイナス逆に刷りゃ同じになるけどそれって自由な選択じゃなくて座標系に合わせてデータ差し変えてるわけで 意味合いが違うな ああ右手用データを左手座標にぶちこんでも全部逆になるから結局見た目は同じになるって言いたいわけ？ 左手系の為に左手系のデータを用意するのも含めてアプリの自由だと言ってんだよ
やたら頭堅いやつが紛れてるな 左手系の為に左手系のデータやプログラムを用意する
右手系の為に右手系のデータやプログラムを用意する
どっちかを決定するのはDirectXが決める事じゃなくてアプリの自由だという単純な事だぞ？ >>570
座標系に縛られるから不自由とかはグラフィックス計算の話題じゃないな
計算するのが不自由って意味になる… それよりボトムアップなのがややこしい
FBOでテクスチャに描いたときに上下が逆になってしまう
対策は頂点シェーダーで座標を逆転させるか
普通のテクスチャを逆転させるか Aという行列があるとして
→X=(x,y,z)というベクトルを用意して
→Y = →XA という掛け算をするのが「いわゆる左手系と呼ばれる操作」
↑X'=(
x',
y',
z')
というベクトルを用意して
↑Y' = A↑X' という掛け算をするのが「いわゆる右手系と呼ばれる操作」
の違いでしかない
(要するにどちらも本質的には同じ) >>575
アプリ内で反転したテクスチャをレンダラに渡すって手もあるが猛烈にメモリーの無駄
うちはGIMPでエクスポートするとき上下の鏡像反転だね 計算回数も変わらないしね
ボトムアップなのは、数学のグラフと同じ座標系にしたかったから、とか聞いたことがある。
xが接線、yが法線、zが従法線として、キチンと向きが揃うとかなんとか ttp://stackoverflow.com/questions/4124041/is-opengl-coordinate-system-left-handed-or-right-handed
OpenGLはobjspaceとworldspaceでは右手系で
glOrtho/glFrustumの実装のせいでwindow座標では左手系になるらしい
といっても古いOpenGLのお話 Vulkan SDK 1.0.39.0
ttp://vulkan.lunarg.com/sdk/home >>576
大間違い
それは単に行列が列指向(column oriented)か行指向の違いでしかない
Wikipediaにちゃんと書いてあるんだから見ればいい >>578
> xが接線、yが法線、zが従法線として
それだとトップダウンにならないか？
接空間(tangent space)の事を言ってるなら
x=接線(tangent) y=従法線(binormal) z=法線(normal) だな OpenGL 4.0 シェーディング言語 -実例で覚えるGLSLプログラミング
https://github.com/daw42/glslcookbook
ここのサンプルは右手系と左手系どちらなのでしょうか GLしか使わないからハンドネスなんかどうでもいいが
原点視点から離れていく方向が+だからGLのほうが自然では無いかと
あんまりなさそうだけど訴訟になった場合の対策でz逆にしたのかしらね ジンバルロックの理屈はわかるけど、実際何が問題なの？2軸が重なろうが構わず指定通り回転させればいいのでは？ 2軸を外積を使って残りの軸を割り出す時に、完全に2軸が重なってると
外積の結果はゼロベクトルになってしまうけど、微妙な距離だと方向が
激しく変化する事により、向きがブルブルしてしまう事をジンバルロックと言う (以下Y軸プラス方向が真上とする)
よくある状況としてはlookatを使う時に普通はUpベクトルにY軸を渡すけど
真上を向こうとした時に方向ベクトル(eye - center)がY軸とほぼ同じ方向に
なった時にサイドベクトル(X軸)が>>590の状況により、激しく変化して
グルグル回ってしまうとかある x軸を外積で出さないでベクトル値を持っていればいいのでは？ 方向ベクトルが任意なのにそのx軸ベクトルが固定値になるわけがない 最初だけ外積で出して後はそれを一緒に回転させればいいのでは その「一緒に回転」を数学的に厳密に描写してみ
ジンバルロックと同じ問題が出るから カメラの視線ベクトルも上ベクトルも、極座標変数θ、φから計算して常に直交するようにして与えてる。 FPSみたいなゲームだと真上を向くのは人間の首だからY軸と一定の角度以上には
上を向けないように制限してジンバルロックに対処してるのがほとんどだな 再度ジンバルロックについてお尋ねします。
軸が重なると言っているのは、初期姿勢のXYZ軸と、
回転後のXYZ軸が重なるということを言っているのだと思いますが、
２番目だけ９０度だとマズイと言っていますが、
１番目を９０度にしても軸は重なりますよね？
例えばXYZ軸の順で回転したい場合、
X軸をいきなり９０度回せばY軸とZ軸は重なってしまうと思うのですが、
これはジンバルロックにならないのでしょうか？ また、２番目を９０度にしても、一番目を何度か動かせば、
初期軸と回転後の軸は重ならないと思うのですが。
XYZ軸の順で回転させる場合、
Xを45度回し、Y軸を90度回しても、回転後のX軸と最初のZ軸は重なりませんよね？ 回転と考えるから理解出来ないんだよ
単にあるものを回転させてるだけならジンバルロックなんて起きない
いわゆるジンバルを中のリングはいじらずにそのもの全体をぐるぐる回してるに過ぎない
ジンバルロックというのは中のリングの内2つが同一平面上にある時の事を言う
その状態は要するに2軸が完全に重なっている事を意味する
そうすると残りのリングは一方向に回転するしかなくなり、向きたい方向に向け無くなってしまう
これが厳密な意味でのジンバルロックだ。わかったか？
3軸が全て垂直を保ったままの回転はジンバルロックは起きない
で、3D計算上でのジンバルロックというのはlookatのコードのように2軸から
外積を使って3軸目を求める時に2軸がほぼ重なってる時に向きがランダムな
状態になる事を言う AppleがWebGPUなる新APIを発表したが
これ標準になるのかね？ シェーダコードと頂点、テクスチャの無償寄付サイトになるな ソースコード公開されてたらタダだーと勝手にコピーして使っちゃう人？ 610みたいな無知がいるから法律ってのは必要なんだよな WebGLはTyped Arrayの内容をいちいちアップロードせずにテクスチャやバッファとして使えないかとは思う
VRAMが共有されてる環境ならコピー無しで使える
しかしGPUが使用中のデータは書き換えてはいけなかったり
GCがコンパクションでデータを移動しないようにメモリ上の位置を固定→パフォーマンスが低下するなど
ややこしい事になるかもしれない >>609
バレて炎上してるのはこういう人が居るからか。 >>602
なんかジェットコースター宙返りのように反り続けていくとてっぺんで急に向きがくるんと変わっちゃうあれですよね。 Intelも新グラフィックスドライバでVulkanに対応
ttp://pc.watch.impress.co.jp/docs/news/1044145.html >>614
それはlookAtが宙返り対応してないで裏がえる現象じゃね >>612
BufferObjectをダブルバッファにすればGPUとCPUで並列処理出来るよ
実際にコピーしてるかどうかはドライバ次第だ
Intelの内蔵GPUとかはコピーしてない気もするからな(実際のところは知らん) >>610
著作権表記がない場合は自動で付くんじゃなかった？ スマソが、グローシェーディングとかするのに法線使うけど、
その場合、頂点と1対1にするの？
OBJファイルでインデックス方式になってるのを、uv含めて展開するのが正しいのかな？ ■ このスレッドは過去ログ倉庫に格納されています
