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/

**デフォルトの名無しさん** · 2015/09/21(月) 00:42:42.41

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

**デフォルトの名無しさん** · 2015/09/21(月) 01:27:50.66

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

**デフォルトの名無しさん** · 2015/09/21(月) 06:53:50.45

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

**デフォルトの名無しさん** · 2015/09/21(月) 19:09:44.31

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

**デフォルトの名無しさん** · 2015/09/22(火) 15:49:19.14

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

**デフォルトの名無しさん** · 2015/09/24(木) 00:46:56.91

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

**デフォルトの名無しさん** · 2015/09/24(木) 01:10:48.32

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

**デフォルトの名無しさん** · 2015/09/24(木) 02:47:19.21

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

**デフォルトの名無しさん** · 2015/09/24(木) 02:52:10.66

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と相性悪そうな気がする

**デフォルトの名無しさん** · 2015/09/24(木) 02:52:42.00

誤爆

**デフォルトの名無しさん** · 2015/09/27(日) 17:17:31.03

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

43 · 2015/09/27(日) 17:20:16.60

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

**デフォルトの名無しさん** · 2015/09/27(日) 23:51:56.33

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

43 · 2015/09/29(火) 00:37:27.42

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

**デフォルトの名無しさん** · 2015/10/16(金) 10:10:43.89

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

**デフォルトの名無しさん** · 2015/10/16(金) 10:32:49.32

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

**デフォルトの名無しさん** · 2015/10/16(金) 10:38:04.32

>>47
二枚目って自作？
とりあえず続きはブログでやってくれ

**デフォルトの名無しさん** · 2015/10/17(土) 09:57:29.33

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

**デフォルトの名無しさん** · 2015/10/23(金) 09:31:24.55

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

**デフォルトの名無しさん** · 2015/10/23(金) 14:20:58.65

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

**デフォルトの名無しさん** · 2015/10/25(日) 13:13:26.63

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

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

**デフォルトの名無しさん** · 2015/10/25(日) 13:14:32.16

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

**デフォルトの名無しさん** · 2015/10/25(日) 15:10:32.81

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

**デフォルトの名無しさん** · 2015/10/26(月) 19:03:55.27

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

**デフォルトの名無しさん** · 2015/10/26(月) 23:26:16.82

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

**デフォルトの名無しさん** · 2015/10/26(月) 23:38:52.89

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

**デフォルトの名無しさん** · 2015/10/26(月) 23:48:03.22

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

**デフォルトの名無しさん** · 2015/10/26(月) 23:51:14.09

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

**デフォルトの名無しさん** · 2015/10/27(火) 00:20:29.74

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

**デフォルトの名無しさん** · 2015/10/27(火) 00:46:01.74

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

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

**デフォルトの名無しさん** · 2015/10/27(火) 00:48:11.27

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

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

57 · 2015/10/27(火) 02:09:35.31

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

**デフォルトの名無しさん** · 2015/10/27(火) 11:55:48.66

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

**デフォルトの名無しさん** · 2015/10/27(火) 13:15:44.86

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

**デフォルトの名無しさん** · 2015/10/27(火) 13:47:32.50

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

**デフォルトの名無しさん** · 2015/10/28(水) 21:53:41.91

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

**デフォルトの名無しさん** · 2015/10/29(木) 20:41:18.37

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

**デフォルトの名無しさん** · 2015/10/29(木) 20:49:56.74

なんか有利あんだっけ？

**デフォルトの名無しさん** · 2015/10/29(木) 20:54:28.65

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

**デフォルトの名無しさん** · 2015/10/30(金) 09:47:52.19

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

**デフォルトの名無しさん** · 2015/10/30(金) 19:15:23.10

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

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

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

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

**デフォルトの名無しさん** · 2015/10/30(金) 23:18:37.32

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

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

**デフォルトの名無しさん** · 2015/10/31(土) 10:55:57.04

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

**デフォルトの名無しさん** · 2015/10/31(土) 12:10:59.00

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

**デフォルトの名無しさん** · 2015/10/31(土) 12:39:03.93

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

**デフォルトの名無しさん** · 2015/10/31(土) 12:43:38.96

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

**デフォルトの名無しさん** · 2015/10/31(土) 14:54:45.53

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

**デフォルトの名無しさん** · 2015/10/31(土) 18:10:18.47

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

**デフォルトの名無しさん** · 2015/10/31(土) 19:11:13.20

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

