OpenGL/Vulkanスレ Part22©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2015/08/27(木) 18:12:51.54

クロスプラットフォームの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/

**デフォルトの名無しさん** · 2016/11/03(木) 03:16:29.40

こっちがソースか
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はハード直叩きに限り無く近いからな

**デフォルトの名無しさん** · 2016/11/03(木) 03:23:08.12

>>477
なんだ、そういうことかw
ローレベルって言えば通じるのかな？日本語って難しいなw

**デフォルトの名無しさん** · 2016/11/03(木) 07:29:33.57

つーか素人うぜえよ
テメエで使ったこともねえくせに
良いだの悪いだの
アホじゃねーの？

**デフォルトの名無しさん** · 2016/11/03(木) 09:55:27.53

なら玄人しかいない場所いけよ馬鹿

**デフォルトの名無しさん** · 2016/11/03(木) 11:51:36.18

手続きの手順が違うから
まっさらからVulkanに合わせて作るならともかく
既存のOpenGLベースのコードの中身を入れ替えたり拡張するような使い方じゃ性能でないよって話だよね？

**デフォルトの名無しさん** · 2016/11/03(木) 12:13:24.92

プログラム書かないひとかもね

**デフォルトの名無しさん** · 2016/11/03(木) 13:01:20.70

質問です
画像を描画する際、配列を渡して一斉に描画するほうが高速だと聞きました
ですが渡す配列が固定長だと描画枚数が増えた時に柔軟に対応できない気がします
皆さんはそういった場合、毎フレーム動的配列を生成・削除してるのでしょうか？

**デフォルトの名無しさん** · 2016/11/03(木) 13:25:03.45

前回と同じサイズのものは使いまわす

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

**デフォルトの名無しさん** · 2016/11/03(木) 13:34:07.71

前回と同じサイズのものは使いまわせばいいことは分かっています
描画する数が毎回変わるならどうすれば・・・って話です

**デフォルトの名無しさん** · 2016/11/03(木) 13:35:50.93

気になるなら予め最大値判る大きさにしとけよ

**デフォルトの名無しさん** · 2016/11/03(木) 13:43:51.84

描画したくないものまで描画されるじゃないですか
画面外に描画する。それでいいんですかね
めんどくさいので配列として扱わないことにしました

**デフォルトの名無しさん** · 2016/11/03(木) 17:31:55.68

みんなマルチスレッド化されたOpenGLが欲しかったんだよね？

**デフォルトの名無しさん** · 2016/11/03(木) 17:47:51.27

そうでもない

**デフォルトの名無しさん** · 2016/11/03(木) 19:19:47.74

>>488
OpenGLは必ず配列内の有効な個数を指定する必要がある
余計に描画されるとかしょうもない推測をするな

**デフォルトの名無しさん** · 2016/11/03(木) 21:14:58.89

>>491
thx。やり方がわかりました

**デフォルトの名無しさん** · 2016/11/04(金) 01:29:43.97

>>488
なんで必ず最大数描画するだよ、描画個数決めれるだろ
必要な分だけ先頭に詰めれ

**デフォルトの名無しさん** · 2016/11/04(金) 03:35:43.26

縦横の慣習が違うのは
民族性とか文化の違いから来てるんですか

**デフォルトの名無しさん** · 2016/11/04(金) 11:13:20.80

>>467
お前らが叩くから記事消えちゃったじゃん

**デフォルトの名無しさん** · 2016/11/04(金) 14:57:33.75

> 描画したくないものまで描画されるじゃないですか
？
頂点数指定するだろ。

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

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

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

**デフォルトの名無しさん** · 2016/11/04(金) 14:58:53.65

ごめん、リロードしてなかった。

**デフォルトの名無しさん** · 2016/11/05(土) 01:13:00.41

>>495
ｸｿﾜﾛﾀww
消すような記事最初から書くなよw

**デフォルトの名無しさん** · 2016/11/15(火) 10:16:57.35

Vulkanってローレベル過ぎて使いづらそう
なんかこう
OpenGLとVulkanの中間みたいのが欲しい

**デフォルトの名無しさん** · 2016/11/16(水) 01:11:12.85

