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/ dxは日本語リファレンスが神
3dに対する情報も多く含み大変勉強になる
俺もdx11を勧める >>388,389
レスありがとう
やっぱ日本語の情報が沢山ある方がやる気にも繋がるよね つうか3DAPIに安定を求めても無駄だ
OpenGLは比較的安定してるから研究目的で使われてるだけだ
それと最先端の情報は間違いなく日本語ではない OpenGLとD3D9は古い手法が混ざっていて混乱の元
VulkanとD3D12は周辺知識が余計に要る WindowsだけならDirectXで良いけど、スマフォとかMacとかマルチを考えるならOpenGL 1から勉強するならWebGLが最適
最新のブラウザには良く出来たデバッガとプロファイラが備わってるし
コンソールにはご丁寧に実行時エラーを表示してくれる
どうせお前ら実行時エラー出しまくりなんだろうからこれが滅茶苦茶役に立つ
で、基礎を身に着けたらC++とかでやればいい >>385
ES2.0はプログラマブルシェーダーあるGPUが前提になって
それに要らん機能は削除されてる
Coreプロファイルもなんか色々削除されてるはず 2.xまでにあった要らん機能まで思い切って削っちゃったバージョン？ directx周りのossのライブラリは軒並み微妙な印象 >>365
電池も再来年に革新が起こりそうだけどね
まあVulkanに取り組んどいた方が後々楽だと思うよ >>400
違うスレでも見た気がするけど、その電池の革新って何だ？
ソースプリーズ 日経エレクトロニクスでも記事になってた全固体電池じゃね？
安全で容量が数倍になるうえに寿命も長く、さらに充電時間も短縮するとか。 固体電池が実用になるのは早くても2020年頃になると思うけどね
で、容量が大きくなったからと言ってGPUをブン回すことが出来るかって言うとそうじゃないな
電池の持ちは良くなるだろうけど現状でもスマホで3Dゲームやると
持ってられなくなるぐらい熱くなるから、結局GPUの省電力化が全てだろう >>405
本当に永遠と言い切れるか？
電力を無線で飛ばす時代だ
普通に持ってるだけでスマホに500W以上の大電力が供給される可能性だってゼロとは言えない
そうなるとPCを超えられる 物理的なサイズの問題はどこいったのかな。
小型で高性能化したスマホの技術を結局デスクトップに応用できるんだからでかいほうが強いのはずっとかわらん。 >>408
PC用にボードを販売しても儲からないからスマホに最先端GPUを供給するようになったら立場が逆転する
経済的に立場が逆転する事は十分考えられる
よって永遠とは言い難い >>410
昔はCGをスパコンでレンダリングする事が当たり前だったが
今はPCを使っている(今でもスパコンの方が性能が上なのにだ)
この期に及んでPCはスパコンを超えられないと言ってるようなもん
あるしきい値を超えるとデカい方が衰退していく ま、単純に「いつか mobile が PC 追い越す」と言えば納得するだろ
そんなの今時みんな言ってる
要するに何を追い越すと明記してないから俺はPC用のディスクリートGPUなんて
いつか誰も使わなくなるという観点から書き込んでただけだ PC用のディスクリートGPUの方がデカいからモバイル用GPUは性能が「永遠」に追いつかないなんて
短絡的で糞つまらん事書き込む奴がいるからこんな事になった 合わせてPCの性能も高くなるので永久に追いつかない件 サルは「永遠」に人類を超えられない、と言ってる事が一緒だなｗ
サルには無事で人類にだけ感染する致命的な病気で人類が絶滅する可能性があったり
知能指数が低い子供しか生まれなくなる可能性もある
「永遠」とか簡単に言って納得してる奴ってプログラマとしては致命的だな >>417
それな
モバイルが速くなるんなら
PCの箱の中がほとんど空っぽで真ん中にモバイルとかな 頭の悪さがプログラマとして致命的だな
ただの荒らしだろうけど >>421
「永遠」を証明するにはそれを阻害するあらゆる可能性を全て排除出来て初めて証明出来るが
それは要するに悪魔の証明という事だ
とりあえず、お前の突っ込みはただ悪口を言うだけの幼稚園児並みだなｗ 簡単な話、PCもモバイルも無くなるかも知れない。
PC が先に無くなれば、モバイルが追い越す期間が存在することになる。
どうでもいい話だ。
仕事があればスマホでもPCでもコンシューマでも、必要な程度に作りこむさ。 デスクトップが衰退していくのは無くなるからモバイルが追い越すとか、それ性能の話とは全く関係ないっていう滑稽さ ダウンサイジングでWSやオフコンが消えたから今度はPCが消える的な話なら多少はね
若い世代はPC持たないしフツーの家庭からPCが消える可能性もなくはない 性能なんて相対的なもんだろ
PCが無くなってスマホがその位置になって、コンピューターは指輪ぐらいの大きさになって
その指輪ぐらいの大きさの何かが永遠にスマホを越えられないって誰かが言うんだろうよ 何年も前から
ネットサーフィンとメールしかやらない層がフル機能のＰＣ買って
ウイルスにやられたりするのは愚かしいと思ってたし
あるべき姿に戻るだけ
スマホの詰め込み過ぎもいずれアジアの廉価製品が出てきて駆逐されるだろう 質問だけど
2D画像を表示するために構造体でテクスチャID、幅と高さの大きさを持たせて使ってるんだが
テクスチャIDから画像の幅と高さを取得するメソッドってないの？
スッキリさせたい。glfwです 見つかりました。glGetTexLevelParameterivのことですね！
ありがとうございます バカルンの本はまだ出ないんだな
まあどうせ実機ないからテストできん ばかるん？
PCでもわりと最近のGPUなら動くだろ？Vulkan ゲームなら既に、DOOMとThe Talos PrincipleとDota2がVulkanで動いてる。
本なんて要らんだろ。本が必要なレベルの人間には扱えない。 んなことはない
日本語の本は期待できないが本家赤本は最初7月には出るはずだったのがひと月ずつずれていって今では11月発売だ
とりあえず赤本待ち >>437
OpenGL1の赤本と同じだと思ってるお前の方がバカだろw
英語読めないのかよww Vulkanを魔術みたいに特別扱いしてる奴ダサ過ぎw
PS4のローレベルなAPIはかなりむずいが詳細なドキュメントが日本語で付いてるよ
それ理解した奴ならVulkanに置き換えるのは簡単だろ、同じAMDだし
俺らはそんな経験ないんだから赤本から始めるんだ 英語のＷｅｂサイトなんであんな真っ黒なんだよ
アダルトサイトと区別つかねえ Vulkan使っても体感速度はほとんど変わらない
PCならせいぜい10%程度みたい CPUに負荷が掛かりまくりでギリギリでも無ければ体感速度は変わらないでしょ？ 無駄な処理が減れば、それだけ消費電力が減るんだよ！ Vulkan使って変わらないのは単に使いこなしてないだけじゃないのか？ gtkmm3+epoxy+sgslで隠面消去の方法を質問したいのだけど
何処のスレが良いのですか？ sgslって何だ・・・org
glslです
プログラム板のくだすれで質問できそうなのは「くだすれC++/CLI（初心者用）part2」だけど・・・
行ってみます PBOからテクスチャにピクセルデータの転送を行いたいのですが、バッファ上の画像のピッチと
テクスチャのピッチが異なる場合で困っています。
テクスチャの方が大きい場合はglTexImage2Dでできそうなんですが、逆にバッファ上の画像の方が
大きい場合にその一部をテクスチャに転送する方法がわかりませんでした。
OpenCLやCUDAのような、srcとdstのピッチが違う場合でも使える汎用的な矩形転送って無いんでしょうか？ ありがとうございます。
でもglTexSubImage2Dは転送元のバッファ側が連続している必要あるんじゃないですか？
テクスチャの方が小さい場合はバッファの一部の矩形領域を転送することになりますが、
そういうことはできないような。 ああ、そう言うことか。
それならパデイングを含むサイズのダミーテクスチャ作ってglCopyTextureSubImage2Dだけとなんか無駄だなぁ
前提条件を見直した方がいい気がする 小さいテクスチャをテクスチャとして矩形をテクスチャにレンダリングするだけだろ ぐぐったら同じ問題の人がいて、その人はラインごとに転送したとか。
自分は結局テクスチャと同サイズのバッファを別に作ることにしました。
>>457
具体的なやり方がちょっとわかりませんが、FBOとか使うんですかね？ 適当に書くけどglPixelStoreiのGL_UNPACK_ROW_LENGTH？ テクスチャからPBOにコピーはやったことあるから、たぶん逆もできるだろうけど、調べるのめんどくせ >>459
なるほど。これとSKIPを組み合わせたら目的のことができるんですかね。
それにしてもglTexSubImage2Dの方に説明がないのはわかりづらいなぁ。 OpenGLやDirect2Dで画像処理して高速化するってどういうことなんでしょうか？？
例えば、GPGPUでOpenCLなどを使ってピクセルの処理を行って高速化するのはわかるんですが、
OpenGLとかではどうやるのかと。
例えば、画像をテクスチャとしてOpenGLになり取り込んで、ピクセルシェーダーだか
知りませんがそれで画像のピクセルのアクセスして処理する感じなのでしょうか？？ メッシュ変形とかの3D機能を応用する場合を除けば
基本はGPGPUと変わらんよ 画像はテクスチャとして取り込まないといけない？から、処理できる画像の
最大サイズ制限はあるってことですかね？？
OpenGL ES3.1などで追加されたCompute Shaderの場合もテクスチャ取り込む？
Image Store/Loadって使っても？
初心者なのでちんぷんかんぷんな事言ってたらすみません。 少なくともスマホではvulkan使う価値ないみたいね
http://project-asura.com/blog/?p=3509
＞以上を踏まえて，私が出した結論は「Vulkanは絶対に触るべきではない」です
ｗｗｗｗｗｗ スマホこそ消費電力減らすために導入は必須だよ。
やり方が違って複雑だと嘆いているアホでしょ。 VulkanはAMDが自社GPUを効率良く動かすために実装したMantleがベースになってるから
> 基本的にVulkan専用のハードとか作っている会社は無いと思うので
こんな事言ってる奴は馬鹿丸出しで見てて恥ずかしくなる…
PS4のAPIもAMDが実装しててVulkanに似てるしもっと低レベルなAPIだ
PS4で自社エンジンでゲーム作ってる会社はみんなVulkanより低レベルのAPIで作ってる
当然難しいのは間違いないが、日本語の詳細なドキュメントやらサンプルやらついてるから
ある程度経験者なら普通に使うことは出来る ちなみに10年も前のPS3から低レベルAPIだぞ
ただマルチスレッド未対応だったから今ほどは洗練されてなかったと思われる
PS3の頃はシェーダー未経験な人ばっかだからみんな面食らって
想定した全機能を実装するのに数ヶ月どころか半年近く掛かるなんてざらだったと思われる 複雑で嘆くのはみんな通る道だが、1本グラフィックエンジン仕上げてもいないのに
クソと言ってしまうのが無能な証拠
Vulkanでゲームを1本マスターアップさせてから、やっぱりVulkaクソだったと言うなら間違いなくクソなんだろう 無能な奴でも使えるもん作れない奴らも無能だわ。
つーか、日本語で唯一vulkanの情報を発信していた人がサジを投げたわけだな。 だから、無能な奴はOpenGL使ってればいいだろ。まだ進化もドライバサポートもしてんだし
Vulkanは限界までパフォーマンスを引き出す為のもんだよ
お前らがゲームのグラに一喜一憂するから、開発者はどんだけ難しくて大変でも
ちゃんとパフォーマンスさえ出れば何でも使うんだよ
Vulkanはパフォーマンスがちゃんと出るか出ないかが問題なんだよ PS4のAPIがVulkanより低レベルとか本気でいってんのかな… ん？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と比べてもとてもローレベルと言ってるぞ こっちがソースか
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はハード直叩きに限り無く近いからな >>477
なんだ、そういうことかw
ローレベルって言えば通じるのかな？日本語って難しいなw つーか素人うぜえよ
テメエで使ったこともねえくせに
良いだの悪いだの
アホじゃねーの？ 手続きの手順が違うから
まっさらからVulkanに合わせて作るならともかく
既存のOpenGLベースのコードの中身を入れ替えたり拡張するような使い方じゃ性能でないよって話だよね？ 質問です
画像を描画する際、配列を渡して一斉に描画するほうが高速だと聞きました
ですが渡す配列が固定長だと描画枚数が増えた時に柔軟に対応できない気がします
皆さんはそういった場合、毎フレーム動的配列を生成・削除してるのでしょうか？ 前回と同じサイズのものは使いまわす
っていうかそんなことより0で埋めるとか馬鹿な初期化する方が無駄 前回と同じサイズのものは使いまわせばいいことは分かっています
描画する数が毎回変わるならどうすれば・・・って話です ■ このスレッドは過去ログ倉庫に格納されています
