5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

OpenGL/Vulkanスレ Part22©2ch.net

1 :デフォルトの名無しさん 転載ダメ©2ch.net:2015/08/27(木) 18:12:51.54 ID:VxmGCqDu
クロスプラットフォームの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/

2 :デフォルトの名無しさん:2015/08/27(木) 18:13:59.79 ID:Ifj661nZ
== 必読書 ==

-- 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 :デフォルトの名無しさん:2015/08/27(木) 18:14:34.65 ID:Ifj661nZ
== 必読書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 :デフォルトの名無しさん:2015/08/27(木) 18:43:34.00 ID:N4V/w5+H
 
http://wakarandouga3.blog.fc2.com/blog-entry-1202.html

エロいお姉さんwwwwwwwwwwwwwwww
 

5 :デフォルトの名無しさん:2015/08/28(金) 00:40:51.72 ID:J/FclS9C
今、点と線を描くプログラム↓を書いています

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 :デフォルトの名無しさん:2015/08/28(金) 02:07:15.11 ID:Ev5A+taN
>>1

7 :デフォルトの名無しさん:2015/08/28(金) 11:34:06.01 ID:1j3Jp4TC
>>1乙!

8 :デフォルトの名無しさん:2015/08/28(金) 12:42:16.17 ID:PU1M3ZK/
>>5
点のはちゃんと動いてんの?だったら9割方出来てんじゃん…

9 :デフォルトの名無しさん:2015/08/28(金) 15:20:19.68 ID:J/FclS9C
>>8
はい、点の方はちゃんと動いています!
ここに線を加えようとしても上手くいかず困っています

10 :デフォルトの名無しさん:2015/08/28(金) 18:33:28.46 ID:PU1M3ZK/
>>9
ほとんどエスパー状態だが…LINESとLINE_STRIPの区別できてる?

11 :デフォルトの名無しさん:2015/08/28(金) 20:15:55.51 ID:J/FclS9C
>>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 :デフォルトの名無しさん:2015/08/28(金) 20:24:29.73 ID:PU1M3ZK/
>>11
line_dataに2×線の数だけ座標が入ってるか?

13 :デフォルトの名無しさん:2015/08/28(金) 20:40:54.15 ID:J/FclS9C
あ、原因が分かりました
>>12も含めて見直していると型がdoubleでなくshortになっていることに気が付きました
ありがとうございました
(昨日あれだけ見直しても気付かなかったなんて・・・)

14 :デフォルトの名無しさん:2015/09/03(木) 01:28:36.62 ID:NZelf7lm
シェーダ初心者です
フラグメントシェーダで出力するベクトルはwが変わるとxyzにも影響が出るものでしょうか?

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

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

15 :デフォルトの名無しさん:2015/09/03(木) 01:58:45.78 ID:7WrobgbO
>>14
GL_BLENDがEnableになっててブレンドされてたりして

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

17 :デフォルトの名無しさん:2015/09/07(月) 23:59:15.25 ID:zlL3a7qU
FBO使う場合にRBOかテクスチャか関連付けて使いますよね?
後から効果付けるの便利なのでテクスチャばかり使ってて
RBOってどういう時に使えばいいのか分からないのですが 上手い使い分け方とかあります?

18 :デフォルトの名無しさん:2015/09/11(金) 11:35:53.77 ID:fr07wZLl
>>17
https://www.opengl.org/wiki/Renderbuffer_Object

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

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

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

19 :デフォルトの名無しさん:2015/09/11(金) 14:22:16.05 ID:jg8fOB+V
デプスをテクスチャにするにはES2.0だと拡張機能が必要だな

20 :デフォルトの名無しさん:2015/09/12(土) 15:22:12.26 ID:HMzU4nPJ
Chrome 45.0.2454.85のANGLEを使うと
Intel HD Graphicsでだけテクスチャが変になるな
昔懐かしのR5G6B5の16bitカラーテクスチャみたいな色になる
44.0.2403.157だと普通

21 :デフォルトの名無しさん:2015/09/14(月) 19:52:48.19 ID:nW8KHDe7
スレタイにVulkanが入っているので質問したいのですが、
これから3Dグラフィックを独学で勉強し始める場合、
OpenGLをやった方がいいのでしょうか?それとも、
いきなりVulkanをやっても大丈夫でしょうか

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

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

22 :デフォルトの名無しさん:2015/09/14(月) 20:00:27.33 ID:ni7Sx5as
Vulkanはまだ資料もすくないから必要がなければとっつくこともないかと
そもそお3Dの知識なしには多分キツイはず
OpenGLは覚えること多いけど、資料も多いから勉強するならこっち

23 :デフォルトの名無しさん:2015/09/14(月) 20:17:07.23 ID:nW8KHDe7
>>22
ありがd
たしかに資料の多さは魅力ですね

24 :デフォルトの名無しさん:2015/09/14(月) 20:36:34.75 ID:AlOlEiNV
>>22
少ないっていうか無いでしょ
有るなら見てみたいけど

25 :デフォルトの名無しさん:2015/09/15(火) 23:37:01.54 ID:iBP99bbY
Vulkan対応ドライバやOSがまだそもそも出てなくね?

26 :デフォルトの名無しさん:2015/09/16(水) 02:04:27.03 ID:JciVp4Nw
仕様もまだ正式に出てない

27 :デフォルトの名無しさん:2015/09/19(土) 18:56:08.54 ID:YQpUAMED
製品出始めて暫くはドライバの問題で地獄だろうしな
特にモバイル

28 :デフォルトの名無しさん:2015/09/19(土) 20:00:14.04 ID:DcCV9f4N
Vulkanは薄いレイヤーだからドライバに優しい仕様だ
OpenGLドライバよりは楽だろう

29 :デフォルトの名無しさん:2015/09/20(日) 10:17:29.98 ID:ppyDSJna
その分ハードウェアの癖が出やすくなったりしないのかね
ま、どうせチューニングせざるを得ないなら薄いほうが良いな

30 :デフォルトの名無しさん:2015/09/20(日) 11:37:36.41 ID:W0H8rt0f
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みたいにぶ厚い方が
ドライバ依存の部分が多くなって予測不可能な動作をしやすい気がするが

31 :デフォルトの名無しさん:2015/09/20(日) 12:34:08.41 ID:9sOZdp6w
異なるハードウェアの差異はOpenGLのレイヤーで吸収
それ以上に低層で扱いたい場合はVulkan

32 :デフォルトの名無しさん:2015/09/20(日) 14:57:05.05 ID:LJD7mjJ9
>>30
自分が当たったのは

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

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

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

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

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

33 :デフォルトの名無しさん:2015/09/21(月) 00:42:42.41 ID:Kj2opw9V
>>32
その駄目AMDがいまやPC系のOpenGLでは最も安定動作し性能が良いんだからな
おかげでOpenCLのスタンダードになり、そして、Vulkanを後続規格に出来たんだからな

34 :デフォルトの名無しさん:2015/09/21(月) 01:27:50.66 ID:xJnGLVr2
>>33
Adrenoは元AMD(ATI)でしょ
今はQualcommが作ってる
Qualcommはドライバーを軽視してる感がある

35 :デフォルトの名無しさん:2015/09/21(月) 06:53:50.45 ID:14VyAGI9
>>34
性能はいいけど・・・って感じだよね、
nVIdiaとVulkanはMantle的に相性は悪いがそれでも今のスマホGPUよりかはよっぽどましな挙動をすると思う

36 :デフォルトの名無しさん:2015/09/21(月) 19:09:44.31 ID:0lL32CsL
しかもモバイルのドライバ更新されないからな
Nexus5使ってるけどOSの更新はされてるけどドライバのバグずっとそのまま
まぁ、AndroidはOSの更新すらされないデバイスだらけだから一部の端末だけ更新されて新たなバグ埋め込まれても困るけど

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

38 :デフォルトの名無しさん:2015/09/24(木) 00:46:56.91 ID:r/3RmciX
https://www.khronos.org/assets/uploads/developers/library/2015-cedec/Vulkan-CEDEC2015-DMP_Aug15.pdf
VulkanのOverviewが日本語に翻訳されてた
しかもVulkanAPIの解説付きだからこれでVulkanの全貌が把握出来る

39 :デフォルトの名無しさん:2015/09/24(木) 01:10:48.32 ID:r/3RmciX
ドキュメント読むとハードルめちゃ高いなー
早くVulkanのプログラムしたいけどGPUも買い換えないといけないのかなぁ…
NVIDIAだけど既存のGPUもサポートしてくれる事を祈る

40 :デフォルトの名無しさん:2015/09/24(木) 02:47:19.21 ID:F12mSHo9
>>39
自前で組む分にはハードルが高いが
実際は有志から出された物やドライバのレイヤーを使って組むことが多いと思う

41 :デフォルトの名無しさん:2015/09/24(木) 02:52:10.66 ID:F12mSHo9
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と相性悪そうな気がする

42 :デフォルトの名無しさん:2015/09/24(木) 02:52:42.00 ID:F12mSHo9
誤爆

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

44 :43:2015/09/27(日) 17:20:16.60 ID:UvPGCZi1
補足
動作環境はwindowsのデスクトップPCを想定してます

45 :デフォルトの名無しさん:2015/09/27(日) 23:51:56.33 ID:hiI0CHA6
>>43
αの扱いによってDXT1〜5を選択するだけで素のRGBAは有り得ない

46 :43:2015/09/29(火) 00:37:27.42 ID:VYlPl96E
>>45
遅レスだけど返答ありがとう
劣化が気になることもあるけどDXT主体で使い分けてみるよ

47 :デフォルトの名無しさん:2015/10/16(金) 10:10:43.89 ID:JZSeEXRz
openglでMMD表示してみたけどこれは落胆
http://i.imgur.com/6XSVauj.png
http://i.imgur.com/DCk9pII.png

48 :デフォルトの名無しさん:2015/10/16(金) 10:32:49.32 ID:l04muiBk
MMDはアプリだから表示なんかできないと思うんだが…
openglで表示してみた、というのは自分で何かopenglのプログラムを作ったという事かな?
だとすると表示が落胆ものなのは、完全に>>47 自信のスキルがアレなせいだと思う

49 :デフォルトの名無しさん:2015/10/16(金) 10:38:04.32 ID:+fJvXx/R
>>47
二枚目って自作?
とりあえず続きはブログでやってくれ

50 :デフォルトの名無しさん:2015/10/17(土) 09:57:29.33 ID:o8rjpUAD
なぜかあにまさ式だとうまくできました、
ブログはHTMLが面倒なのでげ製作でやっときます

51 :デフォルトの名無しさん:2015/10/23(金) 09:31:24.55 ID:I0uni5nx
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

52 :デフォルトの名無しさん:2015/10/23(金) 14:20:58.65 ID:M7dNli7I
Lat式は表示方法自体がMMDデフォの描画プロセスを完全再現しないと
とんでもない事になる特殊なモデリングだから仕方なし

53 :デフォルトの名無しさん:2015/10/25(日) 13:13:26.63 ID:vAKl7Lz8
2D描画をステート変更無しで高速に行えて
少し古い環境でも動くのってTexture Atlasだけ?

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

54 :デフォルトの名無しさん:2015/10/25(日) 13:14:32.16 ID:vAKl7Lz8
Texture Atlasの手法だと色が混ざっちゃうからミップマッピング出来ないのだけ不便

55 :デフォルトの名無しさん:2015/10/25(日) 15:10:32.81 ID:MYRFLLoW
2D描画でミップマップなんて使わないだろ
奥行きがある多重スクロールとかかよ

56 :デフォルトの名無しさん:2015/10/26(月) 19:03:55.27 ID:NExmEVH8
マップチップ的なものならES3.0が使えるならArray Textureでいけるし
無くても1/4までなら画質は大丈夫
それ以外は諦める

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

58 :デフォルトの名無しさん:2015/10/26(月) 23:38:52.89 ID:2nnyXhaR
多分、色々と食い潰してる。
どうでもいいが「重い」とか言っときながら、まさかプロセスやリソースの状態も
調べてないとか言い出すなよ?

59 :デフォルトの名無しさん:2015/10/26(月) 23:48:03.22 ID:yMfxLlxA
リッチなデバッガ、プロファイラのある環境で作ってEmscriptenで変換

60 :デフォルトの名無しさん:2015/10/26(月) 23:51:14.09 ID:U+ZA45+s
あ、WGLってWebGLじゃなくてWinGLの事か。

61 :デフォルトの名無しさん:2015/10/27(火) 00:20:29.74 ID:MDUv4Uu+
>>58
デバッグ用の拡張命令とかも調べつつなんでお察しください…
>>59
JavaScriptとかよく分からないんだけど…C++コード弄るの飽きたら試してみるわ
>>60
不安になってググってみたらWinGLもなんか違うな…wglCreateContext関数とか使うやつだわ

62 :デフォルトの名無しさん:2015/10/27(火) 00:46:01.74 ID:XDD7LrKE
最近のVisual Studioは無料版でもプロファイラが付いているからまずそれを使う
後はOpenGLデバッガのgDEBuggerを使うとか

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

63 :デフォルトの名無しさん:2015/10/27(火) 00:48:11.27 ID:XDD7LrKE
これとは無関係
てか普通WGLをWinGLって書く奴は見たことねえ

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

64 :57:2015/10/27(火) 02:09:35.31 ID:MDUv4Uu+
>>62
VSのプロファイラは使ってるけどgDEBuggerってのは使ってなかったので試してみるよ ありがとう

65 :デフォルトの名無しさん:2015/10/27(火) 11:55:48.66 ID:to74HYda
WindowsでOpenGLするならNVIDIAだよな?
AMDは使ってないから分からんが多分大丈夫だろうけど
IntelのWindows用OpenGLドライバは腐ってる

66 :デフォルトの名無しさん:2015/10/27(火) 13:15:44.86 ID:gPvV5cn8
腐ってるとこを上手に避けでも駄目なの?

67 :デフォルトの名無しさん:2015/10/27(火) 13:47:32.50 ID:S+IQphBI
どこが腐っているか分かるのであればどうぞ

68 :デフォルトの名無しさん:2015/10/28(水) 21:53:41.91 ID:gVmYV2et
>>65
昔はNvidiaだったが、いまやOpenGL・OpenCLのデファクトVGAはATI
Win/Linuxで安定度・性能がNvidiaよりずっと上

69 :デフォルトの名無しさん:2015/10/29(木) 20:41:18.37 ID:5gekmfvH
Vulkanのことを考えるとATIAMD一択

70 :デフォルトの名無しさん:2015/10/29(木) 20:49:56.74 ID:FU1wYuSd
なんか有利あんだっけ?

71 :デフォルトの名無しさん:2015/10/29(木) 20:54:28.65 ID:M5LgoQD5
AMDのMantleが元になってるからな。
これでAMDが負けたら日本人が日本語クイズでアメリカ人に負けるようなもの

72 :デフォルトの名無しさん:2015/10/30(金) 09:47:52.19 ID:KICymkbE
Vulkanは超シンプルなAPIだからハード性能がダイレクトに効いてくる
当然AMDのハードが良かったらVulkanで勝てるだろうが別に有利不利とかはない

73 :デフォルトの名無しさん:2015/10/30(金) 19:15:23.10 ID:kIMI498u
文字列をテクスチャに描画するのにFBOを使っていたんだが
PCだと爆速なのにAndroid機 (Snapdragon 801)だと10〜20個ぐらいでもう60fps出せないぐらい遅かった

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

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

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

74 :デフォルトの名無しさん:2015/10/30(金) 23:18:37.32 ID:RKkoxr6k
PowerVR系のTBDRが文字描画と相性が悪いというのは有名だけど
Snapdragon(Adreno)だと何だろうね

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

75 :デフォルトの名無しさん:2015/10/31(土) 10:55:57.04 ID:InQpe4ua
Android機なんてPCの10分の1程度の性能なんだからそんなもんだろ

76 :デフォルトの名無しさん:2015/10/31(土) 12:10:59.00 ID:8Bda5lAI
言いたいことは分かるがAndroidとPCて比較できる関係にないだろ
それにデスクトップPCの時代は過ぎたし

77 :デフォルトの名無しさん:2015/10/31(土) 12:39:03.93 ID:InQpe4ua
OpenGL ESはデスクトップで動くんだから完全に比較できるでしょ
あとデスクトップPCの時代が過ぎたって意味が分からん
Steamの同時接続ユーザー数がピーク時に1150万人以上を記録とか言ってるし
むしろ増え続けてる

78 :デフォルトの名無しさん:2015/10/31(土) 12:43:38.96 ID:uu+i9WLB
日本ではPCは終わってるかもね。
いや、始まってすらいないか。
PC使えない老害と新卒新入社員が問題になる国だもんな。

79 :デフォルトの名無しさん:2015/10/31(土) 14:54:45.53 ID:InQpe4ua
問題って…どんだけネットに洗脳されてんだ…
仕事がPCが出来る出来ないだけで方が付くんであれば楽なもんだな

80 :デフォルトの名無しさん:2015/10/31(土) 18:10:18.47 ID:2qMna6cK
こんな事書いてあるけど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.

81 :デフォルトの名無しさん:2015/10/31(土) 19:11:13.20 ID:ylRFVIHZ
コマンドが戻って来る来ないってのがよく分からないけど
処理が遅くなるって事なら前のコマンドが解決されてなかったりすれば後のコマンドもその分待たされるんじゃないの?

82 :デフォルトの名無しさん:2015/10/31(土) 19:40:24.93 ID:8Bda5lAI
>>77
そうじゃなく泥タブだってPCといえばPCだしPCの定義って何って話
MacはPCじゃないらしいけどな

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

83 :デフォルトの名無しさん:2015/11/01(日) 02:26:33.11 ID:Pwz2JCQ5
スマホから見ればPCはすべてを導いてくれる神様なんだからPC使えないんだったら黙って崇めとけ

84 :デフォルトの名無しさん:2015/11/03(火) 14:21:40.06 ID:V53UaXPp
>>80
戻ってこないなんて書いてあるか?
ChromeとかブラウザのWindows版は全部WebGL(OpenGL)→DirectXに変換して実行してるから
その為に一旦自前のコマンドバッファに溜め込んでるよって事でしょ

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

85 :デフォルトの名無しさん:2015/11/03(火) 23:10:42.25 ID:ltuo8JAD
別にANGLE限定とは書いてない
互換性やセキュリティの問題はWindows以外でも存在するし

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

86 :デフォルトの名無しさん:2015/11/04(水) 11:22:45.65 ID:4VARUgDB
よく見たらWebGLの話しではなかったな…
HTMLレンダラーとかGPU使って描画する時の話しだったな

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

87 :デフォルトの名無しさん:2015/11/04(水) 13:18:18.56 ID:3HqGJBgB
>>86
別にWebGLでは使ってないとは書いてないけど

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

88 :デフォルトの名無しさん:2015/11/08(日) 18:44:22.99 ID:POF/ID6D
質問させてください。

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

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

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

89 :デフォルトの名無しさん:2015/11/08(日) 19:25:23.39 ID:m4MzXsh9
>>88
なってません

90 :デフォルトの名無しさん:2015/11/08(日) 20:18:26.44 ID:WIQI5dDH
まともなエンジニアなら
ソフトウェアの組み合わせの前に
100 millions個以上の三角形ポリゴンを
60fpsで描画しないで済む方法を検討すると思うが

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

91 :デフォルトの名無しさん:2015/11/08(日) 22:02:27.62 ID:1RMtYxbs
>100 millions個以上の三角形ポリゴンを
>60fpsで描画しないで済む方法を検討すると思うが

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

92 :デフォルトの名無しさん:2015/11/08(日) 22:41:34.77 ID:m4MzXsh9
どんな解像度でレンダリングしようとしてんのかしらんけど8Kディスプレイでもピクセル数3300万だぞ
1億ポリゴンのうちどれだけ描画されるのか考えた?
その要件が絶対というならそのバカな要件を精々頑張ってくれ

93 :デフォルトの名無しさん:2015/11/08(日) 23:20:50.59 ID:15p3122r
ま、タキオン粒子の研究でもした方が良さそうだね

94 :デフォルトの名無しさん:2015/11/09(月) 00:18:42.73 ID:qCcvicZl
クラスター化したりGPU積むなりして分散レンダリング、通信して集めて重畳するくらいかね

95 :デフォルトの名無しさん:2015/11/09(月) 03:37:54.95 ID:e9NKrZa6
すみません、普段MAX/MSP以外のプログラミングには全然疎くて
それでMAXでOpenGLを使うときの質問なのですが

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

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

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

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

96 :デフォルトの名無しさん:2015/11/09(月) 03:41:04.72 ID:e9NKrZa6
DTM板のMAXスレとマルチですみません。

97 :デフォルトの名無しさん:2015/11/09(月) 17:34:15.03 ID:SvTFDp+i
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.

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

99 :デフォルトの名無しさん:2015/11/09(月) 23:02:58.43 ID:2GPWptLo
>クラスター化したりGPU積むなりして分散レンダリング、通信して集めて重畳するくらいかね
これいいですね アイデア頂きです

100 :デフォルトの名無しさん:2015/11/10(火) 16:16:41.90 ID:HB2gwhXV
分散レンダリングで60fpsを目指すとかさすがだな

101 :デフォルトの名無しさん:2015/11/11(水) 00:08:45.71 ID:7FoGAeK2
技術的課題がたくさんあって燃えますね

102 :デフォルトの名無しさん:2015/11/11(水) 13:18:34.30 ID:OiFKTRuj
レイテンシ問わないならあるいは……
でも並列化が可能なデータなら
クラスタ化の前にできることがあるような……

103 :デフォルトの名無しさん:2015/11/16(月) 11:45:42.10 ID:69xbdtCO
ディファードレンダリングにして各GPUにどのタイルをレンダリングするかを
割り当てれば割と簡単に分散は出来そうだな
ただ頂点処理はかなり重複する事になるから多ポリゴンをレンダリングする
目的には1GPUの時とあまり変わらずに結局向かないと思うよ

104 :デフォルトの名無しさん:2015/11/16(月) 14:17:04.85 ID:hLMLfj5T
4.2からglMemoryBarrier増えてるけどこれってComputeShader使う場合のみ
必要って認識であってる?
例えばTransformFeedbackでVBOの頂点情報変形させてから続けてそのVBO使って
通常の描画する場合ってMemoryBarriorしなくても古いVBOのキャッシュで
描画したりはしないよね

105 :デフォルトの名無しさん:2015/11/17(火) 22:11:56.27 ID:c4hnI4k1
Radeon R7 200 でVTFしようとしてるんだけど
バーテックスシェーダー内でvec4 col=texture(texture1,texcode0);
してもテクスチャカラーがuv 0,0の位置のしか所得出来ない
フラグメントでは問題無く持ってこれる、ドライバ問題?

106 :デフォルトの名無しさん:2015/11/18(水) 01:51:07.68 ID:1oX3XtEG
>>105
別にマイナーな機能でもないし可能性は低いと思う
最新のドライバにして改善しないなら多分お前のコードにバグがある
テクスチャ周りはミスしやすいから
テクスチャユニットの番号が間違ってないかとか
座標の値がおかしくないかとか
ユニフォームの設定が間違ってないかとか調べ直したほうがいい

107 :デフォルトの名無しさん:2015/11/18(水) 13:29:47.46 ID:tmu+VoXJ
>>106
何か情報無いかなと書いてみたんだけど、
やはり自前バグの可能性たかいよね、もう一度調べてみるわ

108 :デフォルトの名無しさん:2015/11/18(水) 13:39:58.84 ID:rijNsXCa
シェーダー内で途中でintを経由して値が0になってるとかだろうな

109 :デフォルトの名無しさん:2015/11/18(水) 21:29:46.73 ID:oULSvKA+
シェーダー周りはデバッグが大変で死ねる

110 :デフォルトの名無しさん:2015/11/20(金) 10:33:54.68 ID:z3NP+fee
105の件解決(?)しました
4頂点の単純な板ポリで試してたんだけど四隅が全部黒の値拾っていた、

トーラスの頂点数の多い物で試したらキチンと反映していた
UVが1.0の値補完か何かで0.0位置の色を拾ってたくさいw

111 :デフォルトの名無しさん:2015/11/20(金) 11:35:21.04 ID:SnNAjHh0
>>110
VTFを数値データとして使うなら普通0.5足してピクセル中央をフェッチするんだよ

112 :デフォルトの名無しさん:2015/11/20(金) 12:50:56.16 ID:z3NP+fee
>>111
もしかしてUVの画像位置と合わせて頂点を凸凹させる時も?

113 :デフォルトの名無しさん:2015/11/20(金) 13:35:46.41 ID:SnNAjHh0
>>112
すまん>>111は書き方が変だったので訂正しておく
0.5というのはu = (x + 0.5) / 1024 のようにするという事を言いたかった
だから最終的に足されるのは0.5とは限らない

要するにテクセルの値を取得する時にはそうすべきというだけで
2つのテクセルのフィルタリングされた値が欲しければする必要はないだろう

114 :デフォルトの名無しさん:2015/11/20(金) 13:44:41.38 ID:z3NP+fee
>>113
やっと理解したかも、補完かからない対策ですね
、1ドットの中心をアクセスすれば安全って事ですか?

115 :デフォルトの名無しさん:2015/11/20(金) 13:51:59.28 ID:SnNAjHh0
>>114
そうだ
あとFILTERの値もNEARESTにする

116 :デフォルトの名無しさん:2015/11/20(金) 13:53:30.75 ID:z3NP+fee
>>115
ありがとう!たすかる

117 :デフォルトの名無しさん:2015/11/23(月) 02:11:18.29 ID:A03ya6CB
glPolygonOffsetでポリゴンの前後関係を調整するのに環境によって
前後関係が異なる結果になることがあるんだけど 上手い対策とか無いでしょうか?

118 :デフォルトの名無しさん:2015/11/23(月) 10:05:33.22 ID:q/XOO9tQ
上手い対策というのは知らないが
unitsを使わないとか
自前でオフセットを計算しとくとか
そもそもZテストを使わないとか

119 :デフォルトの名無しさん:2015/11/23(月) 10:08:58.35 ID:q/XOO9tQ
あとglDepthRange()を使うというテクニックがあったような

120 :デフォルトの名無しさん:2015/11/24(火) 10:45:52.65 ID:PNMHyUFz
>>117
環境ってGPUの違いとかOSとかの事か?
単にシーンの違いとかだとまじめに計算すればちゃんとうまく行くはず
ちなみにZ値は遠くへ行くほど荒くなってるから同じオフセットでも前後関係は変わる

121 :デフォルトの名無しさん:2015/11/26(木) 21:13:44.72 ID:FNrtCodv
今までWindowsでDirect3D(9、11)を使ってたんですが、
新たにAndroidでOpenGL ES 2.0を使おうと考えています。
レンダリングした結果をCPU側に戻すのをやりたいんですが、
OpenGL ES 2.0で可能でしょうか?

122 :デフォルトの名無しさん:2015/11/26(木) 21:59:37.29 ID:AB/dbPZm
glReadPixelsで読める
が、激遅の場合がある、というよりまず遅いと思ったほうがいい
てかそれくらいググれ

123 :121:2015/11/26(木) 22:08:43.27 ID:FNrtCodv
>>122
ありがとうございました!

124 :デフォルトの名無しさん:2015/12/11(金) 16:33:56.96 ID:Xfk/aEIs
OpenSceneGraphなんてあるんだ。
始めて知った。

自作のシーングラフライブラリを置き換えようかな。

125 :デフォルトの名無しさん:2015/12/11(金) 16:45:50.46 ID:Xfk/aEIs
なんだOpenSceneGraphのライセンスはLGPL系か。
GPLは使えない(使いたくない)な。

126 :デフォルトの名無しさん:2015/12/11(金) 17:58:57.42 ID:VH+9SPoV
GPLとLGPLって内容は大分違うと思うんだが

127 :デフォルトの名無しさん:2015/12/11(金) 18:06:39.16 ID:8KiFs03m
GPLって付くだけで怖い

128 :デフォルトの名無しさん:2015/12/11(金) 19:46:36.96 ID:7HdgPmKa
無知は罪だぜ

129 :デフォルトの名無しさん:2015/12/12(土) 00:13:27.08 ID:mfOK7VM0
LGPLは改変せずに使うなら幾ら使っても問題になる事はない

130 :デフォルトの名無しさん:2015/12/12(土) 00:20:10.16 ID:iFwMG7ix
LGPLはおおまかには、静的リンクか動的リンクかでソース公開の義務が変わる

131 :デフォルトの名無しさん:2015/12/12(土) 00:29:53.71 ID:+n5ENKzz
たしかライブラリ側が更新された時にプログラム全体が更新出来るように公開する、だっけ

132 :デフォルトの名無しさん:2015/12/12(土) 00:49:12.40 ID:mfOK7VM0
>>130
そういう事言うからLGPLが敬遠されるんだろうな
スタティックリンクでもソース公開の義務は無いよ
最悪*.oを公開するだけだ
それもゲーム機とか家電用の場合は実行ファイル自体が非公開だから*.oすら公開する必要はないけどな

133 :デフォルトの名無しさん:2015/12/24(木) 06:59:51.83 ID:+ceezo0g
>>132
適当なこと言ってると後で痛い目見るよ
GPLって名前が入ってるものには一切手を触れないのが一番

134 :デフォルトの名無しさん:2015/12/24(木) 12:14:41.98 ID:VUzHb/3L
>>133
適当な事ってなんだよw
https://ja.wikipedia.org/wiki/GNU_Lesser_General_Public_License#LGPL.E3.81.AE.E7.89.B9.E5.BE.B4
Wikiのこんな簡単な文章すら理解できないのかよ

135 :デフォルトの名無しさん:2015/12/30(水) 09:08:09.90 ID:rxkYiXLM
 


ヨウ
ヨウ
エビバーデー


いい加減、「weight」を「重み」って言うのやめね??

あれは誤訳だ

英語のweightとは重さ・重量という意味もあるが「ナニナ〜ニに影響される」「行動や思想などに引っ張られる」

という意味がある


したがっちぇ、これは重みではなく「影響度」と言うべきなのだ!、



 

136 :デフォルトの名無しさん:2016/01/03(日) 15:15:36.12 ID:94fI/gjk
やっとglutに慣れて以前作った物理シミュレーションを可視化しようとしたら
これグローバル変数しか使えないじゃねえか

137 :デフォルトの名無しさん:2016/01/03(日) 15:33:18.95 ID:S9L4IMX7


138 :デフォルトの名無しさん:2016/01/03(日) 15:48:18.16 ID:S9L4IMX7
何にせよglutを新規に使う場合は割り切りが必要だよ

いまさら固定機能使うとか考えたくないし
固定機能相当で十分なら
もっと抽象度の高い(OpenGLを隠蔽した)ライブラリの方がいいんじゃね

139 :デフォルトの名無しさん:2016/01/03(日) 16:35:48.16 ID:HMvIQIbc
>>138
glutからでもGLSL使えるけど?

140 :デフォルトの名無しさん:2016/01/03(日) 16:56:42.16 ID:S9L4IMX7
使えるけど何なんだよ
glut使いたいなら使えばいいよ

141 :デフォルトの名無しさん:2016/01/03(日) 17:26:15.79 ID:HMvIQIbc
>>138はglutを使うには固定機能を使わざるを得ないっていう風によめるんだけど、
どういう割り切りが必要だって主張してんの?

142 :デフォルトの名無しさん:2016/01/03(日) 18:13:26.24 ID:94fI/gjk
構造体とか自由に渡せるようにするにはどうすればいいんだ
glfw使える環境にはしたけどこれ勉強すればいいのか?

143 :デフォルトの名無しさん:2016/01/03(日) 18:32:59.62 ID:S9L4IMX7
>>141
glutを使うのは目的じゃなく手段だろ
そんな基礎的な前提すら共有できていない時点で議論にならん

144 :デフォルトの名無しさん:2016/01/03(日) 20:06:01.37 ID:r0c8SUtA
いやこれは>>141のように読めてしまいますわ

145 :デフォルトの名無しさん:2016/01/04(月) 02:24:11.49 ID:iWeoz0hw
OpenGLでレンダリングしたものだけ表示できて、マウスとキーボード入力ができればいいのであればglfw。
OpenGLと一緒にGUIを使ったり数字や文字列や表やグラフも表示したいならQtを使えばいいかと。
だいたいゲームとかメガデモ以外ならQt上でOpenGLを使えばいいんじゃないだろうか

146 :デフォルトの名無しさん:2016/01/04(月) 12:23:55.71 ID:WW+fICsN
>>138はGLUTに含まれてるプルダウンメニュー?とかが固定機能使ってるって
言いたいんじゃなかろうか?
glutCreateMenu()とglutAddMenuEntry()で簡単にメニュー作れるのは便利だけど
これは固定機能で実装されてるような気がする(詳しくは知らんけど)

147 :デフォルトの名無しさん:2016/01/04(月) 14:16:04.29 ID:ycIevKm8
>>146
glutのmenuの実装にはOpenGL使ってないです

なんにせよglutは古すぎるから今から選択するなら候補から外していいかも
チョットした描画プログラム作るときに使うのには便利だと個人的には思うけど

148 :デフォルトの名無しさん:2016/01/05(火) 11:17:26.76 ID:PF5fRti8
>>145
んじゃQt勉強してみるわ
ありがとう

149 :デフォルトの名無しさん:2016/01/07(木) 00:12:20.20 ID:sjJGp/LC
もっと活気あるところない?

150 :デフォルトの名無しさん:2016/01/07(木) 15:16:06.72 ID:yudiVJqM
 


日本は何でもかんでも文献が少ないか、古すぎる



原因の一つとして、大学が悪いんだよな


アメリカの大学は即戦力の知識を教えている

日本の大学は基礎しか教えていないので企業でまた学び直す必要がある

企業で学んだことは他者に教えてはならないという強迫観念があるので広がらない


 

151 :デフォルトの名無しさん:2016/01/07(木) 19:39:25.20 ID:488/qM8s
ソフトウェアじゃ後追いしかしてないからね

152 :デフォルトの名無しさん:2016/01/07(木) 21:00:26.62 ID:5EdIb4Wm
今までOpenGL1.5程度しか使ってこなかったんだけど、シェーダ周りを勉強してみようかと思ってる
2.xは飛ばして3.xに行ったほうがいい?

153 :デフォルトの名無しさん:2016/01/07(木) 21:01:01.81 ID:5EdIb4Wm
今までOpenGL1.5程度しか使ってこなかったんだけど、シェーダ周りを勉強してみようかと思ってる
2.xは飛ばして3.xに行ったほうがいい?

154 :デフォルトの名無しさん:2016/01/07(木) 21:01:28.13 ID:5EdIb4Wm
すまん、連投してしまった

155 :デフォルトの名無しさん:2016/01/07(木) 21:54:57.44 ID:SYgeeYe0
グラフィックスってただの数学だけどな
数学は中学から教えてる訳だから大学がどうこう言うのは関係無い
日本の企業が結果出てないからひとつ前の大学が悪いって言ってるだけだ

156 :デフォルトの名無しさん:2016/01/08(金) 00:51:53.40 ID:e56/0PxC
ゲームだと、「ゲームの作法」ってのがあるからな
シェーダ知ってるだけではすげえ遅くなる

PCだとOSとDirectXが勝手にメモリを管理するが、ゲーム専用機ではそういう甘えは通用しないのと同様に

157 :デフォルトの名無しさん:2016/01/08(金) 00:53:25.41 ID:e56/0PxC
自動車なども、大学院出ていればすぐに働けると思うはずだが
学校で研究したことと、実際に使用している技術と起こる現象が全然違う

学校で習ったこと、研究したことって何なんだ
ってなるからな

ウソ教えているに等しい

158 :デフォルトの名無しさん:2016/01/08(金) 03:40:24.22 ID:69+Lz/BX
>>153
3では一部の古い機能が非推奨になったから
古い機能を使わなくて済むなら3でいいよ

OpenGL使う人なら英語読めないとやっていけないんじゃね

159 :デフォルトの名無しさん:2016/01/08(金) 11:35:19.21 ID:OhWDmy+4
>>156
そういう小手先のテクより未知のアルゴリズムの発見とか既存のアルゴリズムを
改善とかする方が大幅にクオリティは上がる
ゲーム専用機は全部自分でメモリ管理する必要があって面倒かも知れないけど
結局は誰がやっても大差ないところで落ち着く

160 :デフォルトの名無しさん:2016/01/08(金) 16:27:21.83 ID:erdJpUfu
ゲーム専用機か、、
もう死語レベルだよな
3dsも死に体だし

161 :デフォルトの名無しさん:2016/01/08(金) 20:05:27.31 ID:OhWDmy+4
>>160
んなわけない、海外だと据え置きゲーム機が絶好調だ
GTA5とか3000万本以上売れて全エンターテイメント中で最高売り上げを記録してるよ
日本のゲーム売り上げ高なんて全世界の20分の1にも満たないけど
日本だけで考えればゲーム機は衰退しつつはあるな。ずっとそうかは未知数だが

162 :デフォルトの名無しさん:2016/01/10(日) 11:22:56.00 ID:0fs78EBJ
世界を相手にしている人が2chの辺境スレで
燻っているならそれは残念なことだなぁ

10年前ならネ申とか崇められていたかもしらんが

163 :デフォルトの名無しさん:2016/01/10(日) 12:05:17.29 ID:0fs78EBJ
それと結局クオリティの根幹はデータだよ
高度なライティングを実装したところでテクスチャが糞なら糞

糞なコードを普通のコードに変えればクオリティはぐっと上がるが
普通のコードを優れたコードに変えても大差はない

未知のアルゴリズムの発見とか既存のアルゴリズムを改善なんてのは
実在するならSIGGRAPHとかで発表すべきもので
実態は「小手先のテク」として語られているのがほとんど

独自研究が無駄とは言わんが先人に学ぶ謙虚さと勤勉さが大事だと思う

164 :デフォルトの名無しさん:2016/01/12(火) 13:17:11.20 ID:OumKA2+J
>>163
逆だな
テクスチャが糞でもライティングが良ければパッと見綺麗になる
海外製のFPSとか見たことあるのか?
テクスチャは日本製の丁寧に書き込まれたのに比べると糞だぞ
だけどシェーダーの出来がいいからスゲーリアルに見える
あとFPSとか地形モデルやテクスチャは自動生成していくのが主流じゃないのか?

あと独自研究しろなんて言ってたか?

165 :デフォルトの名無しさん:2016/01/12(火) 16:02:12.20 ID:mjNp/RKz
「未知の」アルゴリズムに先行研究がある訳ないだろ
パラメータチューニングとか具体的なノウハウが非公開ってのはありがちだが
それをアルゴリズムとは言わない

法線マップとかも「データ」に入ると考えられる訳だけども
それらが糞でもシェーダでカバーできるの?

丁寧に書き込まれたのに比べると糞って一般的には糞と言わない
糞は比べるまでもなく糞

166 :デフォルトの名無しさん:2016/01/12(火) 17:02:49.60 ID:OumKA2+J
>>165
お前は何が言いたんだ…
例えばライトスペースパースペクティブシャドウマップみたいな発見(発表)はなんて言うんだ?
これが発表されるまではみんな別の(あまり良くない)アルゴリズムで一生懸命工夫してたけど
LiSPSを使えば簡単にシャドウのクオリティをあげられるようになった
最近はもっと凝ったアルゴリズムも発表されてる(ようだ、詳しくは知らん)
そういうのを考えたり勉強して実装したりする事が大事なんだよ

あとデータが糞と決め付けてるけどなぜ糞になるかを考えないと
糞だから糞ってのは馬鹿っぽい書き込みだな

167 :デフォルトの名無しさん:2016/01/12(火) 18:51:36.57 ID:mjNp/RKz
読み取れないなら絡んでくるなよ

データがなぜ糞になるかにOpenGL関係あるのか?

データの改善によらずプログラム(OpenGL)の範疇のみでの
品質向上は限定的であって
凡人が考え付くようなことは既に誰かが実現しているんだから
幻想抱いていないで勉強しろ、以上

168 :デフォルトの名無しさん:2016/01/12(火) 19:01:28.44 ID:mjNp/RKz
ただ>>159が「未知のアルゴリズムの発見」を
他所の誰かがやってくれるって話なら>>163は的外れだ

でも仮にそうなら「未知のアルゴリズムの発見」をだしに
「小手先のテク」を否定するのはおかしい

「小手先のテク」も嘗て発見されたものであって
「未知のアルゴリズム」のうち汎用性のあるものは
普及して「小手先のテク」となる

169 :デフォルトの名無しさん:2016/01/12(火) 19:19:07.45 ID:OumKA2+J
>>167
お前こそOpenGL関係無い話しをすんなよ、アホか
突然データの話しをし始めたのはお前だろ

データの糞さなんて普通議論の前提に無いよ
法線マップを使うと質感がリアルになる→データが糞なら意味が無い
シャドウマップのアルゴリズムを改善するとクオリティが上がる→データが糞なら意味が無い
なんでこんなアホみたいなことをお前は必死に連呼してんの?

> それと結局クオリティの根幹はデータだよ キリ)www

170 :デフォルトの名無しさん:2016/01/12(火) 19:23:10.13 ID:OumKA2+J
>>168
>>159の「小手先のテク」は>>156の据え置き機のAPIはメモリ管理が〜的な話しに対してだろ
ちゃんとアンカーしてんだから脊髄反射で糞みたいな返答しないで流れを見ろよ

171 :デフォルトの名無しさん:2016/01/16(土) 13:18:31.86 ID:xOOUInQQ
OpenGLって動画を背景にできないのかよ
本当に使えないな

172 :デフォルトの名無しさん:2016/01/16(土) 17:08:00.30 ID:5DMoL/Xm
できるよ
使えないのはお前の頭だよ

173 :デフォルトの名無しさん:2016/01/16(土) 23:21:49.05 ID:kHCtvtbd
まじかよ
買い換えてくるわ

174 :デフォルトの名無しさん:2016/01/17(日) 09:25:58.94 ID:r/9lKueY
アンパンマンか

