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/

**デフォルトの名無しさん** · 2016/09/07(水) 15:01:21.08

>>417
それな

モバイルが速くなるんなら
PCの箱の中がほとんど空っぽで真ん中にモバイルとかな

**デフォルトの名無しさん** · 2016/09/07(水) 15:05:20.64

>>419
勝てる気がしない

**デフォルトの名無しさん** · 2016/09/07(水) 17:27:15.68

頭の悪さがプログラマとして致命的だな
ただの荒らしだろうけど

**デフォルトの名無しさん** · 2016/09/07(水) 19:55:36.21

>>421
「永遠」を証明するにはそれを阻害するあらゆる可能性を全て排除出来て初めて証明出来るが
それは要するに悪魔の証明という事だ
とりあえず、お前の突っ込みはただ悪口を言うだけの幼稚園児並みだなｗ

**デフォルトの名無しさん** · 2016/09/07(水) 23:03:24.31

簡単な話、PCもモバイルも無くなるかも知れない。
PC が先に無くなれば、モバイルが追い越す期間が存在することになる。

どうでもいい話だ。
仕事があればスマホでもPCでもコンシューマでも、必要な程度に作りこむさ。

**デフォルトの名無しさん** · 2016/09/08(木) 01:13:52.71

デスクトップが衰退していくのは無くなるからモバイルが追い越すとか、それ性能の話とは全く関係ないっていう滑稽さ

**デフォルトの名無しさん** · 2016/09/08(木) 01:50:45.12

ダウンサイジングでWSやオフコンが消えたから今度はPCが消える的な話なら多少はね
若い世代はPC持たないしフツーの家庭からPCが消える可能性もなくはない

**デフォルトの名無しさん** · 2016/09/08(木) 02:51:28.88

性能なんて相対的なもんだろ
PCが無くなってスマホがその位置になって、コンピューターは指輪ぐらいの大きさになって
その指輪ぐらいの大きさの何かが永遠にスマホを越えられないって誰かが言うんだろうよ

**デフォルトの名無しさん** · 2016/09/08(木) 08:52:40.65

何年も前から
ネットサーフィンとメールしかやらない層がフル機能のＰＣ買って
ウイルスにやられたりするのは愚かしいと思ってたし
あるべき姿に戻るだけ

スマホの詰め込み過ぎもいずれアジアの廉価製品が出てきて駆逐されるだろう

**デフォルトの名無しさん** · 2016/09/12(月) 16:18:05.89

Vulkan SDK 1.0.26.0

**デフォルトの名無しさん** · 2016/10/01(土) 13:39:18.23

質問だけど
2D画像を表示するために構造体でテクスチャID、幅と高さの大きさを持たせて使ってるんだが
テクスチャIDから画像の幅と高さを取得するメソッドってないの？
スッキリさせたい。glfwです

**デフォルトの名無しさん** · 2016/10/01(土) 16:15:52.39

glgetなんちゃら

**デフォルトの名無しさん** · 2016/10/01(土) 17:51:15.55

見当たりません・・・

**デフォルトの名無しさん** · 2016/10/01(土) 18:02:04.33

見つかりました。glGetTexLevelParameterivのことですね！
ありがとうございます

**デフォルトの名無しさん** · 2016/10/01(土) 18:06:48.64

バカルンの本はまだ出ないんだな
まあどうせ実機ないからテストできん

**デフォルトの名無しさん** · 2016/10/01(土) 19:15:46.11

ばかるん？

PCでもわりと最近のGPUなら動くだろ？Vulkan

**デフォルトの名無しさん** · 2016/10/01(土) 22:45:36.64

ゲームなら既に、DOOMとThe Talos PrincipleとDota2がVulkanで動いてる。

本なんて要らんだろ。本が必要なレベルの人間には扱えない。

**デフォルトの名無しさん** · 2016/10/01(土) 23:46:07.93

んなことはない
日本語の本は期待できないが本家赤本は最初7月には出るはずだったのがひと月ずつずれていって今では11月発売だ
とりあえず赤本待ち

**デフォルトの名無しさん** · 2016/10/02(日) 01:29:36.47

馬鹿るん♪

**デフォルトの名無しさん** · 2016/10/03(月) 01:52:58.66

>>437
OpenGL1の赤本と同じだと思ってるお前の方がバカだろw
英語読めないのかよww

**デフォルトの名無しさん** · 2016/10/03(月) 02:07:52.63

Vulkanを魔術みたいに特別扱いしてる奴ダサ過ぎw
PS4のローレベルなAPIはかなりむずいが詳細なドキュメントが日本語で付いてるよ
それ理解した奴ならVulkanに置き換えるのは簡単だろ、同じAMDだし
俺らはそんな経験ないんだから赤本から始めるんだ