もうこれ以上api増やさないで

**デフォルトの名無しさん** · 2016/11/16(水) 07:35:03.91

赤本出たけど勉強してるの？

**デフォルトの名無しさん** · 2016/11/16(水) 11:01:21.29

そもそも流行りそうに無いんだよなぁ……

**デフォルトの名無しさん** · 2016/11/16(水) 11:08:50.83

そうかなぁ

**デフォルトの名無しさん** · 2016/11/16(水) 12:24:37.35

最近になってOpenGLを触ったんだけど凄く使い辛いと思った
元がとても昔に作られたものだからこんなものかとも考えたが
これかDirectXを最下層として多くのゲーム等が作られているのかと正直驚いた

**デフォルトの名無しさん** · 2016/11/16(水) 12:28:03.81

掲示板と日記帳の使い分けもできないリテラシーのひくそうな人には
いろいろと不便でしょうね(´・ω・｀)

**デフォルトの名無しさん** · 2016/11/16(水) 12:38:57.94

オブジェクト指向マンセーで
ステートマシンを知らないひとには使えない

**デフォルトの名無しさん** · 2016/11/16(水) 14:50:04.43

そのせいでマルチスレッドに対応しづらいのもまた事実

**デフォルトの名無しさん** · 2016/11/16(水) 15:25:39.98

なんでステートマシンになってるのかなと思った
ハードウェアチップをI/O経由でたたくイメージなのかなこれ？
描画ソフトウェアライブラリーというよりSGIのGPUを制御するためのツールとしてデザインしたらこうなったのかな

**デフォルトの名無しさん** · 2016/11/16(水) 15:28:44.99

>>508
FILE*のイメージだろうね

**デフォルトの名無しさん** · 2016/11/16(水) 16:23:15.15

>>504
CoreProfileになればだいぶ違うぞ。
そもそも便利機能は全部拡張機能だ。

**デフォルトの名無しさん** · 2016/11/16(水) 19:42:15.33

何bindしたかで関数の動作や引数の意味が変わってしまうのには嵌るわ。
バッファ関連そんなんばっかし。

**デフォルトの名無しさん** · 2016/11/16(水) 23:34:36.54

そりゃそうだ
Cで構造体をVOID*にするようなもん

**デフォルトの名無しさん** · 2016/11/17(木) 01:30:46.96

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

**デフォルトの名無しさん** · 2016/11/17(木) 08:15:27.88

>>512
それがどう解釈されるかが関数のインターフェースに現れないのが問題。
どっかのグローバル変数の値によってint*かdouble*かが決まるような糞仕様。

**デフォルトの名無しさん** · 2016/11/17(木) 09:19:40.51

オートマトンじゃないものをステートマシンと呼ぶ分野があるのか。

**デフォルトの名無しさん** · 2016/11/17(木) 16:15:12.11

bind , unbindのタイミングの定義がなんかもやもやしてるよね

**デフォルトの名無しさん** · 2016/11/18(金) 16:07:46.20

free不要論者ですし

**デフォルトの名無しさん** · 2016/11/18(金) 23:33:13.88

githubに中国語でコード書いている中国人もいるし
多少はね？

**デフォルトの名無しさん** · 2016/11/19(土) 21:45:54.84

Vulkanで実装されたOpenGLみたいのを使えば
苦労しなくても既存のアプリが少しは早くなるかもって思ったけどそれは無いか

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

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

**デフォルトの名無しさん** · 2016/11/19(土) 22:29:30.25

赤本も出た事だし猿でも分かるVulakanブログを始めようかと思ってるけどね
理解さえすれば偏見もなくなるはずだ

**デフォルトの名無しさん** · 2016/11/19(土) 22:36:41.20

>>519
ゲームエンジンはレンダリング部分をもっと高レベルの所で抽象化してるから意味あるよ。
余程糞設計のゲームエンジンでないかぎりな

**デフォルトの名無しさん** · 2016/11/20(日) 09:20:34.73

Vulkanは今までドライバが勝手にやってくれてたメモリ確保や
コマンドバッファに入れたコマンドの送信も手動っぽいのも面倒くさい

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

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

**デフォルトの名無しさん** · 2016/11/20(日) 09:32:39.51

