OpenGL/Vulkanスレ Part22©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2015/08/27(木) 18:12:51.54

クロスプラットフォームの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/

**デフォルトの名無しさん** · 2017/01/10(火) 04:17:52.45

よろしく

**デフォルトの名無しさん** · 2017/01/15(日) 08:46:04.47

glmapbufferrangeってglbindsubdataで代用できるよね？

**デフォルトの名無しさん** · 2017/01/18(水) 21:02:07.78

>>535
横からだが、座標系の違いはシェーダ時代だと存在自体がユーザの好みじゃないかな
GLとXの座標系の違いは固定機能が原因で、
シェーダだと座標系変換行列が吸収する。

少なくとも、俺が書いたDirectXのシェーダは、右手座標のモデルを入力して実現できている。

**デフォルトの名無しさん** · 2017/01/18(水) 23:17:38.12

変換行列は一緒だぞ
右座標だろうが左座標だろうが関係ない

**デフォルトの名無しさん** · 2017/01/20(金) 11:43:09.83

えっ、Zのプラスとマイナスが違うのに？

**デフォルトの名無しさん** · 2017/01/20(金) 23:47:40.41

Zを+にするか-にするかはアプリがどういう行列を作るかで決めることでグラフィックのAPIレベルでは関係ないぞ。
実際にUnityはGL、Metal、DirectXのどれを使っても左手座標だぞっと。

**デフォルトの名無しさん** · 2017/01/20(金) 23:49:00.32

多分固定機能時代はそれぞれが内部的に決まってたからそういう風に思ってる人が多いんだと思うが

**デフォルトの名無しさん** · 2017/01/20(金) 23:52:08.78

>>556
くやしいのぅ

**デフォルトの名無しさん** · 2017/01/21(土) 01:35:01.75

でもzの範囲の問題でprojectionは互換なかったりするよね？

**デフォルトの名無しさん** · 2017/01/21(土) 10:06:17.46

>>560
それはプロジェクション行列に下駄はかせるか頂点シェーダーで変換すればいいし、右左とは関係ないわな。

**デフォルトの名無しさん** · 2017/01/21(土) 13:20:01.43

ああ、なるほど確かに

**デフォルトの名無しさん** · 2017/01/23(月) 11:52:16.52

ttp://glslsandbox.com/
ここにglslのサンプルがいっぱいあるけど
ここのglslをコピペして自分のpcで動かしたいけどそういうのってできます？

**デフォルトの名無しさん** · 2017/01/23(月) 17:04:45.86

DirectXは左手系と言ってるみたいだけど、多分サンプルとかがそういう風に
実装されてるだけで、実際にはアプリが自由に決めていい
ただANGLEの実装ドキュメントによると最後のウィンドウ座標だけはY軸の向きが
OpenGLとDirectXで逆になってて変換する必要があると書いてあった
Y軸逆なのはテクスチャ座標もそうだな

**デフォルトの名無しさん** · 2017/01/23(月) 17:41:56.34

同じ座標指定したら右手と左手じゃおかれる位置が明らかに変わるんだから
自由じゃない

**デフォルトの名無しさん** · 2017/01/23(月) 18:39:41.15

>>542
jsみたいな高級言語だと、言語自体に予め遊びをいれておき、そこから適切なアルゴリズムを内側で変更するってことは可能じゃないかな
例えば、配列の探索。
シーケンシャルに読むコードであれば、ワークスレッドに分散して速度を稼ぐといった高速化ができる余地がある。
言語にスレッドがないからね

これはcでも可能だが、最適化より予めOpenCLだったかの言語拡張で教え込むことができるから、そのプロファイル自体が要らない。

JavaScriptはよく知らんが、GCと同じでプロセスが落ちたら最適解を忘れそう

**デフォルトの名無しさん** · 2017/01/23(月) 18:52:56.50

