OpenGL 2.0 専用スレ
OpenGL 2.0 専用スレ。
ここでは、OpenGL の猛者のみが生き残る――― >>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は知らんが。 ていうか商用のOpenGLゲームでアニメーションをどのように描画しているのか
激しく謎なんだけど誰かknow-how知りませんかね?
やっぱglDrawElementsでバッチしてるんだろうか。
しかし頂点座標はボーンの計算後に生成されるわけだしなぁ…。 >>199
glLockArraysEXTやってなければ大丈夫なんじゃないか? >199
GPUかCPUのどっちか暇そうなほうにやらせる。
GPUでやる場合は頂点シェーダ。
CPUでやる場合は描画前に頂点座標を計算してバッファに貯めとく。 DirectXだと頂点シェーダをCPUで実行させるのが簡単なんだよね。
正直言ってこの機能だけはうらやましい。 >>201
うーん、やっぱ動的に計算する時は頂点シェーダでスキニングってことになるのか。 >川瀬氏が今Cgいろいろやってるが、苦労してるようだ
何をいまさらって書き込みだよな。
Cgが遅いなんて使ってみればすぐ気づくだろうに。
俺はレジスタ256個分を変数で予約したら劇的に遅くなって気づいた。 Cgが遅いんじゃなくてCgFXの話ですよね?
CgFXって誰も使ってないっぽい
cgGetFirstTechniqueをググって3hitだし...
今自分もCgからCgFXにするかGLSLにするか悩み中。 >204
PS3のゲーム開発でCgやる必要が出てきたとか。
でも今はシリコンスタジオ勤務らしいからそれはないか。
つか個人的には早くGeometry Shaderでウハウハしたいんだが
きっとOpenGLだとベンダ拡張で出るだけで標準になるには1年以上かかるだろうな・・・。
ところでOpenGL2.1っていつ出るの? PS3だからってCg使わなくてもいいだろ。
コンパイルだけさせてレジスタへのパラメータ設定は
ARBの命令使えばいいし。
GLSLも遅いみたいだしそうしたほうが良くね? NVIDIAもわからんところだ。
あれだけ、シェーダのスペシャリスト中のスペシャリストばかり揃ってて
なんでこんな仕様&コンパイラになるんだ。 だから Cg はコンパイラとして使って、アセンブラで埋め込めって。
ライブラリの出来が悪いのはCgFXがマイクロソフトと共同開発だから。 >>208
まーく・じぇい・きるがーど先生のフォースが衰えてきてるから。 >>205
CgFXとGLSLを同列に語るのはおかしいんじゃないか?
CgFXはエフェクトファイルだからあえて比べるならAshliか。
Ashliは使ったことはないがな。
CgFXは遅い上に使い勝手も微妙だから自作した方が早いかも。 ちゅうか、おまえらCg以外にネタないんですかね?
あんましOpenGL2.0とも関係ないし。 実はマイクロソフトもDirectXのEffectクラスの使用は推奨してない。
ConstantTableなんて最近付いたがおかしいと思ったろ?
シェーダー言語はコンパイルだけして自分でシェーダーを扱う
ヘルパークラスを作ったほうが無難。
うまく行けばOpenGLとDirectXで共通に使える自分クラスが出来て便利。
フレームレートも大幅に向上する可能性あり。 MSはEffectクラスの利用を推奨してますがな。
んだからConstantTableとか拡張してんだよ。
GL2.0にもEffectファイルのレイヤーを実装するとか
予定には上がってたんだけど最近聞かないな…。だめぽ。
ID3DXEffectCompiler::CompileShaderを使ってシェーダーをコンパイルして
その時にConstantTableを受け取るんだそ。これやる時点でEffectクラス
なんざ使用しませんが?おれ何か間違えてる? コンパイル後のシェーダーに名前でデータセットするには
ConstantTableのようなクラスが足りなかったしね。
これでHLSLを使いつつもEffectクラスを使わずに済む。 uniform int numLights;
for (int i=0; i<numLights; ++i)
これでリンク通らんのは仕様ですかそうですか。
プログラマブルなんて上っ面だけで実際は描画前にガチガチに固めた
ある種の固定機能じゃねーかこの野郎。 またずいぶんな低脳が沸いてきたな。
汎用CPUと同じことが全部GPUでできるならCPUいらないよ。w