>>519
エラーチェックとかステートの一貫性チェックとかは開発時だけに必要なんだよ
リリースビルド時はバッサリ削除するのが普通
リリース版実行時にOpenGLエラーが発生したらそれは単にバグを残したままリリースしちゃったってことだ

**デフォルトの名無しさん** · 2016/11/20(日) 09:50:10.91

>>523
それアプリ側でglGetError使うかどうかって話じゃないの？

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

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

**デフォルトの名無しさん** · 2016/11/20(日) 12:30:46.79

将来的にGPUメーカーの提供するドライバーがVulkanのみになってOpenGLを切り捨てるとかにならない限り
Vulkanで実装したOpenGL APIとか作っても無意味そうだよね

**デフォルトの名無しさん** · 2016/11/20(日) 16:08:30.99

>>525
GPUメーカーがそれを使えばドライバーがまともになる

**デフォルトの名無しさん** · 2016/11/20(日) 17:38:21.63

それはVulkanドライバーがまともならって前提だな

**デフォルトの名無しさん** · 2016/11/20(日) 18:26:40.97

プロレス技っぽいな

**デフォルトの名無しさん** · 2016/11/21(月) 09:44:08.00

https://www.khronos.org/vulkan/faq#web-vulkan

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

**デフォルトの名無しさん** · 2016/11/21(月) 10:59:28.58

>>524
話の前提が違ってるな
>>519はゲームエンジンはOpenGLを呼ぶように設計されてるからVulkanにしたところで速くならないみたいなことでしょ
で、OpenGLのエラーチェックは開発時だけに必要な機能だからそれをバッサリやらなければ速くなると言ったんだ

**デフォルトの名無しさん** · 2016/11/21(月) 11:04:31.25

>>527
Vulkanドライバーは薄いレイヤーだしコンフォーマンステストも充実してるからドライバーの質が良い可能性は高い
ちなみにOpenGL on Vulkanは既にあるぞ
Khronos謹製じゃないがな

**デフォルトの名無しさん** · 2016/11/21(月) 18:12:23.08

OpenGLをMFCのシングルフォームビューで使用しています。
ピクチャーコントロールをOpenGLで描画しているのですが、他のウィンドウがかぶっていると描画されません。
何か解決策ないでしょうか？

**デフォルトの名無しさん** · 2016/11/21(月) 21:41:00.70

>>529
WebGL3があるならES4.0が実装されるはずだけどそもそもリリースされるのかね？
もはやES3.2で完成してんじゃないかとすら思えるけどね

**デフォルトの名無しさん** · 2016/11/21(月) 23:35:12.90

>>533
OpenGLそのままでもVulkanそのままでも無い何かが作られるなら
WebGL3って言い方は適切じゃなかったな

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

**デフォルトの名無しさん** · 2016/11/21(月) 23:43:31.58

>>534
それ言ったらWindows版ブラウザのWebGL実装は全部DirectXを呼び出してるよ
それがVulkanになるのは時間の問題だろうね
WebGL→DirectXは右手系左手系とかシェーダーの違いとか苦労してるみたいだからVulkanの方が親和性は高いはず

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

**デフォルトの名無しさん** · 2016/11/21(月) 23:49:37.90

そろそろデフォで有効になるWebGL2はPS3以上PS4未満の能力があるから、それで十分だと思うけどね
限界までパフォーマンスを追求するようなプラットフォームじゃないし

**デフォルトの名無しさん** · 2016/11/23(水) 12:41:38.02

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程度

**デフォルトの名無しさん** · 2016/11/23(水) 13:43:42.26

Javascriptとかwebassemblyがネイティブコード並に速くならないとwebvulkanがあってもJavascriptの実行自体がボトルネックになって速くならない。
セキュリティチェックが必要だからネイティブコード並に早くするのは無理。
なのでAPI呼び出しを減らせるようにwebglを設計しようということか。

**デフォルトの名無しさん** · 2016/11/24(木) 03:11:55.41

Vulkan SDK 1.0.33.0

**デフォルトの名無しさん** · 2016/11/24(木) 09:37:42.37

>>532
今時MFC？

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

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