てか、配列探索の説明になってなかった。
配列の場合、言語では配列にみせるが、アクセスがシーケンシャルかインデックス単一要素アクセスのどちらが多いか、要素の削除やクリアの頻度を計るとかがあるような。
それによって内部の変数管理をリストに変更したりベクターにしたりという最適化があり得そう。
だが、実際は予めデザインで決定出来るのだが、そこをダイナミックオプティマイズで設計時間省略！てかはできるかな。
特に素人や頻繁にコードを変えるシーンだと好まれるかもしれない。
スレ違いすまん。

**デフォルトの名無しさん** · 2017/01/24(火) 00:14:13.56

>>565
お前は…
カメラの位置とかデータの内容が全て左手系や右手系を前提に構築されてれば
まったく同じ見栄えのゲームが作れんだよ
だからどっちを選択するのかはアプリの自由という事が理解できないのか？

**デフォルトの名無しさん** · 2017/01/24(火) 00:40:56.70

レンダリングエンジンを抽象化するという発想がないんでしょ

**デフォルトの名無しさん** · 2017/01/24(火) 00:45:59.50

座標データのZのプラスマイナス逆に刷りゃ同じになるけどそれって自由な選択じゃなくて座標系に合わせてデータ差し変えてるわけで意味合いが違うな

**デフォルトの名無しさん** · 2017/01/24(火) 00:56:20.21

ああ右手用データを左手座標にぶちこんでも全部逆になるから結局見た目は同じになるって言いたいわけ？

**デフォルトの名無しさん** · 2017/01/24(火) 02:15:07.07

左手系の為に左手系のデータを用意するのも含めてアプリの自由だと言ってんだよ
やたら頭堅いやつが紛れてるな

**デフォルトの名無しさん** · 2017/01/24(火) 02:17:37.50

左手系の為に左手系のデータやプログラムを用意する
右手系の為に右手系のデータやプログラムを用意する
どっちかを決定するのはDirectXが決める事じゃなくてアプリの自由だという単純な事だぞ？

**デフォルトの名無しさん** · 2017/01/24(火) 08:24:46.56

>>570
座標系に縛られるから不自由とかはグラフィックス計算の話題じゃないな

計算するのが不自由って意味になる…

**デフォルトの名無しさん** · 2017/01/24(火) 10:19:43.83

それよりボトムアップなのがややこしい
FBOでテクスチャに描いたときに上下が逆になってしまう

対策は頂点シェーダーで座標を逆転させるか
普通のテクスチャを逆転させるか

**デフォルトの名無しさん** · 2017/01/24(火) 15:21:07.00

Aという行列があるとして

→X=(x,y,z)というベクトルを用意して
→Y = →XA という掛け算をするのが「いわゆる左手系と呼ばれる操作」

↑X'=(
x',
y',
z')
というベクトルを用意して
↑Y' = A↑X' という掛け算をするのが「いわゆる右手系と呼ばれる操作」

の違いでしかない
(要するにどちらも本質的には同じ)

**デフォルトの名無しさん** · 2017/01/24(火) 18:46:32.22

>>575
アプリ内で反転したテクスチャをレンダラに渡すって手もあるが猛烈にメモリーの無駄
うちはGIMPでエクスポートするとき上下の鏡像反転だね

**デフォルトの名無しさん** · 2017/01/24(火) 18:56:09.33

計算回数も変わらないしね
ボトムアップなのは、数学のグラフと同じ座標系にしたかったから、とか聞いたことがある。

xが接線、yが法線、zが従法線として、キチンと向きが揃うとかなんとか

**デフォルトの名無しさん** · 2017/01/24(火) 19:11:02.74

ttp://stackoverflow.com/questions/4124041/is-opengl-coordinate-system-left-handed-or-right-handed
OpenGLはobjspaceとworldspaceでは右手系で
glOrtho/glFrustumの実装のせいでwindow座標では左手系になるらしい
といっても古いOpenGLのお話

**デフォルトの名無しさん** · 2017/01/24(火) 19:46:57.06

Vulkan SDK 1.0.39.0

ttp://vulkan.lunarg.com/sdk/home

**デフォルトの名無しさん** · 2017/01/25(水) 16:37:16.52

