TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
Access VBA 質問スレ Part2
【統計分析】機械学習・データマイニング28
くだらないアルゴリズムを考えるスレ
くだすれDelphi(超初心者用)その57
「コンパイラ・スクリプトエンジン」相談室16
【入門】Common Lisp その11【質問よろず】
C言語相談室(上級者専用)
リーダブルコーディング技術スレ
【コメント】doxygen【コンソメ】
HSPだって

OpenGL/Vulkanスレ Part22


1 :2015/08/27 〜 最終レス :2018/09/12
クロスプラットフォームの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.sc/test/read.cgi/tech/1409581958/
== 関連スレ ==
【O3D】HTML5用 3D API WebGL 【Canvas:3D】
http://peace.2ch.sc/test/read.cgi/tech/1308761577/
OpenGL 2.0 専用スレ
http://peace.2ch.sc/test/read.cgi/tech/1126268759/

2 :
== 必読書 ==

-- 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シリーズ

3 :
== 必読書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/

4 :
 
http://wakarandouga3.blog.fc2.com/blog-entry-1202.html

エロいお姉さんwwwwwwwwwwwwwwww
 

5 :
今、点と線を描くプログラム↓を書いています

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[]内にある頂点データを使っていくつかの直線を描く関数を上のプログラムに追加したいのですが、どうすればいいでしょうか?

6 :
>>1

7 :
>>1乙!

8 :
>>5
点のはちゃんと動いてんの?だったら9割方出来てんじゃん…

9 :
>>8
はい、点の方はちゃんと動いています!
ここに線を加えようとしても上手くいかず困っています

10 :
>>9
ほとんどエスパー状態だが…LINESとLINE_STRIPの区別できてる?

11 :
>>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();

↑のように付け加えてみましたが、この書き方はだめなようです
直線を描くにはどういう書き方をすればいいのでしょう?

12 :
>>11
line_dataに2×線の数だけ座標が入ってるか?

13 :
あ、原因が分かりました
>>12も含めて見直していると型がdoubleでなくshortになっていることに気が付きました
ありがとうございました
(昨日あれだけ見直しても気付かなかったなんて・・・)

14 :
シェーダ初心者です
フラグメントシェーダで出力するベクトルはwが変わるとxyzにも影響が出るものでしょうか?

gl_FragData[2] = vec4( pos.xyz, w );

上のようにFBOを利用してテクスチャに座標情報を渡してみようと思い
フラグメントの出力に頂点シェーダから受け取ったポジションを渡して
余ったwに適当なデータを含めて試していたのですが
続く描画パスで出力結果のテクスチャを参照してwに触れずxyzのみ参照する場合でも
前の描画パスでwに設定した値が変わると最終的な描画結果が変わってしまうようで
シェーダの仕様かプログラムのバグかも分からず参ってます。

15 :
>>14
GL_BLENDがEnableになっててブレンドされてたりして

16 :
>>15
ご指摘の通りでglDisableでブレンド切ってみたら期待した結果が得られました
複数テクスチャ使う場合のブレンドの設定とかまた調べてみます ありがとうございました

17 :
Vulkanちゃんに興味あっても今のところはMantleちゃんのドキュメント見て予習してろよって状況で合ってる?

18 :
FBO使う場合にRBOかテクスチャか関連付けて使いますよね?
後から効果付けるの便利なのでテクスチャばかり使ってて
RBOってどういう時に使えばいいのか分からないのですが 上手い使い分け方とかあります?

19 :
>>18
https://www.opengl.org/wiki/Renderbuffer_Object

今後描画結果をOpenGLで使うつもりがあるならテクスチャ
そうでなければレンダーバッファ

カラーにはテクスチャを使うが
デプスにはレンダーバッファを使う事なら普通にある

テクスチャはレンダーターゲットとして使うのには最適じゃない事があるかもしれないが
レンダーバッファはレンダーターゲットとして使うのに最適なものになっているという

20 :
デプスをテクスチャにするにはES2.0だと拡張機能が必要だな

21 :
Chrome 45.0.2454.85のANGLEを使うと
Intel HD Graphicsでだけテクスチャが変になるな
昔懐かしのR5G6B5の16bitカラーテクスチャみたいな色になる
44.0.2403.157だと普通

22 :
スレタイにVulkanが入っているので質問したいのですが、
これから3Dグラフィックを独学で勉強し始める場合、
OpenGLをやった方がいいのでしょうか?それとも、
いきなりVulkanをやっても大丈夫でしょうか

別の言い方をすると、Vulkanというのは、OpenGLを使えることを
前提としているのでしょうか?それとも、新しいAPI体系なのでしょうか?

3Dグラフィックスの知識はありません。
学部レベルの数学は大丈夫です

23 :
Vulkanはまだ資料もすくないから必要がなければとっつくこともないかと
そもそお3Dの知識なしには多分キツイはず
OpenGLは覚えること多いけど、資料も多いから勉強するならこっち

24 :
>>23
ありがd
たしかに資料の多さは魅力ですね

25 :
>>23
少ないっていうか無いでしょ
有るなら見てみたいけど

26 :
Vulkan対応ドライバやOSがまだそもそも出てなくね?

27 :
仕様もまだ正式に出てない

28 :
製品出始めて暫くはドライバの問題で地獄だろうしな
特にモバイル

29 :
Vulkanは薄いレイヤーだからドライバに優しい仕様だ
OpenGLドライバよりは楽だろう

30 :
その分ハードウェアの癖が出やすくなったりしないのかね
ま、どうせチューニングせざるを得ないなら薄いほうが良いな

31 :
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

>>30
OpenGLみたいにぶ厚い方が
ドライバ依存の部分が多くなって予測不可能な動作をしやすい気がするが

32 :
異なるハードウェアの差異はOpenGLのレイヤーで吸収
それ以上に低層で扱いたい場合はVulkan

33 :
>>31
自分が当たったのは

Adreno 205でdiscardの後にtexture使うとOSごとクラッシュ

Adreno320でUBOの変数をそのまま計算に使用するとshaderコンパイル時にアプリクラッシュ(なぜか一時変数に代入してから使用するとクラッシュしない)

Adrenoはエラーログ出さずにすぐ死ぬからマジでデバッグが地獄
しかも今Androidで一番使われてるシリーズ

ほかはここに色々
ttp://cpplover.blogspot.jp/2013/09/dolphinopengl.html?m=1

薄かろうがAdrenoがまともなドライバを作れるとは思えない

34 :
>>33
その駄目AMDがいまやPC系のOpenGLでは最も安定動作し性能が良いんだからな
おかげでOpenCLのスタンダードになり、そして、Vulkanを後続規格に出来たんだからな

35 :
>>34
Adrenoは元AMD(ATI)でしょ
今はQualcommが作ってる
Qualcommはドライバーを軽視してる感がある

36 :
>>35
性能はいいけど・・・って感じだよね、
nVIdiaとVulkanはMantle的に相性は悪いがそれでも今のスマホGPUよりかはよっぽどましな挙動をすると思う

37 :
しかもモバイルのドライバ更新されないからな
Nexus5使ってるけどOSの更新はされてるけどドライバのバグずっとそのまま
まぁ、AndroidはOSの更新すらされないデバイスだらけだから一部の端末だけ更新されて新たなバグ埋め込まれても困るけど

38 :
Vulkanはドライバーがシェーダーをコンパイルする必要がないから
それだけでも安定性は増すはず
それとkhronos自体がデバッグしやすくする為のツールを作ったりしてるから期待できる
当然GPUの状態を取得する為のAPIも追加されてるはず
あとドライバがアプリが想定しているバージョンより古いと自動的にダウンロードして
更新するみたいな事をするとチラッと見た

39 :
https://www.khronos.org/assets/uploads/developers/library/2015-cedec/Vulkan-CEDEC2015-DMP_Aug15.pdf
VulkanのOverviewが日本語に翻訳されてた
しかもVulkanAPIの解説付きだからこれでVulkanの全貌が把握出来る

40 :
ドキュメント読むとハードルめちゃ高いなー
早くVulkanのプログラムしたいけどGPUも買い換えないといけないのかなぁ…
NVIDIAだけど既存のGPUもサポートしてくれる事を祈る

41 :
>>40
自前で組む分にはハードルが高いが
実際は有志から出された物やドライバのレイヤーを使って組むことが多いと思う

42 :
http://peace.2ch.sc/test/read.cgi/tech/1440666771/39
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と相性悪そうな気がする

