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/ クラスター化したりGPU積むなりして分散レンダリング、通信して集めて重畳するくらいかね すみません、普段MAX/MSP以外のプログラミングには全然疎くて それでMAXでOpenGLを使うときの質問なのですが nurbs曲線を引きたいんです。 そこでjit.gl.nurbsオブジェクトで、曲面でなく曲線を描きたいのですが、 制御点(のx,y,z座標)を予め設定するには、どうしたらいいですか? ググっても殆ど出てこないし、ネット上のチュートリアルには jit.gl.nurbsの使い方なんて載ってません。 ヘルプを見ても、どうも最初に設定している様子もないので、困っています。 どなたか助けてください・・・ Maliでは各FBOのバインドは1フレーム1回までにしろって書いてあるけど glClear()して同じのを使いまわしたのではパフォーマンス低下する? https://community.arm.com/groups/arm-mali-graphics/blog/2014/04/28/mali-graphics-performance-2-how-to-correctly-handle-framebuffers Binding each FBO (other than FBO 0) exactly once in each frame, rendering it to completion in a contiguous sequence of API calls. >>97 想像だけど1回までにしろといってるのはFBOをアンバインドする時に そのFBOに対する描画が全部完了するまでブロックが発生したりするからだと思われる だからglCleare()で使い回すのはパフォーマンスは低下しないでしょ ただ別にFBO作った方が速いだろうね (レンダリングが並列に実行されるだろうから) >クラスター化したりGPU積むなりして分散レンダリング、通信して集めて重畳するくらいかね これいいですね アイデア頂きです 分散レンダリングで60fpsを目指すとかさすがだな レイテンシ問わないならあるいは…… でも並列化が可能なデータなら クラスタ化の前にできることがあるような…… ディファードレンダリングにして各GPUにどのタイルをレンダリングするかを 割り当てれば割と簡単に分散は出来そうだな ただ頂点処理はかなり重複する事になるから多ポリゴンをレンダリングする 目的には1GPUの時とあまり変わらずに結局向かないと思うよ 4.2からglMemoryBarrier増えてるけどこれってComputeShader使う場合のみ 必要って認識であってる? 例えばTransformFeedbackでVBOの頂点情報変形させてから続けてそのVBO使って 通常の描画する場合ってMemoryBarriorしなくても古いVBOのキャッシュで 描画したりはしないよね Radeon R7 200 でVTFしようとしてるんだけど バーテックスシェーダー内でvec4 col=texture(texture1,texcode0); してもテクスチャカラーがuv 0,0の位置のしか所得出来ない フラグメントでは問題無く持ってこれる、ドライバ問題? >>105 別にマイナーな機能でもないし可能性は低いと思う 最新のドライバにして改善しないなら多分お前のコードにバグがある テクスチャ周りはミスしやすいから テクスチャユニットの番号が間違ってないかとか 座標の値がおかしくないかとか ユニフォームの設定が間違ってないかとか調べ直したほうがいい >>106 何か情報無いかなと書いてみたんだけど、 やはり自前バグの可能性たかいよね、もう一度調べてみるわ シェーダー内で途中でintを経由して値が0になってるとかだろうな 105の件解決(?)しました 4頂点の単純な板ポリで試してたんだけど四隅が全部黒の値拾っていた、 で トーラスの頂点数の多い物で試したらキチンと反映していた UVが1.0の値補完か何かで0.0位置の色を拾ってたくさいw >>110 VTFを数値データとして使うなら普通0.5足してピクセル中央をフェッチするんだよ >>111 もしかしてUVの画像位置と合わせて頂点を凸凹させる時も? >>112 すまん>>111 は書き方が変だったので訂正しておく 0.5というのはu = (x + 0.5) / 1024 のようにするという事を言いたかった だから最終的に足されるのは0.5とは限らない 要するにテクセルの値を取得する時にはそうすべきというだけで 2つのテクセルのフィルタリングされた値が欲しければする必要はないだろう >>113 やっと理解したかも、補完かからない対策ですね 、1ドットの中心をアクセスすれば安全って事ですか? >>114 そうだ あとFILTERの値もNEARESTにする glPolygonOffsetでポリゴンの前後関係を調整するのに環境によって 前後関係が異なる結果になることがあるんだけど 上手い対策とか無いでしょうか? 上手い対策というのは知らないが unitsを使わないとか 自前でオフセットを計算しとくとか そもそもZテストを使わないとか あとglDepthRange()を使うというテクニックがあったような >>117 環境ってGPUの違いとかOSとかの事か? 単にシーンの違いとかだとまじめに計算すればちゃんとうまく行くはず ちなみにZ値は遠くへ行くほど荒くなってるから同じオフセットでも前後関係は変わる 今までWindowsでDirect3D(9、11)を使ってたんですが、 新たにAndroidでOpenGL ES 2.0を使おうと考えています。 レンダリングした結果をCPU側に戻すのをやりたいんですが、 OpenGL ES 2.0で可能でしょうか? glReadPixelsで読める が、激遅の場合がある、というよりまず遅いと思ったほうがいい てかそれくらいググれ OpenSceneGraphなんてあるんだ。 始めて知った。 自作のシーングラフライブラリを置き換えようかな。 なんだOpenSceneGraphのライセンスはLGPL系か。 GPLは使えない(使いたくない)な。 LGPLは改変せずに使うなら幾ら使っても問題になる事はない LGPLはおおまかには、静的リンクか動的リンクかでソース公開の義務が変わる たしかライブラリ側が更新された時にプログラム全体が更新出来るように公開する、だっけ >>130 そういう事言うからLGPLが敬遠されるんだろうな スタティックリンクでもソース公開の義務は無いよ 最悪*.oを公開するだけだ それもゲーム機とか家電用の場合は実行ファイル自体が非公開だから*.oすら公開する必要はないけどな >>132 適当なこと言ってると後で痛い目見るよ GPLって名前が入ってるものには一切手を触れないのが一番 ヨウ ヨウ エビバーデー いい加減、「weight」を「重み」って言うのやめね?? あれは誤訳だ 英語のweightとは重さ・重量という意味もあるが「ナニナ〜ニに影響される」「行動や思想などに引っ張られる」 という意味がある したがっちぇ、これは重みではなく「影響度」と言うべきなのだ!、 やっとglutに慣れて以前作った物理シミュレーションを可視化しようとしたら これグローバル変数しか使えないじゃねえか 何にせよglutを新規に使う場合は割り切りが必要だよ いまさら固定機能使うとか考えたくないし 固定機能相当で十分なら もっと抽象度の高い(OpenGLを隠蔽した)ライブラリの方がいいんじゃね 使えるけど何なんだよ glut使いたいなら使えばいいよ >>138 はglutを使うには固定機能を使わざるを得ないっていう風によめるんだけど、 どういう割り切りが必要だって主張してんの? 構造体とか自由に渡せるようにするにはどうすればいいんだ glfw使える環境にはしたけどこれ勉強すればいいのか? >>141 glutを使うのは目的じゃなく手段だろ そんな基礎的な前提すら共有できていない時点で議論にならん OpenGLでレンダリングしたものだけ表示できて、マウスとキーボード入力ができればいいのであればglfw。 OpenGLと一緒にGUIを使ったり数字や文字列や表やグラフも表示したいならQtを使えばいいかと。 だいたいゲームとかメガデモ以外ならQt上でOpenGLを使えばいいんじゃないだろうか >>138 はGLUTに含まれてるプルダウンメニュー?とかが固定機能使ってるって 言いたいんじゃなかろうか? glutCreateMenu()とglutAddMenuEntry()で簡単にメニュー作れるのは便利だけど これは固定機能で実装されてるような気がする(詳しくは知らんけど) >>146 glutのmenuの実装にはOpenGL使ってないです なんにせよglutは古すぎるから今から選択するなら候補から外していいかも チョットした描画プログラム作るときに使うのには便利だと個人的には思うけど 日本は何でもかんでも文献が少ないか、古すぎる 原因の一つとして、大学が悪いんだよな アメリカの大学は即戦力の知識を教えている 日本の大学は基礎しか教えていないので企業でまた学び直す必要がある 企業で学んだことは他者に教えてはならないという強迫観念があるので広がらない 今までOpenGL1.5程度しか使ってこなかったんだけど、シェーダ周りを勉強してみようかと思ってる 2.xは飛ばして3.xに行ったほうがいい? 今までOpenGL1.5程度しか使ってこなかったんだけど、シェーダ周りを勉強してみようかと思ってる 2.xは飛ばして3.xに行ったほうがいい? グラフィックスってただの数学だけどな 数学は中学から教えてる訳だから大学がどうこう言うのは関係無い 日本の企業が結果出てないからひとつ前の大学が悪いって言ってるだけだ ゲームだと、「ゲームの作法」ってのがあるからな シェーダ知ってるだけではすげえ遅くなる PCだとOSとDirectXが勝手にメモリを管理するが、ゲーム専用機ではそういう甘えは通用しないのと同様に 自動車なども、大学院出ていればすぐに働けると思うはずだが 学校で研究したことと、実際に使用している技術と起こる現象が全然違う 学校で習ったこと、研究したことって何なんだ ってなるからな ウソ教えているに等しい >>153 3では一部の古い機能が非推奨になったから 古い機能を使わなくて済むなら3でいいよ OpenGL使う人なら英語読めないとやっていけないんじゃね >>156 そういう小手先のテクより未知のアルゴリズムの発見とか既存のアルゴリズムを 改善とかする方が大幅にクオリティは上がる ゲーム専用機は全部自分でメモリ管理する必要があって面倒かも知れないけど 結局は誰がやっても大差ないところで落ち着く ゲーム専用機か、、 もう死語レベルだよな 3dsも死に体だし >>160 んなわけない、海外だと据え置きゲーム機が絶好調だ GTA5とか3000万本以上売れて全エンターテイメント中で最高売り上げを記録してるよ 日本のゲーム売り上げ高なんて全世界の20分の1にも満たないけど 日本だけで考えればゲーム機は衰退しつつはあるな。ずっとそうかは未知数だが 世界を相手にしている人が2chの辺境スレで 燻っているならそれは残念なことだなぁ 10年前ならネ申とか崇められていたかもしらんが それと結局クオリティの根幹はデータだよ 高度なライティングを実装したところでテクスチャが糞なら糞 糞なコードを普通のコードに変えればクオリティはぐっと上がるが 普通のコードを優れたコードに変えても大差はない 未知のアルゴリズムの発見とか既存のアルゴリズムを改善なんてのは 実在するならSIGGRAPHとかで発表すべきもので 実態は「小手先のテク」として語られているのがほとんど 独自研究が無駄とは言わんが先人に学ぶ謙虚さと勤勉さが大事だと思う >>163 逆だな テクスチャが糞でもライティングが良ければパッと見綺麗になる 海外製のFPSとか見たことあるのか? テクスチャは日本製の丁寧に書き込まれたのに比べると糞だぞ だけどシェーダーの出来がいいからスゲーリアルに見える あとFPSとか地形モデルやテクスチャは自動生成していくのが主流じゃないのか? あと独自研究しろなんて言ってたか? 「未知の」アルゴリズムに先行研究がある訳ないだろ パラメータチューニングとか具体的なノウハウが非公開ってのはありがちだが それをアルゴリズムとは言わない 法線マップとかも「データ」に入ると考えられる訳だけども それらが糞でもシェーダでカバーできるの? 丁寧に書き込まれたのに比べると糞って一般的には糞と言わない 糞は比べるまでもなく糞 >>165 お前は何が言いたんだ… 例えばライトスペースパースペクティブシャドウマップみたいな発見(発表)はなんて言うんだ? これが発表されるまではみんな別の(あまり良くない)アルゴリズムで一生懸命工夫してたけど LiSPSを使えば簡単にシャドウのクオリティをあげられるようになった 最近はもっと凝ったアルゴリズムも発表されてる(ようだ、詳しくは知らん) そういうのを考えたり勉強して実装したりする事が大事なんだよ あとデータが糞と決め付けてるけどなぜ糞になるかを考えないと 糞だから糞ってのは馬鹿っぽい書き込みだな 読み取れないなら絡んでくるなよ データがなぜ糞になるかにOpenGL関係あるのか? データの改善によらずプログラム(OpenGL)の範疇のみでの 品質向上は限定的であって 凡人が考え付くようなことは既に誰かが実現しているんだから 幻想抱いていないで勉強しろ、以上 ただ>>159 が「未知のアルゴリズムの発見」を 他所の誰かがやってくれるって話なら>>163 は的外れだ でも仮にそうなら「未知のアルゴリズムの発見」をだしに 「小手先のテク」を否定するのはおかしい 「小手先のテク」も嘗て発見されたものであって 「未知のアルゴリズム」のうち汎用性のあるものは 普及して「小手先のテク」となる >>167 お前こそOpenGL関係無い話しをすんなよ、アホか 突然データの話しをし始めたのはお前だろ データの糞さなんて普通議論の前提に無いよ 法線マップを使うと質感がリアルになる→データが糞なら意味が無い シャドウマップのアルゴリズムを改善するとクオリティが上がる→データが糞なら意味が無い なんでこんなアホみたいなことをお前は必死に連呼してんの? > それと結局クオリティの根幹はデータだよ キリ)www >>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部分の重さってのはよく言われてるし ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる