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/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すら公開する必要はないけどな

**デフォルトの名無しさん** · 2015/12/24(木) 06:59:51.83

>>132
適当なこと言ってると後で痛い目見るよ
GPLって名前が入ってるものには一切手を触れないのが一番

**デフォルトの名無しさん** · 2015/12/24(木) 12:14:41.98

>>133
適当な事ってなんだよｗ
https://ja.wikipedia.org/wiki/GNU_Lesser_General_Public_License#LGPL.E3.81.AE.E7.89.B9.E5.BE.B4
Wikiのこんな簡単な文章すら理解できないのかよ

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

　

ヨウ
ヨウ
エビバーデー

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

あれは誤訳だ

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

という意味がある

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

　

**デフォルトの名無しさん** · 2016/01/03(日) 15:15:36.12

やっとglutに慣れて以前作った物理シミュレーションを可視化しようとしたら
これグローバル変数しか使えないじゃねえか

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

？

**デフォルトの名無しさん** · 2016/01/03(日) 15:48:18.16

何にせよglutを新規に使う場合は割り切りが必要だよ

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

**デフォルトの名無しさん** · 2016/01/03(日) 16:35:48.16

>>138
glutからでもGLSL使えるけど？

**デフォルトの名無しさん** · 2016/01/03(日) 16:56:42.16

使えるけど何なんだよ
glut使いたいなら使えばいいよ

**デフォルトの名無しさん** · 2016/01/03(日) 17:26:15.79

>>138はglutを使うには固定機能を使わざるを得ないっていう風によめるんだけど、
どういう割り切りが必要だって主張してんの？

**デフォルトの名無しさん** · 2016/01/03(日) 18:13:26.24

構造体とか自由に渡せるようにするにはどうすればいいんだ
glfw使える環境にはしたけどこれ勉強すればいいのか？

**デフォルトの名無しさん** · 2016/01/03(日) 18:32:59.62

>>141
glutを使うのは目的じゃなく手段だろ
そんな基礎的な前提すら共有できていない時点で議論にならん

**デフォルトの名無しさん** · 2016/01/03(日) 20:06:01.37

いやこれは>>141のように読めてしまいますわ

**デフォルトの名無しさん** · 2016/01/04(月) 02:24:11.49

OpenGLでレンダリングしたものだけ表示できて、マウスとキーボード入力ができればいいのであればglfw。
OpenGLと一緒にGUIを使ったり数字や文字列や表やグラフも表示したいならQtを使えばいいかと。
だいたいゲームとかメガデモ以外ならQt上でOpenGLを使えばいいんじゃないだろうか

**デフォルトの名無しさん** · 2016/01/04(月) 12:23:55.71

>>138はGLUTに含まれてるプルダウンメニュー？とかが固定機能使ってるって
言いたいんじゃなかろうか？
glutCreateMenu()とglutAddMenuEntry()で簡単にメニュー作れるのは便利だけど
これは固定機能で実装されてるような気がする（詳しくは知らんけど）

**デフォルトの名無しさん** · 2016/01/04(月) 14:16:04.29

>>146
glutのmenuの実装にはOpenGL使ってないです

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

**デフォルトの名無しさん** · 2016/01/05(火) 11:17:26.76

>>145
んじゃQt勉強してみるわ
ありがとう

**デフォルトの名無しさん** · 2016/01/07(木) 00:12:20.20

もっと活気あるところない？

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

　

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

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

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

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

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

　

**デフォルトの名無しさん** · 2016/01/07(木) 19:39:25.20

ソフトウェアじゃ後追いしかしてないからね

**デフォルトの名無しさん** · 2016/01/07(木) 21:00:26.62

今までOpenGL1.5程度しか使ってこなかったんだけど、シェーダ周りを勉強してみようかと思ってる
2.xは飛ばして3.xに行ったほうがいい？

**デフォルトの名無しさん** · 2016/01/07(木) 21:01:01.81

今までOpenGL1.5程度しか使ってこなかったんだけど、シェーダ周りを勉強してみようかと思ってる
2.xは飛ばして3.xに行ったほうがいい？

**デフォルトの名無しさん** · 2016/01/07(木) 21:01:28.13

すまん、連投してしまった

**デフォルトの名無しさん** · 2016/01/07(木) 21:54:57.44

グラフィックスってただの数学だけどな
数学は中学から教えてる訳だから大学がどうこう言うのは関係無い
日本の企業が結果出てないからひとつ前の大学が悪いって言ってるだけだ

**デフォルトの名無しさん** · 2016/01/08(金) 00:51:53.40