43 :
誤爆

44 :
テクスチャフォーマットについて
2Dで表示するものは各8bitのRGBA(アルファ不要ならRGB)
3Dや多少の見た目の劣化が許容できるものはDXT1,3,5
こんな感じの使い分けがベターだと思ってるんだけど
詳しく解説されてるの見たことがないのでより良い選択肢があれば教えて欲しい

45 :
補足
動作環境はwindowsのデスクトップPCを想定してます

46 :
>>44
αの扱いによってDXT1〜5を選択するだけで素のRGBAは有り得ない

47 :
>>46
遅レスだけど返答ありがとう
劣化が気になることもあるけどDXT主体で使い分けてみるよ

48 :
openglでMMD表示してみたけどこれは落胆
http://i.imgur.com/6XSVauj.png
http://i.imgur.com/DCk9pII.png

49 :
MMDはアプリだから表示なんかできないと思うんだが…
openglで表示してみた、というのは自分で何かopenglのプログラムを作ったという事かな?
だとすると表示が落胆ものなのは、完全に>>48 自信のスキルがアレなせいだと思う

50 :
>>48
二枚目って自作?
とりあえず続きはブログでやってくれ

51 :
なぜかあにまさ式だとうまくできました、
ブログはHTMLが面倒なのでげ製作でやっときます

52 :
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

53 :
Lat式は表示方法自体がMMDデフォの描画プロセスを完全再現しないと
とんでもない事になる特殊なモデリングだから仕方なし

54 :
2D描画をステート変更無しで高速に行えて
少し古い環境でも動くのってTexture Atlasだけ?

ES3の2D Array Textureって同じサイズのテクスチャじゃないと駄目みたいだし
代わりになりそうなのはBindless Textureだけど普及してないし
当分Texture Atlasを使うしかなさそう

55 :
Texture Atlasの手法だと色が混ざっちゃうからミップマッピング出来ないのだけ不便

56 :
2D描画でミップマップなんて使わないだろ
奥行きがある多重スクロールとかかよ

57 :
マップチップ的なものならES3.0が使えるならArray Textureでいけるし
無くても1/4までなら画質は大丈夫
それ以外は諦める

58 :
同じシーンを描画し続けてて急に負荷が高くなる場合ってどんなところ疑うべき?
起動して10秒くらいまでは軽いんだけど、突然重くなってその状態を維持し続けるっていう…
ごちゃごちゃになってるプログラム整理しながら間違い探してるんだけどWGLとかシェーダとか色々初体験でどこが悪いやら…

59 :
多分、色々と食い潰してる。
どうでもいいが「重い」とか言っときながら、まさかプロセスやリソースの状態も
調べてないとか言い出すなよ?

60 :
リッチなデバッガ、プロファイラのある環境で作ってEmscriptenで変換

61 :
あ、WGLってWebGLじゃなくてWinGLの事か。

62 :
>>59
デバッグ用の拡張命令とかも調べつつなんでお察しください…
>>60
JavaScriptとかよく分からないんだけど…C++コード弄るの飽きたら試してみるわ
>>61
不安になってググってみたらWinGLもなんか違うな…wglCreateContext関数とか使うやつだわ

63 :
最近のVisual Studioは無料版でもプロファイラが付いているからまずそれを使う
後はOpenGLデバッガのgDEBuggerを使うとか

>>62
それがWGLでしょう。

64 :
これとは無関係
てか普通WGLをWinGLって書く奴は見たことねえ

Windows ゲーム作成用ライブラリ for Win16/32
http://www.vector.co.jp/soft/win31/prog/se028202.html

65 :
>>63
VSのプロファイラは使ってるけどgDEBuggerってのは使ってなかったので試してみるよ ありがとう

66 :
WindowsでOpenGLするならNVIDIAだよな?
AMDは使ってないから分からんが多分大丈夫だろうけど
IntelのWindows用OpenGLドライバは腐ってる

67 :
腐ってるとこを上手に避けでも駄目なの?

68 :
どこが腐っているか分かるのであればどうぞ

69 :
>>66
昔はNvidiaだったが、いまやOpenGL・OpenCLのデファクトVGAはATI
Win/Linuxで安定度・性能がNvidiaよりずっと上

70 :
Vulkanのことを考えるとATIAMD一択

