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/ >>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含めて展開するのが正しいのかな？ >>619
最近だとテクスチャをダイナミックに更新したい場面が多い。
バッファオプジェクトのRO宣言って割りと意味ないと思う。
drawを非同期実装とかしないでしょ。 どうか教え下さい
AndroidアプリでNDK側でOpenGLESでテスクチャ作ってるのですが、
それをJava側に渡してGLSurfaceViewで表示したいです
readPixelsで配列データとして渡して表示はできたものの、遅すぎてゲームアプリとしては破綻していて。。。
どんな方法がベストでしょうか？やはり、コンテキストを共有するしかないでしょうか？ ベストを探す前に素直にサンプルと同じやり方を試すべきだと思う
そうしない理由があるのならそれを言わんことには サンプルってどれっすかね？
試すのは大丈夫なんですが、描画スレッド(Java側)と演算スレッド（NDK側）みたいな感じす
スレッド跨いでEGLコンテキスト共有とか、知識あんまり無いです。。
Java側はGLSurfaceView使ってるので、単なるSurfaceViewに変えないとだめっすかね。。 >>631
レス遅くなってすみません
シェーダー使うのもありですが、framebufferからreadpixelsする変わりにシェーダーで対応ってのがどうゆうことか理解できてません
とりあえずNDK側でガリガリ作った画をJava側に60fpsで渡す方法があれば何でも試します スレッドがJavaとNDK側で別なんです
そしてJava側はGLSurfaceViewなので、なおさらコンテキストは共通化できてないっす >>630
どれ？じゃねーよ
NDK使ってるんだろ？
大丈夫なら試せよ >>636
ndk-bundleのソースフォルダのサンプルが使えるってことですか？
使えそうなサンプルは無いように見えますが。。
教えて下さい。 だから何で自分の流儀を前提にしている訳？
あんたの流儀はあんたが一番知っているんだから
他人に聞くだけ無駄だよ こういう支離滅裂なアドバイス(?)する奴はなんなんだろうね？酔っぱらってんのか？ Androidの事は知らんけど、単にコンテキスト間でリソース共有にすればいいだけだよね。
Windowsならできる。同様のAPIあるんじゃね。 http://d.hatena.ne.jp/orangesignal/touch/20120818/1345275541
これをぱっと見た感じGLSurfaceViewのgl.glXxxとNDK側のglXxxは同じコンテキスト使ってるっぽいからtextureID渡すだけで行けそうなものだけど 横からスマソ、
俺もアンドロイドのOpenGL弄ってるんだけど、
GLES20.glxxxがラッパー？で、上で言ってるglxxxがNDKとか言うやつ？
サイトでよく出てくるサンプルはGLES20.使ってるけど、
そのNDKとやらを使うと速いとかなんかいい事あるの？ >>641
VM介さないから処理によっては速度が全然違う
ゲームとかはフルndkのほうがパフォーマンスが良い
これ以上はAndroidスレで聞いたほうがいい Javaだろうと、NDKだろうとスレッド別なら全く別処理でテクスチャも何もかも共有できないよね？ OpenGLESの知識は浅井ですが、自分の認識です↓
ttp://eaglesakura.hatenablog.com/entry/2013/12/28/235121 >>646
shared_contextは遅いの？ >>632
遅いのはJAVAとかNDKとか以前にreadpixelじゃないの？ >>648
そうです。
その代替案を探してるだけなんですが、描画と処理のスレッド別なので、テスクチャIDやフレームバッファを共有できない（EGLコンテキスト共有できない）と思ってましたが方法ありそうですね androidのことは詳しくないけどJava側のレンダリングスレッドからネイティブのレンダリング処理出すんじゃだめ？
CPUは並列に動かせてもGPUは並列には動かないし、別スレッドに分ける意味余りないよね？ レンダリングを別スレッドでやりたいわけじゃないでしょ。 並列で動いてるんじゃねレンダ要求直後VBO書き換えるとチラつく >>652
実装はAPIの関知する限りではない
いわゆる未定義動作の類なのでは？ 未定義つうか禁則じゃねVBO使わずにnioバッファの時は勝手に調停してくれてたんだが ほんと初心者で申し訳ないのですが、質問をお許しください。
現在、MAX/MSP jitterを使っているものです。
GLSLの勉強をしているのですが、例えばjitter側で生成した球に、
グローエフェクトをかけたい場合、どういう考え方でGSGLを記述したらよいでしょうか。
vvvvとかならグローエフェクト専用のノードで一発なのに、
MAXでシェーダを書く場合の例とかいろいろ検索しても出てきません。
質問自体もおかしなところがあるかも知れませんが、是非MAXの環境で
映像を作っていきたい理由があるので、どなたかご教示お願いします。 未定義は定義してないってことだね
禁則はやっちゃいけないってことだね
全然別の意味だね君の頭の中までは文句は無いよ
脳内の混同は取るに足らないありふれた事象だし >>657
プログラマは未定義動作をするプログラムを書いてはいけない事に変わりない。やっちゃいけないことだよ。 未定義動作とごっちゃにしているんだろうなと思ったら案の定。 未定義動作しても構わないよ
そこに到達しないコードを書くのが基本 未定義動作なんて聞かない言葉だと思ってググったらバッファの初期化忘れのことかよ
もしも初期化してなきゃ最初の1フレームは起きるかもしれないが件のは前のフレームと
次のフレームとの境目で起きると思われるちらつきだから未定義動作とやらでは無いわな WebGLだとセキュリティ上の理由でglMapBufferみたいな安全を保証できない機能は使用禁止 GTX1060（モニター①を接続）とQuadro4000（モニター②を接続）の2枚差し
PhotoshopなどのOpenGL系でGTX側に接続しているモニター①を10bitカラー表示させることってでませんか？
どのような効果が見込めるか分からなかったのですが、
NVIDIAコントロールパネル/3D設定の管理/OpenGLレンダリングGPU
の設定ではグローバル設定→Quadro4000に変更してみました ■ このスレッドは過去ログ倉庫に格納されています