**デフォルトの名無しさん** · 2015/10/31(土) 19:40:24.93

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

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

**デフォルトの名無しさん** · 2015/11/01(日) 02:26:33.11

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

**デフォルトの名無しさん** · 2015/11/03(火) 14:21:40.06

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

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

**デフォルトの名無しさん** · 2015/11/03(火) 23:10:42.25

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

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

**デフォルトの名無しさん** · 2015/11/04(水) 11:22:45.65

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

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

**デフォルトの名無しさん** · 2015/11/04(水) 13:18:18.56

>>86
別にWebGLでは使ってないとは書いてないけど

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

**デフォルトの名無しさん** · 2015/11/08(日) 18:44:22.99

質問させてください。

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

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

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

**デフォルトの名無しさん** · 2015/11/08(日) 19:25:23.39

>>88
なってません

**デフォルトの名無しさん** · 2015/11/08(日) 20:18:26.44

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

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

**デフォルトの名無しさん** · 2015/11/08(日) 22:02:27.62

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

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

**デフォルトの名無しさん** · 2015/11/08(日) 22:41:34.77

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

**デフォルトの名無しさん** · 2015/11/08(日) 23:20:50.59

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

**デフォルトの名無しさん** · 2015/11/09(月) 00:18:42.73

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

**デフォルトの名無しさん** · 2015/11/09(月) 03:37:54.95

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

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

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

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

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

**デフォルトの名無しさん** · 2015/11/09(月) 03:41:04.72

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

**デフォルトの名無しさん** · 2015/11/09(月) 17:34:15.03

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.

**デフォルトの名無しさん** · 2015/11/09(月) 18:48:25.44

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

**デフォルトの名無しさん** · 2015/11/09(月) 23:02:58.43

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

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

分散レンダリングで60fpsを目指すとかさすがだな

**デフォルトの名無しさん** · 2015/11/11(水) 00:08:45.71

技術的課題がたくさんあって燃えますね

**デフォルトの名無しさん** · 2015/11/11(水) 13:18:34.30

レイテンシ問わないならあるいは……
でも並列化が可能なデータなら
クラスタ化の前にできることがあるような……

**デフォルトの名無しさん** · 2015/11/16(月) 11:45:42.10

ディファードレンダリングにして各GPUにどのタイルをレンダリングするかを
割り当てれば割と簡単に分散は出来そうだな
ただ頂点処理はかなり重複する事になるから多ポリゴンをレンダリングする
目的には1GPUの時とあまり変わらずに結局向かないと思うよ

**デフォルトの名無しさん** · 2015/11/16(月) 14:17:04.85

4.2からglMemoryBarrier増えてるけどこれってComputeShader使う場合のみ
必要って認識であってる？
例えばTransformFeedbackでVBOの頂点情報変形させてから続けてそのVBO使って
通常の描画する場合ってMemoryBarriorしなくても古いVBOのキャッシュで
描画したりはしないよね

**デフォルトの名無しさん** · 2015/11/17(火) 22:11:56.27

Radeon R7 200 でVTFしようとしてるんだけど
バーテックスシェーダー内でvec4 col=texture(texture1,texcode0);
してもテクスチャカラーがuv 0,0の位置のしか所得出来ない
フラグメントでは問題無く持ってこれる、ドライバ問題？

**デフォルトの名無しさん** · 2015/11/18(水) 01:51:07.68

>>105
別にマイナーな機能でもないし可能性は低いと思う
最新のドライバにして改善しないなら多分お前のコードにバグがある
テクスチャ周りはミスしやすいから
テクスチャユニットの番号が間違ってないかとか
座標の値がおかしくないかとか
ユニフォームの設定が間違ってないかとか調べ直したほうがいい

**デフォルトの名無しさん** · 2015/11/18(水) 13:29:47.46

>>106
何か情報無いかなと書いてみたんだけど、
やはり自前バグの可能性たかいよね、もう一度調べてみるわ

**デフォルトの名無しさん** · 2015/11/18(水) 13:39:58.84

シェーダー内で途中でintを経由して値が0になってるとかだろうな

**デフォルトの名無しさん** · 2015/11/18(水) 21:29:46.73

シェーダー周りはデバッグが大変で死ねる

**デフォルトの名無しさん** · 2015/11/20(金) 10:33:54.68

105の件解決（？）しました
４頂点の単純な板ポリで試してたんだけど四隅が全部黒の値拾っていた、
で
トーラスの頂点数の多い物で試したらキチンと反映していた
UVが1.0の値補完か何かで0.0位置の色を拾ってたくさいｗ