>>576
大間違い
それは単に行列が列指向(column oriented)か行指向の違いでしかない
Wikipediaにちゃんと書いてあるんだから見ればいい

**デフォルトの名無しさん** · 2017/01/25(水) 16:45:53.74

>>578
> xが接線、yが法線、zが従法線として
それだとトップダウンにならないか？
接空間(tangent space)の事を言ってるなら
x=接線(tangent) y=従法線(binormal) z=法線(normal) だな

**デフォルトの名無しさん** · 2017/01/25(水) 16:46:16.20

みなさんは3D行列の勉強はどこでしたんですか？

**デフォルトの名無しさん** · 2017/01/25(水) 17:50:32.20

してないという選択もlookatに丸投げ

**デフォルトの名無しさん** · 2017/01/27(金) 17:24:37.23

OpenGL 4.0 シェーディング言語 -実例で覚えるGLSLプログラミング
https://github.com/daw42/glslcookbook
ここのサンプルは右手系と左手系どちらなのでしょうか

**デフォルトの名無しさん** · 2017/01/27(金) 20:23:38.57

ハンドネスにやたらと拘る異常者が湧いてるな。

**デフォルトの名無しさん** · 2017/01/28(土) 10:23:30.45

Vulkan SDK 1.0.39.1

**デフォルトの名無しさん** · 2017/01/29(日) 16:06:14.97

GLしか使わないからハンドネスなんかどうでもいいが
原点視点から離れていく方向が+だからGLのほうが自然では無いかと
あんまりなさそうだけど訴訟になった場合の対策でz逆にしたのかしらね

**デフォルトの名無しさん** · 2017/02/03(金) 14:26:53.63

ジンバルロックの理屈はわかるけど、実際何が問題なの？2軸が重なろうが構わず指定通り回転させればいいのでは？

**デフォルトの名無しさん** · 2017/02/04(土) 02:53:25.98

2軸を外積を使って残りの軸を割り出す時に、完全に2軸が重なってると
外積の結果はゼロベクトルになってしまうけど、微妙な距離だと方向が
激しく変化する事により、向きがブルブルしてしまう事をジンバルロックと言う

**デフォルトの名無しさん** · 2017/02/04(土) 03:01:48.01

(以下Y軸プラス方向が真上とする)
よくある状況としてはlookatを使う時に普通はUpベクトルにY軸を渡すけど
真上を向こうとした時に方向ベクトル(eye - center)がY軸とほぼ同じ方向に
なった時にサイドベクトル(X軸)が>>590の状況により、激しく変化して
グルグル回ってしまうとかある

**デフォルトの名無しさん** · 2017/02/05(日) 00:53:48.57

x軸を外積で出さないでベクトル値を持っていればいいのでは？

**デフォルトの名無しさん** · 2017/02/05(日) 00:58:49.50

方向ベクトルが任意なのにそのx軸ベクトルが固定値になるわけがない

**デフォルトの名無しさん** · 2017/02/05(日) 01:23:15.93

最初だけ外積で出して後はそれを一緒に回転させればいいのでは

**デフォルトの名無しさん** · 2017/02/05(日) 01:32:20.83

その「一緒に回転」を数学的に厳密に描写してみ
ジンバルロックと同じ問題が出るから

**デフォルトの名無しさん** · 2017/02/05(日) 04:27:58.79

カメラの視線ベクトルも上ベクトルも、極座標変数θ、φから計算して常に直交するようにして与えてる。

**デフォルトの名無しさん** · 2017/02/05(日) 23:06:56.76

FPSみたいなゲームだと真上を向くのは人間の首だからY軸と一定の角度以上には
上を向けないように制限してジンバルロックに対処してるのがほとんどだな

**デフォルトの名無しさん** · 2017/02/06(月) 15:28:30.58

再度ジンバルロックについてお尋ねします。

軸が重なると言っているのは、初期姿勢のXYZ軸と、
回転後のXYZ軸が重なるということを言っているのだと思いますが、
２番目だけ９０度だとマズイと言っていますが、
１番目を９０度にしても軸は重なりますよね？