**デフォルトの名無しさん** · 2016/11/24(木) 19:18:00.38

>>538
JavaScriptとWebAssemblyは同じじゃない
WebAssemblyは遅くてもせいぜいネイティブコードの1.5倍以内の遅さに収まってる
いずれオンゲーはWebAssembly+WebGL2な環境で動かすのが普通になるだろうね

**デフォルトの名無しさん** · 2016/11/24(木) 19:45:27.71

そもそもJSじゃ速度が測定時の状況でかなり変わるし

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

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

**デフォルトの名無しさん** · 2016/11/24(木) 23:20:47.26

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

**デフォルトの名無しさん** · 2016/11/25(金) 09:25:52.13

そもそも実行時プロファイリングは最適化に手間(実行時間)をかける価値のある部分を見つけるためのものだよね？
本当なら全部を最適化をしたいけど、実行時コンパイルでそれやると最適化にかかる時間でかえって遅くなるから最適化処理を必要最小限にしたい
→もっとも効果がある部分をプロファイリングで探す…って

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

**デフォルトの名無しさん** · 2016/11/25(金) 09:43:31.68

そういうベンチ結果ならあるから絶対ないって事は無いだろう

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

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

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

**デフォルトの名無しさん** · 2016/11/25(金) 09:50:03.45

実行結果から最適化した方が良いコードを生成できる可能性高いしな。
エラー処理とかまず通らないコードをインライン展開してもコード密度悪くなって逆に性能悪くなるし。
(コンパイラ拡張で最適化のために殆ど通らないって属性付け出来たりするけど)

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

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

**デフォルトの名無しさん** · 2016/11/25(金) 09:56:19.33

「Rubyのしくみ」に載っているベンチマークでは、
JRubyのループ回数が10万回(0.3秒)から、100万回でも0.3秒なんだよね。
このタイミングでさらに、コンパイルして加速していく

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

**デフォルトの名無しさん** · 2016/11/25(金) 10:03:58.57

SwiftShaderもそういう最適化を行うために動的コード生成を利用してるらしい

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

**デフォルトの名無しさん** · 2016/11/26(土) 17:31:50.79

プロファイルベースの最適化は開発時にプロファイリングして
AOTコンパイル時のヒントとするやり方はかなり効果あるだろう
実際chromeが起動時間が20%速くなったとかあったな
それとJITコンパイラする実行しながらプロファイリングするのと一緒にしてはいけない

**デフォルトの名無しさん** · 2016/12/16(金) 04:43:37.82

DX11はDX12の機能ほしくなる
あとはいまだにCPUにフレームレート引っ張られるのがいらっとくる

**デフォルトの名無しさん** · 2016/12/16(金) 13:27:10.53

Vulkan SDK 1.0.37.0

**デフォルトの名無しさん** · 2017/01/10(火) 04:17:52.45

よろしく

**デフォルトの名無しさん** · 2017/01/15(日) 08:46:04.47

glmapbufferrangeってglbindsubdataで代用できるよね？

**デフォルトの名無しさん** · 2017/01/18(水) 21:02:07.78

>>535
横からだが、座標系の違いはシェーダ時代だと存在自体がユーザの好みじゃないかな
GLとXの座標系の違いは固定機能が原因で、
シェーダだと座標系変換行列が吸収する。

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

**デフォルトの名無しさん** · 2017/01/18(水) 23:17:38.12

変換行列は一緒だぞ
右座標だろうが左座標だろうが関係ない

**デフォルトの名無しさん** · 2017/01/20(金) 11:43:09.83

えっ、Zのプラスとマイナスが違うのに？

**デフォルトの名無しさん** · 2017/01/20(金) 23:47:40.41

Zを+にするか-にするかはアプリがどういう行列を作るかで決めることでグラフィックのAPIレベルでは関係ないぞ。
実際にUnityはGL、Metal、DirectXのどれを使っても左手座標だぞっと。

**デフォルトの名無しさん** · 2017/01/20(金) 23:49:00.32

多分固定機能時代はそれぞれが内部的に決まってたからそういう風に思ってる人が多いんだと思うが

**デフォルトの名無しさん** · 2017/01/20(金) 23:52:08.78