**デフォルトの名無しさん** · 2015/11/20(金) 11:35:21.04

>>110
VTFを数値データとして使うなら普通0.5足してピクセル中央をフェッチするんだよ

**デフォルトの名無しさん** · 2015/11/20(金) 12:50:56.16

>>111
もしかしてUVの画像位置と合わせて頂点を凸凹させる時も？

**デフォルトの名無しさん** · 2015/11/20(金) 13:35:46.41

>>112
すまん>>111は書き方が変だったので訂正しておく
0.5というのはu = (x + 0.5) / 1024 のようにするという事を言いたかった
だから最終的に足されるのは0.5とは限らない

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

**デフォルトの名無しさん** · 2015/11/20(金) 13:44:41.38

>>113
やっと理解したかも、補完かからない対策ですね
、１ドットの中心をアクセスすれば安全って事ですか？

**デフォルトの名無しさん** · 2015/11/20(金) 13:51:59.28

>>114
そうだ
あとFILTERの値もNEARESTにする

**デフォルトの名無しさん** · 2015/11/20(金) 13:53:30.75

>>115
ありがとう！たすかる

**デフォルトの名無しさん** · 2015/11/23(月) 02:11:18.29

glPolygonOffsetでポリゴンの前後関係を調整するのに環境によって
前後関係が異なる結果になることがあるんだけど上手い対策とか無いでしょうか？

**デフォルトの名無しさん** · 2015/11/23(月) 10:05:33.22

上手い対策というのは知らないが
unitsを使わないとか
自前でオフセットを計算しとくとか
そもそもZテストを使わないとか

**デフォルトの名無しさん** · 2015/11/23(月) 10:08:58.35

あとglDepthRange()を使うというテクニックがあったような

**デフォルトの名無しさん** · 2015/11/24(火) 10:45:52.65

>>117
環境ってGPUの違いとかOSとかの事か？
単にシーンの違いとかだとまじめに計算すればちゃんとうまく行くはず
ちなみにZ値は遠くへ行くほど荒くなってるから同じオフセットでも前後関係は変わる

**デフォルトの名無しさん** · 2015/11/26(木) 21:13:44.72

今までWindowsでDirect3D（9、11）を使ってたんですが、
新たにAndroidでOpenGL ES 2.0を使おうと考えています。
レンダリングした結果をCPU側に戻すのをやりたいんですが、
OpenGL ES 2.0で可能でしょうか？

**デフォルトの名無しさん** · 2015/11/26(木) 21:59:37.29

glReadPixelsで読める
が、激遅の場合がある、というよりまず遅いと思ったほうがいい
てかそれくらいググれ

**121** · 2015/11/26(木) 22:08:43.27

>>122
ありがとうございました！

**デフォルトの名無しさん** · 2015/12/11(金) 16:33:56.96

OpenSceneGraphなんてあるんだ。
始めて知った。

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

**デフォルトの名無しさん** · 2015/12/11(金) 16:45:50.46

なんだOpenSceneGraphのライセンスはLGPL系か。
GPLは使えない（使いたくない）な。

**デフォルトの名無しさん** · 2015/12/11(金) 17:58:57.42

GPLとLGPLって内容は大分違うと思うんだが

**デフォルトの名無しさん** · 2015/12/11(金) 18:06:39.16

GPLって付くだけで怖い

**デフォルトの名無しさん** · 2015/12/11(金) 19:46:36.96

無知は罪だぜ

**デフォルトの名無しさん** · 2015/12/12(土) 00:13:27.08

LGPLは改変せずに使うなら幾ら使っても問題になる事はない

**デフォルトの名無しさん** · 2015/12/12(土) 00:20:10.16

LGPLはおおまかには、静的リンクか動的リンクかでソース公開の義務が変わる

**デフォルトの名無しさん** · 2015/12/12(土) 00:29:53.71

たしかライブラリ側が更新された時にプログラム全体が更新出来るように公開する、だっけ

**デフォルトの名無しさん** · 2015/12/12(土) 00:49:12.40

>>130
そういう事言うからLGPLが敬遠されるんだろうな
スタティックリンクでもソース公開の義務は無いよ
最悪*.oを公開するだけだ
それもゲーム機とか家電用の場合は実行ファイル自体が非公開だから*.oすら公開する必要はないけどな