OpenGL/Vulkanスレ Part22©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
クロスプラットフォームの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/ == 必読書 ==
-- CG入門 --
OpenGL以前の普遍的なCGの概念。
CG-ARTS協会の3冊は初心者向け。あとの2冊は上級者向け。
・コンピュータグラフィックス (CG-ARTS協会)
・ビジュアル情報処理 (CG-ARTS協会)
・ディジタル映像表現 (CG-ARTS協会)
・ゲーム制作者になるための3Dグラフィックス技術
・ビジュアルコンピューティング 3次元CGによる画像生成
-- 初心者用 --
・GLUTによるOpenGL入門
・GLUTによるOpenGL入門2 テクスチャマッピング
・OpenGL ES 2.0 プログラミングガイド
-- 上級者用 --
・OpenGL Shading Language (橙本)
・Shader Xシリーズ
・GPU Gemsシリーズ
・GPU Proシリーズ == 必読書2 ==
-- モダンなOpenGL --
シェーダーベースの最新のOpenGLの学習
・OpenGL 4.0 シェーディング言語 -実例で覚えるGLSLプログラミング
・OpenGL SuperBible: Comprehensive Tutorial and Reference
・OpenGL 4.0 グラフィックシステム
-- 数学 --
・ゲームプログラミングのための3Dグラフィックス数学
・実例で学ぶゲーム3D数学
・ゲーム開発のための数学・物理学入門
-- 過去の書籍 --
有名だが古いバージョンのOpenGLをもとに書かれているためすでに時代遅れ
通常は買う必要はない
・OpenGLプログラミングガイド 原著第5版 (赤本)
・OpenGL Reference Manual (青本)
== チュートリアルサイト2 ==
OpenGL Step By Step: http://ogldev.atspace.co.uk/
OpenGL Samples Pack: http://ogl-samples.g-truc.net/ 今、点と線を描くプログラム↓を書いています
glClear(GL_COLOR_BUFFER_BIT);
glColor3f(0.0, 1.0, 1.0);
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(2, GL_DOUBLE, 0, point_data);
glDrawArrays(GL_POINTS, 0, point_num);
glutSwapBuffers();
そこでline_data[]内にある頂点データを使っていくつかの直線を描く関数を上のプログラムに追加したいのですが、どうすればいいでしょうか? >>5
点のはちゃんと動いてんの?だったら9割方出来てんじゃん… >>8
はい、点の方はちゃんと動いています!
ここに線を加えようとしても上手くいかず困っています >>9
ほとんどエスパー状態だが…LINESとLINE_STRIPの区別できてる? >>10
はい、繋がっていない線をいくつか描きたいのでLINESの方を使いたいです
glClear(GL_COLOR_BUFFER_BIT);
glColor3f(0.0, 1.0, 1.0);
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(2, GL_DOUBLE, 0, point_data);
glDrawArrays(GL_POINTS, 0, point_num);
glVertexPointer(2, GL_DOUBLE, 0, line_data);
glDrawArrays(GL_LINES, 0, line_num);
glutSwapBuffers();
↑のように付け加えてみましたが、この書き方はだめなようです
直線を描くにはどういう書き方をすればいいのでしょう? >>11
line_dataに2×線の数だけ座標が入ってるか? あ、原因が分かりました
>>12も含めて見直していると型がdoubleでなくshortになっていることに気が付きました
ありがとうございました
(昨日あれだけ見直しても気付かなかったなんて・・・) シェーダ初心者です
フラグメントシェーダで出力するベクトルはwが変わるとxyzにも影響が出るものでしょうか?
gl_FragData[2] = vec4( pos.xyz, w );
上のようにFBOを利用してテクスチャに座標情報を渡してみようと思い
フラグメントの出力に頂点シェーダから受け取ったポジションを渡して
余ったwに適当なデータを含めて試していたのですが
続く描画パスで出力結果のテクスチャを参照してwに触れずxyzのみ参照する場合でも
前の描画パスでwに設定した値が変わると最終的な描画結果が変わってしまうようで
シェーダの仕様かプログラムのバグかも分からず参ってます。 >>14
GL_BLENDがEnableになっててブレンドされてたりして >>15
ご指摘の通りでglDisableでブレンド切ってみたら期待した結果が得られました
複数テクスチャ使う場合のブレンドの設定とかまた調べてみます ありがとうございました FBO使う場合にRBOかテクスチャか関連付けて使いますよね?
後から効果付けるの便利なのでテクスチャばかり使ってて
RBOってどういう時に使えばいいのか分からないのですが 上手い使い分け方とかあります? >>17
https://www.opengl.org/wiki/Renderbuffer_Object
今後描画結果をOpenGLで使うつもりがあるならテクスチャ
そうでなければレンダーバッファ
カラーにはテクスチャを使うが
デプスにはレンダーバッファを使う事なら普通にある
テクスチャはレンダーターゲットとして使うのには最適じゃない事があるかもしれないが
レンダーバッファはレンダーターゲットとして使うのに最適なものになっているという デプスをテクスチャにするにはES2.0だと拡張機能が必要だな Chrome 45.0.2454.85のANGLEを使うと
Intel HD Graphicsでだけテクスチャが変になるな
昔懐かしのR5G6B5の16bitカラーテクスチャみたいな色になる
44.0.2403.157だと普通 スレタイにVulkanが入っているので質問したいのですが、
これから3Dグラフィックを独学で勉強し始める場合、
OpenGLをやった方がいいのでしょうか?それとも、
いきなりVulkanをやっても大丈夫でしょうか
別の言い方をすると、Vulkanというのは、OpenGLを使えることを
前提としているのでしょうか?それとも、新しいAPI体系なのでしょうか?
3Dグラフィックスの知識はありません。
学部レベルの数学は大丈夫です Vulkanはまだ資料もすくないから必要がなければとっつくこともないかと
そもそお3Dの知識なしには多分キツイはず
OpenGLは覚えること多いけど、資料も多いから勉強するならこっち >>22
ありがd
たしかに資料の多さは魅力ですね >>22
少ないっていうか無いでしょ
有るなら見てみたいけど Vulkan対応ドライバやOSがまだそもそも出てなくね? 製品出始めて暫くはドライバの問題で地獄だろうしな
特にモバイル Vulkanは薄いレイヤーだからドライバに優しい仕様だ
OpenGLドライバよりは楽だろう その分ハードウェアの癖が出やすくなったりしないのかね
ま、どうせチューニングせざるを得ないなら薄いほうが良いな OpenGL ESのドライバ実装の違いによる不具合ってどう言うのがあるんだろう
WindowsデスクトップではANGLEに違いを吸収してもらうとして
問題はスマホなんだが
この2つは知ってる
・iOSで勝手にミップマップ用のメモリを確保するバグがあったらしい
・NVIDIAだと他社ドライバではコンパイル出来ないGLSLのプログラムがコンパイル通る
iOS Textures Taking 33% Extra Memory - Stack Overflow
http://stackoverflow.com/questions/9438009/ios-textures-taking-33-extra-memory
>>29
OpenGLみたいにぶ厚い方が
ドライバ依存の部分が多くなって予測不可能な動作をしやすい気がするが 異なるハードウェアの差異はOpenGLのレイヤーで吸収
それ以上に低層で扱いたい場合はVulkan >>30
自分が当たったのは
Adreno 205でdiscardの後にtexture使うとOSごとクラッシュ
Adreno320でUBOの変数をそのまま計算に使用するとshaderコンパイル時にアプリクラッシュ(なぜか一時変数に代入してから使用するとクラッシュしない)
Adrenoはエラーログ出さずにすぐ死ぬからマジでデバッグが地獄
しかも今Androidで一番使われてるシリーズ
ほかはここに色々
ttp://cpplover.blogspot.jp/2013/09/dolphinopengl.html?m=1
薄かろうがAdrenoがまともなドライバを作れるとは思えない >>32
その駄目AMDがいまやPC系のOpenGLでは最も安定動作し性能が良いんだからな
おかげでOpenCLのスタンダードになり、そして、Vulkanを後続規格に出来たんだからな >>33
Adrenoは元AMD(ATI)でしょ
今はQualcommが作ってる
Qualcommはドライバーを軽視してる感がある >>34
性能はいいけど・・・って感じだよね、
nVIdiaとVulkanはMantle的に相性は悪いがそれでも今のスマホGPUよりかはよっぽどましな挙動をすると思う しかもモバイルのドライバ更新されないからな
Nexus5使ってるけどOSの更新はされてるけどドライバのバグずっとそのまま
まぁ、AndroidはOSの更新すらされないデバイスだらけだから一部の端末だけ更新されて新たなバグ埋め込まれても困るけど Vulkanはドライバーがシェーダーをコンパイルする必要がないから
それだけでも安定性は増すはず
それとkhronos自体がデバッグしやすくする為のツールを作ったりしてるから期待できる
当然GPUの状態を取得する為のAPIも追加されてるはず
あとドライバがアプリが想定しているバージョンより古いと自動的にダウンロードして
更新するみたいな事をするとチラッと見た ドキュメント読むとハードルめちゃ高いなー
早くVulkanのプログラムしたいけどGPUも買い換えないといけないのかなぁ…
NVIDIAだけど既存のGPUもサポートしてくれる事を祈る >>39
自前で組む分にはハードルが高いが
実際は有志から出された物やドライバのレイヤーを使って組むことが多いと思う http://peace.2ch.net/test/read.cgi/tech/1440666771/38
38 名前:デフォルトの名無しさん[sage] 投稿日:2015/09/24(木) 00:46:56.91 ID:r/3RmciX [1/2]
https://www.khronos.org/assets/uploads/developers/library/2015-cedec/Vulkan-CEDEC2015-DMP_Aug15.pdf
VulkanのOverviewが日本語に翻訳されてた
しかもVulkanAPIの解説付きだからこれでVulkanの全貌が把握出来る
なんとなくVulkanもMaxwell2と相性悪そうな気がする テクスチャフォーマットについて
2Dで表示するものは各8bitのRGBA(アルファ不要ならRGB)
3Dや多少の見た目の劣化が許容できるものはDXT1,3,5
こんな感じの使い分けがベターだと思ってるんだけど
詳しく解説されてるの見たことがないのでより良い選択肢があれば教えて欲しい 補足
動作環境はwindowsのデスクトップPCを想定してます >>43
αの扱いによってDXT1〜5を選択するだけで素のRGBAは有り得ない >>45
遅レスだけど返答ありがとう
劣化が気になることもあるけどDXT主体で使い分けてみるよ MMDはアプリだから表示なんかできないと思うんだが…
openglで表示してみた、というのは自分で何かopenglのプログラムを作ったという事かな?
だとすると表示が落胆ものなのは、完全に>>47 自信のスキルがアレなせいだと思う >>47
二枚目って自作?
とりあえず続きはブログでやってくれ なぜかあにまさ式だとうまくできました、
ブログはHTMLが面倒なのでげ製作でやっときます ☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。 Lat式は表示方法自体がMMDデフォの描画プロセスを完全再現しないと
とんでもない事になる特殊なモデリングだから仕方なし 2D描画をステート変更無しで高速に行えて
少し古い環境でも動くのってTexture Atlasだけ?
ES3の2D Array Textureって同じサイズのテクスチャじゃないと駄目みたいだし
代わりになりそうなのはBindless Textureだけど普及してないし
当分Texture Atlasを使うしかなさそう Texture Atlasの手法だと色が混ざっちゃうからミップマッピング出来ないのだけ不便 2D描画でミップマップなんて使わないだろ
奥行きがある多重スクロールとかかよ マップチップ的なものならES3.0が使えるならArray Textureでいけるし
無くても1/4までなら画質は大丈夫
それ以外は諦める 同じシーンを描画し続けてて急に負荷が高くなる場合ってどんなところ疑うべき?
起動して10秒くらいまでは軽いんだけど、突然重くなってその状態を維持し続けるっていう…
ごちゃごちゃになってるプログラム整理しながら間違い探してるんだけどWGLとかシェーダとか色々初体験でどこが悪いやら… 多分、色々と食い潰してる。
どうでもいいが「重い」とか言っときながら、まさかプロセスやリソースの状態も
調べてないとか言い出すなよ? リッチなデバッガ、プロファイラのある環境で作ってEmscriptenで変換 あ、WGLってWebGLじゃなくてWinGLの事か。 >>58
デバッグ用の拡張命令とかも調べつつなんでお察しください…
>>59
JavaScriptとかよく分からないんだけど…C++コード弄るの飽きたら試してみるわ
>>60
不安になってググってみたらWinGLもなんか違うな…wglCreateContext関数とか使うやつだわ 最近のVisual Studioは無料版でもプロファイラが付いているからまずそれを使う
後はOpenGLデバッガのgDEBuggerを使うとか
>>61
それがWGLでしょう。 これとは無関係
てか普通WGLをWinGLって書く奴は見たことねえ
Windows ゲーム作成用ライブラリ for Win16/32
http://www.vector.co.jp/soft/win31/prog/se028202.html >>62
VSのプロファイラは使ってるけどgDEBuggerってのは使ってなかったので試してみるよ ありがとう WindowsでOpenGLするならNVIDIAだよな?
AMDは使ってないから分からんが多分大丈夫だろうけど
IntelのWindows用OpenGLドライバは腐ってる >>65
昔はNvidiaだったが、いまやOpenGL・OpenCLのデファクトVGAはATI
Win/Linuxで安定度・性能がNvidiaよりずっと上 AMDのMantleが元になってるからな。
これでAMDが負けたら日本人が日本語クイズでアメリカ人に負けるようなもの Vulkanは超シンプルなAPIだからハード性能がダイレクトに効いてくる
当然AMDのハードが良かったらVulkanで勝てるだろうが別に有利不利とかはない 文字列をテクスチャに描画するのにFBOを使っていたんだが
PCだと爆速なのにAndroid機 (Snapdragon 801)だと10〜20個ぐらいでもう60fps出せないぐらい遅かった
CPUで画像をコピーするのを避けていたんだが、FBOの切り替えやその他のレンダリングステートの変更、ドローコールが思ったより高価だったようだ
テクスチャを通さず画面に直接描けばそんな遅くないかもしれないが
設計的にそうも行かない事情があった
これはCPU側で全てテクスチャに使う画像を作って送るしかないんだろうか PowerVR系のTBDRが文字描画と相性が悪いというのは有名だけど
Snapdragon(Adreno)だと何だろうね
そのうちフォントのラスタライズもGPUで行う時代になるのかね
ラスタライザの実装自体は難しくないとしても
結局フォントデータが日本語だと1書体で数MB〜数十MBだからなぁ Android機なんてPCの10分の1程度の性能なんだからそんなもんだろ 言いたいことは分かるがAndroidとPCて比較できる関係にないだろ
それにデスクトップPCの時代は過ぎたし OpenGL ESはデスクトップで動くんだから完全に比較できるでしょ
あとデスクトップPCの時代が過ぎたって意味が分からん
Steamの同時接続ユーザー数がピーク時に1150万人以上を記録とか言ってるし
むしろ増え続けてる 日本ではPCは終わってるかもね。
いや、始まってすらいないか。
PC使えない老害と新卒新入社員が問題になる国だもんな。 問題って…どんだけネットに洗脳されてんだ…
仕事がPCが出来る出来ないだけで方が付くんであれば楽なもんだな こんな事書いてあるけどOpenGLのコマンドがすぐに戻って来ないって事は良くあんの?glReadPixelsみたいな結果を得る必要があるコマンドでなくても?
Chromeだと複数のプロセスからのOpenGLコマンドを一つのプロセスでまとめて実行してるようだ
http://www.chromium.org/developers/design-documents/gpu-command-buffer
The #3 goal is speed. Speed is why a command buffer implementation was chosen.
The client can write commands very quickly with little or no communication with the service and only once in a while tell the service it has written more commands.
For example, another implementation could have used a separate IPC for each OpenGL ES 2.0 function but that would arguably be too slow.
The command buffer gets another speed boost because it effectively parallelizes calls into the OS graphics API.
A call like glUniform or glDrawArrays might be a very expensive call but because of the command buffer the client just writes a few bytes into the command buffer and is done.
The GPU process calls the real OpenGL function on another process which effectively makes the program multi-core. コマンドが戻って来る来ないってのがよく分からないけど
処理が遅くなるって事なら前のコマンドが解決されてなかったりすれば後のコマンドもその分待たされるんじゃないの? >>77
そうじゃなく泥タブだってPCといえばPCだしPCの定義って何って話
MacはPCじゃないらしいけどな
Steamのユーザ数とデスクトップPCのシェアは別だよね
それにIntelHDユーザがどれだけいることか スマホから見ればPCはすべてを導いてくれる神様なんだからPC使えないんだったら黙って崇めとけ >>80
戻ってこないなんて書いてあるか?
ChromeとかブラウザのWindows版は全部WebGL(OpenGL)→DirectXに変換して実行してるから
その為に一旦自前のコマンドバッファに溜め込んでるよって事でしょ
その自前のコマンドバッファはマルチコア対応だから軽いよって書いてある
実際ANGLE使わずにOpenGLを直に使うようにするとCPU負荷が少し増える 別にANGLE限定とは書いてない
互換性やセキュリティの問題はWindows以外でも存在するし
複数のスレッドから直接OpenGLのAPIを呼ぶより
アプリ側でAPIコールを纏めて一つのスレッドから呼んだ方が速いとされているのだが
実際にどの程度速度が変わるのかは分からない
ドライバ実装によっても変わるかもしれない よく見たらWebGLの話しではなかったな…
HTMLレンダラーとかGPU使って描画する時の話しだったな
そもそもOpenGLはマルチスレッドに対応してないから複数スレッドからAPIをコール出来ない
複数スレッドからDrawコールをしたい場合は自前のコマンドバッファが必須だな >>86
別にWebGLでは使ってないとは書いてないけど
プロセス毎にOpenGLコンテキストを作ればマルチスレッドでも使えるだろうが
それだと遅かったのだろう 質問させてください。
100 millions個以上の三角形ポリゴンを60fpsで描画したいのですが
一番いいソフトウェア上の組み合わせって何でしょうか。
Windows10(64bit),,GTX750TI,i5,
VS2010で64bitビルド,freeglut2.8
描画にPBO用いてglDrawElements利用
で試したのですが,25 millions個の三角形メッシュで<1FPS程度です。
どうもfreeglutはGDI用いていてそれがボトルネックになっている気がしています。
レス読む限りWGLで書いていくのがよさそうな気がしましたがお知恵下さい。 まともなエンジニアなら
ソフトウェアの組み合わせの前に
100 millions個以上の三角形ポリゴンを
60fpsで描画しないで済む方法を検討すると思うが
要件をはっきりさせるべき >100 millions個以上の三角形ポリゴンを
>60fpsで描画しないで済む方法を検討すると思うが
要件は100 millions個以上の三角形ポリゴンを 60fps以上でです
これを回避出来ないか答えられません。済みませんが どんな解像度でレンダリングしようとしてんのかしらんけど8Kディスプレイでもピクセル数3300万だぞ
1億ポリゴンのうちどれだけ描画されるのか考えた?
その要件が絶対というならそのバカな要件を精々頑張ってくれ クラスター化したり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部分の重さってのはよく言われてるし >>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行以上書く必要があるって
書いたら
> 図形を描画するのにそんな行数が必要な訳ないだろ
> にわかはロムってろ
とかレスしてる奴居たけど、やっとどっちがにわかかを証明できたなw
ちなみにコンシューマーの方がもうちょっとローレベルだな 毎回考えて全行書き直さなきゃならないならともかく
行数とかあんまり意味のある指標には思えんけど
どっちがにわかかなんて更にどうでもいい モデル座標指定してステンシル値取得する関数ってないですかね?
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の部分がーとか言っても寒いだけだぞw >>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の完成が待ち遠しいプログラミングできないアスペルガーw
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で指定する平面を少し離すとちらつきは起きなくなるのですが、
拡大すると幅が見えてしまうので、平面は(向き以外は)1つにしたい
と思っています。 ちらつくのはGPUの計算誤差のせいか
つうか平面で輪切りにするなら
ある程度の厚さは元々必要じゃないの?
GPUの演算精度にあわせて最小の厚みを入れれば?
あと断面を描画したい場合もっとマシな方法があったはず >>251
厚みがあるように見えないようにカメラとの距離や拡大率で2つの平面の距離を変えればいいんじゃない このクリッピングプレーンって
カメラ座標系らしいが
任意の傾きでクリッピングしてくれるんだろうか?
カメラ視線と平行でなくても良いなら
どういう仕組みだろうか C#で、OpenGLリソースの解放忘れても.NETのファイナライザで解放されるようにしたいのだが
調べていたらファイナライザは別スレッドで実行される仕様っぽい事が分かった
コンテキストを有効にできるのは1つのスレッドだけらしいから問題
ミューテックスをロック
↓
コンテキストをMakeCurrent
↓
OpenGLのコマンドを実行
↓
MakeCurrentで現在有効なコンテキストをNULLに
↓
ロック解除
これで何とかなる?
ただロックしたり、何度もMakeCurrent
したりするのは速度的にどうなんだろ
同じコンテキストなら平気?
コマンドをキューから取り出して消費するスレッドを作れば1スレッドでOpenGLコマンドを実行する事も可能かもしれないがそれは複雑そう GLのスレッドが終了する前に全部処理すればいいだけだろ。
というかスレッド消滅しちゃったらたぶんリークする。
GLの仕様なので仕方ない。そっちに合わせろ。 >>251
縦横16倍で書いて、バイリニアで四回縮小するか256texelサンプルするシェーダで平均を取る。
>>256
面方程式が分からないなんて情けないこと言わないでくれよ。
>>257
消去リクエストキューとか作ればいいんじゃないの。 >>259
2chのレベルの低さを
体現してるよアンタ OpenGLってCで書かれてるんでしょうか?
Javaから使いたいんですけどプラットフォームがwindowsならライブラリはどの言語から使っても共通なんでしょうか? 方程式方程式うるせーな
その次のフェーズを言ってるんだよ
その方程式でポリゴンのクリップする境界を特定したとして
どうやってそれを描画するのかってこと >>262
アホか、お前が知らなそうだから聞いてみたんだよ
図星だったんだなw >>264
結局そこはドライバとかハード次第なんじゃないか?
ま、ハードでサポートしてるとは思えないからステンシル使うと思うよ androidスマートフォンにvulkanが搭載されると具体的なこととして何か変わりますか?
また1年後の普及率は個人的にどうなると思いますか >>264
デプスバッファとかアルファリファレンスで discard することを理解できるなら、面方程式でのクリップなんて、内積とって大小比較して discard するだけなんだから、分からない理由がわからない。 >>268
WorldView空間の平面は
WorldViewProj空間では平面ではなく
曲面になる
ただしカメラ方向(z軸)と平行な場合は
平面は平面のままとなる
曲面じゃなく平面のままならそりゃ簡単さ
ただ、GLのクリッピングプレーンの座標系は
カメラ空間とあったので
平面の向きによっては曲面になりうる
その場合どのような実装でクリッピングを実現しているのか気になったわけ
まあ逆行列でWorldView空間に戻して
判定、discardすれば出来なくは無いが、
わざわざそんなまぬけな実装入れるか?ってこと
オタクが見当違いも甚だしいってわかったかよ? >>269
俺は268じゃないが268は正しいよ
それより
> 曲面になる
は笑うところか? だから言ってんじゃん
お前は2chの低レベルっぷりを
体現してる奴だってな
教えてやるのもここまでだ
後は自分で勉強するこった 多分透視除算でzが手前から奥にリニアに変化しないということなんだろう だからまあWVPの行列かけた後の透視除算前に処理するんじゃないか? >>271
お前ピクセルシェーダにどんな風に座標渡してんだよ…
wを1.0にしたカメラ座標orワールド座標を渡せば線形補間されてピクセルシェーダに渡るだろ
バカ過ぎ >>271
リニアにならないのはMVP行列を掛けるとZ値がWに移動してwが1.0にならなくなる
それをピクセルシェーダに渡すとGPUがZ/Wを補間するようになるからリニアにはならなくなる
後は自分で勉強するこったw glhint(gl_perspective_correction_hint gl_nicest)
つまりナイス! クリッププレーンはちゃんとしらべたらシェーダ利用時はそのまま使えないじゃん
別途MV変換した座標を渡す必要があるんだとな glDisableしようとすると1280エラーになるのだけれど私の環境では使えないのでしょうか?
エラーが出るのは GL_CONVOLUTION_1D_EXT GL_CONVOLUTION_2D_EXT GL_SEPARABLE_2D_EXT
GL_HISTOGRAM_EXT GL_MINMAX_EXTです
環境は CPU:Intel core I7-4771 GPU:オンボード MB:ASUS Z87-PRO-V メモリ:8GB
OS:ArchLinux カーネル4.5.4でGNOMEを使っていて
OpenGLのバージョンはよくわからないのでglxinfoを抜粋します
OpenGL renderer string: Mesa DRI Intel(R) Haswell Desktop
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.2
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 11.2.2
OpenGL shading language version string: 1.30
長文申し訳ありませんが、宜しくお願いします >>279
GL_EXT_convolutionとかGL_ARB_imagingが無いなら使えない
つかglDisableするなら別に使えなくてもいいじゃない >>280
レス有難う
Linux版のOpenToonzで落ちるところを探ってて行き当たったので
GL_EXT_convolutionとかGL_EXT_histogramのifdefで囲ってあるようですが上手く判定できていないのかな
もうちと調べてみます >>281
それらがdefineされてるかどうかとお前の使ってるGPUがそれらをサポートしてるかどうかは別の話だから OpenGL(ES)のバージョンを指定で使いたいんだけど、
getコンテキストなんたらで、バージョン指定すりゃいいの?
2.0指定してみたけど、読み出したら3.0になってるんだが・・・ >>284
2のプログラムそのまま動くから3で問題ないよ 機械学習ベース グラフィックAPIまだできてねーのかよ OpenGLで単純な直線・ドット・四角形の描画を実行すると
ドライバ(ビデオカード?)によって同じ座標値を与えても描画結果が異なるみたいなんだけど
そういうもんなの?
環境依存しまくりで頭抱える そういう話がなくはないけど、そこまで単純なモノだったらなにかコーディングが間違ってそう Adrenoはmediump以下の精度にしようとしても無視してhighpにするって読んだ >>287
斜線が途中で微妙に1ドット違う結果になったのを確認した事はあったけど
アルゴリズムとかモバイルだと精度も違うから同じ結果にならないのも納得出来る
けど困るほどズレるかね? 旧APIの固定機能パイプラインの実装が微妙に異なるんじゃね。型とか。 Vertex2d指定で14x14の小さい丸に見立てた八角形を描こうとしたら形が歪んで
ミスが見つけられなかったから他の環境で実行したら違う形にゆがんだので
テスト用にL字型の線分を描かせてみたら違うピクセルが抜けたりと
ぶっちゃけ斜め要素のない四角形以外はおかしかったです >>292
それだけだと何とも言えないけどZテスト有効にしてZ値込みで描画してたりすんじゃないの? >>292
あーVertex2dって書いてあるか…すまん
だとしたらトライアングルストリップの指定がおかしいかぐらいか
どっちにしろそこまで歪むなんて考えられん おかしなコマンドやデータを与えた時の動作は
実装依存でもおかしくない GLSLのShader Storage Buffer Objectで質問だけど、
これを関数の引数に渡すのってどう書くの?
layout(std140,binding=0) buffer _a {
writeonly vec4 a[];
};
layout(std140, binding=1) buffer _b {
readonly vec4 b[];
};
があって、_bの内容を_aにコピーできるような一般的な関数を作る場合に
引数の型がどうなるのかがわかりません。 eglCreateSyncKHRとか、KHR付いた拡張使いたいんだけど、
なんか前提条件ある?
試したらEGL_NO_SYNC_KHRしかかえって来ない、これって駄目って事だよな?
もうひとつ、この手の機能はglFinishとかの代用って解説あるけど、
glutとか使わない生のGLES使ってる分にはeglswapがあるから意味無い? Apple様はMetal推しだからな
いいAPIだと思うよ、移植性を除けば 今時OpenGLが動かない環境なんてクソみたいもんだからどうでもいいよ Vulkanって今まで通り、GLESのコードで動くの? >>307
動かない。
全く違う低レイヤーのAPIでGLESのAPIを低レイヤーのVulkanで実装しようという動きがあるぐらい Vulkanってそんなむずいの?
https://forums.developer.apple.com/thread/38469
MetalはVulkanよりは色々やってくれて優しいみたいな事が書いてある
MetalがVulkanよりハイレベルで動くなら
他のプラットフォームで動くMetal互換の実装を作るのは可能?
でもプロプライエタリAPIの互換実装なんか誰も作らないか VulkanのアプリをMetalで動かすレイヤーはある
Metalは絶対消え去る運命にあるのは間違いない OpenGLでガンヴァロウ
そんなAPIやってられん >>306
なんか勘違いしてそうだけど、環境作る側の「環境」って組み込み機器とかの事だぞ
GPUは無いけどOpenGL ESを動かしたいとかの特殊な状況で役に立つだろう ラッパーライブラリを作る側はアプリを作る側とOpenGLからしてみれば同じだよ >>311
そのOpenGLの中身をVulkanにしよう動きが既に出ている
効率を上げないとしんどいインディーがすごく増えたし
スマホゲームにおいてVulkanを積極的にやらんとMetal持ってるiOSに負ける >>312
それと、搭載予定のGPUが開発中で実物が無い時に、すでに開発はスタートしてるとかね。 >>314
OpenGLをVulkanで実装したところで効率が良くなるとは思えんが…
むしろ間接的になるから効率は悪くなるだろ
OpenGLは仕様上色々ドライバがチェックすべき事が多いからDrawコールが重いんだろう
Vulkanで実装したところでやるべき事は一緒だ OpenGLはまずコマンドバッファの管理がドライバ任せなのが良くない感じ?
テクスチャや頂点バッファ用のメモリ確保とか転送をどうやるかもドライバ次第だしな
モバイルでglTexSubImage2dがやたら遅いとかよくあった
モバイルだと殆どのGPUがタイルベースだけど
この処理もドライバ任せだし
処理結果を取っておいたりも出来ない >>317
コンテキストが一つってのが問題点じゃなかったでしたっけ? コード量が増えるってことはバグも人件費も増えるってことじゃないの
普及するのかね >>318
コンテキストは複数持てるけど
MakeCurrentが同時に一つのスレッドからしか出来なくて
1つのスレッドからしかコマンドを送れないのが問題では
このマルチコアCPUの時代に どうせ使われてないんだから過去の互換性なんか切り捨ててくればよかったのに
使われまくってるDirectXでもやってんのに >>320
結局実行速度が厳しいスマホだからこそ急いで開発しないとマジでiOSに人取られるからなあ
より負荷の高いゲームでどっちが快適に動くかってのを見せられてしまうとなおさら Vulkanは最近のGPUの仕様に合わせて策定されてんだから今後は普通に使われるようになるだろ
時代はどんどん先へ進んでんだよ
プログラマが追い付かなきゃいかんよ >>326
そう思うなら直接使うの諦めてゲームエンジンとかのミドルウェア使えばいいじゃん。それらが対応してれば恩恵受けれるんだし OpenGLもミドルウェア的な物を通じて使う物じゃないのか コード的には退化とか言って
ハードの進化がPGのオナニーに帳消しにされてるのが我慢ならない。
クソみたいに遅いなスクリプト言語は禁止せよ 高級言語のFORTRANから低級言語のCに「退化」したようなもんだろ。 今まで抽象化されてドライバ任せだったメモリ管理とかが、今後はソフトやプログラマが直接管理しなきゃならないから、
直にはついて行けない奴も大勢いるだろ
というか、エンジンや環境自体を開発しているようなハイエンドな連中以外は環境が整うまで待ちだろ つうか赤本早くしてくれ…(一応10月発売予定にはなってる) そこだよね
どこまで対応したドライバが普及するのか 今は泥でGLつついてるんだがjavaでVulkanAPIとかパフォーマンス出なそう
まあ遅い言語でチューニングした方が感コツ掴めそうだから完成したらC++に清書か Intel内蔵GPUでもLinuxだったらIvy Bridge(2012年発売)から対応してるぞ
Windows版だと最近のしか対応しないようだが
NVIDIAも2012年製のから対応してる
↓詳しいことはこれ見れば分かる
https://en.wikipedia.org/wiki/Vulkan_(API) AndroidはAdreno一強だけど500からしか対応しないから今年の最新モデルからだね
PowerVRはかなり古いのから対応してるけどこっちはほぼApple専用だしな… intelの対応が遅いのがな
Macの少し前のでは動かないの確定か・・・ >>339
ハードウェア的にはそこそこ古いものでも対応出来るんだろうがAndroidのSoCベンダーは一度出した製品のドライバー絶対更新しないからな…
Googleすらドライバーのバグを回避するworkaround書いてる程だから グラフィック周りの更新は特に文鎮化の危険あるからな >>337
そもそもAndroidのVulkan APIってNDK前提じゃ? 幸いな事にVulkanはモバイルとデスクトップでAPIに差がないからとりあえずデスクトップで組んでおくのがいいだろうね VulkanのAPIがローレベル過ぎてJavaバインディングを作るのは難しいのかも OpenGLを蹴ってまでのAPIでJava使ったら速度でなくて意味ないじゃん 流れを見るとJava+OpenGL→Java+Vulkanって話でしょ
当然意味はある
あとバインディングもOpenGLより簡単だろう
VulkanAPIは全てXMLで定義されてるからツールに通して作れるはず OpenGLでもややこしいのにこれ以上ややこしくするなよ よくわからないけど
GPUのこと詳しくなればVulkanのほうがわかりやすくなるんじゃね
よくわからないけど 実際そうだと思う。OpenCLを先にやってたらOpenGLは暗黙の了解みたいなのが多くてわけわからなかった。 VulkanをJavaに持っていこうとしても
JNIでやり取りする時のコストがでかくて
低オーバーヘッドの意味がなくなるとかない? SDKサンプルが上がってこないとわかんないな最初に描画手順のコード?渡して
後は頂点渡すだけみたいな感じなら普通に恩恵あるだろうし 複雑なアプリを作ってるとOpenGLはステートを内部でもってるから整合性を保つのが滅茶苦茶面倒になる
Vulkanは外部に置いておけるからその辺は簡単になるだろう
OpenGL→最初簡単だけど後が大変
Vulkan→最初大変だけど後が楽
じゃないか? nvidiaはPCで不利になるから裏でVulkanを普及させたくない意図が見え隠れしてるけど
OpenGLはいい加減古い NVIDIAは無理してVulkanに移行しなくてもOpenGLだけでCPU負荷を減らせる拡張を用意してるだけだ
デベロッパーに優しいんだよ
それとゲームはDirectX12の速度の方が重要じゃないか? Steamの調査だとWindowsが95%以上だけどな スマホは電池の問題があるから意図的に遅くても消費電力少ないCPU使ってるから
PCを超えることはないんだよバーカ 逆にAndroidがWindowsを置き換える
MS帝国の終焉 それ言うならChromeOS(Chromebook)だな
もはやAndroidも包含してんだから AndroidのOpenGLESは正直無茶苦茶で完全にiOSに敗北してるからさっさとVulkanラッパーに移行したい ChromeOSを電話に乗せればよかったんじゃと思う泥は急こしらえっていうか雑だね嫌いじゃないが >>368
Vulkanの薄いAPIすら心配なレベルだからなぁ… AndroidのOpenGLESが無茶苦茶に思えるのは腐ってるドライバのせいだろ
しかもアップデートもされない
Vulkanではそうならないことを願う >>369
ChromeOSに限らずGoogleの出すものは全部雑な感じする vulkanってHLSL使えるらしいからGLSLいらないね ていうか特定のシェーダー言語に捕らわれる必要は無くなったわけだし なんにしろそんな最新ハードまだ持ってないし日本語本もないしOpenGL ES3の方が覚えたい Vulkan実行すると、OSいきなり落ちたりしない?
コーディングしてて即落ちして萎える。 OpenGLみたいにドライバーが実行時エラーを補足しないからな DirectXじゃなくてOpenGL使う意味ってある?OpenGLは研究に使われてるイメージ >>382
DirectXの方が速いはず
やってることは同じ DirectXで書くといずれ動く環境が無くなる可能性があるが
OpenGLはいまだにドライバが1.0のコードが動くように対応している
その違い
だからといって今更begin,end,vertexを使ったコードを書くべきでは全くない
たまに質問見かけたりするけどな >>383-385
使えるAPIもOpenGLの方が少ないイメージあったんだけどあまり変わらないってことか 1から勉強する場合はDirectXとOpenGLとVulkan、どれがいいのん? 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の性能も高くなるので永久に追いつかない件 サルは「永遠」に人類を超えられない、と言ってる事が一緒だなw
サルには無事で人類にだけ感染する致命的な病気で人類が絶滅する可能性があったり
知能指数が低い子供しか生まれなくなる可能性もある
「永遠」とか簡単に言って納得してる奴ってプログラマとしては致命的だな >>417
それな
モバイルが速くなるんなら
PCの箱の中がほとんど空っぽで真ん中にモバイルとかな 頭の悪さがプログラマとして致命的だな
ただの荒らしだろうけど >>421
「永遠」を証明するにはそれを阻害するあらゆる可能性を全て排除出来て初めて証明出来るが
それは要するに悪魔の証明という事だ
とりあえず、お前の突っ込みはただ悪口を言うだけの幼稚園児並みだなw 簡単な話、PCもモバイルも無くなるかも知れない。
PC が先に無くなれば、モバイルが追い越す期間が存在することになる。
どうでもいい話だ。
仕事があればスマホでもPCでもコンシューマでも、必要な程度に作りこむさ。 デスクトップが衰退していくのは無くなるからモバイルが追い越すとか、それ性能の話とは全く関係ないっていう滑稽さ ダウンサイジングでWSやオフコンが消えたから今度はPCが消える的な話なら多少はね
若い世代は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だし
俺らはそんな経験ないんだから赤本から始めるんだ 英語のWebサイトなんであんな真っ黒なんだよ
アダルトサイトと区別つかねえ 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は絶対に触るべきではない」です
wwwwww スマホこそ消費電力減らすために導入は必須だよ。
やり方が違って複雑だと嘆いているアホでしょ。 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になればだいぶ違うぞ。
そもそも便利機能は全部拡張機能だ。 何bindしたかで関数の動作や引数の意味が変わってしまうのには嵌るわ。
バッファ関連そんなんばっかし。 そりゃそうだ
Cで構造体をVOID*にするようなもん >>508
今のようなメモリ上に分散したデータをまとめてDMAでゴソッとGPUに渡すようなハードじゃなくて
ハードウェア上に1つだけステートがあって、それこそI/OポートとかメモリマップドIOとかで
GPUのレジスタを一つずつ設定してdrawするんであれば、初期のOpenGLの実装は理にかなってると言えるかも
想像で言ってるだけだが >>512
それがどう解釈されるかが関数のインターフェースに現れないのが問題。
どっかのグローバル変数の値によってint*かdouble*かが決まるような糞仕様。 オートマトンじゃないものをステートマシンと呼ぶ分野があるのか。 bind , unbindのタイミングの定義がなんかもやもやしてるよね githubに中国語でコード書いている中国人もいるし
多少はね? Vulkanで実装されたOpenGLみたいのを使えば
苦労しなくても既存のアプリが少しは早くなるかもって思ったけどそれは無いか
Vulkanの大きなメリットの一つはレンダリングステートやコマンドバッファを再利用できる事みたいだが
ゲームエンジン側は毎回OpenGLのAPIを呼ぶような構造になってて
再利用する前提になってないから無意味そう
OpenGLの仕様に合わせようとするとエラーチェックも必須でさらにオーバーヘッドが 赤本も出た事だし猿でも分かるVulakanブログを始めようかと思ってるけどね
理解さえすれば偏見もなくなるはずだ >>519
ゲームエンジンはレンダリング部分をもっと高レベルの所で抽象化してるから意味あるよ。
余程糞設計のゲームエンジンでないかぎりな Vulkanは今までドライバが勝手にやってくれてたメモリ確保や
コマンドバッファに入れたコマンドの送信も手動っぽいのも面倒くさい
OpenGLとNV_command_listのVulkan版みたいの欲しいな
あれVulkanで出来る事に近いんでしょ?
ANGLEのVulkanバックエンドのコードは見てみたが
まだ何も実装されていなかった >>519
エラーチェックとかステートの一貫性チェックとかは開発時だけに必要なんだよ
リリースビルド時はバッサリ削除するのが普通
リリース版実行時にOpenGLエラーが発生したらそれは単にバグを残したままリリースしちゃったってことだ >>523
それアプリ側でglGetError使うかどうかって話じゃないの?
もしかしたらglGetErrorが使われるかもしれないし
エラー発生時もGPUによって違う結果になったりしないように
OpenGLドライバは常にエラーチェックをしてる
そのせいでオーバーヘッドが大きいとか聞く
これ無視してエラーチェックの無いOpenGL実装を作ったら
それはもはや規格外OpenGLだと思う 将来的にGPUメーカーの提供するドライバーがVulkanのみになってOpenGLを切り捨てるとかにならない限り
Vulkanで実装したOpenGL APIとか作っても無意味そうだよね >>525
GPUメーカーがそれを使えばドライバーがまともになる それはVulkanドライバーがまともならって前提だな https://www.khronos.org/vulkan/faq#web-vulkan
WebVulkanは出ないけど
Vulkanっぽい機能を追加したWebGL3は有り得る感じ? >>524
話の前提が違ってるな
>>519はゲームエンジンはOpenGLを呼ぶように設計されてるからVulkanにしたところで速くならないみたいなことでしょ
で、OpenGLのエラーチェックは開発時だけに必要な機能だからそれをバッサリやらなければ速くなると言ったんだ >>527
Vulkanドライバーは薄いレイヤーだしコンフォーマンステストも充実してるからドライバーの質が良い可能性は高い
ちなみにOpenGL on Vulkanは既にあるぞ
Khronos謹製じゃないがな OpenGLをMFCのシングルフォームビューで使用しています。
ピクチャーコントロールをOpenGLで描画しているのですが、他のウィンドウがかぶっていると描画されません。
何か解決策ないでしょうか? >>529
WebGL3があるならES4.0が実装されるはずだけどそもそもリリースされるのかね?
もはやES3.2で完成してんじゃないかとすら思えるけどね >>533
OpenGLそのままでもVulkanそのままでも無い何かが作られるなら
WebGL3って言い方は適切じゃなかったな
実装にはVulkan使えば良いだろう >>534
それ言ったらWindows版ブラウザのWebGL実装は全部DirectXを呼び出してるよ
それがVulkanになるのは時間の問題だろうね
WebGL→DirectXは右手系左手系とかシェーダーの違いとか苦労してるみたいだからVulkanの方が親和性は高いはず
上っ面のAPIはずっとWebGLのままだと思う そろそろデフォで有効になるWebGL2はPS3以上PS4未満の能力があるから、それで十分だと思うけどね
限界までパフォーマンスを追求するようなプラットフォームじゃないし http://floooh.github.io/2016/08/13/webgl-next.html
VulkanをそのままWebに持っていけない理由が色々挙げられてる
セキュリティとか性能の問題とかAPIの複雑さとか色々
それでもWebGLは普通にOpenGLを使うのと比べて遥かにオーバーヘッドがでかいようなので
その辺を改善した後継は出るんなら欲しい
この人によると良くできたOpenGLドライバでネイティブだと60fpsで100kのドローコールが出来るけど
WebGLだと60fpsで出来るのは5,000程度らしい
オンボードのGPU(Intel?)の出来の悪いドライバだと10k程度 Javascriptとかwebassemblyがネイティブコード並に速くならないとwebvulkanがあってもJavascriptの実行自体がボトルネックになって速くならない。
セキュリティチェックが必要だからネイティブコード並に早くするのは無理。
なのでAPI呼び出しを減らせるようにwebglを設計しようということか。 >>532
今時MFC?
ウィンドウ被ったら描画されないってWM_PAINTイベントで描画してないとか?
でも最近のWindowsってウィンドウが被っていても消えたりしないよな
デスクトップコンポジションがあるから >>538
JavaScriptとWebAssemblyは同じじゃない
WebAssemblyは遅くてもせいぜいネイティブコードの1.5倍以内の遅さに収まってる
いずれオンゲーはWebAssembly+WebGL2な環境で動かすのが普通になるだろうね そもそもJSじゃ速度が測定時の状況でかなり変わるし
C++じゃ実行時にプロファイリングして得た情報で高速化なんて出来ないし
参照カウントとかで手動でメモリ管理する方がGCより速いとも言えないらしい
APIコールには一定のオーバーヘッドがあるので
それはC++より不利 >>542
手動でメモリ管理するのは速度の為じゃなくて、適切なタイミングでメモリの取得解放を行う為だ
あとプロファイリングは開発時に散々してチューニングすれば問題無い
実行時にプロファイリングしてC++よりも高速なコードを生成するなんてほとんど幻想に近いが有り得ないことはない
ただそれもあてにならないわけだし、安定したフレームレートが必要なゲームには全く向かない そもそも実行時プロファイリングは最適化に手間(実行時間)をかける価値のある部分を見つけるためのものだよね?
本当なら全部を最適化をしたいけど、実行時コンパイルでそれやると最適化にかかる時間でかえって遅くなるから最適化処理を必要最小限にしたい
→もっとも効果がある部分をプロファイリングで探す…って
C/C++はピックアップせず全てを最適化するからプロファイリングは不要だし
最適化にかかる時間をプログラムの実行時間外(事前)にまわせるから
これより速く動作させる事なんて不可能でしょ そういうベンチ結果ならあるから絶対ないって事は無いだろう
実際にどんなパターンで実行されるかって情報だけはAOTじゃ分からないからな
それを加味して最適化するとデメリットがメリットが上回り速くなることは有り得る
あまり頻繁に実行しない部分を時間を掛けて最適化してもあまり速度は速くならないし
https://en.wikipedia.org/wiki/Adaptive_optimization 実行結果から最適化した方が良いコードを生成できる可能性高いしな。
エラー処理とかまず通らないコードをインライン展開してもコード密度悪くなって逆に性能悪くなるし。
(コンパイラ拡張で最適化のために殆ど通らないって属性付け出来たりするけど)
VC++2017には実行した結果から最適化させる機能が入った
https://msdn.microsoft.com/ja-jp/library/e7k32f4k.aspx 「Rubyのしくみ」に載っているベンチマークでは、
JRubyのループ回数が10万回(0.3秒)から、100万回でも0.3秒なんだよね。
このタイミングでさらに、コンパイルして加速していく
最終的には、1,000万回(1秒)で、CRubyよりも速くなる。
CPUセントリックな処理、つまりI/Oが無い場合、
予測分岐とか最適化技術では、Javaが、Cよりも勝る プロファイルベースの最適化は開発時にプロファイリングして
AOTコンパイル時のヒントとするやり方はかなり効果あるだろう
実際chromeが起動時間が20%速くなったとかあったな
それとJITコンパイラする実行しながらプロファイリングするのと一緒にしてはいけない DX11はDX12の機能ほしくなる
あとはいまだにCPUにフレームレート引っ張られるのがいらっとくる glmapbufferrangeってglbindsubdataで代用できるよね? >>535
横からだが、座標系の違いはシェーダ時代だと存在自体がユーザの好みじゃないかな
GLとXの座標系の違いは固定機能が原因で、
シェーダだと座標系変換行列が吸収する。
少なくとも、俺が書いたDirectXのシェーダは、右手座標のモデルを入力して実現できている。 変換行列は一緒だぞ
右座標だろうが左座標だろうが関係ない Zを+にするか-にするかはアプリがどういう行列を作るかで決めることでグラフィックのAPIレベルでは関係ないぞ。
実際にUnityはGL、Metal、DirectXのどれを使っても左手座標だぞっと。 多分固定機能時代はそれぞれが内部的に決まってたからそういう風に思ってる人が多いんだと思うが でもzの範囲の問題でprojectionは互換なかったりするよね? >>560
それはプロジェクション行列に下駄はかせるか頂点シェーダーで変換すればいいし、右左とは関係ないわな。 ttp://glslsandbox.com/
ここにglslのサンプルがいっぱいあるけど
ここのglslをコピペして自分のpcで動かしたいけどそういうのってできます? DirectXは左手系と言ってるみたいだけど、多分サンプルとかがそういう風に
実装されてるだけで、実際にはアプリが自由に決めていい
ただANGLEの実装ドキュメントによると最後のウィンドウ座標だけはY軸の向きが
OpenGLとDirectXで逆になってて変換する必要があると書いてあった
Y軸逆なのはテクスチャ座標もそうだな 同じ座標指定したら右手と左手じゃおかれる位置が明らかに変わるんだから
自由じゃない >>542
jsみたいな高級言語だと、言語自体に予め遊びをいれておき、そこから適切なアルゴリズムを内側で変更するってことは可能じゃないかな
例えば、配列の探索。
シーケンシャルに読むコードであれば、ワークスレッドに分散して速度を稼ぐといった高速化ができる余地がある。
言語にスレッドがないからね
これはcでも可能だが、最適化より予めOpenCLだったかの言語拡張で教え込むことができるから、そのプロファイル自体が要らない。
JavaScriptはよく知らんが、GCと同じでプロセスが落ちたら最適解を忘れそう てか、配列探索の説明になってなかった。
配列の場合、言語では配列にみせるが、アクセスがシーケンシャルかインデックス単一要素アクセスのどちらが多いか、要素の削除やクリアの頻度を計るとかがあるような。
それによって内部の変数管理をリストに変更したりベクターにしたりという最適化があり得そう。
だが、実際は予めデザインで決定出来るのだが、そこをダイナミックオプティマイズで設計時間省略!てかはできるかな。
特に素人や頻繁にコードを変えるシーンだと好まれるかもしれない。
スレ違いすまん。 >>565
お前は…
カメラの位置とかデータの内容が全て左手系や右手系を前提に構築されてれば
まったく同じ見栄えのゲームが作れんだよ
だからどっちを選択するのかはアプリの自由という事が理解できないのか? レンダリングエンジンを抽象化するという発想がないんでしょ 座標データのZのプラスマイナス逆に刷りゃ同じになるけどそれって自由な選択じゃなくて座標系に合わせてデータ差し変えてるわけで 意味合いが違うな ああ右手用データを左手座標にぶちこんでも全部逆になるから結局見た目は同じになるって言いたいわけ? 左手系の為に左手系のデータを用意するのも含めてアプリの自由だと言ってんだよ
やたら頭堅いやつが紛れてるな 左手系の為に左手系のデータやプログラムを用意する
右手系の為に右手系のデータやプログラムを用意する
どっちかを決定するのはDirectXが決める事じゃなくてアプリの自由だという単純な事だぞ? >>570
座標系に縛られるから不自由とかはグラフィックス計算の話題じゃないな
計算するのが不自由って意味になる… それよりボトムアップなのがややこしい
FBOでテクスチャに描いたときに上下が逆になってしまう
対策は頂点シェーダーで座標を逆転させるか
普通のテクスチャを逆転させるか Aという行列があるとして
→X=(x,y,z)というベクトルを用意して
→Y = →XA という掛け算をするのが「いわゆる左手系と呼ばれる操作」
↑X'=(
x',
y',
z')
というベクトルを用意して
↑Y' = A↑X' という掛け算をするのが「いわゆる右手系と呼ばれる操作」
の違いでしかない
(要するにどちらも本質的には同じ) >>575
アプリ内で反転したテクスチャをレンダラに渡すって手もあるが猛烈にメモリーの無駄
うちはGIMPでエクスポートするとき上下の鏡像反転だね 計算回数も変わらないしね
ボトムアップなのは、数学のグラフと同じ座標系にしたかったから、とか聞いたことがある。
xが接線、yが法線、zが従法線として、キチンと向きが揃うとかなんとか ttp://stackoverflow.com/questions/4124041/is-opengl-coordinate-system-left-handed-or-right-handed
OpenGLはobjspaceとworldspaceでは右手系で
glOrtho/glFrustumの実装のせいでwindow座標では左手系になるらしい
といっても古いOpenGLのお話 Vulkan SDK 1.0.39.0
ttp://vulkan.lunarg.com/sdk/home >>576
大間違い
それは単に行列が列指向(column oriented)か行指向の違いでしかない
Wikipediaにちゃんと書いてあるんだから見ればいい >>578
> xが接線、yが法線、zが従法線として
それだとトップダウンにならないか?
接空間(tangent space)の事を言ってるなら
x=接線(tangent) y=従法線(binormal) z=法線(normal) だな OpenGL 4.0 シェーディング言語 -実例で覚えるGLSLプログラミング
https://github.com/daw42/glslcookbook
ここのサンプルは右手系と左手系どちらなのでしょうか GLしか使わないからハンドネスなんかどうでもいいが
原点視点から離れていく方向が+だからGLのほうが自然では無いかと
あんまりなさそうだけど訴訟になった場合の対策でz逆にしたのかしらね ジンバルロックの理屈はわかるけど、実際何が問題なの?2軸が重なろうが構わず指定通り回転させればいいのでは? 2軸を外積を使って残りの軸を割り出す時に、完全に2軸が重なってると
外積の結果はゼロベクトルになってしまうけど、微妙な距離だと方向が
激しく変化する事により、向きがブルブルしてしまう事をジンバルロックと言う (以下Y軸プラス方向が真上とする)
よくある状況としてはlookatを使う時に普通はUpベクトルにY軸を渡すけど
真上を向こうとした時に方向ベクトル(eye - center)がY軸とほぼ同じ方向に
なった時にサイドベクトル(X軸)が>>590の状況により、激しく変化して
グルグル回ってしまうとかある x軸を外積で出さないでベクトル値を持っていればいいのでは? 方向ベクトルが任意なのにそのx軸ベクトルが固定値になるわけがない 最初だけ外積で出して後はそれを一緒に回転させればいいのでは その「一緒に回転」を数学的に厳密に描写してみ
ジンバルロックと同じ問題が出るから カメラの視線ベクトルも上ベクトルも、極座標変数θ、φから計算して常に直交するようにして与えてる。 FPSみたいなゲームだと真上を向くのは人間の首だからY軸と一定の角度以上には
上を向けないように制限してジンバルロックに対処してるのがほとんどだな 再度ジンバルロックについてお尋ねします。
軸が重なると言っているのは、初期姿勢のXYZ軸と、
回転後のXYZ軸が重なるということを言っているのだと思いますが、
2番目だけ90度だとマズイと言っていますが、
1番目を90度にしても軸は重なりますよね?
例えばXYZ軸の順で回転したい場合、
X軸をいきなり90度回せばY軸とZ軸は重なってしまうと思うのですが、
これはジンバルロックにならないのでしょうか? また、2番目を90度にしても、一番目を何度か動かせば、
初期軸と回転後の軸は重ならないと思うのですが。
XYZ軸の順で回転させる場合、
Xを45度回し、Y軸を90度回しても、回転後のX軸と最初のZ軸は重なりませんよね? 回転と考えるから理解出来ないんだよ
単にあるものを回転させてるだけならジンバルロックなんて起きない
いわゆるジンバルを中のリングはいじらずにそのもの全体をぐるぐる回してるに過ぎない
ジンバルロックというのは中のリングの内2つが同一平面上にある時の事を言う
その状態は要するに2軸が完全に重なっている事を意味する
そうすると残りのリングは一方向に回転するしかなくなり、向きたい方向に向け無くなってしまう
これが厳密な意味でのジンバルロックだ。わかったか?
3軸が全て垂直を保ったままの回転はジンバルロックは起きない
で、3D計算上でのジンバルロックというのはlookatのコードのように2軸から
外積を使って3軸目を求める時に2軸がほぼ重なってる時に向きがランダムな
状態になる事を言う AppleがWebGPUなる新APIを発表したが
これ標準になるのかね? シェーダコードと頂点、テクスチャの無償寄付サイトになるな ソースコード公開されてたらタダだーと勝手にコピーして使っちゃう人? 610みたいな無知がいるから法律ってのは必要なんだよな WebGLはTyped Arrayの内容をいちいちアップロードせずにテクスチャやバッファとして使えないかとは思う
VRAMが共有されてる環境ならコピー無しで使える
しかしGPUが使用中のデータは書き換えてはいけなかったり
GCがコンパクションでデータを移動しないようにメモリ上の位置を固定→パフォーマンスが低下するなど
ややこしい事になるかもしれない >>609
バレて炎上してるのはこういう人が居るからか。 >>602
なんかジェットコースター宙返りのように反り続けていくとてっぺんで急に向きがくるんと変わっちゃうあれですよね。 Intelも新グラフィックスドライバでVulkanに対応
ttp://pc.watch.impress.co.jp/docs/news/1044145.html >>614
それはlookAtが宙返り対応してないで裏がえる現象じゃね >>612
BufferObjectをダブルバッファにすればGPUとCPUで並列処理出来るよ
実際にコピーしてるかどうかはドライバ次第だ
Intelの内蔵GPUとかはコピーしてない気もするからな(実際のところは知らん) >>610
著作権表記がない場合は自動で付くんじゃなかった? スマソが、グローシェーディングとかするのに法線使うけど、
その場合、頂点と1対1にするの?
OBJファイルでインデックス方式になってるのを、uv含めて展開するのが正しいのかな? >>619
最近だとテクスチャをダイナミックに更新したい場面が多い。
バッファオプジェクトのRO宣言って割りと意味ないと思う。
drawを非同期実装とかしないでしょ。 どうか教え下さい
AndroidアプリでNDK側でOpenGLESでテスクチャ作ってるのですが、
それをJava側に渡してGLSurfaceViewで表示したいです
readPixelsで配列データとして渡して表示はできたものの、遅すぎてゲームアプリとしては破綻していて。。。
どんな方法がベストでしょうか?やはり、コンテキストを共有するしかないでしょうか? ベストを探す前に素直にサンプルと同じやり方を試すべきだと思う
そうしない理由があるのならそれを言わんことには サンプルってどれっすかね?
試すのは大丈夫なんですが、描画スレッド(Java側)と演算スレッド(NDK側)みたいな感じす
スレッド跨いでEGLコンテキスト共有とか、知識あんまり無いです。。
Java側はGLSurfaceView使ってるので、単なるSurfaceViewに変えないとだめっすかね。。 >>631
レス遅くなってすみません
シェーダー使うのもありですが、framebufferからreadpixelsする変わりにシェーダーで対応ってのがどうゆうことか理解できてません
とりあえずNDK側でガリガリ作った画をJava側に60fpsで渡す方法があれば何でも試します スレッドがJavaとNDK側で別なんです
そしてJava側はGLSurfaceViewなので、なおさらコンテキストは共通化できてないっす >>630
どれ?じゃねーよ
NDK使ってるんだろ?
大丈夫なら試せよ >>636
ndk-bundleのソースフォルダのサンプルが使えるってことですか?
使えそうなサンプルは無いように見えますが。。
教えて下さい。 だから何で自分の流儀を前提にしている訳?
あんたの流儀はあんたが一番知っているんだから
他人に聞くだけ無駄だよ こういう支離滅裂なアドバイス(?)する奴はなんなんだろうね?酔っぱらってんのか? Androidの事は知らんけど、単にコンテキスト間でリソース共有にすればいいだけだよね。
Windowsならできる。同様のAPIあるんじゃね。 http://d.hatena.ne.jp/orangesignal/touch/20120818/1345275541
これをぱっと見た感じGLSurfaceViewのgl.glXxxとNDK側のglXxxは同じコンテキスト使ってるっぽいからtextureID渡すだけで行けそうなものだけど 横からスマソ、
俺もアンドロイドのOpenGL弄ってるんだけど、
GLES20.glxxxがラッパー?で、上で言ってるglxxxがNDKとか言うやつ?
サイトでよく出てくるサンプルはGLES20.使ってるけど、
そのNDKとやらを使うと速いとかなんかいい事あるの? >>641
VM介さないから処理によっては速度が全然違う
ゲームとかはフルndkのほうがパフォーマンスが良い
これ以上はAndroidスレで聞いたほうがいい Javaだろうと、NDKだろうとスレッド別なら全く別処理でテクスチャも何もかも共有できないよね? OpenGLESの知識は浅井ですが、自分の認識です↓
ttp://eaglesakura.hatenablog.com/entry/2013/12/28/235121 >>646
shared_contextは遅いの? >>632
遅いのはJAVAとかNDKとか以前にreadpixelじゃないの? >>648
そうです。
その代替案を探してるだけなんですが、描画と処理のスレッド別なので、テスクチャIDやフレームバッファを共有できない(EGLコンテキスト共有できない)と思ってましたが方法ありそうですね androidのことは詳しくないけどJava側のレンダリングスレッドからネイティブのレンダリング処理出すんじゃだめ?
CPUは並列に動かせてもGPUは並列には動かないし、別スレッドに分ける意味余りないよね? レンダリングを別スレッドでやりたいわけじゃないでしょ。 並列で動いてるんじゃねレンダ要求直後VBO書き換えるとチラつく >>652
実装はAPIの関知する限りではない
いわゆる未定義動作の類なのでは? 未定義つうか禁則じゃねVBO使わずにnioバッファの時は勝手に調停してくれてたんだが ほんと初心者で申し訳ないのですが、質問をお許しください。
現在、MAX/MSP jitterを使っているものです。
GLSLの勉強をしているのですが、例えばjitter側で生成した球に、
グローエフェクトをかけたい場合、どういう考え方でGSGLを記述したらよいでしょうか。
vvvvとかならグローエフェクト専用のノードで一発なのに、
MAXでシェーダを書く場合の例とかいろいろ検索しても出てきません。
質問自体もおかしなところがあるかも知れませんが、是非MAXの環境で
映像を作っていきたい理由があるので、どなたかご教示お願いします。 未定義は定義してないってことだね
禁則はやっちゃいけないってことだね
全然別の意味だね君の頭の中までは文句は無いよ
脳内の混同は取るに足らないありふれた事象だし >>657
プログラマは未定義動作をするプログラムを書いてはいけない事に変わりない。やっちゃいけないことだよ。 未定義動作とごっちゃにしているんだろうなと思ったら案の定。 未定義動作しても構わないよ
そこに到達しないコードを書くのが基本 未定義動作なんて聞かない言葉だと思ってググったらバッファの初期化忘れのことかよ
もしも初期化してなきゃ最初の1フレームは起きるかもしれないが件のは前のフレームと
次のフレームとの境目で起きると思われるちらつきだから未定義動作とやらでは無いわな WebGLだとセキュリティ上の理由でglMapBufferみたいな安全を保証できない機能は使用禁止 GTX1060(モニター@を接続)とQuadro4000(モニターAを接続)の2枚差し
PhotoshopなどのOpenGL系でGTX側に接続しているモニター@を10bitカラー表示させることってでませんか?
どのような効果が見込めるか分からなかったのですが、
NVIDIAコントロールパネル/3D設定の管理/OpenGLレンダリングGPU
の設定ではグローバル設定→Quadro4000に変更してみました photoshopなら設定にあるけど他のソフトはソフトが対応してるかだからユーザーがどうこうできる問題じゃない >>664
つうかWebGL以前にglMapBufferはOpenGL ESにねーし
GLESベースのWebGLに無くて当然
WebGL1.0でもテクスチャ使えば似たような事は出来る glewの2.0.0のVC10のglew.slnをビルドすると
error LNK2019:未解決の外部シンボル memsetが関数 glewContextInitで参照されました
と出てビルドできないのですが、どう直せばいいのでしょうか? ちなみにソリューションを検索しても「memset」の文字列は出てきませんでした。 VAOで描画する時ってglBufferSubDataとかで毎フレーム頂点データを書き換えるような場合は使えない? VAOって何よ GL_DYNAMIC_DRAW指定しとけ glslのIDEとかってないですか?
vulkanで使うのですが 人とAIの共存を主とする「Google PAIR」、機械学習(NN含む)をブラウザ上で全て実行できるWebMLライブラリ「deeplearn.js 0.1.0」をリリース
http://shiropen.com/2017/08/12/27359
人を中心としたAIシステムの研究と設計をするGoogleのプロジェクト「The People + AI Research Initiative(PAIR)」は、
ブラウザ上で機械学習(Machine learning)を全て実行できるオープンソースライブラリ「deeplearn.js 0.1.0」をリリースしました。
本ライブラリは、可能な限り多くの人に機械学習を開かせたいという思いのもと開発されました。
その為、インストールやバックエンドなし、ブラウザ上で全て実行できる仕様になっています。
今までもWeb Machine learning(WebML)ライブラリは存在していましたが、
Javascriptの速度によって制限されていたり、
訓練ではなく推論に限定されていたりしていました。
一方で、deeplearn.jsは、
WebGLを利用しGPUで計算することで大幅にスピードアップさせ、
またニューラルネットワークを学習させる際に用いられるアルゴリズムBackpropagation(バックプロパゲーション)機能も備わっています。 > 「OpenGL 4.6」が公開
> 「OpenGL 4.6」の仕様公開を発表した
> OpenGL 4.5は2010年に登場したOpenGL 4系の最新版。
> OpenGL 4.5の仕様はプロジェクトのWebサイトで公開されている。 Androidで動くVulkanとOpenGLESの比較できるベンチマークアプリ知らない? >>679
スラドのhylom
OSDNマガジンの末岡洋子 最新トップYoutuberの年収は10億円、1億円の時代はもう古い
http://www.himatubushisp.com/entry/2017/05/10/224945
Youtuberヒカルが月収を明らかに!!おはよう朝日です出演
https://www.youtube.com/watch?v=RLZGrqQnnZc
第1回案件王ランキング!YouTuberで1番稼いでるのは誰だ!
https://www.youtube.com/watch?v=asF2wQ2xhjY&t=61s
ユーチューバーの儲けのカラクリを徹底検証!
https://www.youtube.com/watch?v=FUSb4erJSXE&t=504s
【給料公開】チャンネル登録者4万人突破記念!YouTuberの月収公開!
https://www.youtube.com/watch?v=Y7DAQ0RKilM&t=326s
誰も言わないなら俺がYouTuberのギャラ相場を教えます
https://www.youtube.com/watch?v=E4q-vaQh2EQ&t=118s
最高月収5000万円だとさ。年収じゃなくて「月収」な
おまえらもyoutubeに動画投稿したほうがいい
手っ取り早く視聴数稼ぐには有名ユーチューバーへの物申す系動画がオススメ
しばたーやよりひとやkunやぽんちやモンスタージョンなどを真似すればいい AndroidでGLES2で実装されてるやつをVulkanに置き換えてみたんだが1/3(GLES2は45 Vulkanは15程度)しかFPS出なかった。(3D性能自体あんまりよくない中華スマホ)
単純に置き換えただけじゃFPS出ないとはよく言われてるし最適化考えてないベタ移植だからこんなもんかなぁと思ってたんだが、Windows上のNVIDIA環境で動かしたら1割アップ(GL3は880、Vulkanは1000)してた。
これデバイスの特性ってやつなのかスマホのドライバーがアレなのかどっちだと思う?
デバイスの特性だったとしたらどうやって最適化したらええんやろか… モバイルだとライフサイクルからして
ドライバとデバイスを分ける意味はあんまりないと思うけど
ベタ移植でも環境によっては効果があるなら
両方実装して性能の良いほうに切り替えれば良いのでは 素人が効率の良いOpenGL実装をVulkanで作るって不可能な気がするので
ANGLEに期待
ANGLE on Vulkan Update Q1 2017
https://groups.google.com/d/msg/angleproject/HfDeJyIXlrU/MnSe6jNiAQAJ 自前じゃ一枚絵を出すのも大変そうだから公式レンダラを
みんなでチューニングやカスタマイズみたいな方向になるのかしらね >>683
不明要素が多いから何とも言えない
バックバッファの切り替えウェイト、デバイス固有のリミッタとかに填まっている可能性もある。
中身はARMで泥ならば、所詮はVM。
変更できない要素に左右される。
例えば、電池消耗を抑えるためにフレームレートを制限なんかは想像しやすい。
MS違う iOSはJava使ってないから無条件に速いと思ってる
iPhone信者か 電池理由でアプリに制限を掛ける。
そういう設計もあるって話。
スマホでfpsを求めるのが間違い。
一番電池を消耗するのは、電波発信。
次がバックライト。その次がプロセッサ どう解釈したら>>690と>>687が繋がるのかさっぱり分からん
電池理由でアプリに制限を掛ける設計があるとして
GLES2とVulkanで性能差が出る説明にならないし
結局はアプリによるが
性能が限られたスマホだからこそfpsが求められるんじゃないの?
要求が60fps超でなく例えば30fpsだとしても VulkanってAndroidのJava APIからは使えないよね 用意されるのかなそれともvulcan入れてあるけどNDKでやってくれとなるのか JavaってC#みたいな構造体やポインタの操作みたいな
ローレベルな事は出来ないけど
VulkanみたいなローレベルのAPIを持ってけんの? 提供されるとは思わんが
できるかできないかで言えばで
構造体は「同等のバイナリを生成する」クラスで実現できるし
ポインタ操作(演算)はそもそも必要ないだろう
ポインタ使った最適化したければNDK使えで済む話 >>691
そのデバイスでバックバッファをクリアとスワップをするだけのアプリを走らせれば、性能が出せるのかは、わかるだろ JavaからじゃvkMapMemoryで頂点バッファにアクセス出来ないよな
WebGLも同じような理由でglMapBufferがない
代わりにglBufferData的なバッファのアップロード用の関数が必要 3DMarkに追加されたAPI Overhead TestをHuawei P10 Liteでやったが
OpenGL ES 3.0: 31547
Vulkan: 45753
でVulkanの方が45%ぐらい早いという結果に
ミッドレンジのGPU貧弱な端末だとこんなものか
Galaxy S7 edgeだと5.8倍近い差がつくらしい
http://www.4gamer.net/games/143/G014363/20170818014/ >>698
おー情報サンクス。リリースグットタイミングだわ。
グラフ見るとOpenGLESのほう60までしかFPS出てないからvsyncで頭打ちになってるっぽいね。
単純にスコアの比較はできない
俺もHuawei P10 Liteだからやってみたけど
GLES 36950
Vulkan 53200
だったけど、GLESは60以上出てなかったし、Draw Call per frameの線とFPSの線が交わる高さが一緒だから効率全く変わらない気がする(リンク先のGalaxyだとVulkanの方が交わる位置が高い)
CommandBufferを一度作ったら作り直さないみたいなLowLevelAPIに有利さな実装になってると思うから、それで互角ってことはそれができないアプリだと逆にVulkan負けそう。もちろんP10 Liteの話ね。 OpenGL ES超絶難易度アルティメット級でワロタw
俺かなりITと親和性も高いし、3Dそのものは15年以上やってるけど、
CGがちゃんと表示できないwwww
これどうやったらちゃんと表示できんの?w
もう2週間くらい挑戦してるけど全く進まなくて辛すぎwwwwwwwwwwww
教えてえろい人w それはみんな通過する儀式的なもの絵を出せて半人前
しかし泥なんかあんなにユーザーいるのにまともなレンダラ無いんだよな
テクスチャと頂点と視点渡せば絵が出るようなやつが最初からあれば
捗るんだが そんな中途半端なものがまともだとは思えないんだが。 中途半端かね?完成したものはどんなだか興味があるな
入門者が玉転し作れる程度の物すらないのよね 初心者向けならユニティでいいじゃないかと。
なんでJavaで作りたいのか OpenGL 4.6の進化点やOpenCLの将来について,Khronos Group代表のNeil Trevett氏に聞いてみた
http://www.4gamer.net/games/107/G010729/20170907023/
・OpenGL 4.6がリリース
Vulkanとの相互連携機能を搭載
・2017年はVulkanのアップデートなし
移植工程を短縮するラッパーの開発が進む
・OpenCLソフトウェア資産をVulkanで動作させるソリューションを開発
・glTFは物理ベースレンダリングに対応
WebGLはFlash終了問題が普及の追い風に
・AMDの「プリミティブシェーダ」は,OpenGLやVulkanに取り入れられるのか? glTFの物理ベースって
最新観てもペンディングだったんだが。
器を汎用的で高機能を目指すにしても、別にこの形式のままシェーダに流し込む訳でもないだろうと。 初心者がスクラッチで0からレンダラ書くと年単位でかかる
発熱が少ないバイナリが小さいユニティ使ったこと無いけどなー 最新のOpenGLでできることを
OpenGL ESで実現しようとすると大変だが
OpenGL ESで実現できることは
OpenGLでも(スレチだがDirect Xでも)大差ないと思うんだが
>>700はなぜES名指しなんだろう? 昔のOpenGLはシェーダとか使わなくてもよかったからじゃないかな。 OpenGL 1.5が約15年前な訳だが
携帯デバイスだとデバッグがやりにくい
というのなら分からんでもないが
それは難易の問題じゃないしなぁ 昔のOpenGLを再現するデフォルトシェーダーとかあると良いのにネ 俺がOpenGL始めたの2007年くらいだったけど
そのころは固定機能パイプラインによる解説ばっかだった気がする。
スマホが普及してESが登場した頃から日本度でもまともにGLSLを学習できるようになった気がする。 当時はリアルタイムグラフィックス分野はDirectXが開拓していた
だからあえてOpenGLをやる人は
クロスプラットフォームだとか互換性を重視していた
DirectXやっていた人がOpenGLに流れたのが
スマホが普及してESが登場した頃であって
OpenGL内だけで言えば固定機能パイプラインとの決別は
OpenGL3の策定時点(それこそ2007年頃)で既に決定的だったと思う >>712
それなら素直にOpenGLES1.1使えばええやん 動作も軽いし製作者の力量でソコソコ綺麗な絵出るもんね
ただ時代の流れでサポ切りとかあるのか無いのか知りたい GLES自体新しくて多くの端末で動いてるし動かないアプリが出ても困るから安易に切られることはナイアル スマホはDirectX使えないからな
必然的に互換性という面でOpenGLが出てくる
スマホ、特にAndroidはパフォーマンス厳しいしVulkanに頼りたくなる OpenGL系は基本後方互換前提の代物だからそうそう切られることはないはず
アーキテクチャの違いでパフォーマンスが下がるとかはあるかもしれないけど誤差の範囲でしょ GLUT (pronounced like the glut in gluttony) is the OpenGL Utility Toolkit, a window system independent toolkit for writing OpenGL programs. glutでポリゴンにアンチエイリアスかけれないんだが。
線ならかけれるのに。
どうやんの? 実際のところ画面の高解像度化で
アンチエイリアシングなしでも
そこそこ鑑賞に堪えうるようになってしまった
ミップマップや異方性フィルタリングは欲しいが WinはDirectX
MacはMetal
VulkanはLinux専門になりそう ほんでもクロスプラットフォームにしようとおもったらVulkan一択なんやろ? >>730
別にWinでもVulkan普通に動くじゃん
Androidでもいつかはみんな使うようになる
問題はAppleなんだよな AppleはmacOSでもiOSでもAPIとして採用する気無はなくMetal以外眼中に無い感じやしね
最近Web標準のAPI草案にMetal特有の仕様を突っ込もうとしてMSとGoogleに反発されてなかったっけ 各プラットフォームが足並み揃えてくれないと、クロスプラットフォームが形骸化してしまうし使う意味もなくなるな
WebGLはどうなるんだろ
ライブラリの開発者は大変だな 物凄く大変だとは思うがそれに見合った収益はあんのかしら glfwとglewで OpenGL 4.6 ターゲットにプログラムしています。
glslの "layout(binding = N)" が反映されず困っています。
glGet○○すると 0 が返って来ます。
どうやら宣言順にインデックスが付けられてるようで
glGet○○の値を使えば正常に動作します。
でも気持ち悪いです。
何で binding 指定が有効にならいのでしょうか?
初めはUniformBuffer使おうとして気づいたのですが、
ショートプログラムで確認した結果、
shaderStorage、sampler、image等も同じく反映されないようです。
環境はGeforce GTX760、ドライバVer388.13、VSコミュ2017使ってます。 >>736
横からだが、シェーダ側で指定したバインド順番をCPUに強制させたいという話かと理解したが
それは後方互換性を維持するためではないかと DX9cから始めて11のあとにglに来たんだが
混乱と雑音をうむだけの後方互換性は、はよ切り捨てろとは思った。
glは統一規格を目指してない。
専用機での利用を大前提としたGPU規格のテンプレートみたいな印象がした。 >>736
GLSL一行目の#version指定が正しくないとか?
layout指定は300以降だったかな?
OpenGL/GLESとGLSLのversion指定って混乱するよね…… >>739
一行目必須、BOM禁止。コメント禁止だしね
それ以外もドライバ依存が激しい。
PS4やDSなんかのコンソールやiPhoneなら、それ以外がないから気にならないが
泥の現状はカオス、コキュートスモード 腹が立ってきた。
glはハードウェア実装に特化して作る方ほことを考えてないんだな。
directXが至高と思えてきた。
せめてカレントあたりについては、リファレンスも目的語か「どこに」を書けよ。 自己解決しました。
glGet(Uniform/Resoruce)Indexが返す値が"layout(binding = N)"のNと思い込んでいました。
プログラムオブジェクトに入力するパラメータは必ずバインドしないといけないと思い込んでおりました。
layout(binding = N) と glBindBufferBase(GL_UNIFORM_BUFFER, N, ubo);
が対になっていてglUniformBlockBinding呼ぶ必要ないと。
酒飲んでプログラムすると駄目だなぁ。 単位ベクトル同士の外積は単位ベクトルになるのかと思ってたら違ったでござるよ orz 全ての辺の長さが1の平行四辺形の面積は色々だからな。 |a||b|sinθ
だからな
角度によって面積はゼロに近づく #include <GLFW/glfw3.h>
int main() {
GLFWwindow *window;
if (!glfwInit())
return -1;
window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL);
if (!window) {
glfwTerminate();
return -1;
}
glfwMakeContextCurrent(window);
while (!glfwWindowShouldClose(window)) {
glClear(GL_COLOR_BUFFER_BIT);
glfwSwapBuffers(window);
glfwPollEvents();
}
glfwTerminate();
return 0;
}
$ g++ -L/usr/local/lib -lglfw -framework OpenGL main.cpp
$ ./a.out
キタ━━━━(゚∀゚)━━━━!! ES3.2をJavaのみで書ききり、嫌になってバルカンに移行。
泥で触っているんだけど、かなりいいね。使いやすい。
ほとんどDX11と同じ感覚で使える。
バルカンは、普及する感じがした。 泥バルカン。
スワップチェイン、フレームバッファとサーフェスをコアダンプなしで通せたが、
いまだに残るパイプラインとシェーダ。
またまだ続く簡易フレームワークを作る作業。
現在のコード量。6000行 愚痴。バルカンネタ
ようやくディscripter、パイプラインあたりも実装が終わった。
今日あたりになんかのジオメトリを描画できそう。
残りは定数バッファへの値の流し込み。 Vulkanでジオメトリの描画成功記念カキコ
あっけなく描画できた。
Windowsで作った描画フレームワークのジオメトリがあっさり描けた。
ようやくスタートライん。 あっさり描画できましたか
あっさり描画できてよかったですね 最近のバージョンのAndroidはVulkan対応してるらしいけど
使ってるゲームってあるの? ないと思うよ。
2016年末に定まった規格だから対応機種は、その頃以降の機種になると思う。
というか、これからの規格ではないかと。
字形を描画する機能がない。 調べてきた。
APIレベル 23以降。泥6以降。
23以前もsoでどうこうは、恐らく、使えないことを確かめる手段の提供を以て対応の整理だろう。
泥6のシェアは、10%辺り。泥は4が今でも主軸のレガシィ 大事なことを書き忘れた。
スナップドラゴン、エクスペリアXZsでも
ジオメトリシェーダ ×
あとはわかるな OpenGLでもいいんやけどねぇ
OpenGLのどこがいかんのや Vulkanはドライバーが未成熟なせいで
OpenGL ES 3.1より遅いかもと
3DMarkのAndroid版のSling Shot Extremeの説明には書かれている >>765
何で一個人がデータセンターの心配してんの?
貧乏人はGeForce使ってればいいんだよ >>767
は?個人ならGeForce使ったって何の問題も無いんだよ
馬鹿も休み休み言え
ちょっとGeForce集めただけでデータセンター気取りかよw 貧乏人が深層学習やりたかったら、時間貸しのデータセンターしか満足できる速度で実行できないでしょ? 深窓学習は、昔のホストコンピューティンぐへの回帰現象かな
とりま、そこらのDCよりも京の方が安くつく、とすら感じる。
できることも占い程度。 >>762
時代遅れすぎる情報が未だにごされと紹介されている。
もうGLとdxの違いは、深度区画だけなんだから ちなみにGeForceをデータセンター云々の記述はアメリカのサイトには書いてない
だから海外では(今のところ)合法
日本にNVIDIAを激怒させるようなよっぽどの乞食が居たんだろうな
さくらインターネットか?迷惑な話だ その辺の事情がわからんのだが
具体的にさくらインターネットが何をしたん? ドライバに対するライセンス条項
No Datacenter Deployment.
データセンタに配布すんな
The SOFTWARE is not licensed for datacenter deployment,
繰り返すが、このソフトウェアは、データセンタへの配布をライセンスしてない、
except that blockchain processing in a datacenter is permitted.
しかし、データセンタにおけるブロックチェイン計算なら許してやるよ、こじきども(キャハ)
条項よりも、話題の論点がようわからん。 ちな、ブロックチェイン計算とは履歴みたいな奴。
具体的な実装でいえば、イーサリアルだかピットコインなんかが、それだったと思う。
何にしろ、確かにテスラを買わせる為の制限条項との指摘は理解できる。
もっともな指摘だなー、と。 ジオメトリシェーダーって性能が出ないとかで
いらない子扱いされてるらしいけど
なんで? Mayaって昔はQuadroでしか動作保証してなかった気がするけど、仕事で使わせるものには高いやつを売り付けるというNVIDIAの昔からの常套手段だな 1dテクスチャの使い方のサンプルはどこかにありませぬかあ
カラーマップで使いたいんだけど探してもなかなかヒットしませぬ
何卒。。。 テクスチャを作るときのフラグが違うだけだと思う。
シェーダからはUだけ指定。
使ったことないけど。
法線マップのアルファにカラーマスクを仕込んで使った方が立体的に色を当てられるような。
実行時に色を交換したいなら定数バッファにいれた方が楽に思う。 法線マップを圧縮しないならね。
2D ゲーム作ってる可能性もかなりあると思うけど。
定数バッファがいいかどうかは、複数のシェーダで使うのかどうかかな。 いやいやカラーマップ(パレット)って普通テクスチャ毎に必要でしょ
またはオブジェクト毎とか
要するにユーザーが服の色を指定するとかすると必要になる
シェーダー毎とか関係無い グレースケールでデザインさせて、配色をそのつぎに決めるとかなら、あるような。
14なんかはそんな感じにみえる。
あれはユーザが基本色を選べる。
配色数が少ないなら、全通りをテクスチャでもつとかできるかもだが、配色数が多いと読み込みも地獄なら、VRAM要求も地獄になる。
だからパレットだけを一次元でもつのだろうが、配色選択のためならば、やっぱり一次元じゃなく、二次元で持ちたくなると思う。
横に配色、縦にバリエーション(ユーザが選択する軸)と配列して。 0次元 テクスチャ使わないで単に色指定じゃ駄目なんかしら
1次元 線をテクスチャで使うってのは珍しいな 泥はとっくに対応済みなような。7以上だけど。
自分の端末で動かしたから間違いない。 あんま大したネタじゃないが、D3D12とvulkanに特徴的なのは
・DescripterSet
・パイプラインハンドル
・テクスチャロード手続き
・コマンドリスト
かな
一つを使い回さず、目的別に個別に作れと言われている気がした。
D3D9、11、GL、GLESと使ってきたけど、バルカンは使いやすく、GPUを理解しやすい。 ほぉ場合によってはMetalを他所のプラットホームに展開して世界征服なんてのも面白いと思うがそうきたか これ基本Metal APIへの変換レイヤーなだけで別にAppleは何もしてねえのでは Appleは何もしてないぞ
単にMetalのラッパーだな
しかしOpenGL使うよりはCPU負荷は減ると書いてある
知りたいのは直接Metalを使った場合よりどれぐらいオーバーヘッドがあるかだけど分からん バルカンに字形描画はない。
そこをどう折り合うのだろう Vulkanにフォント描画が無ければ実装しないだけじゃないか?
ゲームは普通APIに依存しない形でフォント描画を実装してると思うからそれほど重要ではない気がする ゲーム、動画再生のみバルカン
OS内部はESとvkのデゥアルスタックか。 Vulkanを使ってみたいけど、Amazonで本を探しても英語の本しか出てこないし、その英語の本もレビューを見ると今一だし、どうしたもんか... Vulkanは公式のC++ラッパーが有るのが助かる
これから日本語の書籍を書こうと思っている人は絶対C++11前提で書いてほしい
こんなとこで言っても無駄だろうが… いままで公式の出版物は良書だったからな今後に期待だね でもバルカン理解するには、GPUのアーキテクチャというか、描画パイプラインの知識が大前提な気がする。
簡単なフレームワークを書いたが、理解しにくいのは、
シェーダにポインタを与えるDscripterset
テクスチャロード
まんまパイプラインと名づけられたパイプラインハンドル周辺
テクスチャなんかは、何故、一度ステージにいれてからコマンド投げて転送するのか?
フォーマットをレイアウトする為だが、他のAPIだと透過的にできたことをやらされるので、ディスに使われると思う。 >>810
まあ、そのへんは慣れなんじゃないか?
OpenGL3.0系に初めて触ったとき、「これ使うのにソフトウェアでレンダリングエンジン書ける知識が必要じゃねえか」と衝撃を覚えたし openGLをなに入れればいいのかわからないよ〜、openGLって名前じゃないのもあるからわけわからないよ〜 そのレベルならJuliaとかPythonからglfwを使うのがよい C言語は知識あるからC言語でopenGL使うにはどうすればいいかなって聞こうと思ってたんだよ 諸事情でopenGL触らないといけなくなったんだけど全然分からない……
最終的にwindowsアプリ作るところまで持ってかなきゃいけないんだけど1週間位あーでもないこーでもないやってようやくウインドウに立体を表示させられるくらい
床井先生のところ参考にしたりしてるけど全然だめ。難しすぎないこれ。泣きそう そもそも1週間でマスターできると思ってたのかよ
コンピュータグラフィック舐めすぎだろ ごめん。マスターなんておこがましいことは考えてない。
ただこれまでの課題はそこそこ順調だったもんで急ブレーキになったもんだから
っていうかwindowsプログラミングの難しさもやっぱあんのかなこれ……openglの参考書写経してるときはほうほうなんて思いながらやれたりもするのに 今時のOpenGLを裸で叩いて立体の表示まで行ったのなら、あとはどうとでもなるような気がするが…
ワールド座標から同次行列使ってスクリーン座標にできてるし、シェーダーも動いてるってことだろ? OpenGLで2Dをするか3Dをするかで必要な数学の知識は変わってくる GLで混乱して挫折するのは、
頂点・索引配列絡みとカレントじゃないかな
プロセッサから毎回頂点要素(座標、法線なんか)を送り込む初期のGL方式が未だにWebには最新情報とアフィリエイトされているし。
Google先生もこれをオススメするしね。
あとはWebGLが曲者。
発展途上のAPIはDXのように丸ごと差し替えるのが正解なんだろう。
混乱のもと。 そうだ、ちらうら。
OpenGLとVulkanはデバイス座標系における正数方向の向きが違う。
なんとDirect3Dとも異なる第三の座標系
まあ射影行列の符号が変わるだけだが れんとうすまん。
Yを↓にしたのは、恐らくは、加速度センサーの符号を意識したIoT機器配慮の設計だと理解している。実際の趣旨はしらん。 >>826
主な理由は普通にコンピュータで扱う一般的な座標にあわせただけでしょ PSのコントローラーを箱で使えた時にPSの時と方向が逆転するって昔きたわ >>823
WebGLはまんまOpenGL ES2.0だし絶対に必要な環境
JavaScriptと若干のWebの知識が必要だけど1から3Dの勉強するには最も敷居が低い環境と言える >>826
しかも最後まで右手系のままで一貫してる
だからといって何かメリットがあるわけでもないだろうが 昔作ったopenGLのGLAUXで作ったコードはglutに書き換えた方が良い?今後参考にするためにもそっちの方が良い? >>821
同次行列って何?シェーダーってなんだっけ?レベルなのでお察しください
ファイルから座標読み込んできっちり画面内に収まるように表示させろとか、視点を3次元で回転させるとか、しかもそれをマウスで出来るようにしろとか、オブジェクト選択させろとか……
そもそもMFCすらよく分かんないからもう OpenGLとか低レベルのことは忘れて、ライブラリを使うべき 開発環境準備するの解らなくて、C言語でopenGL使ってしょぼいシューティングゲーム作ろうと思ってるんだけどなに入れた方が良い?
glutだけでいいの?>>1の全部入れておいた方が良い? >>823
さすがにVBOが主流になってから7-8年は経ってるけど、考えてみるとOpenGL3以降に対応した赤本ってまだ日本語版ないんだっけ?
というか、今のはどういう記述になってるんだろう
シェーダー前提の記述になると、三角形を表示するまでがけっこう遠いよな でかい本屋行ったり古本屋みたりして思ったんだけどさopenglって優しい参考書無いの辛い
例えばjavaとかcとかだったらそれこそ具体例なり比喩なりイラストなり駆使してステップバイステップで進めていけるような本いくらでもあるじゃない
もういきなり変換だのなんだの言われても何やってんのかまずそこから丁寧に説明しろやって思う
行列の話で込み入ったことになるというならもっとイメージをつかませてくれるというか…… >>838
日本語は少ないと感じた。
おれはバルカンで0から描画だけは、なんちゃってフレームワークを書き上げたから、GLには戻りたくない。
ジオメトリファイルを読み込むところからスキンメッシュ処理まではバルカンでできる。
今後の課題は、輪郭線の強調にタイムラインアニメーション。
バルカンは使いやすい。分かりやすい。 見ていてわかるが、ニーアや15のグラフィックス機能は、やっぱり最高峰と言われるだけある。
やはり、その道のプロは違う。
どんだけ血反吐はいたんだろう、と。 積み上げれば良いだけで、血反吐を吐く必要なんて無い。 FF15はともかく、ニーアは低予算にあえぎながらあれだけのものを作ったのがすごい FF15ってopenGLなの?全然か書かれてないしどうやってみんなわかるんだ 取り敢えず本屋行ってゲーム数学みたいな本を一冊買って読め
話はそれからだ
3DやりたいからっていきなりOpenGLのAPIを使いはじめても遠回り
ここの初心者の質問見てるとつくづくそう思う >>843
PS4は専用の非公開APIで箱はDirectX12でしょ
OpenGLは売りもんのゲームじゃほぼ使われてないでしょ
スマホだとほぼ全部GLESなはず openGLはグラフィックドライバーに入ってて補助・拡張ライブラリを追加して入れないともっと手軽に作れないって理解で合ってる? OpenGLはグラボ叩くためのライブラリだから、ゲームループとかWindow周りの処理とかイベント処理は自前で実装するか別ライブラリのお世話になるしかないね GLもメタルもバルカンもd3dもゲームコントローラやキーボード、マウス入力、
OSウインドウの移動もファイルの読み書きも、サウンド再生も、動画のデコードも、
セーブデータの暗号化もサポート外だしな。
配色デザインもしてくれないし、メッシュ、ジオメトリの生成もしないし、2Bを笑顔にしてもくれないし、声もだせないし、スキンメッシュも簡単にできるAPIなんかない。
可愛いキャラを作ってもくれない。
スカートの布を綺麗に捲ってもくれません。 GLで作られたゲームはMinecraftとDoomぐらいしか思いつかないや
ニーアとかFFもwindowsだとDirectXだしpsだと別のapiだろうし スマホ向けケームはほとんどGLだったんじゃね?
今はVulkanとかMetalかもしれんけど New SDK released for Vulkan 1.1!
Please note --- this new SDK supports Vulkan 1.1.70, and is backward-compatible with Vulkan 1.0.70. 動かせないコードからどの拡張ライブラリ入れれば動かせるってことはわかる? glulookatのパラメータいじくって視点動かそうかと思ってるんだけど、最後の3引数の上方向ってどうやって決めればええのか教えてくれんか
例えば原点中心、半径1の球を(0, 0, 2)から見てるとするじゃない。そうすると当然glulookat(0, 0, 2, 0, 0, 0, 0, 1, 0)になるじゃない
でもこれで仮に視点をX軸中心に45度回転させたとして、(0, √2、√2)から原点を眺めるわけだけどこの場合上ってどう決めればいいんかな
他にも90度だったらようは真下向くことになるのに上方向(0, 1, 0)じゃないよなとか
基本的な質問で悪いんだが色々調べてもわからんかったから誰か頼む >>854
Please noteってRelease noteの間違いか? >>856
視線ベクトル用の変換行列で
上ベクトルを変換させれば良いだけ
カメラのパラメータとして
視線ベクトルを持たせるんではなく
姿勢行列(横、上、前)を持たせるとわかりやすい >>856
ビュー行列は、カメラ設置点(ワールド座標系)を原点とした座標系に頂点を変換する作用を持つ。
同時に天地を決定させる。
lookat()の中では、上ベクトル(ワールド座標系)を注視点ベクトルとの外積(法線)を取って、それを三つの「軸」を決めている。
長くなったが、ワールド座標系でみて、上の向きとしたいベクトルを与えればいい。
厳密には、上ベクトルに与えるベクトルが注視点に向けて垂直に向けるべきだが、あんま気にせずともよい。
真面目に計算すると酔う絵になる。 visualstudio2015でglut32.libが開けないんだけど
スペックは
osWindows8
調べたけど全然わからないよ、助けてくれ〜 1>------ ビルド開始: プロジェクト:ConsoleApplication3, 構成:Debug x64 ------
1>LINK : fatal error LNK1104: ファイル 'glut32.lib' を開くことができません。
========== ビルド: 0 正常終了、1 失敗、0 更新不要、0 スキップ ==========
こんなの出た
リンカーでもパス通してるんだけど 1からコンソールアプリ作り直してやったけどやっぱエラーが出るな
1>------ ビルド開始: プロジェクト:ConsoleApplication1, 構成:Debug x64 ------
1> stdafx.cpp
1> ConsoleApplication1.cpp
1>c:\k013a2065\consoleapplication1\consoleapplication1\consoleapplication1.cpp(10): error C2664: 'void glutInit_ATEXIT_HACK(int *,char **)': 引数 2 を '_TCHAR *[]' から 'char **' へ変換できません。
1> c:\k013a2065\consoleapplication1\consoleapplication1\consoleapplication1.cpp(10): note: 指示された型は関連がありません。変換には reinterpret_cast、C スタイル キャストまたは関数スタイルのキャストが必要です。
1>c:\k013a2065\consoleapplication1\consoleapplication1\consoleapplication1.cpp(11): error C2664: 'int glutCreateWindow_ATEXIT_HACK(const char *)': 引数 1 を '_TCHAR *' から 'const char *' へ変換できません。
1> c:\k013a2065\consoleapplication1\consoleapplication1\consoleapplication1.cpp(11): note: 指示された型は関連がありません。変換には reinterpret_cast、C スタイル キャストまたは関数スタイルのキャストが必要です。
========== ビルド: 0 正常終了、1 失敗、0 更新不要、0 スキップ ========== そういう基本でこける奴は
GLじゃなくてDirect3D使った方が良いと思うぞ
APIとしての難易度は一緒だろうが
Direct3Dの方が情報が遥に得やすいだろうからな >>886
これ解決したわ、freeglutのglut.h freeglut.h freeglut_std.h freeglut_ext.h三つの置き場所8.0に入れたら動いたわ
win8でやってるからWindows Kits/8.0の方に入れなきゃダメだったみたいだ >>857->>858 >>861->>863
ありがとう。正直あまり理解できないけど参考にして頑張ってみる。
そもそも座標系だとか視点だとかねそこら辺で行列云々とかもうちんぷんかんぷんなんだよね……
いやほら1次変換とかで座標を動かすのに行列掛け算するのは知ってるけど、視点だの投影だのとどう行列が絡むんだよみたいな >>873
GPUはデバイス座標系で点を打つデバイスである。
だから、まずは行列を忘れることから始めることをオススメする。
ここを押さえないと、マジックやブラックボックスな理解にしかたどり着かない。 たかが点を打つために行列の使用を強制されるんでしょ 別に行列じゃなくてもいいよ
連立方程式で線形代数計算してるだけだし なんちゃら座標とかなんちゃら行列とか、計算しやすいから使ってるだけで
最終的にxyzが-1〜+1の範囲に収まってる点だけ描画される
直線の中間とか三角形の内部とかはいい感じに計算してくれる
と、こんな認識 3D空間の(x,y,z) → 2D画面の(X,Y) >>877
その通りだね。行列は計算式をコンパクトにまとめた様式に過ぎない。
計算機時代に適した計算方法。
手計算の方が計算回数は少なく、
行列は無駄な計算(結果が計算前と変わらない成分)が含まれやすい。 4x4の同時行列を知って感動したのは、三角関数なしに座標変換できることだったな
最初は狐につままれたような気分だった あーもー座標系ってのがわかんない。座標は座標で一つじゃないか。(0,0,0)は原点だし、(1,0,0)はそこからx軸方向に1進んだとこ。それだけじゃないか……
その座標上の点を動かすのに行列を動かすのは分かる。でも座標が動かない視点移動に行列だのもうちんぷんかんぷん。俺こんな頭悪かったかなぁ。C++やらjavaやらの勉強してるときにこんな詰まったことないよ
>>878
その-1〜+1ってのが全然分かんないんだよね。どっからでてきたその正方形ってなってる
表示されるのは長方形だし、座標はてんでばらばらな位置にあるしわけがわからない -1〜+1ってのはただの取り決めだろ
計算上も都合がいいし、大きすぎても小さすぎても誤差が発生する浮動小数点数を扱う上でも都合がいい
最終的には表示デバイスの個々のピクセルへ反映されるわけだけれども だから844で言ってるけどゲーム数学の本を一冊読め
それで理解できないなら3Dは諦めて2Dに専念しろ >>881
手計算ってのはスカラーでの計算の事を言ってるんだろうけど、スカラーに分解した方が速いなんて事は座標変換に対してはまず有り得ないと言える
それとも本当に手で計算する事を言っているのか… >>886
言葉のあや。
座標変換だけなら4回は変化のない計算が含まれたり、移動だけなら3回。
しかし行列だと必ず16回計算する。
それをマルチコアとストリームで最適化するから見えない、という話。 >>883
デバイス座標系は「比の世界」
ラスタライザがビューポートとレンダリングターゲットのサイズを分けることにも機能がある。おれは便利に使っている。
解ると流石はトップチームの設計と感動するし。 まあ行列の乗算はSIMDと相性が良いし
単純に16回とは言い切れない部分もある >>887
つうか…積和演算又は内積を100回勉強してから出直してこい
「手計算」で16回な訳ないだろ
掛け算足し算合わせて64回だよ
SIMDだと4回で済む >>887
一部同意だけど
PとかMとかRの行列があって順に座標ベクトルに掛けるのが決まってるなら
あらかじめ行列の積をもって置いて計算量減らしたりは出来る
手計算でも減るけどこの辺はごちゃごちゃする気がするんだ >>891
ID違うだろうから今更だけど、計算回数の違いは、
偏に「アルゴリズム(計算式)の形に起因する計算回数の違い」に依存する。
つまり、アルゴリズムがループかシーケンスかの違いね。
この当たりって専門学校でも普通(一般教養の観点で基礎的)に教える分野だと思ったけど違うのかな。
演算子の数で計算量は決定しない。 演算子は最適化できる。
計算量を決定する因子は、行列の列数と行数であり、その数で決定される。
そういう認識から、16回って書いたんだけど。 >>892
だから何で16回なんだよ…
足し算は無視かよ
足し算も含めて64回だよ 行列演算って並列処理向きだよな
行と列の数が決まってて、それぞれを掛けて足すだけだし、個々の要素が他に影響も与えないから先読みもできる
SIMDとかそういう感じなんだろうけど、1っ個ずつ掛け算して足してって逐次処理でやってるわけじゃないからね
個々の要素を並列でガッと掛け算してガッと足し算するだけだから2ステップで終わる感じ?
専用プロセッサで並列処理してるから行列の要素の数とかほとんど影響なんじゃね?
まぁ、GPUじゃなくてCPU側で計算させてる所はそうじゃないだろうけど >>894
SIMDはガッと掛けてガッと足して1ステップだよ
最近GPUに搭載され始めてるテンソル用の演算器はガッと行列掛けて1ステップだよ
但しFP16に限るが 個人的には逆数などクロック数がかかる演算は
演算器を倍速で動かすなどして
スループットを1にして欲しい >>897
何がたったの1回なんだ?
>>893と>>895は俺だぞ… >>897
計算回数が1回になるってどんな数学だよ…
専用のハードウェアによってスループットが1になったって事だよ 数式として1回なのか
実装として1クロックなのか
混同しているのな バルカン。
サブミットでデバイスロストする。
泥だと比較的簡単に絵が出せたのだが、窓だと妙に落ちる個人的な印象。
怪しいのはSPIR-Vバイトコードとディスクリプタなんだが、なんでこうもエラーを返さず落ちるのか 解決しました。一応シェア
OnCreateでサーフェスを作るとデバイスロストになる様子。
終わり VulkanのVkEnumerateInstanceExtensionPropertiesって、引数のlayerNameがNULLの時は利用可能な拡張が全部返ってきて、レイヤ名を与えた時はそのレイヤが提供している拡張(レイヤが必要としている拡張ではなく)を返すで間違いない? テストすればわかること。
他機種全プラットフォームにおいて、一様に同じ挙動をする保証があるのかは知らん。
スナドラと窓で確認した限りは、そう返した、
だが、デバッグレイヤーの有効化は、コんふィグレーションに依存して、返却されるものが変わる様子。
窓だとレジストリとジェイソンのぱラメータで返却される値がかわった。
あと1.1にすると文字列がかわる。 Khronosが語る「Vulkan 1.1」。VR&AR向けAPI「OpenXR」の最新動向も
ttp://www.4gamer.net/games/293/G029343/20180330081/ >>905
kronosがレイトレーシングのAPIを出したらまた面白いな。 漸くバリカンでテキスチャマップが期待通りにできるようになりました。
それと遂にZ値(深度値の分解能問題)と戦うことになりました。
まあ射影深度を0.1から1000とかの適当な数字が悪いんだけど。 Freetype
いいね。これ
vulkanの字形機能なしの課題が完全に解決したよ。
半日でビットマップが取れた。 初心者ですが、質問です。
aを押したらソリッドが、bを押したらワイヤーフレームが描画されるようにしたんですが、
キーを押しただけでは切り替わらなくて、マウスでウインドウを動かしてやらないと切り替わらないのですが、
どこが悪いのですか?
またどうすればキーを押したでけで切り替わるようになりますか?
よろしくお願いします。 >>911
自己解決しました。
アイドルコールバックの中にglutPostRedisplay();を入れたら、キーを押しただけで切り替わるようになりました。 Khronos Vulkan Developer Day in Montreal
Date: April 30, 2018
Location: Ubisoft, 5480 Rue St-Dominique, Montreal, Quebec
Cost: Free
Sessions confirmed so far
・Overview and Vulkan 1.1 Recap ? Alon Or-bach, Samsung Electronics
・Vulkan Subgroup Functionality ? Daniel Koch, NVIDIA
・Shader Toolchain: HLSL In Vulkan ? Lei Zhang, Google
・Descriptor Indexing ? Hai Nguyen, Google
・Memory Management in Vulkan ? Jordan Logan, AMD
・Vulkan Assistant Layer and Vulkan Layer Factory ? Mark Lobodzinski, LunarG
・Porting Frostbite to Vulkan ? Nicolas Lopez and Jean-Francois Lopez, EA Motive 適当に某エミュの中のOpenGLいじってたら、いろいろ調べるのにネットに情報なさすぎわろた;; >>915
なんで全部疑問形なんだよw
みんな自信無さ過ぎw お前らVulkan使ってる?
俺は初期化だけで涙目だよ Vulkanの前にシェーダー覚える為にOpenGLやってたら
OpenGLで満足しちゃって止まってる 使ってるよ。
特定のことを複数方法があるOpenGLより解りやすい。
窓と泥のVulkanは、細かい部分で違いがある。
泥のVulkanは、スモールセット
窓のVulkanは、最大セット
震度バッファなんかでも違いがある。
泥のVulkanだと32ビット深度バッファが未対応な機種があるとか。(24ビット+ステンシル8ビットまでとか。すなどら) 久々の休みだしちょっといじってみっかなぁ
とDemoビルドしてキューブ回転させて満足しちまった
つか最小デモでプロジェクト4つもあって萎えたわ >>924
サラッとgitなめた感じだと、すごくイイと感じた、
面倒なサブバス、ディスクリプタ、描画パイプラインがキャッシュメカニズムでラップされているのか、こいつらをアプリケーションで管理しなくて済みそうなところに感動した。
需要が多いと思われるAndroid未対応。(窓のみ)
泥対応したら、確実にこれが採用されると思う。
さすがAMD 描画パイプラインといえば、何故か内のスマホだと描画パイプラインを作る所で、激しく処理時間がかかるんだよな。
シェーダが29、描画パイプラインを58
これを2セット作る部分で3分くらい握りこむ。
ちな、テクスチャ60MBとかは、1秒も掛からない。
描画できるようになれば、普通に30fpsは出る リアルタイム れンダリングの世界は、
どこまでも外部ツールによるデータ(頂点、テクスチャ)のコンパイルに行き着く。 なんか興味がなくなってきた。
Vulkanで一応は動くようになった。
・遅延レンダリング(いわゆる深度バッファシャドー)
・ボーンアニメーション
・環境反射マッピング
・レイヤ合成
・入力アタッチメント
・マルチサンプリング
なんかは、スクラッチから一通り書けるようになった。
SSAOなんかは、深度バッファの応用だから、この先はアイデアの分野にみえた。
3DCGは、レンダリングより準備段階の方が楽しそうだと思った。
ちらうら。 その中でOpenGLではできなくてVulkanならではのものってある? >>929
強いてあげれば。描画パスかな。
あとは理解の容易さ。後者のメリットはGLとは比較にならない。
今後GLが下火になるのは間違いない。
これから勉強する人間は、必ずVulkanを選ぶだろうよ。 高いと思うよ。
2016年より前のコンピュータ機器は、デスクトップのボードを除くとアンドロイドを含めて対応機種0だしね。泥の世代交代も進んでない。
泥の半数から3割が未だにAndroid 4世代。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
SHK5K VTK使ってる人いませんか?
全く話題がないし>>1でも紹介されてないしマイナーなんですかね? VTKもC++用ラッパーだよな
OpenSceneGraphとどっちがいいの? What’s New in macOS
https://developer.apple.com/macos/whats-new/
> Deprecation of OpenGL and OpenCL あちゃー、ここで独自規格にシフトして勝算あるのかね。
せめてMetalをLinuxとWindowsでも使えるようにしてくれよ。 >>942
KronosやらがSDK出すだけでAppleはなんもしないよ でもあぁあと2、3年は使えるやろ
OpenGLに依存してるアプリがたくさん残ってるうちはAppleも簡単には消せないはず みんなiPhone買わなきゃいいんだよ
特に日本人な MSと真逆でAppleはdeprecatedつったら割とソッコで消すことが多いから楽観はせん方が・・・ Appleはいつもこういうやり方だからな(笑)。
死亡。 今からならVulkanにしとくか、GPUに慣れる目的でOpenGLに触っておくかくらいじゃね
まだVulkanの日本語のチュートリアルって少ないんかな あとプラットフォームによるか
webGLでなにか作りたいならむしろVulkanだと何もできない? しれっとOpenCLもdepってるけど、これの代わりって有るのか?
OpenCL方面は疎いから分からん MetalのComputeShaderでやれってことらしいよ。OpenCLはAppleが作らせたのにね。 >>959
Metalってそんな汎用的なAPIなのかよ…
だとしても強引過ぎるだろ
Appleを嫌いになりそう Vulkanは計算用パイプラインが元からある。
あとアップルが後方互換を維持するとか、あり得ない。
切るといったら、次の機種で切る。 某3Dモデリングソフト開発がOpenGL2.0止まりだって聞いたことある。 ComputeなんたらってGPGPU用に流行ったけど、結局わざわざ別のシステムを用意しなくてもVulkanやMetalのComputeShaderを使えば事足りるということで落ち着いたのかな?
その割りにはNVIDIAはCUDAをやめるようには思えないけど さす林檎
Apple Rejects iOS App For Using MoltenVK (Vulkan Over Metal)
https://www.phoronix.com/scan.php?page=news_item&px=Apple-Rejects-iOS-MoltenVK
まあ問題となるのは非公開APIの使用らしいから嫌がらせというわけではないだろうけど マウスの位置にポリゴンを配置する方法はありますか? みつきほにゃららを背景テクスチャに貼って、その上にポリゴンを億。
2パスか3パスでいける。 MoltenVK
パッチ当てられて再びiOSでも使えるようになってた VulkanじゃなくてOpenGL 4.6でも良いの?
APIオーバーヘッド減らす拡張が標準化したって話だし
MetalとかVulkanとかD3D12上で互換レイヤー作られたら
何処でも使えるし Metalはよく知らないが、
コマンドリストが使えるか?
コンテキストやカレントがあるなら、いずれ切り捨てられると思う まだOpenGLも開発されてるんだな過去の資産もあるし使い慣れてるからな
Vulkanその他ローレベルAPIと共存で軽量化か上手いこと考えるわ ドライバ維持(サポート)とハードウェア簡易化の観点でGLが提供され続ける未来は低いだろう。
gl向けとは、ハードウェア回路の単純化に関係しないけど、ドライバ提供で重い枷を引きずり続けるのに、機能を使いきらないミドルがサポートしなければ、物理的に損失を積み重ねるハードウェアガスベテのコタに Vulkanの上にOpenGL乗せるのは難しいのかな OpenGLは公開規格だから後方互換性は原則残されるでしょ
最新ハードだけ想定してれば良いって事ではないからハードを限定できない OpenGLES1.0とOpenGLES2.0はどっちが速いですか? APIに速いも遅いも無い
強いか弱いかで言ったら2.0の方が強い Snapdragon845のZenfone5zでも3dMarkのSlingShot Extremeのスコア
VulkanよりOpenGL ES 3.1の方が高い
Vulkanドライバは最適化されてないから遅いかも、ってかいてあるけど
いつVulkanがOpenGLを越えるんだ?
対応端末が出てから結構経ってるのに
APIオーバーヘッドのテストだとVulkan早いけど
実際のゲームに近いテストだとだめって事か OpenGL ESはCPUのオーバーヘッドがそもそも少ないとKhronosの人が言ってたよ
それでもVulkanの方が遅いってのは納得行かないけど
OpenGL ES4.0とかは全てのバッファとステートをプログラマが制御出来るようにしてくれたら、もうVulkan要らない 基本OpenGL用に作ってあるものをVulkanに対応させるためにOpenGLでVulkanをラッピングするレイヤーを作ったとかかね
Vulkan流儀で構造を最適化してるわけじゃないから同等かむしろ遅くなるとか >>982
シェーダー書くより固定パイプラインのほうが速いらしいつまり1.1が最速
まあ聞話つうかネットで見ただけだからな異論あるなら好きなだけどうぞ 1じゃそもそも望む表現が出来ないんじゃ意味ないしなあ
粗い画質な分、速いとかいう理論だろ Vulkanの上でGLESをエミュレーションは出来るだろうが、GLを使う時点でマルチスレッドレンダリングは不可能になると思う。
そもそもVulkanが制定された理由は、複雑怪奇なGLの後方互換性維持に白旗を挙げたことが理由。
いずれ切り捨てられるか過去に開発したハードウェアとドライバを利用してね。
となるだけではないかな。
UEやウニティが切り捨てたら終わりだろう。 OpenGLとOpenGL ESは別物
ESはいたってシンプルなんでサポートが打ち切られるとか無い ポリゴン数増やしていくと、やたらスピード落ちるんですよね。
どうにかならないのこれ? >>990
今時ポリゴン数増やす程度で遅くならない
どうせ大量のDrawコールをしてんだろ
それを減らす >>989
泥も切り捨てる流れなのにか?
推奨はバルカンだよ。 >>990
ポリゴン数のみで遅くなるのは昔の話
参照するテクスチャが4kとか無駄なことしてるんでないの 台風24号の影響により開催を中止とさせていただきます。 ご理解の程よろしくお願いいたします。 このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 1129日 8時間 45分 57秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。