>>556
くやしいのぅ

**デフォルトの名無しさん** · 2017/01/21(土) 01:35:01.75

でもzの範囲の問題でprojectionは互換なかったりするよね？

**デフォルトの名無しさん** · 2017/01/21(土) 10:06:17.46

>>560
それはプロジェクション行列に下駄はかせるか頂点シェーダーで変換すればいいし、右左とは関係ないわな。

**デフォルトの名無しさん** · 2017/01/21(土) 13:20:01.43

ああ、なるほど確かに

**デフォルトの名無しさん** · 2017/01/23(月) 11:52:16.52

ttp://glslsandbox.com/
ここにglslのサンプルがいっぱいあるけど
ここのglslをコピペして自分のpcで動かしたいけどそういうのってできます？

**デフォルトの名無しさん** · 2017/01/23(月) 17:04:45.86

DirectXは左手系と言ってるみたいだけど、多分サンプルとかがそういう風に
実装されてるだけで、実際にはアプリが自由に決めていい
ただANGLEの実装ドキュメントによると最後のウィンドウ座標だけはY軸の向きが
OpenGLとDirectXで逆になってて変換する必要があると書いてあった
Y軸逆なのはテクスチャ座標もそうだな

**デフォルトの名無しさん** · 2017/01/23(月) 17:41:56.34

同じ座標指定したら右手と左手じゃおかれる位置が明らかに変わるんだから
自由じゃない

**デフォルトの名無しさん** · 2017/01/23(月) 18:39:41.15

>>542
jsみたいな高級言語だと、言語自体に予め遊びをいれておき、そこから適切なアルゴリズムを内側で変更するってことは可能じゃないかな
例えば、配列の探索。
シーケンシャルに読むコードであれば、ワークスレッドに分散して速度を稼ぐといった高速化ができる余地がある。
言語にスレッドがないからね

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

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

**デフォルトの名無しさん** · 2017/01/23(月) 18:52:56.50

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

**デフォルトの名無しさん** · 2017/01/24(火) 00:14:13.56

>>565
お前は…
カメラの位置とかデータの内容が全て左手系や右手系を前提に構築されてれば
まったく同じ見栄えのゲームが作れんだよ
だからどっちを選択するのかはアプリの自由という事が理解できないのか？

**デフォルトの名無しさん** · 2017/01/24(火) 00:40:56.70

レンダリングエンジンを抽象化するという発想がないんでしょ

**デフォルトの名無しさん** · 2017/01/24(火) 00:45:59.50

座標データのZのプラスマイナス逆に刷りゃ同じになるけどそれって自由な選択じゃなくて座標系に合わせてデータ差し変えてるわけで意味合いが違うな

**デフォルトの名無しさん** · 2017/01/24(火) 00:56:20.21

ああ右手用データを左手座標にぶちこんでも全部逆になるから結局見た目は同じになるって言いたいわけ？

**デフォルトの名無しさん** · 2017/01/24(火) 02:15:07.07

左手系の為に左手系のデータを用意するのも含めてアプリの自由だと言ってんだよ
やたら頭堅いやつが紛れてるな

**デフォルトの名無しさん** · 2017/01/24(火) 02:17:37.50

左手系の為に左手系のデータやプログラムを用意する
右手系の為に右手系のデータやプログラムを用意する
どっちかを決定するのはDirectXが決める事じゃなくてアプリの自由だという単純な事だぞ？

**デフォルトの名無しさん** · 2017/01/24(火) 08:24:46.56

>>570
座標系に縛られるから不自由とかはグラフィックス計算の話題じゃないな

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

**デフォルトの名無しさん** · 2017/01/24(火) 10:19:43.83

それよりボトムアップなのがややこしい
FBOでテクスチャに描いたときに上下が逆になってしまう

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

**デフォルトの名無しさん** · 2017/01/24(火) 15:21:07.00

Aという行列があるとして

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

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

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

**デフォルトの名無しさん** · 2017/01/24(火) 18:46:32.22

>>575
アプリ内で反転したテクスチャをレンダラに渡すって手もあるが猛烈にメモリーの無駄
うちはGIMPでエクスポートするとき上下の鏡像反転だね