71 :
なんか有利あんだっけ?

72 :
AMDのMantleが元になってるからな。
これでAMDが負けたら日本人が日本語クイズでアメリカ人に負けるようなもの

73 :
Vulkanは超シンプルなAPIだからハード性能がダイレクトに効いてくる
当然AMDのハードが良かったらVulkanで勝てるだろうが別に有利不利とかはない

74 :
文字列をテクスチャに描画するのにFBOを使っていたんだが
PCだと爆速なのにAndroid機 (Snapdragon 801)だと10〜20個ぐらいでもう60fps出せないぐらい遅かった

CPUで画像をコピーするのを避けていたんだが、FBOの切り替えやその他のレンダリングステートの変更、ドローコールが思ったより高価だったようだ

テクスチャを通さず画面に直接描けばそんな遅くないかもしれないが
設計的にそうも行かない事情があった

これはCPU側で全てテクスチャに使う画像を作って送るしかないんだろうか

75 :
PowerVR系のTBDRが文字描画と相性が悪いというのは有名だけど
Snapdragon(Adreno)だと何だろうね

そのうちフォントのラスタライズもGPUで行う時代になるのかね
ラスタライザの実装自体は難しくないとしても
結局フォントデータが日本語だと1書体で数MB〜数十MBだからなぁ

76 :
Android機なんてPCの10分の1程度の性能なんだからそんなもんだろ

77 :
言いたいことは分かるがAndroidとPCて比較できる関係にないだろ
それにデスクトップPCの時代は過ぎたし

78 :
OpenGL ESはデスクトップで動くんだから完全に比較できるでしょ
あとデスクトップPCの時代が過ぎたって意味が分からん
Steamの同時接続ユーザー数がピーク時に1150万人以上を記録とか言ってるし
むしろ増え続けてる

79 :
日本ではPCは終わってるかもね。
いや、始まってすらいないか。
PC使えない老害と新卒新入社員が問題になる国だもんな。

80 :
問題って…どんだけネットに洗脳されてんだ…
仕事がPCが出来る出来ないだけで方が付くんであれば楽なもんだな

81 :
こんな事書いてあるけど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.

82 :
コマンドが戻って来る来ないってのがよく分からないけど
処理が遅くなるって事なら前のコマンドが解決されてなかったりすれば後のコマンドもその分待たされるんじゃないの?

83 :
>>78
そうじゃなく泥タブだってPCといえばPCだしPCの定義って何って話
MacはPCじゃないらしいけどな

Steamのユーザ数とデスクトップPCのシェアは別だよね
それにIntelHDユーザがどれだけいることか

84 :
スマホから見ればPCはすべてを導いてくれる神様なんだからPC使えないんだったら黙って崇めとけ

85 :
>>81
戻ってこないなんて書いてあるか?
ChromeとかブラウザのWindows版は全部WebGL(OpenGL)→DirectXに変換して実行してるから
その為に一旦自前のコマンドバッファに溜め込んでるよって事でしょ

その自前のコマンドバッファはマルチコア対応だから軽いよって書いてある
実際ANGLE使わずにOpenGLを直に使うようにするとCPU負荷が少し増える

86 :
別にANGLE限定とは書いてない
互換性やセキュリティの問題はWindows以外でも存在するし

複数のスレッドから直接OpenGLのAPIを呼ぶより
アプリ側でAPIコールを纏めて一つのスレッドから呼んだ方が速いとされているのだが
実際にどの程度速度が変わるのかは分からない
ドライバ実装によっても変わるかもしれない

87 :
よく見たらWebGLの話しではなかったな…
HTMLレンダラーとかGPU使って描画する時の話しだったな

そもそもOpenGLはマルチスレッドに対応してないから複数スレッドからAPIをコール出来ない
複数スレッドからDrawコールをしたい場合は自前のコマンドバッファが必須だな

88 :
>>87
別にWebGLでは使ってないとは書いてないけど

プロセス毎にOpenGLコンテキストを作ればマルチスレッドでも使えるだろうが
それだと遅かったのだろう

89 :
質問させてください。

100 millions個以上の三角形ポリゴンを60fpsで描画したいのですが
一番いいソフトウェア上の組み合わせって何でしょうか。

