OpenGL 2.0 専用スレ
OpenGL 2.0 専用スレ。
ここでは、OpenGL の猛者のみが生き残る――― >>96
アリだと思う。ちょっと仕様変わる(JSR-231)が、Java 6 に標準装備される
可能性が高いし。 FBO拡張さわり始めたけどpbufferで心が折れそうになった俺には神的に使いやすいAPIだな。
DirectXから比べてもZBufferを簡単にテクスチャ化できるのも素敵だ。
しかし、まぁ、一昔前に比べると海外の情報サイトも激減したように見えるがどうかねぇ。
英語が読めない日本人ならいざ知らず外人まで何が仕様で何がドライバのバグなのか
混乱してDirectXに逃げてる感じ。
GLSL触っててドライバーのエラーで気づいたんだけどGLSLって
NVIDIAのドライバ内で一度cgコードに変換されてコンパイルされてんのね。
道理でコンパイル遅い訳だ。
GLSLってDirectXに比べて中間コード無しで直接ドライバにソースコード
渡せるからよりカツカツな最適化できるのがメリットとかテキトーな言い訳
してたけど結果がこれじゃねぇ。
DirectXから比べると遅いねぇ。
Effectファイルみたいなシェーダ管理機構もないからシェーダファイルの数も膨れ上がるし。
シェーダコードをバイナリ化しとけないのも×。
言っちゃなんだけど製品に使うには粗がありすぎだと思うけどどうか?
実際にGLSL使われてる製品ってあんの? っていうか、ゲームってGLばっかだと思ってたけど。
昔カーマックがDX使わないって言ってたのを聞いた事がある。 ゲームはほぼdirectxのみ。
多くの開発者にとって神であるカーマックがopengl支持だったから、辛うじて残ってたくらい。
そのカーマックすらxbox360でdirectx陣営に回りそうって話で、ゲーム分野での死滅は免れそうに無い。 はっきり言っちゃうと、個人的にはゲームなんてどうでもいい。
ゲームのおかげでGPUが安く高性能になったのには助けられているが。 ウンコリヤルエンジン3がOpenGLサポぅツ
だからPS3とダメ箱、PCでも問題ない ウンコリアルエンジン見たくドライバメーカと蜜月な関係に
でもならんとGLで製品作るのは相当辛いと思われるが。
なもんで、NVIDIAがライブラリを豊富に用意した
かつOpenGLなので面白い関数は速攻ライブラリ行きにできる
ましてコンソールだから承認を待つ必要もなく、
作ったところが自由に入れ込める
もし優秀ならばSDKアップデートとして他メーカーにも提供していけるという話
権利がどうなるのかは知らないが 何の話?そんな素敵ライブラリがあったらGLは衰退してねしょ? PS3の話と他の話の区別ができないバカも出るわけだわ ケータイゲーム業界(というよりキャリア(というよりチップメーカー))が
OpenGL/ESを選んだから
OpenGLのゲーム業界進出はこれからが本番だよ さすがにMS以外DirectX乗せるわけ無いからね glHogeSCE拡張の嵐でウンザリするに100EE。
そいうえばOpenVGとかどうなったんだろうな。 OpenGL毛嫌いすんのはアレでしょ、要するにアホ。
某自称社長なんか知ったかコイて「Xbox360のほうが性能がいい」とか言っていたが
ジョン・カーマックが「PS3のほうが性能はいい」
ああいう誰かも分からないアホよりもカーマックのいうことのほうが説得力がある
よくよく見れば単なるDXファンボーイ
そういうバカの集まりだよDXファンボーイは HEYユー
DXファンボーイを侮るんじゃあないぜ。やつらは大勢だ
そこんとこユーはアンダスタン? OpenGLなんか使われてもネェ・・・
オナニーじゃないんだから 情報がすくねーな。あとドライバのGL実装がバグバグ。
というかGLマンセーな人はATIやNVのドライバの糞実装で泣いた事は無いのか?
あいつら、明らかにやる気ないぞ。
>>120
全然。
S3が変な実装しているのを見かけたことはあるがな。 そか。その程度の所しか触ってないならそれはそれで幸せだと思うぞ。
人間楽な道に行くとバカなことしか言わなくなるし
ロクなこともできない 貧乏人って苦労してるからどんどんバカじゃなくなっていくね
じっと手をみる カーマックがDXボーイだったら、多分今頃落ちぶれてたであろう。 結局のところGLは実装依存になってるんだよなぁ
DXと何が違うのやら こっちのスレまで不毛な論争が入ってきたな。
どうなろうがここはOpenGL関連のスレなんだからOpenGLの価値否定ばっかしてもしょうがないだろ。
実際の2.0関連の話を粛々とすればいいんじゃないの? 粛々とする対象の話がない。
できるレベルに達している人が集まってない。 でも、DirectXの話ははっきり言ってうざいだけ。
どうしてもやるならOpenGL vs DirectXみたいなスレでも立てて
そちらへ隔離してほしい。 OpenGL2.0の達人の方々に質問です。
FBOに対してFSAAをかける方法解る人いますか?
拡張命令を目を皿にして眺めてもよくわかんなかったれす。
>>133
EXT_framebuffer_object の Issues 41 は読んだ? 久しぶりに来てみたら。なんだ。お前らまだOpenGLなんかやってやがる。
ダメじゃん。全然未来が見えてないジャン。
やっていることは。種子島の鉄砲伝来以来。変わってないジャン。
ま。そういう民族ってことなんだろうけど。
お前らには悪いが。私は一足お先に未来へと行かせてもらうよ。 >>135
両方のスレへコピペご苦労。はやく未来とやらに逝ってください。 コピペをコピペであると指摘するのはアホ
コピペにマジスレするのが知識人 最後の希望、OpenGL2.0専用スレも、もはや死に体同然だな。 >>135
一瞬、ちょっとだけ過去にタイムスリップしたかと思ったZE!
>>134
Issues41は読みました…。う〜良くわからん。
まだ実装されてないって事?実装する予定が無いって事?
またpbufferに逆戻りか…。
>>148
一言で言えば「まだできない」だと思う。各ベンダの独自拡張までは調べてないけど。 >>149
マジカ!折角pbufferの呪縛から逃れて新たにFBOで仕切りなおしかと思いきや
FSAAで拡張地獄に付き合わなきゃあかんのか。DX Boyがシャカリキになるのも
うなづけるってもんだ。
ってか、GLスレでちゃんとレス貰えると思わなかった。サンクス。
JavaのJOGLならpbufferの違いを隠蔽してくれるみたいだぞ GLSLでマルチテクスチャができねぇ
フラグメントシェーダで二つ目のテクスチャがサンプリングされない
つーか全てのレンダリングステートを意識するのが疲れる
glActiveTextureARB( GL_TEXTURE0_ARB ) / glActiveTextureARB( GL_TEXTURE1_ARB )とか
glEnable( GL_TEXTURE_2D ) / glDisable( GL_TEXTURE_2D )とか
BindTextureとか
とかいつどの順番でどう呼べばいいのかわからんボケ(`') GLSL
uniform sampler2D tex0, tex1;
↓
glUniform1i(glGetUniformLocation(prog, "tex"), 1); // GL_TEXTURE1
↓
glActiveTexture( GL_TEXTURE1)の後、glBindTexture
GLSLの時、glEnable/glDisableいらない(かも
↓
寝る くそっできねー
>>153
寝ないでくれ。
そんな感じでやってるのだがやっぱりダメできない。
テクスチャの読み込み時にもglActiveTextureARBは必要なのだろうか。どっちにしろできなかったけど。
VBO使ってるのは関係あるんかな。
今環境マッピングやってて、一つ目のテクスチャUVはVBOで、二つ目のテクスチャUVはフラグメントシェーダ中で計算してるのだけど。
今から非VBOでやってみる。
GLSL+マルチテクスチャできた人でつまづいたところとかあったら教えてくで。 >>154
テクスチャ読み込むときもバインド必要だよ。
読み込み
glBindTexture(...
gluBulid2DMipmaps(...
描画
glActiveTexture(...
glBindTexture(... まず152はテクスチャフェッチとテクスチャユニットの関係から勉強するべき。
ていうか実際にシェーダ書く前にシェーダパイプラインの構造を勉強するべき。
そんなんやってらんねーよ、とか言うなら素直にDirectXに行くべき。 非VBO(glMultiTexCoord2fARB)でもダメだった。一つ目のテクスチャしか表示されねぇ。
gl_FragColor = texture2DProj( tex1, gl_TexCoord[0] ) * texture2DProj( tex2, gl_TexCoord[1] );
>>155
そこは既に見ている、のだけど・・・
>>156
読み込み
glActiveTexture ←不要?
glGenTextures
glBindTexture
glTexImage2D
描画
glActiveTexture
glBindTexture
glTexParameteri
//ここで描画
>>157
了解、勉強してくる。たぶん中途半端な理解だから。 UVがおかしいのかテクスチャがおかしいのかをはっきりさせろ。
ためしに、
gl_FragColor = texture2DProj( tex2, gl_TexCoord[0] );
とか、
gl_FragColor = texture2DProj( tex1, gl_TexCoord[1] );
とか、やってみろ。 マジレスすると、
シェーダはテクスチャユニットからテクスチャをフェッチしてくるので
テクスチャユニットにテクスチャが何もバインドされていなければ
シェーダはテクスチャユニットからテクスチャをフェッチできない。
したがってシェーダでテクスチャをフェッチする場合は必ず
テクスチャユニットにテクスチャをバインドしてテクスチャユニットを
アクティブにしなければならない。 マジレスすると、
シェーダはテクスチャをバインドしてテクスチャユニットから
テクスチャをテクスチャユニットにテクスチャがフェッチしてくるので
テクスチャユニットにテクスチャがテクスチャユニットをアクティブに
何もバインドされていなければテクスチャユニットからテクスチャをフェッチ
シェーダはテクスチャユニットからテクスチャをフェッチできない。
したがってテクスチャユニットにシェーダでテクスチャをフェッチする場合は必ず
テクスチャユニットにテクスチャユニットをアクティブにテクスチャをバインドして
テクスチャユニットをテクスチャユニットからテクスチャをテクスチャユニットに
テクスチャアクティブにしなければならない。 正直こんなところでつまづくならDirectXのほうが理解が早いぞ。
DirectX10でまた色々強化されるし乗り換えておいたほうがいいんじゃね? やっとできた!
glUseProgramObjectARBでハンドルを指定する前にglUniform1iARBしていたのが原因だったようだ。
読み込み時にglActiveTextureする必要はなかった。
同じUV値で>>159の方法で悩んだり、なんかどんどん小さいエンバグしていって、もうn
レスしてくれた人、一緒に考えてくれた人、ありがとう。
アホだけど、やっぱり好きです。 >>172
OpenGL 1.3以降なら標準機能だす。無論2.0でも使える。 Xbox360大盛況でどうみてもDirectXの圧勝です。
OpenGLは終了致しました。
ご声援ありがとうございました。
今後はDirectXをお使いください。 まだだ! まだ我々にはOpenGL2.1がある!! glUniform1iARBって言えば、俺もハマッた記憶あるな。1時間ぐらい悩んだ。
つか、DX-Boyの俺にはサンプラ変数にシェーダ内に値が持てないのがまず理解できない。
cgでもつかえって事か。 CgはCgで色々ある
コンパイラに任せとくと実行速度が1/2になることも Cgは遅いから気をつけろよ。
無駄な変数を定義せず無駄なセットをしないこと。
シェーダーが切り替わると共有変数とか関係なしに
全変数(未使用も含む)が再セットされるのでコストがでかい。 Cg はライブラリは使わず、コンパイラとしてのみ使うのが吉だな。 DirectXのHLSLも同じくアセンブラにコンパイルして使ったほうがいいな。 >>179
>>180
まじで? CgがそうだってことはHLSLも?
GLSLはどうなんだろう・・・。 GLSLはよく知らないけど、CgやHLSLはアセンブラの知識が必須。
特にピクセルシェーダ1.x系列の場合は。
シェーダを書くときは一度コンパイル結果をアセンブラに落として
中身を確認した方がいい。特に従属テクスチャ命令なんかは命令の
制限が解ってないと、きちんとアセンブラの命令に落ちてくれない。
まあ、ピクセルシェーダ2.x以降は適当に書いててもコンパイル
できちゃうんだけどね。それはそれでまずいんだけど。 GLSLはループ回してる時に動的分岐入れるとまずコンパイルできない。
いや、コンパイルはできるんだがリンクできない。
「ループ時にブランチするな」とはどこにも書いてないので、恐らくコンパイラのバグなんだろう。
(ちなみにnVIDIAのCgコンパイラ経由)
かと言ってARB_vertex/fragment_programはループもブランチも実装されてないから
アセンブラでチマチマ書こうにも書けない。
結局、ベンダがコンパイラの質を上げてくれるのを待つしかない。 川瀬氏が今Cgいろいろやってるが、苦労してるようだ 投稿日 11月22日(火)04時29分 投稿者 Masa 削除
参照しているプログラムどころか、
使っている/いないに全く関係無しに、
エフェクト内の全ての uniform 変数は
エフェクト内の全てのプログラムに
連結されているみたいです。
結果、全く使われない無駄な連結が何百とあったので、
それを cgDisconnectParameter するだけでも
テストプログラム全体の速度が倍以上速くなりました。
…
ありえない…。 >>180はCgFXの話だよね?
>>185 GLSLじゃないけど、CgのFP40プロファイルとかはどうだろう。一応ループはコンパイル通って動いたよ。
NVIDIAのボードじゃないと動かないかもしれないけど つーかPCもビデオカードなんて捨ててGPUコアをCPUみたく直接M/Bに乗せるアーキテクチャにするべき。
で、広帯域のメモリをCPU/GPUで共有。勿論、各種バッファ(頂点、フレーム、ステンシルetc)にCPU側からアクセス可能、と。
正直RTVBなんかやってられないわけですよ。 まぁ、Shader1.x世代のコードを書いてた人にはHLSLはちょっとアレかも
知れないが実際には意外と予想した通りのコードを吐き出してくれる。
どのみちペアリング実行とかテクスチャレイテンシーは仕様制定されて
ないから中間コードをドライバが最適化してくれるのを期待するしかないしね。
つか同じボードで同じ処理をしてもGLSLの方が2〜3割減ぐらいでパフォーマンス
出ない。特に動的/静的分岐周りは意味不明なパフォーマンスになる。
FBOのバインドにはms単位でコストかかるし、本当にこれでゲーム作れるのか…
と疑問に思うよ。
セガのアーケードボードはLinux+OpenGL2.0なんだっけ?バーチャ5とか凄い映像
なんだけどやっぱドライバとか専用にカスタマイズしてもらってるんだろうね。いいなぁ。 >>190
>GLSLの方が2〜3割減ぐらいでパフォーマンス出ない
頂点の描画方法に問題があるかと
OpenGLはIMだとドライバのオーバーヘッドありまくりで激遅
DLも結局ドライバ内部で命令のスイッチが起こるのでVBOが最適 うはwいつのまにかOpenGL2.0専用スレらしくなってるw なんでもそうだが、コンパイラ任せでそのまんま
ってのはダメだ う〜ん、でもコンパイラトリッキーなコードはそれはそれで問題だからなぁ。
>>191
OpenGL(というかNVIDIAドライバ)はOpenGLになると急に頂点能力落ちるね。
ハードで効率よく扱える頂点ストリームに特定の法則があるっぽいんだが意味不明。
uniform変数の連結ポリシーもそうなんだけど、
そこら辺何も言わないしどこにも書いてないから困る
書かれてあれば、自分でディスパッチしたり切断したりできるのに >>194
VBO使えば、1つのバッファ・1つのデータ配列で頂点も法線もUVもカラーもマルチUVも一挙に流し込めるからマジお奨め。
しかもそのデータ配列の構造も自由に構成できるから(例えばGL_FLOATの頂点3/UV2/法線2)柔軟性が非常に高い。
まぁ、DirectXは知らんが。