**デフォルトの名無しさん** · 2016/10/03(月) 21:09:30.88

英語のＷｅｂサイトなんであんな真っ黒なんだよ
アダルトサイトと区別つかねえ

**デフォルトの名無しさん** · 2016/10/09(日) 18:49:04.27

Vulkan使っても体感速度はほとんど変わらない
PCならせいぜい10%程度みたい

**デフォルトの名無しさん** · 2016/10/09(日) 22:52:45.33

10%は十分大きいと思うけど

**デフォルトの名無しさん** · 2016/10/11(火) 14:03:30.72

CPUに負荷が掛かりまくりでギリギリでも無ければ体感速度は変わらないでしょ？

**デフォルトの名無しさん** · 2016/10/11(火) 16:42:10.06

無駄な処理が減れば、それだけ消費電力が減るんだよ！

**デフォルトの名無しさん** · 2016/10/11(火) 22:08:02.31

Vulkan使って変わらないのは単に使いこなしてないだけじゃないのか？

**デフォルトの名無しさん** · 2016/10/15(土) 15:33:54.85

Vulkan SDK 1.0.30.0

**デフォルトの名無しさん** · 2016/10/16(日) 23:15:10.74

太陽戦隊

**デフォルトの名無しさん** · 2016/10/22(土) 02:06:34.20

https://youtu.be/rvCD9FaTKCA

**デフォルトの名無しさん** · 2016/10/22(土) 09:00:47.31

gtkmm3+epoxy+sgslで隠面消去の方法を質問したいのだけど
何処のスレが良いのですか？

**デフォルトの名無しさん** · 2016/10/22(土) 10:59:15.86

くだすれ

**デフォルトの名無しさん** · 2016/10/22(土) 11:23:56.21

sgslって何だ・・・org
glslです

プログラム板のくだすれで質問できそうなのは「くだすれC++/CLI（初心者用）part2」だけど・・・
行ってみます

**デフォルトの名無しさん** · 2016/10/24(月) 08:30:59.75

OpenGLAPIでラップして使えるなら使う

**デフォルトの名無しさん** · 2016/10/25(火) 20:56:46.57

PBOからテクスチャにピクセルデータの転送を行いたいのですが、バッファ上の画像のピッチと
テクスチャのピッチが異なる場合で困っています。
テクスチャの方が大きい場合はglTexImage2Dでできそうなんですが、逆にバッファ上の画像の方が
大きい場合にその一部をテクスチャに転送する方法がわかりませんでした。
OpenCLやCUDAのような、srcとdstのピッチが違う場合でも使える汎用的な矩形転送って無いんでしょうか？

**デフォルトの名無しさん** · 2016/10/26(水) 07:32:45.55

glTexSubImage2Dかな。

**453** · 2016/10/26(水) 08:18:34.18

ありがとうございます。
でもglTexSubImage2Dは転送元のバッファ側が連続している必要あるんじゃないですか？
テクスチャの方が小さい場合はバッファの一部の矩形領域を転送することになりますが、
そういうことはできないような。

**デフォルトの名無しさん** · 2016/10/26(水) 12:12:11.17

ああ、そう言うことか。
それならパデイングを含むサイズのダミーテクスチャ作ってglCopyTextureSubImage2Dだけとなんか無駄だなぁ
前提条件を見直した方がいい気がする

**デフォルトの名無しさん** · 2016/10/26(水) 16:10:22.42

小さいテクスチャをテクスチャとして矩形をテクスチャにレンダリングするだけだろ

**デフォルトの名無しさん** · 2016/10/26(水) 20:20:11.52

ぐぐったら同じ問題の人がいて、その人はラインごとに転送したとか。
自分は結局テクスチャと同サイズのバッファを別に作ることにしました。

>>457
具体的なやり方がちょっとわかりませんが、FBOとか使うんですかね？

**デフォルトの名無しさん** · 2016/10/26(水) 20:35:27.43

適当に書くけどglPixelStoreiのGL_UNPACK_ROW_LENGTH？

**デフォルトの名無しさん** · 2016/10/26(水) 22:08:52.23

テクスチャからPBOにコピーはやったことあるから、たぶん逆もできるだろうけど、調べるのめんどくせ

**デフォルトの名無しさん** · 2016/10/26(水) 22:54:36.78

>>459
なるほど。これとSKIPを組み合わせたら目的のことができるんですかね。
それにしてもglTexSubImage2Dの方に説明がないのはわかりづらいなぁ。