例えばXYZ軸の順で回転したい場合、
X軸をいきなり９０度回せばY軸とZ軸は重なってしまうと思うのですが、
これはジンバルロックにならないのでしょうか？

**598** · 2017/02/06(月) 15:30:51.89

また、２番目を９０度にしても、一番目を何度か動かせば、
初期軸と回転後の軸は重ならないと思うのですが。

XYZ軸の順で回転させる場合、
Xを45度回し、Y軸を90度回しても、回転後のX軸と最初のZ軸は重なりませんよね？

**デフォルトの名無しさん** · 2017/02/06(月) 15:34:01.74

うん

**598** · 2017/02/06(月) 15:49:33.60

じゃあ結局、何が問題なんです？

**デフォルトの名無しさん** · 2017/02/06(月) 21:07:00.36

回転と考えるから理解出来ないんだよ
単にあるものを回転させてるだけならジンバルロックなんて起きない
いわゆるジンバルを中のリングはいじらずにそのもの全体をぐるぐる回してるに過ぎない
ジンバルロックというのは中のリングの内2つが同一平面上にある時の事を言う
その状態は要するに2軸が完全に重なっている事を意味する
そうすると残りのリングは一方向に回転するしかなくなり、向きたい方向に向け無くなってしまう
これが厳密な意味でのジンバルロックだ。わかったか？
3軸が全て垂直を保ったままの回転はジンバルロックは起きない
で、3D計算上でのジンバルロックというのはlookatのコードのように2軸から
外積を使って3軸目を求める時に2軸がほぼ重なってる時に向きがランダムな
状態になる事を言う

**デフォルトの名無しさん** · 2017/02/10(金) 10:46:44.10

AppleがWebGPUなる新APIを発表したが
これ標準になるのかね？

**デフォルトの名無しさん** · 2017/02/10(金) 15:25:49.78

Metalが標準になるような未来がもし来れば

**デフォルトの名無しさん** · 2017/02/11(土) 10:32:30.83

シェーダコードと頂点、テクスチャの無償寄付サイトになるな

**デフォルトの名無しさん** · 2017/02/11(土) 10:53:09.39

ソースコード公開されてたらタダだーと勝手にコピーして使っちゃう人？

**デフォルトの名無しさん** · 2017/02/11(土) 13:07:50.78

参考にするだけです

**デフォルトの名無しさん** · 2017/02/11(土) 13:30:47.81

metalはc++で使えないのが厳しすぎる

**デフォルトの名無しさん** · 2017/02/11(土) 13:40:07.89

バレなきゃok
わかりっこないし
こんなもんよ

**デフォルトの名無しさん** · 2017/02/11(土) 13:41:27.87

>>606
日本のソースコードに著作権はないよ。

**デフォルトの名無しさん** · 2017/02/11(土) 14:00:40.28

610みたいな無知がいるから法律ってのは必要なんだよな

**デフォルトの名無しさん** · 2017/02/11(土) 14:12:23.72

WebGLはTyped Arrayの内容をいちいちアップロードせずにテクスチャやバッファとして使えないかとは思う
VRAMが共有されてる環境ならコピー無しで使える

しかしGPUが使用中のデータは書き換えてはいけなかったり
GCがコンパクションでデータを移動しないようにメモリ上の位置を固定→パフォーマンスが低下するなど
ややこしい事になるかもしれない

**デフォルトの名無しさん** · 2017/02/11(土) 18:55:07.85

>>609
バレて炎上してるのはこういう人が居るからか。

**デフォルトの名無しさん** · 2017/02/13(月) 04:30:53.35

>>602
なんかジェットコースター宙返りのように反り続けていくとてっぺんで急に向きがくるんと変わっちゃうあれですよね。

**デフォルトの名無しさん** · 2017/02/14(火) 20:31:42.76

Intelも新グラフィックスドライバでVulkanに対応
ttp://pc.watch.impress.co.jp/docs/news/1044145.html

**デフォルトの名無しさん** · 2017/02/15(水) 07:52:58.06

>>614
それはlookAtが宙返り対応してないで裏がえる現象じゃね

**デフォルトの名無しさん** · 2017/02/15(水) 11:08:57.36

フライトシミュレーターでもあるな

**デフォルトの名無しさん** · 2017/02/15(水) 19:10:02.58

上方ベクトルは正しく設定しよう

**デフォルトの名無しさん** · 2017/02/16(木) 19:23:56.82

>>612
BufferObjectをダブルバッファにすればGPUとCPUで並列処理出来るよ
実際にコピーしてるかどうかはドライバ次第だ
Intelの内蔵GPUとかはコピーしてない気もするからな(実際のところは知らん)

**デフォルトの名無しさん** · 2017/02/28(火) 23:44:46.26

Vulkan SDK 1.0.42.0

**デフォルトの名無しさん** · 2017/03/11(土) 21:38:04.37

Vulkan SDK 1.0.42.1

**デフォルトの名無しさん** · 2017/03/29(水) 10:55:29.16

>>610
著作権表記がない場合は自動で付くんじゃなかった？

**デフォルトの名無しさん** · 2017/03/30(木) 19:32:54.16

スマソが、グローシェーディングとかするのに法線使うけど、
その場合、頂点と1対1にするの？
OBJファイルでインデックス方式になってるのを、uv含めて展開するのが正しいのかな？

**デフォルトの名無しさん** · 2017/03/30(木) 20:37:39.14

>>623
正しい

**デフォルトの名無しさん** · 2017/04/01(土) 08:37:36.41

>>619
最近だとテクスチャをダイナミックに更新したい場面が多い。
バッファオプジェクトのRO宣言って割りと意味ないと思う。
drawを非同期実装とかしないでしょ。

**デフォルトの名無しさん** · 2017/04/01(土) 13:11:28.85

Vulkan SDK 1.0.42.2

**デフォルトの名無しさん** · 2017/04/07(金) 06:17:33.77

Vulkan SDK 1.0.46.0

**デフォルトの名無しさん** · 2017/04/09(日) 23:59:57.43

どうか教え下さい
AndroidアプリでNDK側でOpenGLESでテスクチャ作ってるのですが、
それをJava側に渡してGLSurfaceViewで表示したいです
readPixelsで配列データとして渡して表示はできたものの、遅すぎてゲームアプリとしては破綻していて。。。

どんな方法がベストでしょうか？やはり、コンテキストを共有するしかないでしょうか？

**デフォルトの名無しさん** · 2017/04/10(月) 00:15:57.40

ベストを探す前に素直にサンプルと同じやり方を試すべきだと思う
そうしない理由があるのならそれを言わんことには

**デフォルトの名無しさん** · 2017/04/10(月) 00:47:22.23

サンプルってどれっすかね？
試すのは大丈夫なんですが、描画スレッド(Java側)と演算スレッド（NDK側）みたいな感じす
スレッド跨いでEGLコンテキスト共有とか、知識あんまり無いです。。
Java側はGLSurfaceView使ってるので、単なるSurfaceViewに変えないとだめっすかね。。

**デフォルトの名無しさん** · 2017/04/10(月) 01:57:45.01

シェーダー使わんの？

**デフォルトの名無しさん** · 2017/04/10(月) 21:03:21.49

>>631
レス遅くなってすみません
シェーダー使うのもありですが、framebufferからreadpixelsする変わりにシェーダーで対応ってのがどうゆうことか理解できてません

とりあえずNDK側でガリガリ作った画をJava側に60fpsで渡す方法があれば何でも試します

**デフォルトの名無しさん** · 2017/04/10(月) 22:12:20.96

textureIDだけ渡したらいいんじゃないの？

**デフォルトの名無しさん** · 2017/04/10(月) 22:21:58.29

スレッドがJavaとNDK側で別なんです
そしてJava側はGLSurfaceViewなので、なおさらコンテキストは共通化できてないっす

