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/ >>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で埋めるとか馬鹿な初期化する方が無駄 前回と同じサイズのものは使いまわせばいいことは分かっています
描画する数が毎回変わるならどうすれば・・・って話です 描画したくないものまで描画されるじゃないですか
画面外に描画する。それでいいんですかね
めんどくさいので配列として扱わないことにしました みんなマルチスレッド化されたOpenGLが欲しかったんだよね？ >>488
OpenGLは必ず配列内の有効な個数を指定する必要がある
余計に描画されるとかしょうもない推測をするな >>488
なんで必ず最大数描画するだよ、描画個数決めれるだろ
必要な分だけ先頭に詰めれ 縦横の慣習が違うのは
民族性とか文化の違いから来てるんですか >>467
お前らが叩くから記事消えちゃったじゃん > 描画したくないものまで描画されるじゃないですか
？
頂点数指定するだろ。
ていうか配列でというのは連続したメモリ領域をという意味だから、常にプログラミング言語仕様で言うところの配列の先頭からでなくともよい。
でかい固定配列をリングバッファとして使っても良い。
> 配列を渡して一斉に描画するほうが高速だと聞きました
これを言った人が何を意味していたのか分からないが、
・4頂点ずつ描画キックするよりはまとめてキックした方が良い
・glVertex や glColor の類を使うよりはglVertexPointerを使う方が良い
・VBO を使うとより良い
と言える。
素人は何を聞いているのか分からないことが良くある。もっと謙虚になるといい。 >>495
ｸｿﾜﾛﾀww
消すような記事最初から書くなよw Vulkanってローレベル過ぎて使いづらそう
なんかこう
OpenGLとVulkanの中間みたいのが欲しい 最近になってOpenGLを触ったんだけど凄く使い辛いと思った
元がとても昔に作られたものだからこんなものかとも考えたが
これかDirectXを最下層として多くのゲーム等が作られているのかと正直驚いた 掲示板と日記帳の使い分けもできないリテラシーのひくそうな人には
いろいろと不便でしょうね(´・ω・｀) オブジェクト指向マンセーで
ステートマシンを知らないひとには使えない そのせいでマルチスレッドに対応しづらいのもまた事実 なんでステートマシンになってるのかなと思った
ハードウェアチップをI/O経由でたたくイメージなのかなこれ？
描画ソフトウェアライブラリーというよりSGIのGPUを制御するためのツールとしてデザインしたらこうなったのかな >>504
CoreProfileになればだいぶ違うぞ。
そもそも便利機能は全部拡張機能だ。 ■ このスレッドは過去ログ倉庫に格納されています