**デフォルトの名無しさん** · 2016/10/27(木) 16:25:07.88

OpenGLやDirect2Dで画像処理して高速化するってどういうことなんでしょうか？？
例えば、GPGPUでOpenCLなどを使ってピクセルの処理を行って高速化するのはわかるんですが、
OpenGLとかではどうやるのかと。

例えば、画像をテクスチャとしてOpenGLになり取り込んで、ピクセルシェーダーだか
知りませんがそれで画像のピクセルのアクセスして処理する感じなのでしょうか？？

**デフォルトの名無しさん** · 2016/10/27(木) 16:56:16.97

メッシュ変形とかの3D機能を応用する場合を除けば
基本はGPGPUと変わらんよ

**デフォルトの名無しさん** · 2016/10/27(木) 17:18:13.80

画像はテクスチャとして取り込まないといけない？から、処理できる画像の
最大サイズ制限はあるってことですかね？？

OpenGL ES3.1などで追加されたCompute Shaderの場合もテクスチャ取り込む？
Image Store/Loadって使っても？

初心者なのでちんぷんかんぷんな事言ってたらすみません。

**デフォルトの名無しさん** · 2016/10/27(木) 21:01:07.59

はい

**デフォルトの名無しさん** · 2016/10/27(木) 21:03:59.99

はいじゃないが

**デフォルトの名無しさん** · 2016/11/02(水) 12:27:08.57

少なくともスマホではvulkan使う価値ないみたいね

http://project-asura.com/blog/?p=3509

＞以上を踏まえて，私が出した結論は「Vulkanは絶対に触るべきではない」です

ｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2016/11/02(水) 13:41:59.29

スマホこそ消費電力減らすために導入は必須だよ。
やり方が違って複雑だと嘆いているアホでしょ。

**デフォルトの名無しさん** · 2016/11/02(水) 18:10:39.64

>>468
ちゃんと記事読んでないアホ発見

**デフォルトの名無しさん** · 2016/11/02(水) 23:38:20.18

VulkanはAMDが自社GPUを効率良く動かすために実装したMantleがベースになってるから
> 基本的にVulkan専用のハードとか作っている会社は無いと思うので
こんな事言ってる奴は馬鹿丸出しで見てて恥ずかしくなる…
PS4のAPIもAMDが実装しててVulkanに似てるしもっと低レベルなAPIだ
PS4で自社エンジンでゲーム作ってる会社はみんなVulkanより低レベルのAPIで作ってる

当然難しいのは間違いないが、日本語の詳細なドキュメントやらサンプルやらついてるから
ある程度経験者なら普通に使うことは出来る

**デフォルトの名無しさん** · 2016/11/02(水) 23:48:26.87

ちなみに10年も前のPS3から低レベルAPIだぞ
ただマルチスレッド未対応だったから今ほどは洗練されてなかったと思われる

PS3の頃はシェーダー未経験な人ばっかだからみんな面食らって
想定した全機能を実装するのに数ヶ月どころか半年近く掛かるなんてざらだったと思われる

**デフォルトの名無しさん** · 2016/11/03(木) 00:19:08.23

複雑で嘆くのはみんな通る道だが、1本グラフィックエンジン仕上げてもいないのに
クソと言ってしまうのが無能な証拠
Vulkanでゲームを1本マスターアップさせてから、やっぱりVulkaクソだったと言うなら間違いなくクソなんだろう

**デフォルトの名無しさん** · 2016/11/03(木) 00:52:21.85

無能な奴でも使えるもん作れない奴らも無能だわ。
つーか、日本語で唯一vulkanの情報を発信していた人がサジを投げたわけだな。

**デフォルトの名無しさん** · 2016/11/03(木) 01:02:58.29

だから、無能な奴はOpenGL使ってればいいだろ。まだ進化もドライバサポートもしてんだし
Vulkanは限界までパフォーマンスを引き出す為のもんだよ
お前らがゲームのグラに一喜一憂するから、開発者はどんだけ難しくて大変でも
ちゃんとパフォーマンスさえ出れば何でも使うんだよ
Vulkanはパフォーマンスがちゃんと出るか出ないかが問題なんだよ

**デフォルトの名無しさん** · 2016/11/03(木) 02:31:52.70

PS4のAPIがVulkanより低レベルとか本気でいってんのかな…

**デフォルトの名無しさん** · 2016/11/03(木) 02:59:06.79

ん？GNMXじゃなくてGNMの事だぞ？
なかなか情報がないけど
http://www.neogaf.com/forum/showthread.php?t=1021024
> Sony’s current API is much low level compared to Mantle and even Vulkan
MantleやVulkanと比べてもとてもローレベルと言ってるぞ