ゲームだと、「ゲームの作法」ってのがあるからな
シェーダ知ってるだけではすげえ遅くなる

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

**デフォルトの名無しさん** · 2016/01/08(金) 00:53:25.41

自動車なども、大学院出ていればすぐに働けると思うはずだが
学校で研究したことと、実際に使用している技術と起こる現象が全然違う

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

ウソ教えているに等しい

**デフォルトの名無しさん** · 2016/01/08(金) 03:40:24.22

>>153
3では一部の古い機能が非推奨になったから
古い機能を使わなくて済むなら３でいいよ

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

**デフォルトの名無しさん** · 2016/01/08(金) 11:35:19.21

>>156
そういう小手先のテクより未知のアルゴリズムの発見とか既存のアルゴリズムを
改善とかする方が大幅にクオリティは上がる
ゲーム専用機は全部自分でメモリ管理する必要があって面倒かも知れないけど
結局は誰がやっても大差ないところで落ち着く

**デフォルトの名無しさん** · 2016/01/08(金) 16:27:21.83

ゲーム専用機か、、
もう死語レベルだよな
3dsも死に体だし

**デフォルトの名無しさん** · 2016/01/08(金) 20:05:27.31

>>160
んなわけない、海外だと据え置きゲーム機が絶好調だ
GTA5とか3000万本以上売れて全エンターテイメント中で最高売り上げを記録してるよ
日本のゲーム売り上げ高なんて全世界の20分の1にも満たないけど
日本だけで考えればゲーム機は衰退しつつはあるな。ずっとそうかは未知数だが

**デフォルトの名無しさん** · 2016/01/10(日) 11:22:56.00

世界を相手にしている人が2chの辺境スレで
燻っているならそれは残念なことだなぁ

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

**デフォルトの名無しさん** · 2016/01/10(日) 12:05:17.29

それと結局クオリティの根幹はデータだよ
高度なライティングを実装したところでテクスチャが糞なら糞

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

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

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

**デフォルトの名無しさん** · 2016/01/12(火) 13:17:11.20

>>163
逆だな
テクスチャが糞でもライティングが良ければパッと見綺麗になる
海外製のFPSとか見たことあるのか？
テクスチャは日本製の丁寧に書き込まれたのに比べると糞だぞ
だけどシェーダーの出来がいいからスゲーリアルに見える
あとFPSとか地形モデルやテクスチャは自動生成していくのが主流じゃないのか？

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

**デフォルトの名無しさん** · 2016/01/12(火) 16:02:12.20

「未知の」アルゴリズムに先行研究がある訳ないだろ
パラメータチューニングとか具体的なノウハウが非公開ってのはありがちだが
それをアルゴリズムとは言わない

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

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

**デフォルトの名無しさん** · 2016/01/12(火) 17:02:49.60

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

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

**デフォルトの名無しさん** · 2016/01/12(火) 18:51:36.57

読み取れないなら絡んでくるなよ

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

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

**デフォルトの名無しさん** · 2016/01/12(火) 19:01:28.44

ただ>>159が「未知のアルゴリズムの発見」を
他所の誰かがやってくれるって話なら>>163は的外れだ

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

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

**デフォルトの名無しさん** · 2016/01/12(火) 19:19:07.45

>>167
お前こそOpenGL関係無い話しをすんなよ、アホか
突然データの話しをし始めたのはお前だろ

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

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

**デフォルトの名無しさん** · 2016/01/12(火) 19:23:10.13

>>168
>>159の「小手先のテク」は>>156の据え置き機のAPIはメモリ管理が～的な話しに対してだろ
ちゃんとアンカーしてんだから脊髄反射で糞みたいな返答しないで流れを見ろよ

**デフォルトの名無しさん** · 2016/01/16(土) 13:18:31.86

OpenGLって動画を背景にできないのかよ
本当に使えないな

**デフォルトの名無しさん** · 2016/01/16(土) 17:08:00.30

できるよ
使えないのはお前の頭だよ

**デフォルトの名無しさん** · 2016/01/16(土) 23:21:49.05

まじかよ
買い換えてくるわ

**デフォルトの名無しさん** · 2016/01/17(日) 09:25:58.94

アンパンマンか

**デフォルトの名無しさん** · 2016/01/22(金) 02:55:19.84

>>134
読んだら解ると思うけど、LGPLのライブラリを静的にリンクして生成されたオブジェクトコード(実行バイナリーも含む)

**デフォルトの名無しさん** · 2016/01/22(金) 03:01:13.65

途中で書き込んでしまった

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

**デフォルトの名無しさん** · 2016/01/22(金) 12:42:22.88

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