175 :デフォルトの名無しさん:2016/01/22(金) 02:55:19.84 ID:4tPCkE/9
>>134
読んだら解ると思うけど、LGPLのライブラリを静的にリンクして生成されたオブジェクトコード(実行バイナリーも含む)

176 :デフォルトの名無しさん:2016/01/22(金) 03:01:13.65 ID:2lXYGh8y
途中で書き込んでしまった

静的にリンクして生成されたオブジェクトコード(実行バイナリーも含む)の配布に制限をかけてはならないので、
もしプログラムを販売したとして、それを買った人がプログラムをコピーして転売とかネットにアップロードして再配布とか制限出来ないって事だからな
実行バイナリ以外のリソースがあってそれがないと意味をなさないプログラムであれば(それらのリソースにはLGPLは波及しないので)実質問題無いかも知れないがね

177 :デフォルトの名無しさん:2016/01/22(金) 12:42:22.88 ID:yW17RJ8f
>>176
>>134までの流れはソース公開の有無についてでオブジェクトの再配布については
何も触れてはいなかったけど、確かに言われてみればそうだな
ちなみにゲーム機のOSにはLGPLなライブラリも沢山使われてるけど
そういうのは全部動的にロードするタイプのものばかりだな
それに改変して使ってるLGPLなライブラリのソースはちゃんと公開されてるし

178 :デフォルトの名無しさん:2016/02/12(金) 17:22:58.18 ID:8ijdDdmn
ちょっと聞きたいんだが、
OpenGLのテクスチャ関連の情報源が纏まっているお勧め本とかサイトってある?
特にTexparameteriとかfとか。
APIそのものの仕様というより
特定のテクニック(遅延シェーディングとか)で
このパラメーターの設定必須とかいう話がうまくまとまっている所。

179 :デフォルトの名無しさん:2016/02/12(金) 17:40:28.96 ID:oazN+lFe
「OpenGL 4.0シェーディング言語 : 実例で覚えるGLSLプログラミング」とか?

180 :デフォルトの名無しさん:2016/02/17(水) 00:59:50.05 ID:gHIsUjz8
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.

181 :デフォルトの名無しさん:2016/02/17(水) 01:06:37.00 ID:eBG9H+q0
ガタッ)ついに来たか!!(AA略

182 :デフォルトの名無しさん:2016/02/17(水) 01:50:22.59 ID:gHIsUjz8
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.

183 :デフォルトの名無しさん:2016/02/17(水) 04:11:29.54 ID:kjmsDbJN
http://steamcommunity.com/app/257510/discussions/0/412447331651559970/#p3
案の定というか、GeForceだとクラッシュしやすい感じだな

184 :デフォルトの名無しさん:2016/02/17(水) 11:23:22.50 ID:7JeOmJWL
俺のNVIDIAGPUでもVulkanドライバー来たーー!!
ありがとうNVIDIA!!
早速Vulkanのコードを書いてみるかな
かなり敷居が高いからポリゴン1つ出すだけでも何日も掛かりそうだが…

185 :デフォルトの名無しさん:2016/02/17(水) 12:12:45.77 ID:7JeOmJWL
QualcommはSnapdragon820からだな
これが搭載されたスマホが出るなんてかなり先になりそうだ

186 :デフォルトの名無しさん:2016/02/17(水) 15:22:09.91 ID:gHIsUjz8
ドライバの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

187 :デフォルトの名無しさん:2016/02/17(水) 15:28:25.91 ID:gHIsUjz8
cmake -G "Visual Studio 12 Win64" ..
は Visual Studio 2015の場合は
cmake -G "Visual Studio 14 Win64" ..
への変更が必要。

188 :デフォルトの名無しさん:2016/02/17(水) 21:22:26.71 ID:gHIsUjz8
The Talos Principleの無料demo版でもVulkan対応してた。

The Talos Principle - Update 257458 - public beta
https://steamcommunity.com/app/257510/discussions/0/412447331651559970/

189 :デフォルトの名無しさん:2016/02/18(木) 01:09:41.24 ID:Q9SStqkJ
>>185
なに、つまり今のQualcommものはVulkanサポートしないってことか
スマホの方が普及速度が速いって思ってんだが

190 :デフォルトの名無しさん:2016/02/18(木) 21:56:38.61 ID:PM+lWUH8
すいません
ここで聞いていいのかどうかわからないんですが
OpenGLでプログラミングして生成系の動画を作りたいと思っています
PCのみでプログラミングから動画書き出しまでできる環境って何がありますか?

191 :デフォルトの名無しさん:2016/02/19(金) 03:22:58.69 ID:lRUD/4+H
>>190
Processing

192 :デフォルトの名無しさん:2016/02/19(金) 22:01:40.10 ID:4+n75gL4
>>191
190です
ありがとうございます

193 :デフォルトの名無しさん:2016/02/20(土) 23:35:12.00 ID:CTZ/6uFO
>>185
OSがVulkan描写だとかなり軽くなるだろうなあ・・・
iOSに快適さで負けてるのはOS部分の重さってのはよく言われてるし

194 :デフォルトの名無しさん:2016/02/21(日) 23:41:57.56 ID:lgM7AeG9
>>189
Androidは他のベンダーもだけど一度製品として出したらドライバまったく更新しないからな。
ドライバに変更が必要だから対応されないんだろう。ハードウェア的に対応できるものだったとしてもね。

>>193
ないない。
Androidが重いのはJavaのフレームワークの質の問題

195 :デフォルトの名無しさん:2016/02/22(月) 21:57:07.62 ID:OQxBKkBP
iOSのアプリはネイティブコードで動いてるからそりゃAndroidより速いに決まってる
逆にネイティブコード動かしてよくセキュリティが保たれてるなと思う
iOSの事はよく知らんけど

196 :デフォルトの名無しさん:2016/02/23(火) 12:26:09.77 ID:h5Nadqe3
>>195
知らないのかよw

AndroidもNDKで99%ネイティブコードのアプリは作れるじゃん
ネイティブコード使おうがアプリは権限で許可されたことしか出来ないから安全

近年はVMの改善で割とヌルヌル動くし

197 :デフォルトの名無しさん:2016/02/23(火) 13:03:29.99 ID:MgSDdSDU
>>196
知ってるよ
セキュリティホールというのは許可されてない機能の穴の事だろ
Javaだとそういう事がやりづらいがネイティブコードだと
セキュリティホールを突くコードを書きやすい

198 :デフォルトの名無しさん:2016/02/25(木) 06:14:04.49 ID:7aAJM7Qo
OpenGL始めたばかりなのですが、質問させてください。

ある座標(xyz)の手前に別のモデルが描画されているかを知りたいのですが
depth値と、world変換した座標のZ値比較ではうまく行かないことがあります。

Z値はnear=0, far=1で正規化されているようですが、depth値は視錘台の中で
最奥で描画される位置を1にしているように見えます。
#far平面を遠くへ移動すると、Z値は減りますがdepth値は変わらなかった

depthとZを同じ範囲で正規化出来れば、最前面の判定が出来そうなのですが、
どうしたらよいのでしょうか?

199 :デフォルトの名無しさん:2016/02/25(木) 12:25:09.27 ID:Ey2CZbRS
それぞれの座標空間を明確しろ
depth値ってのは射影空間なのか?
z値はworld座標空間なのか?
異なる座標系の値を比較したって駄目だぞ

200 :デフォルトの名無しさん:2016/02/25(木) 13:30:07.23 ID:xV2izCwr
>>194
2重苦3重苦ならせめて描画関係を最適化してJavaの処理に集中させるべきだと思うわ
どっちみち無駄が多いAPIを通して余計な電力をさらに余計に消費して描画してるのは事実だし

201 :デフォルトの名無しさん:2016/02/25(木) 20:27:44.91 ID:PWvH50+Z
http://gigazine.net/news/20160223-vulkan-benchmark/

微妙すぎ

202 :デフォルトの名無しさん:2016/02/26(金) 10:26:10.93 ID:4BVW97k5
>>201
まだドライバが成熟してないんだから評価は早すぎる

203 :デフォルトの名無しさん:2016/02/26(金) 10:33:42.53 ID:vOww0VK6
というかVulkanとOpenGLの差があるのは複雑なアルゴリズムを実装する場合でしょ
単純な描写じゃGPUが変わるわけじゃないんだからOpenGLと大差出ない

204 :デフォルトの名無しさん:2016/02/26(金) 12:58:44.77 ID:XAqxrE9C
>>201
CPU負荷とGPU負荷を分けて表示させない時点でお察しだろ
Vulkanは主にCPU負荷を減らす為のモンだからな、CPUがスカスカなゲームには効果無い

205 :デフォルトの名無しさん:2016/02/28(日) 11:39:09.43 ID:jdc2WBDZ
CPUコア数が増えると伸びるなGLと12は変化してない
高速に描画してなんぼの世界だけどこれから改良されるでしょ

206 :デフォルトの名無しさん:2016/02/28(日) 13:37:33.52 ID:ciVnMih0
https://t.co/mVqHJeduwh

207 :デフォルトの名無しさん:2016/02/28(日) 14:47:16.12 ID:ZOTD4X0A
>>206を見ると初期化だけで1000行近くいってるな
前にコンシューマーゲーム機だとポリゴン1個出すのに1000行以上書く必要があるって
書いたら
> 図形を描画するのにそんな行数が必要な訳ないだろ
> にわかはロムってろ
とかレスしてる奴居たけど、やっとどっちがにわかかを証明できたなw
ちなみにコンシューマーの方がもうちょっとローレベルだな

208 :デフォルトの名無しさん:2016/02/28(日) 18:30:53.69 ID:71gdqeOf
毎回考えて全行書き直さなきゃならないならともかく
行数とかあんまり意味のある指標には思えんけど

どっちがにわかかなんて更にどうでもいい

209 :デフォルトの名無しさん:2016/02/29(月) 07:41:33.37 ID:bHMRUJeM
モデル座標指定してステンシル値取得する関数ってないですかね?
gluProjectがdoubleで座標取れるためだと思うんだけど、
drawした位置と微妙にずれるのですが。。
使ってるのはopenglです

210 :デフォルトの名無しさん:2016/02/29(月) 19:57:04.30 ID:p/s6qQVA
微妙ってのが1pxより大きいのか
一定方向にずれているのか
とかその辺から原因を絞っていけば?

そもそもステンシルで特定の1pxを読み出すって使い方が
一般的ではないというか効率が悪い気がする

211 :デフォルトの名無しさん:2016/02/29(月) 20:20:52.51 ID:bHMRUJeM
>>210
1pxより大きくずれることはいまのとこないのですが、
ずれる方向はカメラの位置によって変わりますね。

陰面消去されない点の一覧を取りたいのですが、
難しいですね

212 :デフォルトの名無しさん:2016/03/05(土) 21:15:57.52 ID:UBbBH9IM
vulkan難しすぎだわ
openglでもできない雑魚が多いのにこれじゃあな

213 :デフォルトの名無しさん:2016/03/07(月) 14:46:37.02 ID:z45Edf5n
Vulkanの赤本は英語版が8月に出るけど日本語版は同時には出ないよな…
英語版をギリギリまで予約せずにおくけど日本語版出すなら早めに頼むぞ
どうせボーンデジタルがやるんでしょ?

214 :デフォルトの名無しさん:2016/03/07(月) 21:12:33.34 ID:uXN+Q7bH
仕様書の和訳をカットシステムに出してもらえればそれでいいや。

215 :デフォルトの名無しさん:2016/03/07(月) 21:37:42.55 ID:z45Edf5n
Vulkanの赤本は目次見た限りだとOpenGLのと違って3Dの入門的な内容は皆無だよ
メモリとかスレッド周りをちゃんと理解したいから赤本には期待してる
出るのが遅すぎるけどな

216 :デフォルトの名無しさん:2016/03/07(月) 23:34:39.29 ID:4MHiKawP
Windowsで7までサポート範囲広げるのアフォすぎるわ
これ絶対後々最適化で足を引っ張る
それじゃなくても最適化が放置気味なのに

217 :デフォルトの名無しさん:2016/03/08(火) 12:14:48.23 ID:b6RFSG6E
7と10でそんなに違うか?
むしろDirectX12が使えない7ではVulkanが対応していて欲しいけど

218 :デフォルトの名無しさん:2016/03/08(火) 20:30:04.24 ID:6Lhz8+Tr
それぞれのOSでテストしない訳にはいかないし
OSのバージョンごとにバグ報告も上がってくる
面倒事この上ない

219 :デフォルトの名無しさん:2016/03/09(水) 08:24:04.27 ID:n19kSxSj
Win10に移行したがらない奴らばかりだししばらくはVulkanだろうなあ

220 :デフォルトの名無しさん:2016/03/09(水) 10:41:58.73 ID:0Gq8vrNb
>>218
だったらWindows7を動作対象外にすればいいだろ

221 :デフォルトの名無しさん:2016/03/09(水) 20:58:57.28 ID:o2uw7+V5
さっさとWin10に移行して欲しいMSの妨害をしてDirtectX12を潰してるんだろ

222 :デフォルトの名無しさん:2016/03/09(水) 21:39:54.39 ID:0Gq8vrNb
Vulkan使えば7も10もAndroidもそれだけでまかなえるからウマーってなって
メーカーがみんなVulkanのみサポートになれば最高だが…なるわけないか

223 :デフォルトの名無しさん:2016/03/10(木) 15:33:29.85 ID:7DWmda66
ずっと移行が進まないでGLのままの未来だったり

224 :デフォルトの名無しさん:2016/03/10(木) 15:46:04.05 ID:Kw0ks46m
別にあり得るんじゃね
dx12もこれも効率アップが
売りだけど、ピーク性能を求めてない
ユーザーには無用の長物だし

225 :デフォルトの名無しさん:2016/03/10(木) 17:06:12.28 ID:3/fujhr0
GPUはまだ進化し続けるだろうけどGLドライバが更新されなくなったらどうしようもない
OpenGLはそのうちVulkan上に実装されたのを使う事になりそう
別にそれでも構わんけど

226 :デフォルトの名無しさん:2016/03/13(日) 23:22:20.10 ID:nwsHoZ9R
てかOpenGLはゆくゆくはVulkanのラッパーにするってスライドに書いてなかったっけ

227 :デフォルトの名無しさん:2016/03/16(水) 07:15:01.80 ID:6braCi5j
>>224
出てくるゲームがことごとく現行のDXやOpenGLと相性の悪い処理を多用してて
ピーク性能以前の問題になってきてるから必要になってきてる

228 :デフォルトの名無しさん:2016/03/27(日) 00:58:30.90 ID:M0YlQb8w
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

229 :デフォルトの名無しさん:2016/03/28(月) 14:51:31.82 ID:6ufq8Y0K
WebVulkanを待ち望む

230 :デフォルトの名無しさん:2016/03/28(月) 16:19:34.06 ID:wQQhq7gT
なんでWebでjavascriptでCのAPIそのまんまなんだよ
そのままなら既存のOpenGLプログラマが喜んで飛びついてくれると思ってたのか?
残念ながら、OpenGL使ってる奴らほどOpenGLにうんざりするんだよ。
まじでWebの規格決めてる奴らって馬鹿ばっかなんだな

231 :デフォルトの名無しさん:2016/03/28(月) 19:36:50.98 ID:87gm1Pz1
>>230
WebGL知らずに書いてるな…
WebGLのベースはES2.0だが当然そのままではない
しかしほぼ同じになるようにJavaScriptを拡張している
Float32ArrayとかWebGLの為に決められた規格は幾つかある
そんでシェーダーはほぼそのまま同じものが使える
お前こそ今更Cの部分がーとか言っても寒いだけだぞw

232 :デフォルトの名無しさん:2016/03/28(月) 19:52:17.53 ID:87gm1Pz1
>>230
C++で作りたかったらasm.jsとかWebAssemblyとかでコンバートして動かせばいいし
あと海外で3DのゲームをAndroidからブラウザに移植したらブラウザ版のほうが利益を上げてるとかある
ま、日本人はやっと最近ブラウザからネイティブアプリに移行したばっかだからそれに気付くのは5年後だと思うけど

233 :デフォルトの名無しさん:2016/03/30(水) 07:27:24.76 ID:EYPv1wzL
>>230
既存のゲームエンジンは飛びついてくれてるけど?

234 :デフォルトの名無しさん:2016/04/01(金) 08:43:17.88 ID:kpR8TlAX
http://rebuild.fm/135a/

235 :デフォルトの名無しさん:2016/04/08(金) 09:52:19.39 ID:FXnfnjYw
Vulkan SDK 1.0.8.0

236 :デフォルトの名無しさん:2016/04/08(金) 13:02:47.06 ID:/Pf1PHt2
cudaってglslより概念が複雑になってて使いにくいんだけど

237 :デフォルトの名無しさん:2016/04/11(月) 21:36:06.79 ID:JWPJe1l7
比べるものが違う気がするが…

238 :デフォルトの名無しさん:2016/04/13(水) 13:55:57.67 ID:CPNvCG3Q
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

239 :デフォルトの名無しさん:2016/04/14(木) 18:51:04.85 ID:QdC6+6/a
最適化において、描画量を減らすこと、drawCallを減らすこと、どちらを優先すべきでしょうか?
描画量を減らすために地理的な要素で分割すると、今度は drawCall が増えるし。教えてください。

240 :デフォルトの名無しさん:2016/04/14(木) 23:10:53.87 ID:xfBTHsgR
マ イ ン ド コ ン ト ロ ー ル の手法

・沢山の人が、偏った意見を一貫して支持する
 偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法

・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
 誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法

偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い

靖 国 参 拝、皇 族、国 旗 国 歌、神 社 神 道を嫌う カ ル ト

10人に一人は カ ル ト か 外 国 人

「ガ ス ラ イ テ ィ ン グ」 で 検 索 を !

241 :デフォルトの名無しさん:2016/04/16(土) 15:09:37.57 ID:vYVWd6Tu
>>239
CPUに余裕があればドローコール減らす以外の最適化を優先で
余裕が無ければドローコールを減らす

PCならドローコールを発行出来る数はCPUの速度に依存する

モバイルはTegraを除いてみんなTBR/TBDRのGPU
タイル分割処理をしている関係で
いくら頑張っても200〜300回/フレームぐらいまでしか無理っぽい
それ以下になるようにバッチ処理したりするしかない

242 :デフォルトの名無しさん:2016/04/19(火) 07:54:33.12 ID:G5LQQDiU
etheriumで描画コモディティ先物市場まだできてねーのかよ

243 :デフォルトの名無しさん:2016/04/22(金) 20:03:01.00 ID:ShvRhSha
>>242
IoTのメガトレンド化でこの業界にもおこぼれの資本が流れてきてほしいね

244 :デフォルトの名無しさん:2016/05/01(日) 12:19:49.18 ID:tKi6j9CT
匿名通信(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的に分散され、特定のサーバーに依存しません
-

245 :デフォルトの名無しさん:2016/05/04(水) 05:24:39.27 ID:1PZsD9TR
Vulkan SDK 1.0.11.0

246 :デフォルトの名無しさん:2016/05/05(木) 16:26:14.00 ID:yHFZxL6v
Vulkan SDK 1.0.11.1

247 :デフォルトの名無しさん:2016/05/21(土) 10:39:39.90 ID:SK4V46be
Vulkan SDK 1.0.13.0

248 :デフォルトの名無しさん:2016/05/22(日) 17:06:39.95 ID:B1ZnT2eI
頂点のデータ1個分が半端なサイズだと性能が低下するみたいに書いてあるけどマジ?

https://developer.nvidia.com/content/understanding-structured-buffer-performance

5%とは書いてあるけどその5%が結構でかいか?

249 :デフォルトの名無しさん:2016/05/23(月) 18:25:59.24 ID:sxSKeUhG
>>248
それはメモリ一般の話でGPUだけの話じゃないな
float4 position;にしてw成分にradiusを入れるとかよくやる
多分、float3 position; float radius;でも駄目なはず

250 :デフォルトの名無しさん:2016/05/23(月) 20:15:41.27 ID:rfU8/+zM
>>249
いやそれはちゃんとパックされるはず
vec3,vec3,vec2とかは駄目だけど

251 :デフォルトの名無しさん:2016/05/24(火) 07:23:41.22 ID:hRqmCXiK
openglで、3Dモデルの断面だけを表示したいのですが、

以下のやり方だと視点変更時にちらつきが起こってしまいます。
glClipPlane(GL_CLIP_PLANE0, 平面);
glClipPlane(GL_CLIP_PLANE1, 平面(逆向き));

ちらつきを回避する方法をご存じの方、いらっしゃるでしょうか。
0,1で指定する平面を少し離すとちらつきは起きなくなるのですが、
拡大すると幅が見えてしまうので、平面は(向き以外は)1つにしたい
と思っています。

252 :デフォルトの名無しさん:2016/05/24(火) 09:56:54.89 ID:cQa1G5gr
ちらつくのはGPUの計算誤差のせいか
つうか平面で輪切りにするなら
ある程度の厚さは元々必要じゃないの?
GPUの演算精度にあわせて最小の厚みを入れれば?
あと断面を描画したい場合もっとマシな方法があったはず

253 :デフォルトの名無しさん:2016/05/24(火) 10:26:25.89 ID:TKPt/9v7
>>251
ヒント: 1/∞

254 :デフォルトの名無しさん:2016/05/24(火) 13:41:51.46 ID:kfi1pEM9
>>251
厚みがあるように見えないようにカメラとの距離や拡大率で2つの平面の距離を変えればいいんじゃない

255 :デフォルトの名無しさん:2016/05/24(火) 14:32:55.62 ID:NcOn82rz
glPolygonOffset

256 :デフォルトの名無しさん:2016/05/24(火) 17:16:47.81 ID:4MJ+rKOz
このクリッピングプレーンって
カメラ座標系らしいが
任意の傾きでクリッピングしてくれるんだろうか?
カメラ視線と平行でなくても良いなら
どういう仕組みだろうか

257 :デフォルトの名無しさん:2016/05/24(火) 23:13:35.09 ID:73PdSs4C
C#で、OpenGLリソースの解放忘れても.NETのファイナライザで解放されるようにしたいのだが
調べていたらファイナライザは別スレッドで実行される仕様っぽい事が分かった
コンテキストを有効にできるのは1つのスレッドだけらしいから問題

ミューテックスをロック

コンテキストをMakeCurrent

OpenGLのコマンドを実行

MakeCurrentで現在有効なコンテキストをNULLに

ロック解除

これで何とかなる?
ただロックしたり、何度もMakeCurrent
したりするのは速度的にどうなんだろ
同じコンテキストなら平気?

コマンドをキューから取り出して消費するスレッドを作れば1スレッドでOpenGLコマンドを実行する事も可能かもしれないがそれは複雑そう

258 :デフォルトの名無しさん:2016/05/25(水) 01:11:39.37 ID:bZif6UFV
GLのスレッドが終了する前に全部処理すればいいだけだろ。
というかスレッド消滅しちゃったらたぶんリークする。
GLの仕様なので仕方ない。そっちに合わせろ。

259 :デフォルトの名無しさん:2016/05/25(水) 07:55:56.73 ID:d+DQRqHD
>>251
縦横16倍で書いて、バイリニアで四回縮小するか256texelサンプルするシェーダで平均を取る。

>>256
面方程式が分からないなんて情けないこと言わないでくれよ。

>>257
消去リクエストキューとか作ればいいんじゃないの。

260 :デフォルトの名無しさん:2016/05/25(水) 09:35:29.39 ID:Jg8l7ZmY
>>259
2chのレベルの低さを
体現してるよアンタ

261 :デフォルトの名無しさん:2016/05/25(水) 15:27:30.58 ID:fzqm+Lrj
>>259
じゃあ、その面方程式を書いてみてよ

262 :デフォルトの名無しさん:2016/05/25(水) 16:03:06.10 ID:Pw7Hw/FX
>>261
教えてくださいお願いしますだろ

263 :デフォルトの名無しさん:2016/05/25(水) 16:41:44.52 ID:Qi/4WCte
OpenGLってCで書かれてるんでしょうか?
Javaから使いたいんですけどプラットフォームがwindowsならライブラリはどの言語から使っても共通なんでしょうか?

264 :デフォルトの名無しさん:2016/05/25(水) 16:42:45.54 ID:Td5FGjy5
方程式方程式うるせーな
その次のフェーズを言ってるんだよ
その方程式でポリゴンのクリップする境界を特定したとして
どうやってそれを描画するのかってこと

265 :デフォルトの名無しさん:2016/05/25(水) 23:30:11.95 ID:SpZNKB3W
>>262
アホか、お前が知らなそうだから聞いてみたんだよ
図星だったんだなw

266 :デフォルトの名無しさん:2016/05/25(水) 23:33:36.28 ID:SpZNKB3W
>>264
結局そこはドライバとかハード次第なんじゃないか?
ま、ハードでサポートしてるとは思えないからステンシル使うと思うよ

267 :デフォルトの名無しさん:2016/05/26(木) 08:19:37.94 ID:m6HlOT3G
androidスマートフォンにvulkanが搭載されると具体的なこととして何か変わりますか?
また1年後の普及率は個人的にどうなると思いますか

268 :デフォルトの名無しさん:2016/05/26(木) 15:31:00.55 ID:8n8nKgcZ
>>264
デプスバッファとかアルファリファレンスで discard することを理解できるなら、面方程式でのクリップなんて、内積とって大小比較して discard するだけなんだから、分からない理由がわからない。

269 :デフォルトの名無しさん:2016/05/26(木) 18:55:19.65 ID:lgnLogyr
>>268
WorldView空間の平面は
WorldViewProj空間では平面ではなく
曲面になる
ただしカメラ方向(z軸)と平行な場合は
平面は平面のままとなる
曲面じゃなく平面のままならそりゃ簡単さ
ただ、GLのクリッピングプレーンの座標系は
カメラ空間とあったので
平面の向きによっては曲面になりうる
その場合どのような実装でクリッピングを実現しているのか気になったわけ
まあ逆行列でWorldView空間に戻して
判定、discardすれば出来なくは無いが、
わざわざそんなまぬけな実装入れるか?ってこと
オタクが見当違いも甚だしいってわかったかよ?

270 :デフォルトの名無しさん:2016/05/26(木) 19:29:40.41 ID:IMqlwn34
>>269
俺は268じゃないが268は正しいよ
それより
> 曲面になる
は笑うところか?

271 :デフォルトの名無しさん:2016/05/26(木) 20:33:50.99 ID:lgnLogyr
だから言ってんじゃん
お前は2chの低レベルっぷりを
体現してる奴だってな
教えてやるのもここまでだ
後は自分で勉強するこった

272 :デフォルトの名無しさん:2016/05/26(木) 20:54:41.79 ID:KxXBNl+O
多分透視除算でzが手前から奥にリニアに変化しないということなんだろう

273 :デフォルトの名無しさん:2016/05/26(木) 21:37:28.12 ID:Z1edgFxo
だからまあWVPの行列かけた後の透視除算前に処理するんじゃないか?

274 :デフォルトの名無しさん:2016/05/26(木) 22:04:39.82 ID:H0ytGV88
>>271
お前ピクセルシェーダにどんな風に座標渡してんだよ…
wを1.0にしたカメラ座標orワールド座標を渡せば線形補間されてピクセルシェーダに渡るだろ
バカ過ぎ

275 :デフォルトの名無しさん:2016/05/26(木) 22:11:24.04 ID:H0ytGV88
>>271
リニアにならないのはMVP行列を掛けるとZ値がWに移動してwが1.0にならなくなる
それをピクセルシェーダに渡すとGPUがZ/Wを補間するようになるからリニアにはならなくなる
後は自分で勉強するこったw

276 :デフォルトの名無しさん:2016/05/26(木) 22:26:10.65 ID:Z1edgFxo
ピクセルシェーダなんて話は誰もしてないわけだが

277 :デフォルトの名無しさん:2016/05/26(木) 23:01:04.80 ID:CLG55rQ1
glhint(gl_perspective_correction_hint gl_nicest)
つまりナイス!

278 :デフォルトの名無しさん:2016/05/27(金) 09:55:07.38 ID:fT3TR/+E
クリッププレーンはちゃんとしらべたらシェーダ利用時はそのまま使えないじゃん
別途MV変換した座標を渡す必要があるんだとな

279 :デフォルトの名無しさん:2016/05/27(金) 11:49:01.50 ID:UpqEF0dP
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

長文申し訳ありませんが、宜しくお願いします

280 :デフォルトの名無しさん:2016/05/27(金) 14:09:39.83 ID:5/CmsdlJ
>>279
GL_EXT_convolutionとかGL_ARB_imagingが無いなら使えない

つかglDisableするなら別に使えなくてもいいじゃない

281 :デフォルトの名無しさん:2016/05/27(金) 14:30:29.08 ID:UpqEF0dP
>>280
レス有難う
Linux版のOpenToonzで落ちるところを探ってて行き当たったので
GL_EXT_convolutionとかGL_EXT_histogramのifdefで囲ってあるようですが上手く判定できていないのかな
もうちと調べてみます

282 :デフォルトの名無しさん:2016/05/27(金) 14:42:52.68 ID:fvoGjXwU
>>281
それらがdefineされてるかどうかとお前の使ってるGPUがそれらをサポートしてるかどうかは別の話だから

283 :デフォルトの名無しさん:2016/05/27(金) 20:11:31.75 ID:LFdJJr4H
なぜextension調べないのか

284 :デフォルトの名無しさん:2016/06/03(金) 20:26:38.31 ID:hF5p/WFD
OpenGL(ES)のバージョンを指定で使いたいんだけど、
getコンテキストなんたらで、バージョン指定すりゃいいの?
2.0指定してみたけど、読み出したら3.0になってるんだが・・・

285 :デフォルトの名無しさん:2016/06/03(金) 20:43:22.41 ID:0Rj+QG2p
>>284
2のプログラムそのまま動くから3で問題ないよ

286 :デフォルトの名無しさん:2016/06/05(日) 04:14:39.27 ID:ye6u/kZm
機械学習ベース グラフィックAPIまだできてねーのかよ

287 :デフォルトの名無しさん:2016/06/05(日) 16:37:43.32 ID:vQseBiFc
OpenGLで単純な直線・ドット・四角形の描画を実行すると
ドライバ(ビデオカード?)によって同じ座標値を与えても描画結果が異なるみたいなんだけど
そういうもんなの?

環境依存しまくりで頭抱える

288 :デフォルトの名無しさん:2016/06/05(日) 16:40:06.35 ID:J5Uoisn/
そういう話がなくはないけど、そこまで単純なモノだったらなにかコーディングが間違ってそう

289 :デフォルトの名無しさん:2016/06/05(日) 22:42:25.12 ID:fKt+kMxz
Adrenoはmediump以下の精度にしようとしても無視してhighpにするって読んだ

290 :デフォルトの名無しさん:2016/06/06(月) 02:12:48.61 ID:etHtvK3t
>>287
斜線が途中で微妙に1ドット違う結果になったのを確認した事はあったけど
アルゴリズムとかモバイルだと精度も違うから同じ結果にならないのも納得出来る
けど困るほどズレるかね?

291 :デフォルトの名無しさん:2016/06/06(月) 07:00:36.40 ID:UEWlMU/Q
旧APIの固定機能パイプラインの実装が微妙に異なるんじゃね。型とか。

292 :デフォルトの名無しさん:2016/06/06(月) 07:37:17.36 ID:Y6IHoxrC
Vertex2d指定で14x14の小さい丸に見立てた八角形を描こうとしたら形が歪んで
ミスが見つけられなかったから他の環境で実行したら違う形にゆがんだので
テスト用にL字型の線分を描かせてみたら違うピクセルが抜けたりと
ぶっちゃけ斜め要素のない四角形以外はおかしかったです

293 :デフォルトの名無しさん:2016/06/06(月) 21:08:34.91 ID:EceGlO4T
凹ポリ描こうとしてたり…
無いか

294 :デフォルトの名無しさん:2016/06/07(火) 13:27:04.82 ID:irsyXiHg
>>292
それだけだと何とも言えないけどZテスト有効にしてZ値込みで描画してたりすんじゃないの?

295 :デフォルトの名無しさん:2016/06/07(火) 13:28:59.61 ID:irsyXiHg
>>292
あーVertex2dって書いてあるか…すまん
だとしたらトライアングルストリップの指定がおかしいかぐらいか
どっちにしろそこまで歪むなんて考えられん

296 :デフォルトの名無しさん:2016/06/07(火) 13:40:18.91 ID:YXdpUuyy
おかしなコマンドやデータを与えた時の動作は
実装依存でもおかしくない

297 :デフォルトの名無しさん:2016/06/09(木) 22:51:32.59 ID:Z2ZBFZUW
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にコピーできるような一般的な関数を作る場合に
引数の型がどうなるのかがわかりません。

298 :デフォルトの名無しさん:2016/06/16(木) 19:35:08.66 ID:Sexkwk5r
eglCreateSyncKHRとか、KHR付いた拡張使いたいんだけど、
なんか前提条件ある?
試したらEGL_NO_SYNC_KHRしかかえって来ない、これって駄目って事だよな?

もうひとつ、この手の機能はglFinishとかの代用って解説あるけど、
glutとか使わない生のGLES使ってる分にはeglswapがあるから意味無い?

299 :デフォルトの名無しさん:2016/06/26(日) 02:07:41.62 ID:dw6nt173
Vulkan SDK 1.0.17.0

300 :デフォルトの名無しさん:2016/06/27(月) 11:49:12.99 ID:E0ORTsPB
AppleはVulkan対応しないの?

301 :デフォルトの名無しさん:2016/06/29(水) 07:20:04.87 ID:bcgc76wf
Apple様はMetal推しだからな
いいAPIだと思うよ、移植性を除けば

302 :デフォルトの名無しさん:2016/06/30(木) 18:59:31.43 ID:qTuZz+mN
https://osdn.jp/magazine/16/06/30/154000

303 :デフォルトの名無しさん:2016/06/30(木) 19:42:05.22 ID:LevSiXF4
mesaみたいなもんなんだろうか?

304 :デフォルトの名無しさん:2016/07/01(金) 22:57:55.48 ID:pgrRPR6O
今時OpenGLが動かない環境なんてクソみたいもんだからどうでもいいよ

305 :デフォルトの名無しさん:2016/07/02(土) 19:55:01.85 ID:ZiIDTaS+
環境を作る側に行く可能性が無い人にとってはね。

306 :Office & Gamers @ 試験運用中(トリなしw:2016/07/05(火) 03:47:43.79 ID:fGwSDfE9
そっそw

DarkGDK Part.2(c)2ch.net
http://echo.2ch.net/test/read.cgi/tech/1467514934/

307 :デフォルトの名無しさん:2016/07/05(火) 19:42:37.58 ID:QfXwP4YG
Vulkanって今まで通り、GLESのコードで動くの?

308 :デフォルトの名無しさん:2016/07/05(火) 21:54:11.70 ID:l6bE/62d
>>307
動かない。
全く違う低レイヤーのAPIでGLESのAPIを低レイヤーのVulkanで実装しようという動きがあるぐらい

309 :デフォルトの名無しさん:2016/07/05(火) 22:15:52.17 ID:+mdcf8kt
Vulkanってそんなむずいの?
https://forums.developer.apple.com/thread/38469

MetalはVulkanよりは色々やってくれて優しいみたいな事が書いてある

MetalがVulkanよりハイレベルで動くなら
他のプラットフォームで動くMetal互換の実装を作るのは可能?

でもプロプライエタリAPIの互換実装なんか誰も作らないか

310 :デフォルトの名無しさん:2016/07/06(水) 00:03:57.85 ID:zRpS2tef
VulkanのアプリをMetalで動かすレイヤーはある
Metalは絶対消え去る運命にあるのは間違いない

311 :デフォルトの名無しさん:2016/07/06(水) 12:27:48.03 ID:qioYPRFr
OpenGLでガンヴァロウ
そんなAPIやってられん

312 :デフォルトの名無しさん:2016/07/07(木) 23:12:05.35 ID:hGlT+uLz
>>306
なんか勘違いしてそうだけど、環境作る側の「環境」って組み込み機器とかの事だぞ
GPUは無いけどOpenGL ESを動かしたいとかの特殊な状況で役に立つだろう

313 :デフォルトの名無しさん:2016/07/07(木) 23:13:23.07 ID:hGlT+uLz
ラッパーライブラリを作る側はアプリを作る側とOpenGLからしてみれば同じだよ

314 :デフォルトの名無しさん:2016/07/08(金) 12:23:32.11 ID:VW0hfFNQ
>>311
そのOpenGLの中身をVulkanにしよう動きが既に出ている
効率を上げないとしんどいインディーがすごく増えたし
スマホゲームにおいてVulkanを積極的にやらんとMetal持ってるiOSに負ける

315 :デフォルトの名無しさん:2016/07/08(金) 12:44:15.91 ID:UF+RGGyc
>>312
それと、搭載予定のGPUが開発中で実物が無い時に、すでに開発はスタートしてるとかね。

316 :デフォルトの名無しさん:2016/07/08(金) 15:17:39.75 ID:M+8Itm4Z
>>314
OpenGLをVulkanで実装したところで効率が良くなるとは思えんが…
むしろ間接的になるから効率は悪くなるだろ
OpenGLは仕様上色々ドライバがチェックすべき事が多いからDrawコールが重いんだろう
Vulkanで実装したところでやるべき事は一緒だ

317 :デフォルトの名無しさん:2016/07/08(金) 16:12:15.71 ID:XUluGpCt
OpenGLはまずコマンドバッファの管理がドライバ任せなのが良くない感じ?

テクスチャや頂点バッファ用のメモリ確保とか転送をどうやるかもドライバ次第だしな
モバイルでglTexSubImage2dがやたら遅いとかよくあった

モバイルだと殆どのGPUがタイルベースだけど
この処理もドライバ任せだし
処理結果を取っておいたりも出来ない

318 :デフォルトの名無しさん:2016/07/09(土) 23:10:45.67 ID:M+Fpadyy
>>317
コンテキストが一つってのが問題点じゃなかったでしたっけ?

319 :名無しさん@そうだ選挙に行こう! Go to vote!:2016/07/10(日) 11:16:29.74 ID:JU0nYL+k
コード量が増えるってことはバグも人件費も増えるってことじゃないの
普及するのかね

320 :名無しさん@そうだ選挙に行こう! Go to vote!:2016/07/10(日) 11:59:50.38 ID:gNtLgAII
実行速度を重視するかどうかで分かれるだけでしょ

321 :名無しさん@そうだ選挙に行こう! Go to vote!:2016/07/10(日) 12:15:17.43 ID:IeFM40zW
>>318
コンテキストは複数持てるけど
MakeCurrentが同時に一つのスレッドからしか出来なくて
1つのスレッドからしかコマンドを送れないのが問題では
このマルチコアCPUの時代に

322 :名無しさん@そうだ選挙に行こう! Go to vote!:2016/07/10(日) 13:08:45.63 ID:BPe8fmjI
どうせ使われてないんだから過去の互換性なんか切り捨ててくればよかったのに
使われまくってるDirectXでもやってんのに

323 :名無しさん@そうだ選挙に行こう! Go to vote!:2016/07/10(日) 15:17:11.91 ID:SUPEDuXc
>>320
結局実行速度が厳しいスマホだからこそ急いで開発しないとマジでiOSに人取られるからなあ
より負荷の高いゲームでどっちが快適に動くかってのを見せられてしまうとなおさら

324 :名無しさん@そうだ選挙に行こう! Go to vote!:2016/07/10(日) 18:01:48.02 ID:7bNQZoic
>>322
切り捨てて作ったのがVulkanだろ

325 :デフォルトの名無しさん:2016/07/10(日) 21:39:44.73 ID:K/z/M4wG
Vulkanは最近のGPUの仕様に合わせて策定されてんだから今後は普通に使われるようになるだろ
時代はどんどん先へ進んでんだよ
プログラマが追い付かなきゃいかんよ

326 :デフォルトの名無しさん:2016/07/11(月) 11:59:03.53 ID:xfWl4DPh
コード的には退化してる

327 :デフォルトの名無しさん:2016/07/11(月) 12:43:39.07 ID:tFSd98iK
>>326
そう思うなら直接使うの諦めてゲームエンジンとかのミドルウェア使えばいいじゃん。それらが対応してれば恩恵受けれるんだし

328 :デフォルトの名無しさん:2016/07/13(水) 11:22:02.27 ID:0mOEb/aF
OpenGLもミドルウェア的な物を通じて使う物じゃないのか

329 :デフォルトの名無しさん:2016/07/13(水) 21:54:26.00 ID:fWwCFzYf
コード的には退化とか言って
ハードの進化がPGのオナニーに帳消しにされてるのが我慢ならない。
クソみたいに遅いなスクリプト言語は禁止せよ

330 :デフォルトの名無しさん:2016/07/13(水) 22:16:54.83 ID:0mOEb/aF
?

331 :デフォルトの名無しさん:2016/07/13(水) 22:34:50.16 ID:ygJbv1Fw
高級言語のFORTRANから低級言語のCに「退化」したようなもんだろ。

332 :デフォルトの名無しさん:2016/07/14(木) 07:32:49.91 ID:X1+/IxXc
アーキテクチャの進化に付いていけないって悲しいな

333 :デフォルトの名無しさん:2016/07/14(木) 22:30:11.83 ID:y2jpUAL1
今まで抽象化されてドライバ任せだったメモリ管理とかが、今後はソフトやプログラマが直接管理しなきゃならないから、
直にはついて行けない奴も大勢いるだろ
というか、エンジンや環境自体を開発しているようなハイエンドな連中以外は環境が整うまで待ちだろ

334 :デフォルトの名無しさん:2016/07/15(金) 00:08:34.60 ID:TvQRmVn+
つうか赤本早くしてくれ…(一応10月発売予定にはなってる)

335 :デフォルトの名無しさん:2016/07/15(金) 20:23:03.82 ID:3Sl2ginq
対応実機持ってないしなあ

336 :デフォルトの名無しさん:2016/07/15(金) 20:23:51.70 ID:zqzheoRV
そこだよね
どこまで対応したドライバが普及するのか

337 :デフォルトの名無しさん:2016/07/15(金) 20:47:56.99 ID:+hrWOFBB
今は泥でGLつついてるんだがjavaでVulkanAPIとかパフォーマンス出なそう
まあ遅い言語でチューニングした方が感コツ掴めそうだから完成したらC++に清書か

338 :デフォルトの名無しさん:2016/07/15(金) 20:51:50.49 ID:NV7zQ3yX
Intel内蔵GPUでもLinuxだったらIvy Bridge(2012年発売)から対応してるぞ
Windows版だと最近のしか対応しないようだが
NVIDIAも2012年製のから対応してる
↓詳しいことはこれ見れば分かる
https://en.wikipedia.org/wiki/Vulkan_(API)

339 :デフォルトの名無しさん:2016/07/15(金) 20:56:33.06 ID:NV7zQ3yX
AndroidはAdreno一強だけど500からしか対応しないから今年の最新モデルからだね
PowerVRはかなり古いのから対応してるけどこっちはほぼApple専用だしな…

340 :デフォルトの名無しさん:2016/07/15(金) 21:26:25.72 ID:zqzheoRV
intelの対応が遅いのがな
Macの少し前のでは動かないの確定か・・・

341 :デフォルトの名無しさん:2016/07/15(金) 22:07:21.36 ID:kBkiG3Sk
>>339
ハードウェア的にはそこそこ古いものでも対応出来るんだろうがAndroidのSoCベンダーは一度出した製品のドライバー絶対更新しないからな…
Googleすらドライバーのバグを回避するworkaround書いてる程だから

342 :デフォルトの名無しさん:2016/07/15(金) 22:44:03.45 ID:+hrWOFBB
グラフィック周りの更新は特に文鎮化の危険あるからな

343 :デフォルトの名無しさん:2016/07/15(金) 22:58:50.58 ID:3IYjBgbR
>>337
そもそもAndroidのVulkan APIってNDK前提じゃ?

344 :デフォルトの名無しさん:2016/07/16(土) 00:26:24.80 ID:f/DgtYZl
幸いな事にVulkanはモバイルとデスクトップでAPIに差がないからとりあえずデスクトップで組んでおくのがいいだろうね

345 :デフォルトの名無しさん:2016/07/16(土) 00:37:04.46 ID:YVZVQkaI
>>342
いや、関係ないだろ

346 :デフォルトの名無しさん:2016/07/16(土) 07:41:16.22 ID:7CVppVRt
>>343
へーそうなの初耳だわ

347 :デフォルトの名無しさん:2016/07/16(土) 09:51:04.73 ID:bNZm+5vP
VulkanのAPIがローレベル過ぎてJavaバインディングを作るのは難しいのかも

348 :デフォルトの名無しさん:2016/07/17(日) 16:43:47.60 ID:cm6P0jo0
OpenGLを蹴ってまでのAPIでJava使ったら速度でなくて意味ないじゃん

349 :デフォルトの名無しさん:2016/07/18(月) 23:16:14.49 ID:7760Fm83
流れを見るとJava+OpenGL→Java+Vulkanって話でしょ
当然意味はある
あとバインディングもOpenGLより簡単だろう
VulkanAPIは全てXMLで定義されてるからツールに通して作れるはず

350 :デフォルトの名無しさん:2016/07/23(土) 09:48:38.91 ID:Plvoi5O2
OpenGLでもややこしいのにこれ以上ややこしくするなよ

351 :デフォルトの名無しさん:2016/07/23(土) 11:51:52.48 ID:q2oxmEOv
よくわからないけど
GPUのこと詳しくなればVulkanのほうがわかりやすくなるんじゃね
よくわからないけど

352 :デフォルトの名無しさん:2016/07/23(土) 12:49:49.76 ID:V4JGvq9g
実際そうだと思う。OpenCLを先にやってたらOpenGLは暗黙の了解みたいなのが多くてわけわからなかった。

353 :デフォルトの名無しさん:2016/07/24(日) 10:00:19.87 ID:BvjWz3uk
VulkanをJavaに持っていこうとしても
JNIでやり取りする時のコストがでかくて
低オーバーヘッドの意味がなくなるとかない?

354 :デフォルトの名無しさん:2016/07/24(日) 10:16:24.11 ID:Z3SkWthj
試せ

355 :デフォルトの名無しさん:2016/07/24(日) 13:19:04.93 ID:dq+Rqgee
SDKサンプルが上がってこないとわかんないな最初に描画手順のコード?渡して
後は頂点渡すだけみたいな感じなら普通に恩恵あるだろうし

356 :デフォルトの名無しさん:2016/07/24(日) 17:20:27.50 ID:XV2OXjbQ
複雑なアプリを作ってるとOpenGLはステートを内部でもってるから整合性を保つのが滅茶苦茶面倒になる
Vulkanは外部に置いておけるからその辺は簡単になるだろう
OpenGL→最初簡単だけど後が大変
Vulkan→最初大変だけど後が楽
じゃないか?

357 :デフォルトの名無しさん:2016/07/24(日) 23:47:56.68 ID:QfpMWXUS
Vulkan SDK 1.0.21.1

358 :デフォルトの名無しさん:2016/07/25(月) 12:28:39.42 ID:bHa5mRdV
nvidiaはPCで不利になるから裏でVulkanを普及させたくない意図が見え隠れしてるけど
OpenGLはいい加減古い

359 :デフォルトの名無しさん:2016/07/26(火) 00:57:36.60 ID:P70t/zUn
NVIDIAは無理してVulkanに移行しなくてもOpenGLだけでCPU負荷を減らせる拡張を用意してるだけだ
デベロッパーに優しいんだよ
それとゲームはDirectX12の速度の方が重要じゃないか?

360 :デフォルトの名無しさん:2016/07/26(火) 01:56:37.46 ID:R2cFxA5u
>>359
Windowsしか使わないの?

361 :デフォルトの名無しさん:2016/07/26(火) 20:37:51.77 ID:jYnejzD0
いまやスマホだよな

362 :デフォルトの名無しさん:2016/07/26(火) 20:37:53.18 ID:jYnejzD0
いまやスマホだよな

363 :デフォルトの名無しさん:2016/07/26(火) 23:46:34.98 ID:1yunqESs
Steamの調査だとWindowsが95%以上だけどな

364 :デフォルトの名無しさん:2016/07/26(火) 23:50:35.33 ID:HtJzFbj/
スマホもハードが進化したらPC用OSになる

365 :デフォルトの名無しさん:2016/07/27(水) 10:44:58.20 ID:MIqC1yVf
スマホは電池の問題があるから意図的に遅くても消費電力少ないCPU使ってるから
PCを超えることはないんだよバーカ

366 :デフォルトの名無しさん:2016/07/27(水) 12:34:24.99 ID:n5XSmKiJ
逆にAndroidがWindowsを置き換える
MS帝国の終焉

367 :デフォルトの名無しさん:2016/07/27(水) 13:36:40.66 ID:lrmpmMbD
それ言うならChromeOS(Chromebook)だな
もはやAndroidも包含してんだから

368 :デフォルトの名無しさん:2016/07/27(水) 14:24:40.83 ID:CeyxgAlj
AndroidのOpenGLESは正直無茶苦茶で完全にiOSに敗北してるからさっさとVulkanラッパーに移行したい

369 :デフォルトの名無しさん:2016/07/27(水) 17:57:49.91 ID:aSOycJoj
ChromeOSを電話に乗せればよかったんじゃと思う泥は急こしらえっていうか雑だね嫌いじゃないが

370 :デフォルトの名無しさん:2016/07/27(水) 22:46:27.42 ID:+xrdoiGB
>>368
Vulkanの薄いAPIすら心配なレベルだからなぁ…

371 :デフォルトの名無しさん:2016/07/27(水) 22:50:44.37 ID:0Ef+lpVH
AndroidのOpenGLESが無茶苦茶に思えるのは腐ってるドライバのせいだろ
しかもアップデートもされない
Vulkanではそうならないことを願う

372 :デフォルトの名無しさん:2016/07/30(土) 16:49:27.46 ID:NnN7Vre0
>>369
ChromeOSに限らずGoogleの出すものは全部雑な感じする

373 :デフォルトの名無しさん:2016/08/02(火) 06:56:55.79 ID:R+izKGGu
vulkanってHLSL使えるらしいからGLSLいらないね

374 :デフォルトの名無しさん:2016/08/03(水) 00:09:59.72 ID:jr+ageRA
GLSLは滅びぬ、何度でも蘇るさ!

375 :デフォルトの名無しさん:2016/08/03(水) 00:26:49.09 ID:TYVGHSEt
ていうか特定のシェーダー言語に捕らわれる必要は無くなったわけだし

376 :デフォルトの名無しさん:2016/08/03(水) 10:22:21.68 ID:n1aeLSbX
なんにしろそんな最新ハードまだ持ってないし日本語本もないしOpenGL ES3の方が覚えたい

377 :デフォルトの名無しさん:2016/08/08(月) 23:48:34.59 ID:k72FOCvw
Vulkan実行すると、OSいきなり落ちたりしない?
コーディングしてて即落ちして萎える。

378 :デフォルトの名無しさん:2016/08/09(火) 00:02:34.00 ID:/90aZcQE
おま環じゃね?

379 :デフォルトの名無しさん:2016/08/09(火) 01:02:18.05 ID:cMzsnvho
OpenGLみたいにドライバーが実行時エラーを補足しないからな

380 :デフォルトの名無しさん:2016/08/11(木) 11:27:04.55 ID:lFfds5RZ
おまコードじゃね?

381 :デフォルトの名無しさん:2016/08/11(木) 13:12:10.10 ID:FP3MI2h+
おま○コード

382 :デフォルトの名無しさん:2016/08/16(火) 17:35:02.14 ID:/553Bm79
DirectXじゃなくてOpenGL使う意味ってある?OpenGLは研究に使われてるイメージ

383 :デフォルトの名無しさん:2016/08/16(火) 17:48:32.17 ID:+HOVpTRk
mac対応

384 :デフォルトの名無しさん:2016/08/16(火) 18:34:02.00 ID:6YKAxD8c
>>382
DirectXの方が速いはず
やってることは同じ

385 :デフォルトの名無しさん:2016/08/16(火) 18:43:56.12 ID:HlSmpCVY
DirectXで書くといずれ動く環境が無くなる可能性があるが
OpenGLはいまだにドライバが1.0のコードが動くように対応している
その違い
だからといって今更begin,end,vertexを使ったコードを書くべきでは全くない
たまに質問見かけたりするけどな

386 :デフォルトの名無しさん:2016/08/16(火) 20:03:30.29 ID:/553Bm79
>>383-385
使えるAPIもOpenGLの方が少ないイメージあったんだけどあまり変わらないってことか

387 :デフォルトの名無しさん:2016/08/16(火) 20:15:59.04 ID:EOyum1ME
1から勉強する場合はDirectXとOpenGLとVulkan、どれがいいのん?

388 :デフォルトの名無しさん:2016/08/16(火) 20:50:06.17 ID:o2FZVflw
>>387
DirectX(D3D11)安定

389 :デフォルトの名無しさん:2016/08/16(火) 21:20:02.38 ID:5Trr3wwO
dxは日本語リファレンスが神
3dに対する情報も多く含み大変勉強になる
俺もdx11を勧める

390 :デフォルトの名無しさん:2016/08/16(火) 21:45:25.49 ID:EOyum1ME
>>388,389
レスありがとう
やっぱ日本語の情報が沢山ある方がやる気にも繋がるよね

391 :デフォルトの名無しさん:2016/08/16(火) 23:35:20.25 ID:56zF905F
つうか3DAPIに安定を求めても無駄だ
OpenGLは比較的安定してるから研究目的で使われてるだけだ
それと最先端の情報は間違いなく日本語ではない

392 :デフォルトの名無しさん:2016/08/17(水) 11:03:05.64 ID:VM9CuBkP
OpenGLとD3D9は古い手法が混ざっていて混乱の元
VulkanとD3D12は周辺知識が余計に要る

393 :デフォルトの名無しさん:2016/08/17(水) 13:52:00.66 ID:P3V6aYuj
お前どっちもちゃんと扱った事ないだろw

394 :デフォルトの名無しさん:2016/08/17(水) 15:34:47.82 ID:fGC+I60P
WindowsだけならDirectXで良いけど、スマフォとかMacとかマルチを考えるならOpenGL

395 :デフォルトの名無しさん:2016/08/17(水) 16:45:06.27 ID:7YeA1aVk
1から勉強するならWebGLが最適
最新のブラウザには良く出来たデバッガとプロファイラが備わってるし
コンソールにはご丁寧に実行時エラーを表示してくれる
どうせお前ら実行時エラー出しまくりなんだろうからこれが滅茶苦茶役に立つ
で、基礎を身に着けたらC++とかでやればいい

396 :デフォルトの名無しさん:2016/08/17(水) 20:09:15.75 ID:QRsMLiC7
>>385
ES2.0はプログラマブルシェーダーあるGPUが前提になって
それに要らん機能は削除されてる

Coreプロファイルもなんか色々削除されてるはず

397 :デフォルトの名無しさん:2016/08/17(水) 20:13:46.78 ID:SlPTVXjn
coreプロファイルってなんですか?

398 :デフォルトの名無しさん:2016/08/18(木) 20:01:09.03 ID:MF6CGVf/
2.xまでにあった要らん機能まで思い切って削っちゃったバージョン?

399 :デフォルトの名無しさん:2016/08/19(金) 20:50:01.17 ID:s5nMr5/q
directx周りのossのライブラリは軒並み微妙な印象

400 :デフォルトの名無しさん:2016/09/02(金) 15:44:31.82 ID:HIFOxvQq
>>365
電池も再来年に革新が起こりそうだけどね
まあVulkanに取り組んどいた方が後々楽だと思うよ

401 :デフォルトの名無しさん:2016/09/03(土) 16:40:52.81 ID:FrYijLTu
>>400
違うスレでも見た気がするけど、その電池の革新って何だ?
ソースプリーズ

402 :デフォルトの名無しさん:2016/09/03(土) 23:51:00.03 ID:h2wll6jz
日経エレクトロニクスでも記事になってた全固体電池じゃね?
安全で容量が数倍になるうえに寿命も長く、さらに充電時間も短縮するとか。

403 :デフォルトの名無しさん:2016/09/06(火) 00:16:04.95 ID:dm/HXvsI
固体電池が実用になるのは早くても2020年頃になると思うけどね
で、容量が大きくなったからと言ってGPUをブン回すことが出来るかって言うとそうじゃないな
電池の持ちは良くなるだろうけど現状でもスマホで3Dゲームやると
持ってられなくなるぐらい熱くなるから、結局GPUの省電力化が全てだろう

404 :デフォルトの名無しさん:2016/09/06(火) 10:46:46.56 ID:dPVu7qd7
さすがにpcか据え置き機でやれよ

405 :デフォルトの名無しさん:2016/09/06(火) 18:54:57.67 ID:MfZbc6Jb
mobile が PC 追い越すことは永遠にない

406 :デフォルトの名無しさん:2016/09/06(火) 21:01:44.94 ID:3p+KPqnG
>>405
本当に永遠と言い切れるか?
電力を無線で飛ばす時代だ
普通に持ってるだけでスマホに500W以上の大電力が供給される可能性だってゼロとは言えない
そうなるとPCを超えられる

407 :デフォルトの名無しさん:2016/09/06(火) 21:23:34.01 ID:e+pQoU+e
お前は未来技術板にでも行くんだな。

408 :デフォルトの名無しさん:2016/09/06(火) 22:32:04.24 ID:xiDyDxAm
物理的なサイズの問題はどこいったのかな。
小型で高性能化したスマホの技術を結局デスクトップに応用できるんだからでかいほうが強いのはずっとかわらん。

409 :デフォルトの名無しさん:2016/09/06(火) 23:50:21.43 ID:BbG5xseE
>>408
PC用にボードを販売しても儲からないからスマホに最先端GPUを供給するようになったら立場が逆転する
経済的に立場が逆転する事は十分考えられる
よって永遠とは言い難い

410 :デフォルトの名無しさん:2016/09/07(水) 00:29:44.15 ID:CPDLZkVP
説得力ゼロでワロタ

411 :デフォルトの名無しさん:2016/09/07(水) 04:08:46.45 ID:QI1brpnk
わりとどうでもいい

412 :デフォルトの名無しさん:2016/09/07(水) 08:27:53.20 ID:v4venNLg
ボードが既にスマホよりでかいのにな

413 :デフォルトの名無しさん:2016/09/07(水) 12:37:33.59 ID:uvFp1gK4
>>410
昔はCGをスパコンでレンダリングする事が当たり前だったが
今はPCを使っている(今でもスパコンの方が性能が上なのにだ)
この期に及んでPCはスパコンを超えられないと言ってるようなもん
あるしきい値を超えるとデカい方が衰退していく

414 :デフォルトの名無しさん:2016/09/07(水) 12:45:57.96 ID:gFiV+ayk
やたらと必死だけど根本的に脳味噌腐っててワロタ

415 :デフォルトの名無しさん:2016/09/07(水) 14:01:53.25 ID:uvFp1gK4
ま、単純に「いつか mobile が PC 追い越す」と言えば納得するだろ
そんなの今時みんな言ってる
要するに何を追い越すと明記してないから俺はPC用のディスクリートGPUなんて
いつか誰も使わなくなるという観点から書き込んでただけだ

416 :デフォルトの名無しさん:2016/09/07(水) 14:08:33.80 ID:uvFp1gK4
PC用のディスクリートGPUの方がデカいからモバイル用GPUは性能が「永遠」に追いつかないなんて
短絡的で糞つまらん事書き込む奴がいるからこんな事になった

417 :デフォルトの名無しさん:2016/09/07(水) 14:11:37.78 ID:EVMT8UqU
合わせてPCの性能も高くなるので永久に追いつかない件

418 :デフォルトの名無しさん:2016/09/07(水) 14:20:37.59 ID:uvFp1gK4
サルは「永遠」に人類を超えられない、と言ってる事が一緒だなw
サルには無事で人類にだけ感染する致命的な病気で人類が絶滅する可能性があったり
知能指数が低い子供しか生まれなくなる可能性もある

「永遠」とか簡単に言って納得してる奴ってプログラマとしては致命的だな

419 :デフォルトの名無しさん:2016/09/07(水) 15:01:21.08 ID:YSZpbVen
>>417
それな

モバイルが速くなるんなら
PCの箱の中がほとんど空っぽで真ん中にモバイルとかな

420 :デフォルトの名無しさん:2016/09/07(水) 15:05:20.64 ID:HvbhVLNV
>>419
勝てる気がしない

421 :デフォルトの名無しさん:2016/09/07(水) 17:27:15.68 ID:17d1VWw3
頭の悪さがプログラマとして致命的だな
ただの荒らしだろうけど

422 :デフォルトの名無しさん:2016/09/07(水) 19:55:36.21 ID:uvFp1gK4
>>421
「永遠」を証明するにはそれを阻害するあらゆる可能性を全て排除出来て初めて証明出来るが
それは要するに悪魔の証明という事だ
とりあえず、お前の突っ込みはただ悪口を言うだけの幼稚園児並みだなw

423 :デフォルトの名無しさん:2016/09/07(水) 23:03:24.31 ID:kDxgbqqE
簡単な話、PCもモバイルも無くなるかも知れない。
PC が先に無くなれば、モバイルが追い越す期間が存在することになる。

どうでもいい話だ。
仕事があればスマホでもPCでもコンシューマでも、必要な程度に作りこむさ。

424 :デフォルトの名無しさん:2016/09/08(木) 01:13:52.71 ID:WFFFt8FR
デスクトップが衰退していくのは無くなるからモバイルが追い越すとか、それ性能の話とは全く関係ないっていう滑稽さ

425 :デフォルトの名無しさん:2016/09/08(木) 01:50:45.12 ID:IjrSLplX
ダウンサイジングでWSやオフコンが消えたから今度はPCが消える的な話なら多少はね
若い世代はPC持たないしフツーの家庭からPCが消える可能性もなくはない

426 :デフォルトの名無しさん:2016/09/08(木) 02:51:28.88 ID:0hht2XCk
性能なんて相対的なもんだろ
PCが無くなってスマホがその位置になって、コンピューターは指輪ぐらいの大きさになって
その指輪ぐらいの大きさの何かが永遠にスマホを越えられないって誰かが言うんだろうよ

427 :デフォルトの名無しさん:2016/09/08(木) 08:52:40.65 ID:7o4m/kCG
何年も前から
ネットサーフィンとメールしかやらない層がフル機能のPC買って
ウイルスにやられたりするのは愚かしいと思ってたし
あるべき姿に戻るだけ

スマホの詰め込み過ぎもいずれアジアの廉価製品が出てきて駆逐されるだろう

428 :デフォルトの名無しさん:2016/09/12(月) 16:18:05.89 ID:GTMYmn5k
Vulkan SDK 1.0.26.0

429 :デフォルトの名無しさん:2016/10/01(土) 13:39:18.23 ID:nUT6iF3U
質問だけど
2D画像を表示するために構造体でテクスチャID、幅と高さの大きさを持たせて使ってるんだが
テクスチャIDから画像の幅と高さを取得するメソッドってないの?
スッキリさせたい。glfwです

430 :デフォルトの名無しさん:2016/10/01(土) 16:15:52.39 ID:PHorM5/5
glgetなんちゃら

431 :デフォルトの名無しさん:2016/10/01(土) 17:51:15.55 ID:nUT6iF3U
見当たりません・・・

432 :デフォルトの名無しさん:2016/10/01(土) 18:02:04.33 ID:nUT6iF3U
見つかりました。glGetTexLevelParameterivのことですね!
ありがとうございます

433 :デフォルトの名無しさん:2016/10/01(土) 18:06:48.64 ID:QBQLTxiB
バカルンの本はまだ出ないんだな
まあどうせ実機ないからテストできん

434 :デフォルトの名無しさん:2016/10/01(土) 19:15:46.11 ID:j7/Bc0bs
ばかるん?

PCでもわりと最近のGPUなら動くだろ?Vulkan

435 :デフォルトの名無しさん:2016/10/01(土) 22:45:36.64 ID:uhQiho5C
ゲームなら既に、DOOMとThe Talos PrincipleとDota2がVulkanで動いてる。

本なんて要らんだろ。本が必要なレベルの人間には扱えない。

436 :デフォルトの名無しさん:2016/10/01(土) 23:46:07.93 ID:skXxXWUu
んなことはない
日本語の本は期待できないが本家赤本は最初7月には出るはずだったのがひと月ずつずれていって今では11月発売だ
とりあえず赤本待ち

437 :デフォルトの名無しさん:2016/10/02(日) 01:29:36.47 ID:sd32PxOB
馬鹿るん♪

438 :デフォルトの名無しさん:2016/10/03(月) 01:52:58.66 ID:RfUrM0Co
>>437
OpenGL1の赤本と同じだと思ってるお前の方がバカだろw
英語読めないのかよww

439 :デフォルトの名無しさん:2016/10/03(月) 02:07:52.63 ID:RfUrM0Co
Vulkanを魔術みたいに特別扱いしてる奴ダサ過ぎw
PS4のローレベルなAPIはかなりむずいが詳細なドキュメントが日本語で付いてるよ
それ理解した奴ならVulkanに置き換えるのは簡単だろ、同じAMDだし
俺らはそんな経験ないんだから赤本から始めるんだ

440 :デフォルトの名無しさん:2016/10/03(月) 21:09:30.88 ID:BkBOvdSx
英語のWebサイトなんであんな真っ黒なんだよ
アダルトサイトと区別つかねえ

441 :デフォルトの名無しさん:2016/10/09(日) 18:49:04.27 ID:Xj0BbRf6
Vulkan使っても体感速度はほとんど変わらない
PCならせいぜい10%程度みたい

442 :デフォルトの名無しさん:2016/10/09(日) 22:52:45.33 ID:cO312FMp
10%は十分大きいと思うけど

443 :デフォルトの名無しさん:2016/10/11(火) 14:03:30.72 ID:+ncvTzhG
CPUに負荷が掛かりまくりでギリギリでも無ければ体感速度は変わらないでしょ?

444 :デフォルトの名無しさん:2016/10/11(火) 16:42:10.06 ID:EYmFfrNB
無駄な処理が減れば、それだけ消費電力が減るんだよ!

445 :デフォルトの名無しさん:2016/10/11(火) 22:08:02.31 ID:Il8D3j4M
Vulkan使って変わらないのは単に使いこなしてないだけじゃないのか?

446 :デフォルトの名無しさん:2016/10/15(土) 15:33:54.85 ID:2eRhSzEv
Vulkan SDK 1.0.30.0

447 :デフォルトの名無しさん:2016/10/16(日) 23:15:10.74 ID:ezHfniSP
太陽戦隊

448 :デフォルトの名無しさん:2016/10/22(土) 02:06:34.20 ID:n4KWzxAz
https://youtu.be/rvCD9FaTKCA

449 :デフォルトの名無しさん:2016/10/22(土) 09:00:47.31 ID:ksoZ+Sju
gtkmm3+epoxy+sgslで隠面消去の方法を質問したいのだけど
何処のスレが良いのですか?

450 :デフォルトの名無しさん:2016/10/22(土) 10:59:15.86 ID:O48rD9qT
くだすれ

451 :デフォルトの名無しさん:2016/10/22(土) 11:23:56.21 ID:ksoZ+Sju
sgslって何だ・・・org
glslです

プログラム板のくだすれで質問できそうなのは「くだすれC++/CLI(初心者用)part2」だけど・・・
行ってみます

452 :デフォルトの名無しさん:2016/10/24(月) 08:30:59.75 ID:OFHJSBPt
OpenGLAPIでラップして使えるなら使う

453 :デフォルトの名無しさん:2016/10/25(火) 20:56:46.57 ID:qOm0CxnU
PBOからテクスチャにピクセルデータの転送を行いたいのですが、バッファ上の画像のピッチと
テクスチャのピッチが異なる場合で困っています。
テクスチャの方が大きい場合はglTexImage2Dでできそうなんですが、逆にバッファ上の画像の方が
大きい場合にその一部をテクスチャに転送する方法がわかりませんでした。
OpenCLやCUDAのような、srcとdstのピッチが違う場合でも使える汎用的な矩形転送って無いんでしょうか?

454 :デフォルトの名無しさん:2016/10/26(水) 07:32:45.55 ID:ZMW8+L5S
glTexSubImage2Dかな。

455 :453:2016/10/26(水) 08:18:34.18 ID:MSxG37Ir
ありがとうございます。
でもglTexSubImage2Dは転送元のバッファ側が連続している必要あるんじゃないですか?
テクスチャの方が小さい場合はバッファの一部の矩形領域を転送することになりますが、
そういうことはできないような。

456 :デフォルトの名無しさん:2016/10/26(水) 12:12:11.17 ID:SKWE6KpR
ああ、そう言うことか。
それならパデイングを含むサイズのダミーテクスチャ作ってglCopyTextureSubImage2Dだけとなんか無駄だなぁ
前提条件を見直した方がいい気がする

457 :デフォルトの名無しさん:2016/10/26(水) 16:10:22.42 ID:HjBsTdOo
小さいテクスチャをテクスチャとして矩形をテクスチャにレンダリングするだけだろ

458 :デフォルトの名無しさん:2016/10/26(水) 20:20:11.52 ID:MSxG37Ir
ぐぐったら同じ問題の人がいて、その人はラインごとに転送したとか。
自分は結局テクスチャと同サイズのバッファを別に作ることにしました。

>>457
具体的なやり方がちょっとわかりませんが、FBOとか使うんですかね?

459 :デフォルトの名無しさん:2016/10/26(水) 20:35:27.43 ID:n7tIDOUO
適当に書くけどglPixelStoreiのGL_UNPACK_ROW_LENGTH?

460 :デフォルトの名無しさん:2016/10/26(水) 22:08:52.23 ID:ToYJ0I9+
テクスチャからPBOにコピーはやったことあるから、たぶん逆もできるだろうけど、調べるのめんどくせ

461 :デフォルトの名無しさん:2016/10/26(水) 22:54:36.78 ID:MSxG37Ir
>>459
なるほど。これとSKIPを組み合わせたら目的のことができるんですかね。
それにしてもglTexSubImage2Dの方に説明がないのはわかりづらいなぁ。

462 :デフォルトの名無しさん:2016/10/27(木) 16:25:07.88 ID:18/J71eF
OpenGLやDirect2Dで画像処理して高速化するってどういうことなんでしょうか??
例えば、GPGPUでOpenCLなどを使ってピクセルの処理を行って高速化するのはわかるんですが、
OpenGLとかではどうやるのかと。

例えば、画像をテクスチャとしてOpenGLになり取り込んで、ピクセルシェーダーだか
知りませんがそれで画像のピクセルのアクセスして処理する感じなのでしょうか??

463 :デフォルトの名無しさん:2016/10/27(木) 16:56:16.97 ID:QhZCyQPS
メッシュ変形とかの3D機能を応用する場合を除けば
基本はGPGPUと変わらんよ

464 :デフォルトの名無しさん:2016/10/27(木) 17:18:13.80 ID:18/J71eF
画像はテクスチャとして取り込まないといけない?から、処理できる画像の
最大サイズ制限はあるってことですかね??

OpenGL ES3.1などで追加されたCompute Shaderの場合もテクスチャ取り込む?
Image Store/Loadって使っても?

初心者なのでちんぷんかんぷんな事言ってたらすみません。

465 :デフォルトの名無しさん:2016/10/27(木) 21:01:07.59 ID:X0THyINs
はい

466 :デフォルトの名無しさん:2016/10/27(木) 21:03:59.99 ID:93fq6rwp
はいじゃないが

467 :デフォルトの名無しさん:2016/11/02(水) 12:27:08.57 ID:FKbGn/qz
少なくともスマホではvulkan使う価値ないみたいね

http://project-asura.com/blog/?p=3509

>以上を踏まえて,私が出した結論は「Vulkanは絶対に触るべきではない」です

wwwwww

468 :デフォルトの名無しさん:2016/11/02(水) 13:41:59.29 ID:VDmk3Fbl
スマホこそ消費電力減らすために導入は必須だよ。
やり方が違って複雑だと嘆いているアホでしょ。

469 :デフォルトの名無しさん:2016/11/02(水) 18:10:39.64 ID:ExTjOOin
>>468
ちゃんと記事読んでないアホ発見

470 :デフォルトの名無しさん:2016/11/02(水) 23:38:20.18 ID:jxsSxn8m
VulkanはAMDが自社GPUを効率良く動かすために実装したMantleがベースになってるから
> 基本的にVulkan専用のハードとか作っている会社は無いと思うので
こんな事言ってる奴は馬鹿丸出しで見てて恥ずかしくなる…
PS4のAPIもAMDが実装しててVulkanに似てるしもっと低レベルなAPIだ
PS4で自社エンジンでゲーム作ってる会社はみんなVulkanより低レベルのAPIで作ってる

当然難しいのは間違いないが、日本語の詳細なドキュメントやらサンプルやらついてるから
ある程度経験者なら普通に使うことは出来る

471 :デフォルトの名無しさん:2016/11/02(水) 23:48:26.87 ID:jxsSxn8m
ちなみに10年も前のPS3から低レベルAPIだぞ
ただマルチスレッド未対応だったから今ほどは洗練されてなかったと思われる

PS3の頃はシェーダー未経験な人ばっかだからみんな面食らって
想定した全機能を実装するのに数ヶ月どころか半年近く掛かるなんてざらだったと思われる

472 :デフォルトの名無しさん:2016/11/03(木) 00:19:08.23 ID:FmaYciHx
複雑で嘆くのはみんな通る道だが、1本グラフィックエンジン仕上げてもいないのに
クソと言ってしまうのが無能な証拠
Vulkanでゲームを1本マスターアップさせてから、やっぱりVulkaクソだったと言うなら間違いなくクソなんだろう

473 :デフォルトの名無しさん:2016/11/03(木) 00:52:21.85 ID:szl3IS/m
無能な奴でも使えるもん作れない奴らも無能だわ。
つーか、日本語で唯一vulkanの情報を発信していた人がサジを投げたわけだな。

474 :デフォルトの名無しさん:2016/11/03(木) 01:02:58.29 ID:FmaYciHx
だから、無能な奴はOpenGL使ってればいいだろ。まだ進化もドライバサポートもしてんだし
Vulkanは限界までパフォーマンスを引き出す為のもんだよ
お前らがゲームのグラに一喜一憂するから、開発者はどんだけ難しくて大変でも
ちゃんとパフォーマンスさえ出れば何でも使うんだよ
Vulkanはパフォーマンスがちゃんと出るか出ないかが問題なんだよ

475 :デフォルトの名無しさん:2016/11/03(木) 02:31:52.70 ID:TH6IiknO
PS4のAPIがVulkanより低レベルとか本気でいってんのかな…

476 :デフォルトの名無しさん:2016/11/03(木) 02:59:06.79 ID:FmaYciHx
ん?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と比べてもとてもローレベルと言ってるぞ

477 :デフォルトの名無しさん:2016/11/03(木) 03:16:03.88 ID:UYPiUT6+
多分「低レベル」の意味を勘違いしてる素人

478 :デフォルトの名無しさん:2016/11/03(木) 03:16:29.40 ID:FmaYciHx
こっちがソースか
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はハード直叩きに限り無く近いからな

479 :デフォルトの名無しさん:2016/11/03(木) 03:23:08.12 ID:FmaYciHx
>>477
なんだ、そういうことかw
ローレベルって言えば通じるのかな?日本語って難しいなw

480 :デフォルトの名無しさん:2016/11/03(木) 07:29:33.57 ID:85+c+nbh
つーか素人うぜえよ
テメエで使ったこともねえくせに
良いだの悪いだの
アホじゃねーの?

481 :デフォルトの名無しさん:2016/11/03(木) 09:55:27.53 ID:szl3IS/m
なら玄人しかいない場所いけよ馬鹿

482 :デフォルトの名無しさん:2016/11/03(木) 11:51:36.18 ID:jbyLkc4A
手続きの手順が違うから
まっさらからVulkanに合わせて作るならともかく
既存のOpenGLベースのコードの中身を入れ替えたり拡張するような使い方じゃ性能でないよって話だよね?

483 :デフォルトの名無しさん:2016/11/03(木) 12:13:24.92 ID:6FeMk1RE
プログラム書かないひとかもね

484 :デフォルトの名無しさん:2016/11/03(木) 13:01:20.70 ID:x7ofF0dY
質問です
画像を描画する際、配列を渡して一斉に描画するほうが高速だと聞きました
ですが渡す配列が固定長だと描画枚数が増えた時に柔軟に対応できない気がします
皆さんはそういった場合、毎フレーム動的配列を生成・削除してるのでしょうか?

485 :デフォルトの名無しさん:2016/11/03(木) 13:25:03.45 ID:6FeMk1RE
前回と同じサイズのものは使いまわす

っていうかそんなことより0で埋めるとか馬鹿な初期化する方が無駄

486 :デフォルトの名無しさん:2016/11/03(木) 13:34:07.71 ID:x7ofF0dY
前回と同じサイズのものは使いまわせばいいことは分かっています
描画する数が毎回変わるならどうすれば・・・って話です

487 :デフォルトの名無しさん:2016/11/03(木) 13:35:50.93 ID:6FeMk1RE
気になるなら予め最大値判る大きさにしとけよ

488 :デフォルトの名無しさん:2016/11/03(木) 13:43:51.84 ID:x7ofF0dY
描画したくないものまで描画されるじゃないですか
画面外に描画する。それでいいんですかね
めんどくさいので配列として扱わないことにしました

489 :デフォルトの名無しさん:2016/11/03(木) 17:31:55.68 ID:M9JiIIXY
みんなマルチスレッド化されたOpenGLが欲しかったんだよね?

490 :デフォルトの名無しさん:2016/11/03(木) 17:47:51.27 ID:MnQTEHWt
そうでもない

491 :デフォルトの名無しさん:2016/11/03(木) 19:19:47.74 ID:FmaYciHx
>>488
OpenGLは必ず配列内の有効な個数を指定する必要がある
余計に描画されるとかしょうもない推測をするな

492 :デフォルトの名無しさん:2016/11/03(木) 21:14:58.89 ID:x7ofF0dY
>>491
thx。やり方がわかりました

493 :デフォルトの名無しさん:2016/11/04(金) 01:29:43.97 ID:FKFPUeAb
>>488
なんで必ず最大数描画するだよ、描画個数決めれるだろ
必要な分だけ先頭に詰めれ

494 :デフォルトの名無しさん:2016/11/04(金) 03:35:43.26 ID:e0uuer+h
縦横の慣習が違うのは
民族性とか文化の違いから来てるんですか

495 :デフォルトの名無しさん:2016/11/04(金) 11:13:20.80 ID:fEiF0USd
>>467
お前らが叩くから記事消えちゃったじゃん

496 :デフォルトの名無しさん:2016/11/04(金) 14:57:33.75 ID:57dKQ7qw
> 描画したくないものまで描画されるじゃないですか

頂点数指定するだろ。

ていうか配列でというのは連続したメモリ領域をという意味だから、常にプログラミング言語仕様で言うところの配列の先頭からでなくともよい。
でかい固定配列をリングバッファとして使っても良い。

> 配列を渡して一斉に描画するほうが高速だと聞きました
これを言った人が何を意味していたのか分からないが、
・4頂点ずつ描画キックするよりはまとめてキックした方が良い
・glVertex や glColor の類を使うよりはglVertexPointerを使う方が良い
・VBO を使うとより良い
と言える。

素人は何を聞いているのか分からないことが良くある。もっと謙虚になるといい。

497 :デフォルトの名無しさん:2016/11/04(金) 14:58:53.65 ID:57dKQ7qw
ごめん、リロードしてなかった。

498 :デフォルトの名無しさん:2016/11/05(土) 01:13:00.41 ID:gzAsh3gw
>>495
クソワロタww
消すような記事最初から書くなよw

499 :デフォルトの名無しさん:2016/11/15(火) 10:16:57.35 ID:YjLtsY+t
Vulkanってローレベル過ぎて使いづらそう
なんかこう
OpenGLとVulkanの中間みたいのが欲しい

500 :デフォルトの名無しさん:2016/11/16(水) 01:11:12.85 ID:xjZDvINt
もうこれ以上api増やさないで

501 :デフォルトの名無しさん:2016/11/16(水) 07:35:03.91 ID:LWdqoO+l
赤本出たけど勉強してるの?

502 :デフォルトの名無しさん:2016/11/16(水) 11:01:21.29 ID:C38vw7lZ
そもそも流行りそうに無いんだよなぁ……

503 :デフォルトの名無しさん:2016/11/16(水) 11:08:50.83 ID:ruJwqX7K
そうかなぁ

504 :デフォルトの名無しさん:2016/11/16(水) 12:24:37.35 ID:I0d/eIi3
最近になってOpenGLを触ったんだけど凄く使い辛いと思った
元がとても昔に作られたものだからこんなものかとも考えたが
これかDirectXを最下層として多くのゲーム等が作られているのかと正直驚いた

505 :デフォルトの名無しさん:2016/11/16(水) 12:28:03.81 ID:rT2aNE5L
掲示板と日記帳の使い分けもできないリテラシーのひくそうな人には
いろいろと不便でしょうね(´・ω・`)

506 :デフォルトの名無しさん:2016/11/16(水) 12:38:57.94 ID:VglaLP8t
オブジェクト指向マンセーで
ステートマシンを知らないひとには使えない

507 :デフォルトの名無しさん:2016/11/16(水) 14:50:04.43 ID:BjAGLSjY
そのせいでマルチスレッドに対応しづらいのもまた事実

508 :デフォルトの名無しさん:2016/11/16(水) 15:25:39.98 ID:I0d/eIi3
なんでステートマシンになってるのかなと思った
ハードウェアチップをI/O経由でたたくイメージなのかなこれ?
描画ソフトウェアライブラリーというよりSGIのGPUを制御するためのツールとしてデザインしたらこうなったのかな

509 :デフォルトの名無しさん:2016/11/16(水) 15:28:44.99 ID:Nj+EczKt
>>508
FILE*のイメージだろうね

510 :デフォルトの名無しさん:2016/11/16(水) 16:23:15.15 ID:/LUNHxha
>>504
CoreProfileになればだいぶ違うぞ。
そもそも便利機能は全部拡張機能だ。

511 :デフォルトの名無しさん:2016/11/16(水) 19:42:15.33 ID:kIxXFuD3
何bindしたかで関数の動作や引数の意味が変わってしまうのには嵌るわ。
バッファ関連そんなんばっかし。

512 :デフォルトの名無しさん:2016/11/16(水) 23:34:36.54 ID:fzskfnoe
そりゃそうだ
Cで構造体をVOID*にするようなもん

513 :デフォルトの名無しさん:2016/11/17(木) 01:30:46.96 ID:PMO9oOjD
>>508
今のようなメモリ上に分散したデータをまとめてDMAでゴソッとGPUに渡すようなハードじゃなくて
ハードウェア上に1つだけステートがあって、それこそI/OポートとかメモリマップドIOとかで
GPUのレジスタを一つずつ設定してdrawするんであれば、初期のOpenGLの実装は理にかなってると言えるかも
想像で言ってるだけだが

514 :デフォルトの名無しさん:2016/11/17(木) 08:15:27.88 ID:4vvrWja6
>>512
それがどう解釈されるかが関数のインターフェースに現れないのが問題。
どっかのグローバル変数の値によってint*かdouble*かが決まるような糞仕様。

515 :デフォルトの名無しさん:2016/11/17(木) 09:19:40.51 ID:bvn/QdTk
オートマトンじゃないものをステートマシンと呼ぶ分野があるのか。

516 :デフォルトの名無しさん:2016/11/17(木) 16:15:12.11 ID:rgT4eIRU
bind , unbindのタイミングの定義がなんかもやもやしてるよね

517 :デフォルトの名無しさん:2016/11/18(金) 16:07:46.20 ID:vbdBJsNN
free不要論者ですし

518 :デフォルトの名無しさん:2016/11/18(金) 23:33:13.88 ID:SgtZza8z
githubに中国語でコード書いている中国人もいるし
多少はね?

519 :デフォルトの名無しさん:2016/11/19(土) 21:45:54.84 ID:48uE9qYW
Vulkanで実装されたOpenGLみたいのを使えば
苦労しなくても既存のアプリが少しは早くなるかもって思ったけどそれは無いか

Vulkanの大きなメリットの一つはレンダリングステートやコマンドバッファを再利用できる事みたいだが
ゲームエンジン側は毎回OpenGLのAPIを呼ぶような構造になってて
再利用する前提になってないから無意味そう

OpenGLの仕様に合わせようとするとエラーチェックも必須でさらにオーバーヘッドが

520 :デフォルトの名無しさん:2016/11/19(土) 22:29:30.25 ID:a2H+q4ub
赤本も出た事だし猿でも分かるVulakanブログを始めようかと思ってるけどね
理解さえすれば偏見もなくなるはずだ

521 :デフォルトの名無しさん:2016/11/19(土) 22:36:41.20 ID:0cH3YNKy
>>519
ゲームエンジンはレンダリング部分をもっと高レベルの所で抽象化してるから意味あるよ。
余程糞設計のゲームエンジンでないかぎりな

522 :デフォルトの名無しさん:2016/11/20(日) 09:20:34.73 ID:D6VOlvSW
Vulkanは今までドライバが勝手にやってくれてたメモリ確保や
コマンドバッファに入れたコマンドの送信も手動っぽいのも面倒くさい

OpenGLとNV_command_listのVulkan版みたいの欲しいな
あれVulkanで出来る事に近いんでしょ?

ANGLEのVulkanバックエンドのコードは見てみたが
まだ何も実装されていなかった

523 :デフォルトの名無しさん:2016/11/20(日) 09:32:39.51 ID:0ByPx+DX
>>519
エラーチェックとかステートの一貫性チェックとかは開発時だけに必要なんだよ
リリースビルド時はバッサリ削除するのが普通
リリース版実行時にOpenGLエラーが発生したらそれは単にバグを残したままリリースしちゃったってことだ

524 :デフォルトの名無しさん:2016/11/20(日) 09:50:10.91 ID:D6VOlvSW
>>523
それアプリ側でglGetError使うかどうかって話じゃないの?

もしかしたらglGetErrorが使われるかもしれないし
エラー発生時もGPUによって違う結果になったりしないように
OpenGLドライバは常にエラーチェックをしてる
そのせいでオーバーヘッドが大きいとか聞く

これ無視してエラーチェックの無いOpenGL実装を作ったら
それはもはや規格外OpenGLだと思う

525 :デフォルトの名無しさん:2016/11/20(日) 12:30:46.79 ID:AFs4tbnF
将来的にGPUメーカーの提供するドライバーがVulkanのみになってOpenGLを切り捨てるとかにならない限り
Vulkanで実装したOpenGL APIとか作っても無意味そうだよね

526 :デフォルトの名無しさん:2016/11/20(日) 16:08:30.99 ID:bRgpXaT+
>>525
GPUメーカーがそれを使えばドライバーがまともになる

527 :デフォルトの名無しさん:2016/11/20(日) 17:38:21.63 ID:AFs4tbnF
それはVulkanドライバーがまともならって前提だな

528 :デフォルトの名無しさん:2016/11/20(日) 18:26:40.97 ID:eKhjuJLo
プロレス技っぽいな

529 :デフォルトの名無しさん:2016/11/21(月) 09:44:08.00 ID:o+vJVwIh
https://www.khronos.org/vulkan/faq#web-vulkan

WebVulkanは出ないけど
Vulkanっぽい機能を追加したWebGL3は有り得る感じ?

530 :デフォルトの名無しさん:2016/11/21(月) 10:59:28.58 ID:1Z4OsYDH
>>524
話の前提が違ってるな
>>519はゲームエンジンはOpenGLを呼ぶように設計されてるからVulkanにしたところで速くならないみたいなことでしょ
で、OpenGLのエラーチェックは開発時だけに必要な機能だからそれをバッサリやらなければ速くなると言ったんだ

531 :デフォルトの名無しさん:2016/11/21(月) 11:04:31.25 ID:1Z4OsYDH
>>527
Vulkanドライバーは薄いレイヤーだしコンフォーマンステストも充実してるからドライバーの質が良い可能性は高い
ちなみにOpenGL on Vulkanは既にあるぞ
Khronos謹製じゃないがな

532 :デフォルトの名無しさん:2016/11/21(月) 18:12:23.08 ID:nG5Ze3rJ
OpenGLをMFCのシングルフォームビューで使用しています。
ピクチャーコントロールをOpenGLで描画しているのですが、他のウィンドウがかぶっていると描画されません。
何か解決策ないでしょうか?

533 :デフォルトの名無しさん:2016/11/21(月) 21:41:00.70 ID:1Z4OsYDH
>>529
WebGL3があるならES4.0が実装されるはずだけどそもそもリリースされるのかね?
もはやES3.2で完成してんじゃないかとすら思えるけどね

534 :デフォルトの名無しさん:2016/11/21(月) 23:35:12.90 ID:o+vJVwIh
>>533
OpenGLそのままでもVulkanそのままでも無い何かが作られるなら
WebGL3って言い方は適切じゃなかったな

実装にはVulkan使えば良いだろう

535 :デフォルトの名無しさん:2016/11/21(月) 23:43:31.58 ID:1Z4OsYDH
>>534
それ言ったらWindows版ブラウザのWebGL実装は全部DirectXを呼び出してるよ
それがVulkanになるのは時間の問題だろうね
WebGL→DirectXは右手系左手系とかシェーダーの違いとか苦労してるみたいだからVulkanの方が親和性は高いはず

上っ面のAPIはずっとWebGLのままだと思う

536 :デフォルトの名無しさん:2016/11/21(月) 23:49:37.90 ID:1Z4OsYDH
そろそろデフォで有効になるWebGL2はPS3以上PS4未満の能力があるから、それで十分だと思うけどね
限界までパフォーマンスを追求するようなプラットフォームじゃないし

537 :デフォルトの名無しさん:2016/11/23(水) 12:41:38.02 ID:2CpUXBO/
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程度

538 :デフォルトの名無しさん:2016/11/23(水) 13:43:42.26 ID:gCl1Ewav
Javascriptとかwebassemblyがネイティブコード並に速くならないとwebvulkanがあってもJavascriptの実行自体がボトルネックになって速くならない。
セキュリティチェックが必要だからネイティブコード並に早くするのは無理。
なのでAPI呼び出しを減らせるようにwebglを設計しようということか。

539 :デフォルトの名無しさん:2016/11/24(木) 03:11:55.41 ID:lzhnkyGu
Vulkan SDK 1.0.33.0

540 :デフォルトの名無しさん:2016/11/24(木) 09:37:42.37 ID:U66XX0gW
>>532
今時MFC?

ウィンドウ被ったら描画されないってWM_PAINTイベントで描画してないとか?

でも最近のWindowsってウィンドウが被っていても消えたりしないよな
デスクトップコンポジションがあるから

541 :デフォルトの名無しさん:2016/11/24(木) 19:18:00.38 ID:l2S9PJI8
>>538
JavaScriptとWebAssemblyは同じじゃない
WebAssemblyは遅くてもせいぜいネイティブコードの1.5倍以内の遅さに収まってる
いずれオンゲーはWebAssembly+WebGL2な環境で動かすのが普通になるだろうね

542 :デフォルトの名無しさん:2016/11/24(木) 19:45:27.71 ID:U66XX0gW
そもそもJSじゃ速度が測定時の状況でかなり変わるし

C++じゃ実行時にプロファイリングして得た情報で高速化なんて出来ないし
参照カウントとかで手動でメモリ管理する方がGCより速いとも言えないらしい

APIコールには一定のオーバーヘッドがあるので
それはC++より不利

543 :デフォルトの名無しさん:2016/11/24(木) 23:20:47.26 ID:l2S9PJI8
>>542
手動でメモリ管理するのは速度の為じゃなくて、適切なタイミングでメモリの取得解放を行う為だ
あとプロファイリングは開発時に散々してチューニングすれば問題無い
実行時にプロファイリングしてC++よりも高速なコードを生成するなんてほとんど幻想に近いが有り得ないことはない
ただそれもあてにならないわけだし、安定したフレームレートが必要なゲームには全く向かない

544 :デフォルトの名無しさん:2016/11/25(金) 09:25:52.13 ID:2hNWEObD
そもそも実行時プロファイリングは最適化に手間(実行時間)をかける価値のある部分を見つけるためのものだよね?
本当なら全部を最適化をしたいけど、実行時コンパイルでそれやると最適化にかかる時間でかえって遅くなるから最適化処理を必要最小限にしたい
→もっとも効果がある部分をプロファイリングで探す…って

C/C++はピックアップせず全てを最適化するからプロファイリングは不要だし
最適化にかかる時間をプログラムの実行時間外(事前)にまわせるから
これより速く動作させる事なんて不可能でしょ

545 :デフォルトの名無しさん:2016/11/25(金) 09:43:31.68 ID:l0xCaCL5
そういうベンチ結果ならあるから絶対ないって事は無いだろう

実際にどんなパターンで実行されるかって情報だけはAOTじゃ分からないからな
それを加味して最適化するとデメリットがメリットが上回り速くなることは有り得る

あまり頻繁に実行しない部分を時間を掛けて最適化してもあまり速度は速くならないし

https://en.wikipedia.org/wiki/Adaptive_optimization

546 :デフォルトの名無しさん:2016/11/25(金) 09:50:03.45 ID:kFMSAmJC
実行結果から最適化した方が良いコードを生成できる可能性高いしな。
エラー処理とかまず通らないコードをインライン展開してもコード密度悪くなって逆に性能悪くなるし。
(コンパイラ拡張で最適化のために殆ど通らないって属性付け出来たりするけど)

VC++2017には実行した結果から最適化させる機能が入った

https://msdn.microsoft.com/ja-jp/library/e7k32f4k.aspx

547 :デフォルトの名無しさん:2016/11/25(金) 09:56:19.33 ID:zIB8Tv/6
「Rubyのしくみ」に載っているベンチマークでは、
JRubyのループ回数が10万回(0.3秒)から、100万回でも0.3秒なんだよね。
このタイミングでさらに、コンパイルして加速していく

最終的には、1,000万回(1秒)で、CRubyよりも速くなる。
CPUセントリックな処理、つまりI/Oが無い場合、
予測分岐とか最適化技術では、Javaが、Cよりも勝る

548 :デフォルトの名無しさん:2016/11/25(金) 10:03:58.57 ID:l0xCaCL5
SwiftShaderもそういう最適化を行うために動的コード生成を利用してるらしい

https://blog.chromium.org/2016/06/universal-rendering-with-swiftshader.html
https://swiftshader.googlesource.com/SwiftShader/+/HEAD/docs/Index.md

549 :デフォルトの名無しさん:2016/11/26(土) 17:31:50.79 ID:I+dI3pi3
プロファイルベースの最適化は開発時にプロファイリングして
AOTコンパイル時のヒントとするやり方はかなり効果あるだろう
実際chromeが起動時間が20%速くなったとかあったな
それとJITコンパイラする実行しながらプロファイリングするのと一緒にしてはいけない

550 :デフォルトの名無しさん:2016/12/16(金) 04:43:37.82 ID:SI46tWvu
DX11はDX12の機能ほしくなる
あとはいまだにCPUにフレームレート引っ張られるのがいらっとくる

551 :デフォルトの名無しさん:2016/12/16(金) 13:27:10.53 ID:VkbBq8iG
Vulkan SDK 1.0.37.0

552 :デフォルトの名無しさん:2017/01/10(火) 04:17:52.45 ID:L2yDESqP
よろしく

553 :デフォルトの名無しさん:2017/01/15(日) 08:46:04.47 ID:9TaWN87P
glmapbufferrangeってglbindsubdataで代用できるよね?

554 :デフォルトの名無しさん:2017/01/18(水) 21:02:07.78 ID:0z00bTSD
>>535
横からだが、座標系の違いはシェーダ時代だと存在自体がユーザの好みじゃないかな
GLとXの座標系の違いは固定機能が原因で、
シェーダだと座標系変換行列が吸収する。

少なくとも、俺が書いたDirectXのシェーダは、右手座標のモデルを入力して実現できている。

555 :デフォルトの名無しさん:2017/01/18(水) 23:17:38.12 ID:W7QnIoZ6
変換行列は一緒だぞ
右座標だろうが左座標だろうが関係ない

556 :デフォルトの名無しさん:2017/01/20(金) 11:43:09.83 ID:iafDXYrd
えっ、Zのプラスとマイナスが違うのに?

557 :デフォルトの名無しさん:2017/01/20(金) 23:47:40.41 ID:OGbCNlg4
Zを+にするか-にするかはアプリがどういう行列を作るかで決めることでグラフィックのAPIレベルでは関係ないぞ。
実際にUnityはGL、Metal、DirectXのどれを使っても左手座標だぞっと。

558 :デフォルトの名無しさん:2017/01/20(金) 23:49:00.32 ID:OGbCNlg4
多分固定機能時代はそれぞれが内部的に決まってたからそういう風に思ってる人が多いんだと思うが

559 :デフォルトの名無しさん:2017/01/20(金) 23:52:08.78 ID:1wzxLI3D
>>556
くやしいのぅ

560 :デフォルトの名無しさん:2017/01/21(土) 01:35:01.75 ID:ANcjdt99
でもzの範囲の問題でprojectionは互換なかったりするよね?

561 :デフォルトの名無しさん:2017/01/21(土) 10:06:17.46 ID:NhoYLNrq
>>560
それはプロジェクション行列に下駄はかせるか頂点シェーダーで変換すればいいし、右左とは関係ないわな。

562 :デフォルトの名無しさん:2017/01/21(土) 13:20:01.43 ID:ANcjdt99
ああ、なるほど確かに

563 :デフォルトの名無しさん:2017/01/23(月) 11:52:16.52 ID:z+XsKe69
ttp://glslsandbox.com/
ここにglslのサンプルがいっぱいあるけど
ここのglslをコピペして自分のpcで動かしたいけどそういうのってできます?

564 :デフォルトの名無しさん:2017/01/23(月) 17:04:45.86 ID:cfoUMNYh
DirectXは左手系と言ってるみたいだけど、多分サンプルとかがそういう風に
実装されてるだけで、実際にはアプリが自由に決めていい
ただANGLEの実装ドキュメントによると最後のウィンドウ座標だけはY軸の向きが
OpenGLとDirectXで逆になってて変換する必要があると書いてあった
Y軸逆なのはテクスチャ座標もそうだな

565 :デフォルトの名無しさん:2017/01/23(月) 17:41:56.34 ID:7QmIAt4p
同じ座標指定したら右手と左手じゃおかれる位置が明らかに変わるんだから
自由じゃない

566 :デフォルトの名無しさん:2017/01/23(月) 18:39:41.15 ID:L7YdrHor
>>542
jsみたいな高級言語だと、言語自体に予め遊びをいれておき、そこから適切なアルゴリズムを内側で変更するってことは可能じゃないかな
例えば、配列の探索。
シーケンシャルに読むコードであれば、ワークスレッドに分散して速度を稼ぐといった高速化ができる余地がある。
言語にスレッドがないからね

これはcでも可能だが、最適化より予めOpenCLだったかの言語拡張で教え込むことができるから、そのプロファイル自体が要らない。

JavaScriptはよく知らんが、GCと同じでプロセスが落ちたら最適解を忘れそう

567 :デフォルトの名無しさん:2017/01/23(月) 18:52:56.50 ID:L7YdrHor
てか、配列探索の説明になってなかった。
配列の場合、言語では配列にみせるが、アクセスがシーケンシャルかインデックス単一要素アクセスのどちらが多いか、要素の削除やクリアの頻度を計るとかがあるような。
それによって内部の変数管理をリストに変更したりベクターにしたりという最適化があり得そう。
だが、実際は予めデザインで決定出来るのだが、そこをダイナミックオプティマイズで設計時間省略!てかはできるかな。
特に素人や頻繁にコードを変えるシーンだと好まれるかもしれない。
スレ違いすまん。

568 :デフォルトの名無しさん:2017/01/24(火) 00:14:13.56 ID:3QRoTv/K
>>565
お前は…
カメラの位置とかデータの内容が全て左手系や右手系を前提に構築されてれば
まったく同じ見栄えのゲームが作れんだよ
だからどっちを選択するのかはアプリの自由という事が理解できないのか?

569 :デフォルトの名無しさん:2017/01/24(火) 00:40:56.70 ID:nvNd8iP1
レンダリングエンジンを抽象化するという発想がないんでしょ

570 :デフォルトの名無しさん:2017/01/24(火) 00:45:59.50 ID:QLkGrWhR
座標データのZのプラスマイナス逆に刷りゃ同じになるけどそれって自由な選択じゃなくて座標系に合わせてデータ差し変えてるわけで 意味合いが違うな

571 :デフォルトの名無しさん:2017/01/24(火) 00:56:20.21 ID:QLkGrWhR
ああ右手用データを左手座標にぶちこんでも全部逆になるから結局見た目は同じになるって言いたいわけ?

572 :デフォルトの名無しさん:2017/01/24(火) 02:15:07.07 ID:3QRoTv/K
左手系の為に左手系のデータを用意するのも含めてアプリの自由だと言ってんだよ
やたら頭堅いやつが紛れてるな

573 :デフォルトの名無しさん:2017/01/24(火) 02:17:37.50 ID:3QRoTv/K
左手系の為に左手系のデータやプログラムを用意する
右手系の為に右手系のデータやプログラムを用意する
どっちかを決定するのはDirectXが決める事じゃなくてアプリの自由だという単純な事だぞ?

574 :デフォルトの名無しさん:2017/01/24(火) 08:24:46.56 ID:HDVL1TLe
>>570
座標系に縛られるから不自由とかはグラフィックス計算の話題じゃないな

計算するのが不自由って意味になる…

575 :デフォルトの名無しさん:2017/01/24(火) 10:19:43.83 ID:gBz7Q60o
それよりボトムアップなのがややこしい
FBOでテクスチャに描いたときに上下が逆になってしまう

対策は頂点シェーダーで座標を逆転させるか
普通のテクスチャを逆転させるか

576 :デフォルトの名無しさん:2017/01/24(火) 15:21:07.00 ID:POlkEAF3
Aという行列があるとして

→X=(x,y,z)というベクトルを用意して
→Y = →XA という掛け算をするのが「いわゆる左手系と呼ばれる操作」

↑X'=(
x',
y',
z')
というベクトルを用意して
↑Y' = A↑X' という掛け算をするのが「いわゆる右手系と呼ばれる操作」

の違いでしかない
(要するにどちらも本質的には同じ)

577 :デフォルトの名無しさん:2017/01/24(火) 18:46:32.22 ID:xI5AmToI
>>575
アプリ内で反転したテクスチャをレンダラに渡すって手もあるが猛烈にメモリーの無駄
うちはGIMPでエクスポートするとき上下の鏡像反転だね

578 :デフォルトの名無しさん:2017/01/24(火) 18:56:09.33 ID:URo6al7Y
計算回数も変わらないしね
ボトムアップなのは、数学のグラフと同じ座標系にしたかったから、とか聞いたことがある。

xが接線、yが法線、zが従法線として、キチンと向きが揃うとかなんとか

579 :デフォルトの名無しさん:2017/01/24(火) 19:11:02.74 ID:2vak9rNa
ttp://stackoverflow.com/questions/4124041/is-opengl-coordinate-system-left-handed-or-right-handed
OpenGLはobjspaceとworldspaceでは右手系で
glOrtho/glFrustumの実装のせいでwindow座標では左手系になるらしい
といっても古いOpenGLのお話

580 :デフォルトの名無しさん:2017/01/24(火) 19:46:57.06 ID:iZdMj9Ng
Vulkan SDK 1.0.39.0

ttp://vulkan.lunarg.com/sdk/home

581 :デフォルトの名無しさん:2017/01/25(水) 16:37:16.52 ID:3Z0+5oxH
>>576
大間違い
それは単に行列が列指向(column oriented)か行指向の違いでしかない
Wikipediaにちゃんと書いてあるんだから見ればいい

582 :デフォルトの名無しさん:2017/01/25(水) 16:45:53.74 ID:3Z0+5oxH
>>578
> xが接線、yが法線、zが従法線として
それだとトップダウンにならないか?
接空間(tangent space)の事を言ってるなら
x=接線(tangent) y=従法線(binormal) z=法線(normal) だな

583 :デフォルトの名無しさん:2017/01/25(水) 16:46:16.20 ID:/RgCtnOd
みなさんは3D行列の勉強はどこでしたんですか?

584 :デフォルトの名無しさん:2017/01/25(水) 17:50:32.20 ID:dJzOsR4q
してないという選択もlookatに丸投げ

585 :デフォルトの名無しさん:2017/01/27(金) 17:24:37.23 ID:Gw4smznt
OpenGL 4.0 シェーディング言語 -実例で覚えるGLSLプログラミング
https://github.com/daw42/glslcookbook
ここのサンプルは右手系と左手系どちらなのでしょうか

586 :デフォルトの名無しさん:2017/01/27(金) 20:23:38.57 ID:6W1NRhqZ
ハンドネスにやたらと拘る異常者が湧いてるな。

587 :デフォルトの名無しさん:2017/01/28(土) 10:23:30.45 ID:UxEI4Vr6
Vulkan SDK 1.0.39.1

588 :デフォルトの名無しさん:2017/01/29(日) 16:06:14.97 ID:4jsjYD83
GLしか使わないからハンドネスなんかどうでもいいが
原点視点から離れていく方向が+だからGLのほうが自然では無いかと
あんまりなさそうだけど訴訟になった場合の対策でz逆にしたのかしらね

589 :デフォルトの名無しさん:2017/02/03(金) 14:26:53.63 ID:mgnUKpuI
ジンバルロックの理屈はわかるけど、実際何が問題なの?2軸が重なろうが構わず指定通り回転させればいいのでは?

590 :デフォルトの名無しさん:2017/02/04(土) 02:53:25.98 ID:Jz71o7M0
2軸を外積を使って残りの軸を割り出す時に、完全に2軸が重なってると
外積の結果はゼロベクトルになってしまうけど、微妙な距離だと方向が
激しく変化する事により、向きがブルブルしてしまう事をジンバルロックと言う

591 :デフォルトの名無しさん:2017/02/04(土) 03:01:48.01 ID:Jz71o7M0
(以下Y軸プラス方向が真上とする)
よくある状況としてはlookatを使う時に普通はUpベクトルにY軸を渡すけど
真上を向こうとした時に方向ベクトル(eye - center)がY軸とほぼ同じ方向に
なった時にサイドベクトル(X軸)が>>590の状況により、激しく変化して
グルグル回ってしまうとかある

592 :デフォルトの名無しさん:2017/02/05(日) 00:53:48.57 ID:lV/1Yc3H
x軸を外積で出さないでベクトル値を持っていればいいのでは?

593 :デフォルトの名無しさん:2017/02/05(日) 00:58:49.50 ID:1XscLD18
方向ベクトルが任意なのにそのx軸ベクトルが固定値になるわけがない

594 :デフォルトの名無しさん:2017/02/05(日) 01:23:15.93 ID:lV/1Yc3H
最初だけ外積で出して後はそれを一緒に回転させればいいのでは

595 :デフォルトの名無しさん:2017/02/05(日) 01:32:20.83 ID:1XscLD18
その「一緒に回転」を数学的に厳密に描写してみ
ジンバルロックと同じ問題が出るから

596 :デフォルトの名無しさん:2017/02/05(日) 04:27:58.79 ID:D/nQCvX6
カメラの視線ベクトルも上ベクトルも、極座標変数θ、φから計算して常に直交するようにして与えてる。

597 :デフォルトの名無しさん:2017/02/05(日) 23:06:56.76 ID:wiSnBw0r
FPSみたいなゲームだと真上を向くのは人間の首だからY軸と一定の角度以上には
上を向けないように制限してジンバルロックに対処してるのがほとんどだな

598 :デフォルトの名無しさん:2017/02/06(月) 15:28:30.58 ID:GIjsSpfL
再度ジンバルロックについてお尋ねします。

軸が重なると言っているのは、初期姿勢のXYZ軸と、
回転後のXYZ軸が重なるということを言っているのだと思いますが、
2番目だけ90度だとマズイと言っていますが、
1番目を90度にしても軸は重なりますよね?

例えばXYZ軸の順で回転したい場合、
X軸をいきなり90度回せばY軸とZ軸は重なってしまうと思うのですが、
これはジンバルロックにならないのでしょうか?

599 :598:2017/02/06(月) 15:30:51.89 ID:GIjsSpfL
また、2番目を90度にしても、一番目を何度か動かせば、
初期軸と回転後の軸は重ならないと思うのですが。

XYZ軸の順で回転させる場合、
Xを45度回し、Y軸を90度回しても、回転後のX軸と最初のZ軸は重なりませんよね?

600 :デフォルトの名無しさん:2017/02/06(月) 15:34:01.74 ID:sNAkUIYE
うん

601 :598:2017/02/06(月) 15:49:33.60 ID:GIjsSpfL
じゃあ結局、何が問題なんです?

602 :デフォルトの名無しさん:2017/02/06(月) 21:07:00.36 ID:NefZ0m3+
回転と考えるから理解出来ないんだよ
単にあるものを回転させてるだけならジンバルロックなんて起きない
いわゆるジンバルを中のリングはいじらずにそのもの全体をぐるぐる回してるに過ぎない
ジンバルロックというのは中のリングの内2つが同一平面上にある時の事を言う
その状態は要するに2軸が完全に重なっている事を意味する
そうすると残りのリングは一方向に回転するしかなくなり、向きたい方向に向け無くなってしまう
これが厳密な意味でのジンバルロックだ。わかったか?
3軸が全て垂直を保ったままの回転はジンバルロックは起きない
で、3D計算上でのジンバルロックというのはlookatのコードのように2軸から
外積を使って3軸目を求める時に2軸がほぼ重なってる時に向きがランダムな
状態になる事を言う

603 :デフォルトの名無しさん:2017/02/10(金) 10:46:44.10 ID:2uqmAdtA
AppleがWebGPUなる新APIを発表したが
これ標準になるのかね?

604 :デフォルトの名無しさん:2017/02/10(金) 15:25:49.78 ID:HJiZ+eh8
Metalが標準になるような未来がもし来れば

605 :デフォルトの名無しさん:2017/02/11(土) 10:32:30.83 ID:PXmesQvE
シェーダコードと頂点、テクスチャの無償寄付サイトになるな

606 :デフォルトの名無しさん:2017/02/11(土) 10:53:09.39 ID:1GGXJcPM
ソースコード公開されてたらタダだーと勝手にコピーして使っちゃう人?

607 :デフォルトの名無しさん:2017/02/11(土) 13:07:50.78 ID:mNcEgBaA
参考にするだけです

608 :デフォルトの名無しさん:2017/02/11(土) 13:30:47.81 ID:F+Wp5HjG
metalはc++で使えないのが厳しすぎる

609 :デフォルトの名無しさん:2017/02/11(土) 13:40:07.89 ID:qtSuuft0
バレなきゃok
わかりっこないし
こんなもんよ

610 :デフォルトの名無しさん:2017/02/11(土) 13:41:27.87 ID:qtSuuft0
>>606
日本のソースコードに著作権はないよ。

611 :デフォルトの名無しさん:2017/02/11(土) 14:00:40.28 ID:at1UL5N0
610みたいな無知がいるから法律ってのは必要なんだよな

612 :デフォルトの名無しさん:2017/02/11(土) 14:12:23.72 ID:bHUvh3Vs
WebGLはTyped Arrayの内容をいちいちアップロードせずにテクスチャやバッファとして使えないかとは思う
VRAMが共有されてる環境ならコピー無しで使える

しかしGPUが使用中のデータは書き換えてはいけなかったり
GCがコンパクションでデータを移動しないようにメモリ上の位置を固定→パフォーマンスが低下するなど
ややこしい事になるかもしれない

613 :デフォルトの名無しさん:2017/02/11(土) 18:55:07.85 ID:1GGXJcPM
>>609
バレて炎上してるのはこういう人が居るからか。

614 :デフォルトの名無しさん:2017/02/13(月) 04:30:53.35 ID:AsOjEe+m
>>602
なんかジェットコースター宙返りのように反り続けていくとてっぺんで急に向きがくるんと変わっちゃうあれですよね。

615 :デフォルトの名無しさん:2017/02/14(火) 20:31:42.76 ID:82eoCw7d
Intelも新グラフィックスドライバでVulkanに対応
ttp://pc.watch.impress.co.jp/docs/news/1044145.html

616 :デフォルトの名無しさん:2017/02/15(水) 07:52:58.06 ID:6LeauESa
>>614
それはlookAtが宙返り対応してないで裏がえる現象じゃね

617 :デフォルトの名無しさん:2017/02/15(水) 11:08:57.36 ID:N3aAX75A
フライトシミュレーターでもあるな

618 :デフォルトの名無しさん:2017/02/15(水) 19:10:02.58 ID:h9Z3TIEZ
上方ベクトルは正しく設定しよう

619 :デフォルトの名無しさん:2017/02/16(木) 19:23:56.82 ID:UHUABR+a
>>612
BufferObjectをダブルバッファにすればGPUとCPUで並列処理出来るよ
実際にコピーしてるかどうかはドライバ次第だ
Intelの内蔵GPUとかはコピーしてない気もするからな(実際のところは知らん)

620 :デフォルトの名無しさん:2017/02/28(火) 23:44:46.26 ID:NdP5yvRM
Vulkan SDK 1.0.42.0

621 :デフォルトの名無しさん:2017/03/11(土) 21:38:04.37 ID:GrzkoI7k
Vulkan SDK 1.0.42.1

622 :デフォルトの名無しさん:2017/03/29(水) 10:55:29.16 ID:usp7p+f3
>>610
著作権表記がない場合は自動で付くんじゃなかった?

623 :デフォルトの名無しさん:2017/03/30(木) 19:32:54.16 ID:aP5Dk+hE
スマソが、グローシェーディングとかするのに法線使うけど、
その場合、頂点と1対1にするの?
OBJファイルでインデックス方式になってるのを、uv含めて展開するのが正しいのかな?

624 :デフォルトの名無しさん:2017/03/30(木) 20:37:39.14 ID:58ZWU75H
>>623
正しい

625 :デフォルトの名無しさん:2017/04/01(土) 08:37:36.41 ID:qoKXZv+f
>>619
最近だとテクスチャをダイナミックに更新したい場面が多い。
バッファオプジェクトのRO宣言って割りと意味ないと思う。
drawを非同期実装とかしないでしょ。

626 :デフォルトの名無しさん:2017/04/01(土) 13:11:28.85 ID:aVi/GLyt
Vulkan SDK 1.0.42.2

627 :デフォルトの名無しさん:2017/04/07(金) 06:17:33.77 ID:8Gy6obSU
Vulkan SDK 1.0.46.0

628 :デフォルトの名無しさん:2017/04/09(日) 23:59:57.43 ID:b2Udeo0n
どうか教え下さい
AndroidアプリでNDK側でOpenGLESでテスクチャ作ってるのですが、
それをJava側に渡してGLSurfaceViewで表示したいです
readPixelsで配列データとして渡して表示はできたものの、遅すぎてゲームアプリとしては破綻していて。。。

どんな方法がベストでしょうか?やはり、コンテキストを共有するしかないでしょうか?

629 :デフォルトの名無しさん:2017/04/10(月) 00:15:57.40 ID:Ly5iuPId
ベストを探す前に素直にサンプルと同じやり方を試すべきだと思う
そうしない理由があるのならそれを言わんことには

630 :デフォルトの名無しさん:2017/04/10(月) 00:47:22.23 ID:uhMdRFo2
サンプルってどれっすかね?
試すのは大丈夫なんですが、描画スレッド(Java側)と演算スレッド(NDK側)みたいな感じす
スレッド跨いでEGLコンテキスト共有とか、知識あんまり無いです。。
Java側はGLSurfaceView使ってるので、単なるSurfaceViewに変えないとだめっすかね。。

631 :デフォルトの名無しさん:2017/04/10(月) 01:57:45.01 ID:fwsZgTkC
シェーダー使わんの?

632 :デフォルトの名無しさん:2017/04/10(月) 21:03:21.49 ID:cUDmNFgv
>>631
レス遅くなってすみません
シェーダー使うのもありですが、framebufferからreadpixelsする変わりにシェーダーで対応ってのがどうゆうことか理解できてません

とりあえずNDK側でガリガリ作った画をJava側に60fpsで渡す方法があれば何でも試します

633 :デフォルトの名無しさん:2017/04/10(月) 22:12:20.96 ID:5vxtV4z5
textureIDだけ渡したらいいんじゃないの?

634 :デフォルトの名無しさん:2017/04/10(月) 22:21:58.29 ID:PM83VykM
スレッドがJavaとNDK側で別なんです
そしてJava側はGLSurfaceViewなので、なおさらコンテキストは共通化できてないっす

635 :デフォルトの名無しさん:2017/04/10(月) 22:46:43.31 ID:Ly5iuPId
>>630
どれ?じゃねーよ
NDK使ってるんだろ?
大丈夫なら試せよ

636 :デフォルトの名無しさん:2017/04/10(月) 23:08:39.40 ID:PM83VykM
>>636
ndk-bundleのソースフォルダのサンプルが使えるってことですか?
使えそうなサンプルは無いように見えますが。。
教えて下さい。

637 :デフォルトの名無しさん:2017/04/10(月) 23:18:56.98 ID:Ly5iuPId
だから何で自分の流儀を前提にしている訳?

あんたの流儀はあんたが一番知っているんだから
他人に聞くだけ無駄だよ

638 :デフォルトの名無しさん:2017/04/10(月) 23:36:22.60 ID:2T6RGgt8
こういう支離滅裂なアドバイス(?)する奴はなんなんだろうね?酔っぱらってんのか?

639 :デフォルトの名無しさん:2017/04/11(火) 00:26:38.47 ID:C7b4Lnba
Androidの事は知らんけど、単にコンテキスト間でリソース共有にすればいいだけだよね。
Windowsならできる。同様のAPIあるんじゃね。

640 :デフォルトの名無しさん:2017/04/11(火) 02:09:09.99 ID:pFzL7UjB
http://d.hatena.ne.jp/orangesignal/touch/20120818/1345275541
これをぱっと見た感じGLSurfaceViewのgl.glXxxとNDK側のglXxxは同じコンテキスト使ってるっぽいからtextureID渡すだけで行けそうなものだけど

641 :デフォルトの名無しさん:2017/04/11(火) 17:50:22.73 ID:JnGBstZh
横からスマソ、
俺もアンドロイドのOpenGL弄ってるんだけど、
GLES20.glxxxがラッパー?で、上で言ってるglxxxがNDKとか言うやつ?
サイトでよく出てくるサンプルはGLES20.使ってるけど、
そのNDKとやらを使うと速いとかなんかいい事あるの?

642 :デフォルトの名無しさん:2017/04/11(火) 18:56:16.06 ID:4xO2/YqC
>>641
VM介さないから処理によっては速度が全然違う
ゲームとかはフルndkのほうがパフォーマンスが良い
これ以上はAndroidスレで聞いたほうがいい

643 :デフォルトの名無しさん:2017/04/11(火) 19:25:19.23 ID:rQmuGoDh
javaはラッパー

644 :デフォルトの名無しさん:2017/04/11(火) 21:13:28.73 ID:FtBQsLuE
Javaだろうと、NDKだろうとスレッド別なら全く別処理でテクスチャも何もかも共有できないよね?

645 :デフォルトの名無しさん:2017/04/11(火) 21:26:42.43 ID:Behbl0oC
>>633
だよね

646 :デフォルトの名無しさん:2017/04/12(水) 00:32:08.21 ID:BrgOd/52
OpenGLESの知識は浅井ですが、自分の認識です↓
ttp://eaglesakura.hatenablog.com/entry/2013/12/28/235121

647 :デフォルトの名無しさん:2017/04/12(水) 01:06:15.23 ID:Bhc0CFYk
>>646
shared_contextは遅いの?

648 :デフォルトの名無しさん:2017/04/12(水) 11:50:27.11 ID:g3ZwxdtV
>>632
遅いのはJAVAとかNDKとか以前にreadpixelじゃないの?

649 :デフォルトの名無しさん:2017/04/12(水) 12:54:48.21 ID:Pb3LvWpJ
>>648
そうです。
その代替案を探してるだけなんですが、描画と処理のスレッド別なので、テスクチャIDやフレームバッファを共有できない(EGLコンテキスト共有できない)と思ってましたが方法ありそうですね

650 :デフォルトの名無しさん:2017/04/12(水) 21:35:08.21 ID:+eTr5qap
androidのことは詳しくないけどJava側のレンダリングスレッドからネイティブのレンダリング処理出すんじゃだめ?
CPUは並列に動かせてもGPUは並列には動かないし、別スレッドに分ける意味余りないよね?

651 :デフォルトの名無しさん:2017/04/12(水) 21:47:27.65 ID:IsZRv2xh
レンダリングを別スレッドでやりたいわけじゃないでしょ。

652 :デフォルトの名無しさん:2017/04/14(金) 05:02:55.11 ID:j3OKtOYa
並列で動いてるんじゃねレンダ要求直後VBO書き換えるとチラつく

653 :デフォルトの名無しさん:2017/04/15(土) 13:04:22.50 ID:GyRyUELf
>>652
実装はAPIの関知する限りではない
いわゆる未定義動作の類なのでは?

654 :デフォルトの名無しさん:2017/04/15(土) 23:00:51.04 ID:FDBlI7Dn
未定義つうか禁則じゃねVBO使わずにnioバッファの時は勝手に調停してくれてたんだが

655 :デフォルトの名無しさん:2017/05/05(金) 12:53:47.74 ID:2J56jDbL
ほんと初心者で申し訳ないのですが、質問をお許しください。

現在、MAX/MSP jitterを使っているものです。

GLSLの勉強をしているのですが、例えばjitter側で生成した球に、
グローエフェクトをかけたい場合、どういう考え方でGSGLを記述したらよいでしょうか。

vvvvとかならグローエフェクト専用のノードで一発なのに、
MAXでシェーダを書く場合の例とかいろいろ検索しても出てきません。

質問自体もおかしなところがあるかも知れませんが、是非MAXの環境で
映像を作っていきたい理由があるので、どなたかご教示お願いします。

656 :デフォルトの名無しさん:2017/05/09(火) 08:46:01.87 ID:8Otut7+9
>>654
未定義=禁則だと思うけど

657 :デフォルトの名無しさん:2017/05/10(水) 16:50:07.71 ID:3NirUCdu
未定義は定義してないってことだね
禁則はやっちゃいけないってことだね

全然別の意味だね君の頭の中までは文句は無いよ
脳内の混同は取るに足らないありふれた事象だし

658 :デフォルトの名無しさん:2017/05/10(水) 22:22:29.85 ID:P1RskujE
>>657
プログラマは未定義動作をするプログラムを書いてはいけない事に変わりない。やっちゃいけないことだよ。

659 :デフォルトの名無しさん:2017/05/10(水) 22:45:03.25 ID:TahTqR8d
未定義動作とごっちゃにしているんだろうなと思ったら案の定。

660 :デフォルトの名無しさん:2017/05/10(水) 22:46:38.87 ID:P1RskujE
>>659
流れを読もうね

661 :デフォルトの名無しさん:2017/05/11(木) 00:37:38.99 ID:s9cCeBkh
未定義動作しても構わないよ
そこに到達しないコードを書くのが基本

662 :デフォルトの名無しさん:2017/05/11(木) 04:33:17.40 ID:QJPjjG3O
未定義動作なんて聞かない言葉だと思ってググったらバッファの初期化忘れのことかよ
もしも初期化してなきゃ最初の1フレームは起きるかもしれないが件のは前のフレームと
次のフレームとの境目で起きると思われるちらつきだから未定義動作とやらでは無いわな

663 :デフォルトの名無しさん:2017/05/11(木) 07:55:54.57 ID:wBC9RJQi
ここってC言語を知らない人も居るんだね

664 :デフォルトの名無しさん:2017/05/11(木) 09:34:12.49 ID:fwiX6jdh
WebGLだとセキュリティ上の理由でglMapBufferみたいな安全を保証できない機能は使用禁止

665 :デフォルトの名無しさん:2017/05/16(火) 18:19:56.36 ID:EpxzEiEV
GTX1060(モニター@を接続)とQuadro4000(モニターAを接続)の2枚差し
PhotoshopなどのOpenGL系でGTX側に接続しているモニター@を10bitカラー表示させることってでませんか?

どのような効果が見込めるか分からなかったのですが、
NVIDIAコントロールパネル/3D設定の管理/OpenGLレンダリングGPU
の設定ではグローバル設定→Quadro4000に変更してみました

666 :デフォルトの名無しさん:2017/05/16(火) 23:46:49.25 ID:eU5MEqDJ
photoshopなら設定にあるけど他のソフトはソフトが対応してるかだからユーザーがどうこうできる問題じゃない

667 :デフォルトの名無しさん:2017/05/19(金) 03:27:17.75 ID:Xjl9lHc/
>>664
つうかWebGL以前にglMapBufferはOpenGL ESにねーし
GLESベースのWebGLに無くて当然
WebGL1.0でもテクスチャ使えば似たような事は出来る

668 :デフォルトの名無しさん:2017/05/20(土) 19:41:55.23 ID:hsMiSaXN
Vulkan SDK 1.0.49.0

669 :デフォルトの名無しさん:2017/05/21(日) 08:13:42.34 ID:GufdndHa
glewの2.0.0のVC10のglew.slnをビルドすると
error LNK2019:未解決の外部シンボル memsetが関数 glewContextInitで参照されました
と出てビルドできないのですが、どう直せばいいのでしょうか?

670 :669:2017/05/21(日) 08:18:16.21 ID:GufdndHa
ちなみにソリューションを検索しても「memset」の文字列は出てきませんでした。

671 :デフォルトの名無しさん:2017/05/21(日) 21:34:37.37 ID:4Y1sL5Ms
vulkanって流行ってンの?

165 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)