**デフォルトの名無しさん** · 2016/11/03(木) 03:16:03.88

多分「低レベル」の意味を勘違いしてる素人

**デフォルトの名無しさん** · 2016/11/03(木) 03:16:29.40

こっちがソースか
http://gamingbolt.com/ps4-should-support-vulkan-ps4s-api-not-completely-native-for-current-gen-yet-brad-wardell
> their low-level API is still lower level than Mantle and Vulkan
って明確にVulkanよりローレベルって言ってる
GNMはハード直叩きに限り無く近いからな

**デフォルトの名無しさん** · 2016/11/03(木) 03:23:08.12

>>477
なんだ、そういうことかw
ローレベルって言えば通じるのかな？日本語って難しいなw

**デフォルトの名無しさん** · 2016/11/03(木) 07:29:33.57

つーか素人うぜえよ
テメエで使ったこともねえくせに
良いだの悪いだの
アホじゃねーの？

**デフォルトの名無しさん** · 2016/11/03(木) 09:55:27.53

なら玄人しかいない場所いけよ馬鹿

**デフォルトの名無しさん** · 2016/11/03(木) 11:51:36.18

手続きの手順が違うから
まっさらからVulkanに合わせて作るならともかく
既存のOpenGLベースのコードの中身を入れ替えたり拡張するような使い方じゃ性能でないよって話だよね？

**デフォルトの名無しさん** · 2016/11/03(木) 12:13:24.92

プログラム書かないひとかもね

**デフォルトの名無しさん** · 2016/11/03(木) 13:01:20.70

質問です
画像を描画する際、配列を渡して一斉に描画するほうが高速だと聞きました
ですが渡す配列が固定長だと描画枚数が増えた時に柔軟に対応できない気がします
皆さんはそういった場合、毎フレーム動的配列を生成・削除してるのでしょうか？

**デフォルトの名無しさん** · 2016/11/03(木) 13:25:03.45

前回と同じサイズのものは使いまわす

っていうかそんなことより0で埋めるとか馬鹿な初期化する方が無駄

**デフォルトの名無しさん** · 2016/11/03(木) 13:34:07.71

前回と同じサイズのものは使いまわせばいいことは分かっています
描画する数が毎回変わるならどうすれば・・・って話です

**デフォルトの名無しさん** · 2016/11/03(木) 13:35:50.93

気になるなら予め最大値判る大きさにしとけよ

**デフォルトの名無しさん** · 2016/11/03(木) 13:43:51.84

描画したくないものまで描画されるじゃないですか
画面外に描画する。それでいいんですかね
めんどくさいので配列として扱わないことにしました

**デフォルトの名無しさん** · 2016/11/03(木) 17:31:55.68

みんなマルチスレッド化されたOpenGLが欲しかったんだよね？

**デフォルトの名無しさん** · 2016/11/03(木) 17:47:51.27

そうでもない

**デフォルトの名無しさん** · 2016/11/03(木) 19:19:47.74

>>488
OpenGLは必ず配列内の有効な個数を指定する必要がある
余計に描画されるとかしょうもない推測をするな

**デフォルトの名無しさん** · 2016/11/03(木) 21:14:58.89

>>491
thx。やり方がわかりました

**デフォルトの名無しさん** · 2016/11/04(金) 01:29:43.97

>>488
なんで必ず最大数描画するだよ、描画個数決めれるだろ
必要な分だけ先頭に詰めれ

**デフォルトの名無しさん** · 2016/11/04(金) 03:35:43.26

縦横の慣習が違うのは
民族性とか文化の違いから来てるんですか

**デフォルトの名無しさん** · 2016/11/04(金) 11:13:20.80

>>467
お前らが叩くから記事消えちゃったじゃん

**デフォルトの名無しさん** · 2016/11/04(金) 14:57:33.75

> 描画したくないものまで描画されるじゃないですか
？
頂点数指定するだろ。

ていうか配列でというのは連続したメモリ領域をという意味だから、常にプログラミング言語仕様で言うところの配列の先頭からでなくともよい。
でかい固定配列をリングバッファとして使っても良い。

> 配列を渡して一斉に描画するほうが高速だと聞きました
これを言った人が何を意味していたのか分からないが、
・4頂点ずつ描画キックするよりはまとめてキックした方が良い
・glVertex や glColor の類を使うよりはglVertexPointerを使う方が良い
・VBO を使うとより良い
と言える。

素人は何を聞いているのか分からないことが良くある。もっと謙虚になるといい。

**デフォルトの名無しさん** · 2016/11/04(金) 14:58:53.65