Windows10(64bit),,GTX750TI,i5,
VS2010で64bitビルド,freeglut2.8
描画にPBO用いてglDrawElements利用

で試したのですが,25 millions個の三角形メッシュで<1FPS程度です。
どうもfreeglutはGDI用いていてそれがボトルネックになっている気がしています。
レス読む限りWGLで書いていくのがよさそうな気がしましたがお知恵下さい。

90 :
>>89
なってません

91 :
まともなエンジニアなら
ソフトウェアの組み合わせの前に
100 millions個以上の三角形ポリゴンを
60fpsで描画しないで済む方法を検討すると思うが

要件をはっきりさせるべき

92 :
>100 millions個以上の三角形ポリゴンを
>61fpsで描画しないで済む方法を検討すると思うが

要件は100 millions個以上の三角形ポリゴンを 60fps以上でです
これを回避出来ないか答えられません。済みませんが

93 :
どんな解像度でレンダリングしようとしてんのかしらんけど8Kディスプレイでもピクセル数3300万だぞ
1億ポリゴンのうちどれだけ描画されるのか考えた?
その要件が絶対というならそのバカな要件を精々頑張ってくれ

94 :
ま、タキオン粒子の研究でもした方が良さそうだね

95 :
クラスター化したりGPU積むなりして分散レンダリング、通信して集めて重畳するくらいかね

96 :
すみません、普段MAX/MSP以外のプログラミングには全然疎くて
それでMAXでOpenGLを使うときの質問なのですが

nurbs曲線を引きたいんです。

そこでjit.gl.nurbsオブジェクトで、曲面でなく曲線を描きたいのですが、
制御点(のx,y,z座標)を予め設定するには、どうしたらいいですか?

ググっても殆ど出てこないし、ネット上のチュートリアルには
jit.gl.nurbsの使い方なんて載ってません。

ヘルプを見ても、どうも最初に設定している様子もないので、困っています。
どなたか助けてください・・・

97 :
DTM板のMAXスレとマルチですみません。

98 :
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.

99 :
>>98
想像だけど1回までにしろといってるのはFBOをアンバインドする時に
そのFBOに対する描画が全部完了するまでブロックが発生したりするからだと思われる
だからglCleare()で使い回すのはパフォーマンスは低下しないでしょ
ただ別にFBO作った方が速いだろうね (レンダリングが並列に実行されるだろうから)

100 :
>クラスター化したりGPU積むなりして分散レンダリング、通信して集めて重畳するくらいかね
これいいですね アイデア頂きです


100〜のスレッドの続きを読む
Xamarin Part6
【Intel】OpenCV総合スレ 5画素目【画像処理】
オナオナ開発プロジェクト
プログラミングを勉強したいのだが
【Java】Wicket【HTML】
Perlについての質問箱 64箱目
Pythonのお勉強 Part60
a4です。P2P人工知能「T」開発。
生産性が低いC++で頑張るために必要な知識
OSSホスティング総合【SourceForge,GitHub,etc..】
--------------------
【不動産】練炭自殺の現場にマンションを建てたらやっぱりヤバかった 大島てるが語る“あるオーナーの悲劇” ★2
【恥】米マイクロソフトのクラインCFO、退任を発表
【名無し奥も○○奥も】気楽に井戸端会議6189【みんな来い】
【アズレン】アズールレーン Part4511
【TBS日曜劇場】ドラマ版この世界の片隅にツッコミを入れずにはおられん人らのスレ 1
アベノミクス修羅場 無限空売りが日本経済を襲う
【新星】シャルル・ピック Lap1【シャル】
【社会】コラムニスト・プチ鹿島氏「旭日旗は日本では広く使われていると言っても嫌な気持ちになる人もいる」[9/17]
【ロッテ】ビックリマンシール総合スレ【98】
捏造別館BBAオチスレ☆11
100日後に死ぬルビィちゃん 2
禁煙スレ
無職毒男1945
【作曲】飯塚昌明3.1曲目【編曲】
ニュース女子実況 【YouTubeライブ・ニコニコ生放送・FRESH LIVE 月曜22:00】 #66
【ゆめいっぱい】ちびまる子ちゃん 三人目
中央精版印刷って?
【ヒロミ】1or8のロケット花火【発射】
【復活】科学究明機構ロヂカ?【希望】
アローと相手にされないJBCについて語ろう
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