**デフォルトの名無しさん** · 2017/04/10(月) 22:46:43.31

>>630
どれ？じゃねーよ
NDK使ってるんだろ？
大丈夫なら試せよ

**デフォルトの名無しさん** · 2017/04/10(月) 23:08:39.40

>>636
ndk-bundleのソースフォルダのサンプルが使えるってことですか？
使えそうなサンプルは無いように見えますが。。
教えて下さい。

**デフォルトの名無しさん** · 2017/04/10(月) 23:18:56.98

だから何で自分の流儀を前提にしている訳？

あんたの流儀はあんたが一番知っているんだから
他人に聞くだけ無駄だよ

**デフォルトの名無しさん** · 2017/04/10(月) 23:36:22.60

こういう支離滅裂なアドバイス(?)する奴はなんなんだろうね？酔っぱらってんのか？

**デフォルトの名無しさん** · 2017/04/11(火) 00:26:38.47

Androidの事は知らんけど、単にコンテキスト間でリソース共有にすればいいだけだよね。
Windowsならできる。同様のAPIあるんじゃね。

**デフォルトの名無しさん** · 2017/04/11(火) 02:09:09.99

http://d.hatena.ne.jp/orangesignal/touch/20120818/1345275541
これをぱっと見た感じGLSurfaceViewのgl.glXxxとNDK側のglXxxは同じコンテキスト使ってるっぽいからtextureID渡すだけで行けそうなものだけど

**デフォルトの名無しさん** · 2017/04/11(火) 17:50:22.73

横からスマソ、
俺もアンドロイドのOpenGL弄ってるんだけど、
GLES20.glxxxがラッパー？で、上で言ってるglxxxがNDKとか言うやつ？
サイトでよく出てくるサンプルはGLES20.使ってるけど、
そのNDKとやらを使うと速いとかなんかいい事あるの？

**デフォルトの名無しさん** · 2017/04/11(火) 18:56:16.06

>>641
VM介さないから処理によっては速度が全然違う
ゲームとかはフルndkのほうがパフォーマンスが良い
これ以上はAndroidスレで聞いたほうがいい

**デフォルトの名無しさん** · 2017/04/11(火) 19:25:19.23

javaはラッパー

**デフォルトの名無しさん** · 2017/04/11(火) 21:13:28.73

Javaだろうと、NDKだろうとスレッド別なら全く別処理でテクスチャも何もかも共有できないよね？

**デフォルトの名無しさん** · 2017/04/11(火) 21:26:42.43

>>633
だよね

**デフォルトの名無しさん** · 2017/04/12(水) 00:32:08.21

OpenGLESの知識は浅井ですが、自分の認識です↓
ttp://eaglesakura.hatenablog.com/entry/2013/12/28/235121

**デフォルトの名無しさん** · 2017/04/12(水) 01:06:15.23

>>646
shared_contextは遅いの？

**デフォルトの名無しさん** · 2017/04/12(水) 11:50:27.11

>>632
遅いのはJAVAとかNDKとか以前にreadpixelじゃないの？

**デフォルトの名無しさん** · 2017/04/12(水) 12:54:48.21

>>648
そうです。
その代替案を探してるだけなんですが、描画と処理のスレッド別なので、テスクチャIDやフレームバッファを共有できない（EGLコンテキスト共有できない）と思ってましたが方法ありそうですね

**デフォルトの名無しさん** · 2017/04/12(水) 21:35:08.21

androidのことは詳しくないけどJava側のレンダリングスレッドからネイティブのレンダリング処理出すんじゃだめ？
CPUは並列に動かせてもGPUは並列には動かないし、別スレッドに分ける意味余りないよね？

**デフォルトの名無しさん** · 2017/04/12(水) 21:47:27.65

レンダリングを別スレッドでやりたいわけじゃないでしょ。

**デフォルトの名無しさん** · 2017/04/14(金) 05:02:55.11

並列で動いてるんじゃねレンダ要求直後VBO書き換えるとチラつく