ごめん、リロードしてなかった。

**デフォルトの名無しさん** · 2016/11/05(土) 01:13:00.41

>>495
ｸｿﾜﾛﾀww
消すような記事最初から書くなよw

**デフォルトの名無しさん** · 2016/11/15(火) 10:16:57.35

Vulkanってローレベル過ぎて使いづらそう
なんかこう
OpenGLとVulkanの中間みたいのが欲しい

**デフォルトの名無しさん** · 2016/11/16(水) 01:11:12.85

もうこれ以上api増やさないで

**デフォルトの名無しさん** · 2016/11/16(水) 07:35:03.91

赤本出たけど勉強してるの？

**デフォルトの名無しさん** · 2016/11/16(水) 11:01:21.29

そもそも流行りそうに無いんだよなぁ……

**デフォルトの名無しさん** · 2016/11/16(水) 11:08:50.83

そうかなぁ

**デフォルトの名無しさん** · 2016/11/16(水) 12:24:37.35

最近になってOpenGLを触ったんだけど凄く使い辛いと思った
元がとても昔に作られたものだからこんなものかとも考えたが
これかDirectXを最下層として多くのゲーム等が作られているのかと正直驚いた

**デフォルトの名無しさん** · 2016/11/16(水) 12:28:03.81

掲示板と日記帳の使い分けもできないリテラシーのひくそうな人には
いろいろと不便でしょうね(´・ω・｀)

**デフォルトの名無しさん** · 2016/11/16(水) 12:38:57.94

オブジェクト指向マンセーで
ステートマシンを知らないひとには使えない

**デフォルトの名無しさん** · 2016/11/16(水) 14:50:04.43

そのせいでマルチスレッドに対応しづらいのもまた事実

**デフォルトの名無しさん** · 2016/11/16(水) 15:25:39.98

なんでステートマシンになってるのかなと思った
ハードウェアチップをI/O経由でたたくイメージなのかなこれ？
描画ソフトウェアライブラリーというよりSGIのGPUを制御するためのツールとしてデザインしたらこうなったのかな

**デフォルトの名無しさん** · 2016/11/16(水) 15:28:44.99

>>508
FILE*のイメージだろうね

**デフォルトの名無しさん** · 2016/11/16(水) 16:23:15.15

>>504
CoreProfileになればだいぶ違うぞ。
そもそも便利機能は全部拡張機能だ。

**デフォルトの名無しさん** · 2016/11/16(水) 19:42:15.33

何bindしたかで関数の動作や引数の意味が変わってしまうのには嵌るわ。
バッファ関連そんなんばっかし。

**デフォルトの名無しさん** · 2016/11/16(水) 23:34:36.54

そりゃそうだ
Cで構造体をVOID*にするようなもん

**デフォルトの名無しさん** · 2016/11/17(木) 01:30:46.96

>>508
今のようなメモリ上に分散したデータをまとめてDMAでゴソッとGPUに渡すようなハードじゃなくて
ハードウェア上に1つだけステートがあって、それこそI/OポートとかメモリマップドIOとかで
GPUのレジスタを一つずつ設定してdrawするんであれば、初期のOpenGLの実装は理にかなってると言えるかも
想像で言ってるだけだが

**デフォルトの名無しさん** · 2016/11/17(木) 08:15:27.88

>>512
それがどう解釈されるかが関数のインターフェースに現れないのが問題。
どっかのグローバル変数の値によってint*かdouble*かが決まるような糞仕様。

**デフォルトの名無しさん** · 2016/11/17(木) 09:19:40.51

オートマトンじゃないものをステートマシンと呼ぶ分野があるのか。

**デフォルトの名無しさん** · 2016/11/17(木) 16:15:12.11

bind , unbindのタイミングの定義がなんかもやもやしてるよね

**デフォルトの名無しさん** · 2016/11/18(金) 16:07:46.20

free不要論者ですし

**デフォルトの名無しさん** · 2016/11/18(金) 23:33:13.88

githubに中国語でコード書いている中国人もいるし
多少はね？

**デフォルトの名無しさん** · 2016/11/19(土) 21:45:54.84

Vulkanで実装されたOpenGLみたいのを使えば
苦労しなくても既存のアプリが少しは早くなるかもって思ったけどそれは無いか

Vulkanの大きなメリットの一つはレンダリングステートやコマンドバッファを再利用できる事みたいだが
ゲームエンジン側は毎回OpenGLのAPIを呼ぶような構造になってて
再利用する前提になってないから無意味そう

OpenGLの仕様に合わせようとするとエラーチェックも必須でさらにオーバーヘッドが