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/ >>163
逆だな
テクスチャが糞でもライティングが良ければパッと見綺麗になる
海外製のFPSとか見たことあるのか？
テクスチャは日本製の丁寧に書き込まれたのに比べると糞だぞ
だけどシェーダーの出来がいいからスゲーリアルに見える
あとFPSとか地形モデルやテクスチャは自動生成していくのが主流じゃないのか？
あと独自研究しろなんて言ってたか？ 「未知の」アルゴリズムに先行研究がある訳ないだろ
パラメータチューニングとか具体的なノウハウが非公開ってのはありがちだが
それをアルゴリズムとは言わない
法線マップとかも「データ」に入ると考えられる訳だけども
それらが糞でもシェーダでカバーできるの？
丁寧に書き込まれたのに比べると糞って一般的には糞と言わない
糞は比べるまでもなく糞 >>165
お前は何が言いたんだ…
例えばライトスペースパースペクティブシャドウマップみたいな発見(発表)はなんて言うんだ？
これが発表されるまではみんな別の(あまり良くない)アルゴリズムで一生懸命工夫してたけど
LiSPSを使えば簡単にシャドウのクオリティをあげられるようになった
最近はもっと凝ったアルゴリズムも発表されてる(ようだ、詳しくは知らん)
そういうのを考えたり勉強して実装したりする事が大事なんだよ
あとデータが糞と決め付けてるけどなぜ糞になるかを考えないと
糞だから糞ってのは馬鹿っぽい書き込みだな 読み取れないなら絡んでくるなよ
データがなぜ糞になるかにOpenGL関係あるのか？
データの改善によらずプログラム（OpenGL）の範疇のみでの
品質向上は限定的であって
凡人が考え付くようなことは既に誰かが実現しているんだから
幻想抱いていないで勉強しろ、以上 ただ>>159が「未知のアルゴリズムの発見」を
他所の誰かがやってくれるって話なら>>163は的外れだ
でも仮にそうなら「未知のアルゴリズムの発見」をだしに
「小手先のテク」を否定するのはおかしい
「小手先のテク」も嘗て発見されたものであって
「未知のアルゴリズム」のうち汎用性のあるものは
普及して「小手先のテク」となる >>167
お前こそOpenGL関係無い話しをすんなよ、アホか
突然データの話しをし始めたのはお前だろ
データの糞さなんて普通議論の前提に無いよ
法線マップを使うと質感がリアルになる→データが糞なら意味が無い
シャドウマップのアルゴリズムを改善するとクオリティが上がる→データが糞なら意味が無い
なんでこんなアホみたいなことをお前は必死に連呼してんの？
> それと結局クオリティの根幹はデータだよ ｷﾘ)ｗｗｗ >>168
>>159の「小手先のテク」は>>156の据え置き機のAPIはメモリ管理が〜的な話しに対してだろ
ちゃんとアンカーしてんだから脊髄反射で糞みたいな返答しないで流れを見ろよ OpenGLって動画を背景にできないのかよ
本当に使えないな >>134
読んだら解ると思うけど、LGPLのライブラリを静的にリンクして生成されたオブジェクトコード(実行バイナリーも含む) 途中で書き込んでしまった
静的にリンクして生成されたオブジェクトコード(実行バイナリーも含む)の配布に制限をかけてはならないので、
もしプログラムを販売したとして、それを買った人がプログラムをコピーして転売とかネットにアップロードして再配布とか制限出来ないって事だからな
実行バイナリ以外のリソースがあってそれがないと意味をなさないプログラムであれば(それらのリソースにはLGPLは波及しないので)実質問題無いかも知れないがね >>176
>>134までの流れはソース公開の有無についてでオブジェクトの再配布については
何も触れてはいなかったけど、確かに言われてみればそうだな
ちなみにゲーム機のOSにはLGPLなライブラリも沢山使われてるけど
そういうのは全部動的にロードするタイプのものばかりだな
それに改変して使ってるLGPLなライブラリのソースはちゃんと公開されてるし ちょっと聞きたいんだが、
OpenGLのテクスチャ関連の情報源が纏まっているお勧め本とかサイトってある？
特にTexparameteriとかfとか。
APIそのものの仕様というより
特定のテクニック(遅延シェーディングとか)で
このパラメーターの設定必須とかいう話がうまくまとまっている所。 「OpenGL 4.0シェーディング言語 : 実例で覚えるGLSLプログラミング」とか？ https://www.khronos.org/vulkan/
> Vulkan is Here!
> Khronos launched the Vulkan 1.0 specification on February 16th, 2016 and
> Khronos members released Vulkan drivers and SDKs on the same day. AMD Radeon? Software Beta for Vulkan? Release Notes
http://support.amd.com/en-us/kb-articles/Pages/Radeon-Vulkan-Beta.aspx
Radeon GPUs are ready for the Vulkan graphics API
https://community.amd.com/community/gaming/blog/2016/02/16/radeon-gpus-are-ready-for-the-vulkan-graphics-api
> Please note that this initial Windows driver is not packaged with DirectXR driver components,
> so it is not a suitable replacement for your everyday graphics driver. 俺のNVIDIAGPUでもVulkanドライバー来たーー！！
ありがとうNVIDIA！！
早速Vulkanのコードを書いてみるかな
かなり敷居が高いからポリゴン1つ出すだけでも何日も掛かりそうだが… QualcommはSnapdragon820からだな
これが搭載されたスマホが出るなんてかなり先になりそうだ ドライバのVulkan API Versionが1.0.2.0だけど
https://vulkan.lunarg.com/signin で過去のバージョンを選択しても
VulkanSDKは1.0.3.1しかダウンロードできない
https://vulkan.lunarg.com/pub/sdks/windows/1.0.2.0 が
307 Temporary Redirect で
VulkanSDK-1.0.3.1-Installer.exe しかダウンロードできない。
VulkanSDKをインストールしてVulkan Runtime 1.0.3.1をアンインストール、
AMDのドライバインストーラーでVulkan Runtimeだけをインストールしなおして、
C:\VulkanSDK\1.0.3.1\Include\vulkan\vulkan.h のVK_API_VERSIONを書き換えたら
// Vulkan API version supported by this file
#if 0
#define VK_API_VERSION VK_MAKE_VERSION(1, 0, 3)
#else
#define VK_API_VERSION VK_MAKE_VERSION(1, 0, 2)
#endif
Sampleコンパイルできて動いた（一部動かない）。
https://github.com/LunarG/VulkanSamples の Building the Vulkan Samples Kit を参考
Python 3.4.4 64bitもインストールした。(cmake時にpython 3.xが必要)
Windows10 64bit / Visual Studio 2015 Community Edition cmake -G "Visual Studio 12 Win64" ..
は Visual Studio 2015の場合は
cmake -G "Visual Studio 14 Win64" ..
への変更が必要。 The Talos Principleの無料demo版でもVulkan対応してた。
The Talos Principle - Update 257458 - public beta
https://steamcommunity.com/app/257510/discussions/0/412447331651559970/ >>185
なに、つまり今のQualcommものはVulkanサポートしないってことか
スマホの方が普及速度が速いって思ってんだが すいません
ここで聞いていいのかどうかわからないんですが
OpenGLでプログラミングして生成系の動画を作りたいと思っています
PCのみでプログラミングから動画書き出しまでできる環境って何がありますか？ >>185
OSがVulkan描写だとかなり軽くなるだろうなあ・・・
iOSに快適さで負けてるのはOS部分の重さってのはよく言われてるし >>189
Androidは他のベンダーもだけど一度製品として出したらドライバまったく更新しないからな。
ドライバに変更が必要だから対応されないんだろう。ハードウェア的に対応できるものだったとしてもね。
>>193
ないない。
Androidが重いのはJavaのフレームワークの質の問題 iOSのアプリはネイティブコードで動いてるからそりゃAndroidより速いに決まってる
逆にネイティブコード動かしてよくセキュリティが保たれてるなと思う
iOSの事はよく知らんけど >>195
知らないのかよw
AndroidもNDKで99%ネイティブコードのアプリは作れるじゃん
ネイティブコード使おうがアプリは権限で許可されたことしか出来ないから安全
近年はVMの改善で割とヌルヌル動くし >>196
知ってるよ
セキュリティホールというのは許可されてない機能の穴の事だろ
Javaだとそういう事がやりづらいがネイティブコードだと
セキュリティホールを突くコードを書きやすい OpenGL始めたばかりなのですが、質問させてください。
ある座標(xyz)の手前に別のモデルが描画されているかを知りたいのですが
depth値と、world変換した座標のZ値比較ではうまく行かないことがあります。
Z値はnear=0, far=1で正規化されているようですが、depth値は視錘台の中で
最奥で描画される位置を1にしているように見えます。
＃far平面を遠くへ移動すると、Z値は減りますがdepth値は変わらなかった
depthとZを同じ範囲で正規化出来れば、最前面の判定が出来そうなのですが、
どうしたらよいのでしょうか？ それぞれの座標空間を明確しろ
depth値ってのは射影空間なのか？
z値はworld座標空間なのか？
異なる座標系の値を比較したって駄目だぞ >>194
2重苦3重苦ならせめて描画関係を最適化してJavaの処理に集中させるべきだと思うわ
どっちみち無駄が多いAPIを通して余計な電力をさらに余計に消費して描画してるのは事実だし >>201
まだドライバが成熟してないんだから評価は早すぎる というかVulkanとOpenGLの差があるのは複雑なアルゴリズムを実装する場合でしょ
単純な描写じゃGPUが変わるわけじゃないんだからOpenGLと大差出ない >>201
CPU負荷とGPU負荷を分けて表示させない時点でお察しだろ
Vulkanは主にCPU負荷を減らす為のモンだからな、CPUがスカスカなゲームには効果無い CPUコア数が増えると伸びるなGLと12は変化してない
高速に描画してなんぼの世界だけどこれから改良されるでしょ >>206を見ると初期化だけで1000行近くいってるな
前にコンシューマーゲーム機だとポリゴン1個出すのに1000行以上書く必要があるって
書いたら
> 図形を描画するのにそんな行数が必要な訳ないだろ
> にわかはロムってろ
とかレスしてる奴居たけど、やっとどっちがにわかかを証明できたなｗ
ちなみにコンシューマーの方がもうちょっとローレベルだな 毎回考えて全行書き直さなきゃならないならともかく
行数とかあんまり意味のある指標には思えんけど
どっちがにわかかなんて更にどうでもいい モデル座標指定してステンシル値取得する関数ってないですかね？
gluProjectがdoubleで座標取れるためだと思うんだけど、
drawした位置と微妙にずれるのですが。。
使ってるのはopenglです 微妙ってのが1pxより大きいのか
一定方向にずれているのか
とかその辺から原因を絞っていけば？
そもそもステンシルで特定の1pxを読み出すって使い方が
一般的ではないというか効率が悪い気がする >>210
1pxより大きくずれることはいまのとこないのですが、
ずれる方向はカメラの位置によって変わりますね。
陰面消去されない点の一覧を取りたいのですが、
難しいですね vulkan難しすぎだわ
openglでもできない雑魚が多いのにこれじゃあな Vulkanの赤本は英語版が8月に出るけど日本語版は同時には出ないよな…
英語版をギリギリまで予約せずにおくけど日本語版出すなら早めに頼むぞ
どうせボーンデジタルがやるんでしょ？ 仕様書の和訳をカットシステムに出してもらえればそれでいいや。 Vulkanの赤本は目次見た限りだとOpenGLのと違って3Dの入門的な内容は皆無だよ
メモリとかスレッド周りをちゃんと理解したいから赤本には期待してる
出るのが遅すぎるけどな Windowsで7までサポート範囲広げるのアフォすぎるわ
これ絶対後々最適化で足を引っ張る
それじゃなくても最適化が放置気味なのに 7と10でそんなに違うか？
むしろDirectX12が使えない7ではVulkanが対応していて欲しいけど それぞれのOSでテストしない訳にはいかないし
OSのバージョンごとにバグ報告も上がってくる
面倒事この上ない Win10に移行したがらない奴らばかりだししばらくはVulkanだろうなあ >>218
だったらWindows7を動作対象外にすればいいだろ さっさとWin10に移行して欲しいMSの妨害をしてDirtectX12を潰してるんだろ Vulkan使えば7も10もAndroidもそれだけでまかなえるからｳﾏｰってなって
メーカーがみんなVulkanのみサポートになれば最高だが…なるわけないか 別にあり得るんじゃね
dx12もこれも効率アップが
売りだけど、ピーク性能を求めてない
ユーザーには無用の長物だし GPUはまだ進化し続けるだろうけどGLドライバが更新されなくなったらどうしようもない
OpenGLはそのうちVulkan上に実装されたのを使う事になりそう
別にそれでも構わんけど てかOpenGLはゆくゆくはVulkanのラッパーにするってスライドに書いてなかったっけ >>224
出てくるゲームがことごとく現行のDXやOpenGLと相性の悪い処理を多用してて
ピーク性能以前の問題になってきてるから必要になってきてる GDCで発表してたIntelのVulkan対応ドライバ
Intel Beta Graphics Driver for Windows 7/8.1/10
15.40.20.4404 (20.19.15.4404)
ttp://downloadcenter.intel.com/download/25848 なんでWebでjavascriptでCのAPIそのまんまなんだよ
そのままなら既存のOpenGLプログラマが喜んで飛びついてくれると思ってたのか？
残念ながら、OpenGL使ってる奴らほどOpenGLにうんざりするんだよ。
まじでWebの規格決めてる奴らって馬鹿ばっかなんだな >>230
WebGL知らずに書いてるな…
WebGLのベースはES2.0だが当然そのままではない
しかしほぼ同じになるようにJavaScriptを拡張している
Float32ArrayとかWebGLの為に決められた規格は幾つかある
そんでシェーダーはほぼそのまま同じものが使える
お前こそ今更Cの部分がーとか言っても寒いだけだぞｗ >>230
C++で作りたかったらasm.jsとかWebAssemblyとかでコンバートして動かせばいいし
あと海外で3DのゲームをAndroidからブラウザに移植したらブラウザ版のほうが利益を上げてるとかある
ま、日本人はやっと最近ブラウザからネイティブアプリに移行したばっかだからそれに気付くのは5年後だと思うけど >>230
既存のゲームエンジンは飛びついてくれてるけど？ cudaってglslより概念が複雑になってて使いにくいんだけど ARM-software/spir2cross: SPIR2CROSS is a practical tool and library for performing reflection on SPIR-V and disassembling SPIR-V back to readable and usable GLSL/ESSL.
https://github.com/ARM-software/spir2cross 最適化において、描画量を減らすこと、drawCallを減らすこと、どちらを優先すべきでしょうか？
描画量を減らすために地理的な要素で分割すると、今度は drawCall が増えるし。教えてください。 マ イ ン ド コ ン ト ロ ー ル の手法
・沢山の人が、偏った意見を一貫して支持する
偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法
・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法
偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い
靖 国 参 拝、皇 族、国 旗 国 歌、神 社 神 道を嫌う カ ル ト
10人に一人は カ ル ト か 外 国 人
「ガ ス ラ イ テ ィ ン グ」 で 検 索 を ！ >>239
CPUに余裕があればドローコール減らす以外の最適化を優先で
余裕が無ければドローコールを減らす
PCならドローコールを発行出来る数はCPUの速度に依存する
モバイルはTegraを除いてみんなTBR/TBDRのGPU
タイル分割処理をしている関係で
いくら頑張っても200〜300回/フレームぐらいまでしか無理っぽい
それ以下になるようにバッチ処理したりするしかない etheriumで描画コモディティ先物市場まだできてねーのかよ >>242
IoTのメガトレンド化でこの業界にもおこぼれの資本が流れてきてほしいね 匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
- >>248
それはメモリ一般の話でGPUだけの話じゃないな
float4 position;にしてw成分にradiusを入れるとかよくやる
多分、float3 position; float radius;でも駄目なはず >>249
いやそれはちゃんとパックされるはず
vec3,vec3,vec2とかは駄目だけど openglで、3Dモデルの断面だけを表示したいのですが、
以下のやり方だと視点変更時にちらつきが起こってしまいます。
glClipPlane(GL_CLIP_PLANE0, 平面);
glClipPlane(GL_CLIP_PLANE1, 平面（逆向き）);
ちらつきを回避する方法をご存じの方、いらっしゃるでしょうか。
0,1で指定する平面を少し離すとちらつきは起きなくなるのですが、
拡大すると幅が見えてしまうので、平面は（向き以外は）１つにしたい
と思っています。 ちらつくのはGPUの計算誤差のせいか
つうか平面で輪切りにするなら
ある程度の厚さは元々必要じゃないの？
GPUの演算精度にあわせて最小の厚みを入れれば？
あと断面を描画したい場合もっとマシな方法があったはず >>251
厚みがあるように見えないようにカメラとの距離や拡大率で２つの平面の距離を変えればいいんじゃない このクリッピングプレーンって
カメラ座標系らしいが
任意の傾きでクリッピングしてくれるんだろうか？
カメラ視線と平行でなくても良いなら
どういう仕組みだろうか C#で、OpenGLリソースの解放忘れても.NETのファイナライザで解放されるようにしたいのだが
調べていたらファイナライザは別スレッドで実行される仕様っぽい事が分かった
コンテキストを有効にできるのは1つのスレッドだけらしいから問題
ミューテックスをロック
↓
コンテキストをMakeCurrent
↓
OpenGLのコマンドを実行
↓
MakeCurrentで現在有効なコンテキストをNULLに
↓
ロック解除
これで何とかなる？
ただロックしたり、何度もMakeCurrent
したりするのは速度的にどうなんだろ
同じコンテキストなら平気？
コマンドをキューから取り出して消費するスレッドを作れば1スレッドでOpenGLコマンドを実行する事も可能かもしれないがそれは複雑そう GLのスレッドが終了する前に全部処理すればいいだけだろ。
というかスレッド消滅しちゃったらたぶんリークする。
GLの仕様なので仕方ない。そっちに合わせろ。 >>251
縦横16倍で書いて、バイリニアで四回縮小するか256texelサンプルするシェーダで平均を取る。
>>256
面方程式が分からないなんて情けないこと言わないでくれよ。
>>257
消去リクエストキューとか作ればいいんじゃないの。 >>259
2chのレベルの低さを
体現してるよアンタ OpenGLってCで書かれてるんでしょうか？
Javaから使いたいんですけどプラットフォームがwindowsならライブラリはどの言語から使っても共通なんでしょうか？ ■ このスレッドは過去ログ倉庫に格納されています
