OpenGLスレ Part11 at TECH
[2ch|▼Menu]
143:デフォルトの名無しさん
07/06/16 01:23:33
>>140
LGPL はスタティックリンクしてもソースは公開しなくて良いんだぜ。
他人が再リンク可能なようにする必要があるだけだから、リンク前の
オブジェクトファイルを同梱しておけばオーケー。ソースは隠しておけ。

144:デフォルトの名無しさん
07/06/16 01:28:53
>>143
おおっ、トリッキーな情報さんきゅです。
確かにそんなこと書いてあった気がする。
これで恥ずかしい自コードを隠しておけそうですヽ(´▽｀)/

145:デフォルトの名無しさん
07/06/16 18:19:21
> LGPL はスタティックリンクしてもソースは公開しなくて良いんだぜ。

嘘はいけないよ、嘘は・・・

146:デフォルトの名無しさん
07/06/16 18:28:43
>>145
釣りするつもりならもう少し工夫したらどうなんだ?
最近少し頑張りが足りないぞ。

147:デフォルトの名無しさん
07/06/16 18:56:46
おいおい、LGPLは動的リンクでないとLGPLになるよ。

だから、みんな、DLLにしてるのに・・・

148:デフォルトの名無しさん
07/06/16 19:09:54
>>147
gnu.org 逝って来い
思い込みだけで書き散らしてないで、原文をきちんと読め

149:デフォルトの名無しさん
07/06/16 19:10:06
というかLGPLなのにソース公開されてないの？

150:デフォルトの名無しさん
07/06/16 19:49:54
つうか、2007 年にもなって LGPL にソース公開義務があると
思っている人間がいたのが驚きだ…

151:デフォルトの名無しさん
07/06/16 23:12:49
lgplを採用するプログラム（ライブラリ）自体にはソースの公開義務はあるだろうよ…
ソースの公開義務が無けりゃ、ＢＳＤとかわらんではないか…

俺は勝手にwikipediaのWikipedia項目ﾘﾝｸが正しいとか思ってるんだが、どうだろうか？

152:デフォルトの名無しさん
07/06/17 15:41:18
for(i=0;i<WIDTH;i++){
for(j=0;j<HEIGHT;j++){
/* test source */
glGetDoublev(GL_MODELVIEW_MATRIX, model);
glGetDoublev(GL_PROJECTION_MATRIX, proj);
glGetIntegerv(GL_VIEWPORT, view);
glReadPixels(i, j, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &z1);
gluUnProject(i, j, 0, model, proj, view, &x1, &y1, &z1); //スクリーン上の座標をワールド座標で取得

/* test source */
}
printf(" at (%d, %d) --> ", i, j);
printf(" at unproject (%lf, %lf, %lf)\n", x1, y1, z1);
}

スクリーン上の各ピクセルが、ワールド座標上でどうなっているのか知りたくて
上のようなソースを書いたのですが、変な値が入ってきます。

視点を<10 10 -20>において、<10 10 0>を見ているときに
左端のX～右端のXを表示しても　
at (0, 256) --> at unproject (10.552285, 10.465990, -19.000000)
at (255, 256) --> at unproject (9.672081, 10.465990, -19.000000)

画面の幅が縦横256なのに、こんな小さな差しか出てきません。
これだとスクリーンは左端～右端までワールド座標中で約-0.5～0.5の差でしかないということでしょうか


gluPerspective(45.0, (double)w / (double)h, 1.0, 1000.0);はこのようにしております。
スクリーンの点から空間の点を知る方法を教えてください

153:デフォルトの名無しさん
07/06/17 15:54:22
スクリーン上の点を空間で表すと直線になるけどな。

154:デフォルトの名無しさん
07/06/17 16:06:50
すみません。仰ってることがわからないです

上のことは、私の勘違いだったかもしれません
画角を90度にして、画面も正方形で作ってみました

そうすると距離が1離れているスクリーンは
左端が-1　右端が+1になりますねよね。

それで正しい値だと認識できました。


155:デフォルトの名無しさん
07/06/17 17:02:30
>>152
とりあえず
gluUnProject(i, j, 0, model, proj, view, &x1, &y1, &z1);
↓
gluUnProject(i, j, z1, model, proj, view, &x1, &y1, &z1);
じゃねぇかね？

156:デフォルトの名無しさん
07/06/17 18:41:26
ワールド座標中でのスクリーンが欲しいときは0にすると以前教えていただきまして
z1だとこの場合スクリーンより奥の値になりますよね？

ここまでやって、スクリーンに向かって光線を打てると思ったのですが詰まりました…はぁ…



157:デフォルトの名無しさん
07/06/17 19:42:18
>>156
＞ワールド座標中でのスクリーンが欲しいときは0にすると以前教えていただきまして
はっきりいって間違ってるよ

158:デフォルトの名無しさん
07/06/17 19:43:06
>>152
>これだとスクリーンは左端～右端までワールド座標中で約-0.5～0.5の差でしかないということでしょうか
そーゆーコトです。(gluPerspectiveに与えたwとhの比にもよりますが)

>gluPerspective(45.0, (double)w / (double)h, 1.0, 1000.0);はこのようにしております。
とのことなので、これはglFrustumでいえば
const double t = tan(22.5 / 180 * M_PI);
　glFrustum(
　　-1.0 * t * w / h,
　　1.0 * t * w / h,
　　-1.0 * t,
　　1.0 * t,
　　1.0
　　1000.0
　);
に相当しますから、nearクリック面の横幅はw/h*2tan22.5度、となります。

>スクリーンの点から空間の点を知る方法を教えてください
求められているように思えますが・・・。

159:デフォルトの名無しさん
07/06/17 19:54:32
多分152さんは、前スレの915～あたりの人ですよね。
もしいまだにnearクリップ面のことを「スクリーン」と呼んでるのなら、早く直した方がいいですよ。
独自の用語を使われると、意志の疎通以前に混乱を招きますので。

>>157
字面だけみると完全に間違ってる(笑)んですけど、
その辺の事情は前スレを見ないと分からないかと・・・。

160:140
07/06/17 20:18:51
ライセンススレ化してすんません。原文読んできました。
スタリンクするものはLGPLの派生物となるが、例外として、
リバエン/改変などの告知をし、完全かつ機械読み取り可能なオブジェクトコードあるいはソースコー ド(どちらかでも可) と一緒にする。
この「オブジェクトコード」がglui.libを指すのであれば大丈夫ですな

161:デフォルトの名無しさん
07/06/17 20:37:56
>>159さん
その節はありがとうございました。
一度他のことで時間を割かれてしまって、もう一度着手しているところです。
ご指摘もありがとうございます。手探りでやっている状態で、、、

上記の方法で、視点位置と、nearクリップ面とを結ぶ直線（レイ）を出そうとして
レイを単位ベクトルにしていざ使おうと思ったのですが
今度はそれと、立方体の面との交点の算出に苦戦しています。

ここはOPEN-GLじゃない、数学のレベルの問題なので、どうにかして頑張ります。
今日は帰れそうになさそうです(´；ω；`)

162:デフォルトの名無しさん
07/06/17 21:00:36
>>160
>この「オブジェクトコード」がglui.libを指すのであれば大丈夫ですな
違う、アプリケーションを構成する.oファイル全てなので、
公開しないコードの部分も.oは公開しないといけない。
つまり、コードは無くても良いけどLGPLの部分が置き換え可能な状態で無ければいけない。


163:デフォルトの名無しさん
07/06/17 21:28:27
>>161
交差判定は面倒ですね～。
こことか参考になるかもですよ。
URLﾘﾝｸ(ft-lab.ne.jp)

日曜なのに大変そうですね。
がんばれ～。・ω・`）ﾉｼ

164:デフォルトの名無しさん
07/06/17 21:30:40
>>162 が正解
LGPL 部分を自分で改変したバイナリで置き換えられる様に、.o を入手可能にする
必要がある。派生物の所持者が入手可能であれば良いから、世界に向けて公開する
必要は無いよ。

165:140
07/06/17 22:45:24
>>162,164
両氏ともありがとうございました。
オブジェクトコード＝.oだったんですね(;ﾟДﾟ)
なるほど、派生物所持者が再びリンクできるようにってことですね。
>世界に向けて公開する 必要は無い
バイナリといえど、ちょっと抵抗があったので安心しました。
重ね重ね感謝ですヽ(´▽｀)/

166:デフォルトの名無しさん
07/06/20 20:36:52
>>163
どうにか無事にレイと面の交差判定、できました！

あとはそれの効率化で頑張ります。
本当にありがとうございました！

167:デフォルトの名無しさん
07/06/23 08:15:38
c++でもextern"C"で頑張って、
dllやらsoを使うのが簡単な気がする。


168:デフォルトの名無しさん
07/06/24 04:46:17
光源の明るさを0にして描画しても真っ暗になりません。
具合的には、
GLfloat lightAmb[4] = {0.0f, 0.0f, 0.0f, 0.0f};
GLfloat lightDif[4] = {0.0f, 0.0f, 0.0f, 0.0f};
GLfloat lightSpe[4] = {0.0f, 0.0f, 0.0f, 0.0f};
glLightfv(GL_LIGHT0, GL_AMBIENT, lightAmb);
glLightfv(GL_LIGHT0, GL_DIFFUSE, lightDif);
glLightfv(GL_LIGHT0, GL_SPECULAR, lightSpe);

GLfloat mateAmb[4] = {1.0f, 1.0f, 1.0f, 0.0f};
GLfloat mateDif[4] = {0.0f, 0.0f, 0.0f, 0.0f};
GLfloat mateSpe[4] = {0.0f, 0.0f, 0.0f, 0.0f};
glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT, mateAmb);
glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, mateDif);
glMaterialfv(GL_FRONT_AND_BACK, GL_SPECULAR, mateSpe);

にして描画すると、薄暗く (RGB=0.1, 0.1, 0.1 ぐらいの暗さ) 描画されてしまいます。
原因がわかる人おりますでしょうか？

環境は、GeForce 7900 GS です。


169:デフォルトの名無しさん
07/06/24 10:16:44
GL_LIGHT_MODEL_AMBIENT

170:デフォルトの名無しさん
07/06/24 11:42:49
>>169
ありがとうございます。原因わかりました。
デフォルトで環境光 0.2 が加わるなんて、知りませんでした。

171:yd
07/06/25 19:05:50
だれかいますか？

172:デフォルトの名無しさん
07/06/25 19:09:03
(@益@ .:;)ﾉｼ

173:yd
07/06/25 19:20:10
こんち



174:yd
07/06/25 19:21:49
(x, y) = (0 + 0.557 * cos( 90 ), 0 + 0.557 * sin(90));
をFor文で回したいんですけどうまく逝きません；；




175:yd
07/06/25 19:31:25
円上にポイントを６４個、均等に置きたいんですm(__)m





176:デフォルトの名無しさん
07/06/25 20:13:16
これはひどいマルチ

177:デフォルトの名無しさん
07/06/25 21:16:28
>>175
int i;
float a;
const float b = 3.1415926535897932384626433832795028*2/64;

glBegin(GL_POINTS);
for(i = a = 0; i < 64; i++, a += b)
glVertex2f(cosf(a), sinf(a));
glEnd();


178:デフォルトの名無しさん
07/06/25 22:55:22
足し算は駄目だろ…

179:デフォルトの名無しさん
07/06/26 00:13:33
>>178
はあ？

180:デフォルトの名無しさん
07/06/26 00:31:45
>>179
誤差が蓄積するからって言う意味だろ。

181:デフォルトの名無しさん
07/06/26 00:45:55
>>180
でも差は、6.283185-6.283182=0.000003だけどな。

182:yd
07/06/26 04:01:08
ありがとうございます。早速試してみますm(__)m


183:デフォルトの名無しさん
07/06/26 04:04:36
どういたしまして

184:デフォルトの名無しさん
07/06/27 00:20:17
フィールドシーケンシャル ３DをOpenGLで実装したいのですが、
方法はさておき、左右の画像を１／２に間引きして交互に合成すれば
いいのでしょうか。こんな感じに

右右右右右右右右右右右右右右
左左左左左左左左左左左左左左
右右右右右右右右右右右右右右
（繰り返し）
左左左左左左左左左左左左左左

資料があまりないので確証がとれません。どこかにありませんか。
英語サイト可です。

185:デフォルトの名無しさん
07/06/27 00:51:01
立体視の話？

186:デフォルトの名無しさん
07/06/27 00:58:43
そうです。

例えば、
640x480右画像
640x480左画像
　　↓
奇数行は右画像から
偶数行は左画像から
　　↓
640x480の（裸眼では見るに堪えない）画像

でいいのでしょうか。それをOpenGLでやりたいんですが。もちろん動画です。


187:デフォルトの名無しさん
07/06/27 01:28:29
あなたがお使いのフィールドシーケンシャル方式のデバイスの
仕様に沿った形で画像データを渡せばよろしいかと思います。

188:yd
07/06/27 12:11:18
円周上にうたれた点に対して、１個飛ばしに円弧で結んでいきたいんですが
直線ニナら結べるんですけど、円弧だとどうアプローチしていいかわかりません
やさしい人教えてください。

189:デフォルトの名無しさん
07/06/27 21:25:16
ニナがキモイ

190:デフォルトの名無しさん
07/06/27 21:44:06
円周上の点を円弧で結んだら1個飛ばしとか関係なく全部の点通るんじゃね?
それはともかくOpenGLでやるなら細かい直線に分けて書く
それも面倒ならgluPartialDisk
ニナって誰?

191:Light
07/06/27 22:26:40
脳の視覚システムを研究している者です。
リンク先のような画像をOpenGLで作製したいのですが、うまくいきません。
URLﾘﾝｸ(en.wikipedia.org)

いまのアルゴリズムは、赤線を描いた後、緑線を描いているんですが、
それだと上描きしてしまうことになるので、リンク先の画像のように、
重なった部分が混ざり合ってぼけた感じになりません。

また、赤と緑を別々に描くと、僕のiMacだと後の方に描いた線が
バチバチします。計算量が無駄に多くなってしまっているのかもしれません。

何か良い解決方法はないでしょうか？
閃いた方、ぜひぜひご教授ください。

192:デフォルトの名無しさん
07/06/28 00:22:00
混ぜるのは色のアルファを指定してBlendしてくれ
ブレンドについてはGL_BLENDとかglBlendFuncで調べれば出てくるはず
パチパチというのはよく分からないがZ比較してるんでないかい?
glEnable(GL_DEPTH_TEST)をやってたらglDisableにしてみれ

あとこのレベルの質問はくだすれOpenGLスレに書いた方が適切と思われる

193:デフォルトの名無しさん
07/06/28 14:35:22
同業界人かよ
パチパチはvsyncに同期してないか、
ダブルバッファリング関係かどちらかかと思われる

194:Light
07/06/28 23:39:57
>>192 & 193の方へ

回答、ありがとうございます。
GL_BLENDは可にしていたんですが、glBlendFuncのパラメーターが良くなかった
ようです。glBlendFunc( GL_SRC_ALPHA, GL_ONE );でうまく色を融合できました。
バチバチは、glutIdleFunc( idle ); を入れると起こってしまいます。
ただし、idle関数の中身は、glutPostRedisplay();です。
glutSwapBuffers()を使っています。
もう少し自分でやってみて、また判らなければ「くだすれOpenGLスレ」に
投稿したいと思います。

195:デフォルトの名無しさん
07/07/03 02:15:15
手抜きOpenGlにあるサンプルが起動しません。
どうしたらいいのですか?


196:デフォルトの名無しさん
07/07/03 02:44:55
>>195
どういうふうに起動しないのよ？
環境わからんからなんとも言えんけど、GLUTは適切にインストールされてる？

197:デフォルトの名無しさん
07/07/03 08:25:16
【派遣ネガティブ根性チェック】

3つ以上、チェックがつけばアナタの性格はひん曲がっており、
ネガティブ負け組派遣人生を歩んでいます。

□派遣先正社員の作った糞開発ツールはたとえ腐っててもマンセーして使う
□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□昼食は必ず派遣先の社員と行くべきだ
□自分の仕事で問題が発生しても解決するのは自分の仕事ではない
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなくプライベートについてもグイグイ引っ張って欲しい
□奢ってくれる派遣先正社員を尊敬する
□自分の月額金額を知らないのは当然だ、単金を聞いてはいけない
□派遣先正社員より自分の生涯収入が低いのは当然だ
□チビは派遣先にかわいがってもらいやすから派遣には有利だ


198:デフォルトの名無しさん
07/07/03 12:33:07
プログラマー板でやれ

199:デフォルトの名無しさん
07/07/03 12:56:45
>>198
文句があるなら派遣を辞めてから言え

200:デフォルトの名無しさん
07/07/03 15:51:08
HaskellでOpenGL使ってる人いる？

201:デフォルトの名無しさん
07/07/03 18:44:55
いらない

202:デフォルトの名無しさん
07/07/03 18:56:57
俺もいらね

203:デフォルトの名無しさん
07/07/03 21:35:56
OpenGLなんて単独で使うもんだ
余計なもんなぞ糞

204:デフォルトの名無しさん
07/07/04 18:55:12
何がいらないのかまったくわからないのですが


205:デフォルトの名無しさん
07/07/04 19:12:14
そうですか

206:デフォルトの名無しさん
07/07/04 19:48:52
>200-202の流れにはﾜﾗﾀけど
>203は全く意味がﾜｶﾗﾝなぁ・・・
OpenGL単独で一体何ができるってんだか。肝心の絵すら出ないよw

207:デフォルトの名無しさん
07/07/04 20:07:38
OpenGLが自我をもって動き出す
行く先も分からぬまま

208:デフォルトの名無しさん
07/07/04 20:40:07
行く先と言えばLongsPeakって出るの今月だっけ?
ほんとに出るのかな…

209:デフォルトの名無しさん
07/07/04 21:58:55
>>206
ヒント
描画ロジックの分離

210:デフォルトの名無しさん
07/07/04 22:35:51
>>209
…描画ロジックを分離するとOpenGL単独でいけるんだ。

…へｪ。

211:デフォルトの名無しさん
07/07/04 22:53:16
俺もOpenGL単独で使いたい!
極意を教えてください!!

212:デフォルトの名無しさん
07/07/04 23:00:40
メンテナンス性を考慮してできるだけOpenGL単独になるように設計するだろ、普通

213:デフォルトの名無しさん
07/07/04 23:20:20
>>200
Haskellみたいな純粋に近い関数型言語ってよく知らないんだけどさ、
OpenGLみたいなStateMachineとの相性って悪くないの？
あれかな、ﾓﾅﾄﾞとかいうやつを使ってむにゃむにゃするのかな？

214:デフォルトの名無しさん
07/07/05 00:09:52
>>212
言語との組み合わせでどう？といわれているのに
単独とかわけの分からないこと言ってるから突っ込まれてるんだろ

215:デフォルトの名無しさん
07/07/05 01:05:16
>>214
エスパー乙

216:デフォルトの名無しさん
07/07/05 01:20:37
>>204
HaskellでOpenGL使ってる人

217:デフォルトの名無しさん
07/07/12 00:10:34
ウィンドウとレンダリングコンテキストとフレームバッファがひとつに
くっついているのって扱いにくくないですか？
スレッドにカレントコンテキストを設定するのもグローバル変数のようで
プログラムが複雑になるような気がします。


218:デフォルトの名無しさん
07/07/12 00:40:14
OpenGLのせいではありません。M＄に文句言ってください。

219:デフォルトの名無しさん
07/07/12 01:23:50
D3Dはそのへんちゃんと作ってるのがムカつくなｗ

220:デフォルトの名無しさん
07/07/12 21:19:22
そうか?
D3DでもDeviceは一個しか作れんし、結局グローバル変数にしちゃわない?
デバイスを使用する関数にいちいち渡してたらそっちの方が複雑になるな

あとは次バージョンのOpenGLにご期待ください

221:デフォルトの名無しさん
07/07/12 21:41:58
>D3DでもDeviceは一個しか作れんし
二個以上作れるしデバイスのAPIが複数スレッドからの
呼び出し可能にするオプションもあるんだなこれが。

ゲームはともかくツールとか作る時には未だにwgl*の適切な取り扱いがよーわからん。

222:デフォルトの名無しさん
07/07/12 21:55:33
そうなのか、昔やった時は1個しか作れなかったからそういう物だと思ってた

確かにツールとか複数ウィンドウに描画する場合はコンテキストの管理が面倒だな
設定は独自管理にしてコンテキスト切り替え時に必ず設定するようにするのがいいのかな

しかしマルチコンテキストの場合は何が共有できるのか分かりづらいのが困る…
これが嫌でpbuffer諦めてFBOにしたしな

223:デフォルトの名無しさん
07/07/13 11:40:57
内部で OpenGL を使うライブラリを作成するときに，ユーザーが
別に OpenGL を使っている可能性があるからライブラリの関数を
呼び出すごとにコンテキストの退避，切り替え，復元をしなけれ
ばならないから非効率

224:デフォルトの名無しさん
07/07/14 20:53:03
それはそのライブラリの仕様が悪いだけのような…

225:デフォルトの名無しさん
07/07/15 01:50:28
ライブラリの作り方をずっと考えてきたがうまいやり方が思いつかなかった。
OpenGL をライブラリ内部に隠蔽してユーザと同じスレッドで動かすライブラリ
の場合，ユーザが設定するコンテキストの影響を受けてもいけないし影響を
与えてもいけない。
結局ライブラリの関数に入ったときにこっそりコンテキストを切り替えて
関数から出るときに元のコンテキストに戻す方法しか思いつかなかった。

226:デフォルトの名無しさん
07/07/19 15:32:06
OpenGL 3.0 は D3D10 とほぼ同じ API にしてくれないかな。
そのほうが学習も楽だし，GPU ベンダーも楽になるのに。

227:デフォルトの名無しさん
07/07/19 17:17:03
それはない。何か(考えが)浅いな。

228:デフォルトの名無しさん
07/07/19 17:24:16
Fahrenheitというのがあってな…。

229:デフォルトの名無しさん
07/07/19 17:32:03
>226
今後はしばらくAPIの策定がD3D先行なのは間違いないから
インターフェイスはともかく出来ることはほぼ同じになるだろうね

少なくともD3Dで出来ることはGLでも出来るようになる（速度は知らんが

230:デフォルトの名無しさん
07/07/19 20:57:40
なってくれないと困る


231:デフォルトの名無しさん
07/07/19 23:25:16
OpenGL初心者の者です．言語はjavaを使っています．
修士研究で使用していますが，周りに使っている人がいないので聞けない状況
です．

解析で出た速度ベクトルを，glutSolidConeで描画したいと思っています．
流体なので，複数のベクトルがあり，陰影がついていないと見づらいのです．
for文で描画しようと思っています．

問題があり，glutSolidConeは，デフォルトでZ軸方向を向くようになっています．
これを回転させて，求めたベクトルの方向に向かせたいのですが，分かりません．
Z軸をこの方向に向かせたとして，他の２軸の向きがどうなろうと
かまわないのですが，Z軸に向かせるだけなのにできません．

調べたところクォータニオンというものがあり，便利ということですが，
あまり資料がありません．また，CGが研究の主題なのではなく，
描画自体はシンプルなものなので，ここまでやらなくてはいけないのか
悩んでいます．

良い方法があったらよろしくお願いしま

232:デフォルトの名無しさん
07/07/19 23:35:07
>>231
回転行列の3列目に向かせたい方向のベクトル入れたらええんちゃうのん？
残りの2列は直交するように適当に

233:デフォルトの名無しさん
07/07/19 23:42:29
それは，glRotatefを使用しない方法でしょうか？
詳しくないものですいません．

234:デフォルトの名無しさん
07/07/19 23:45:39
>231
四元数でもいいけど、glMultMatrix()使うのが分かりやすいかと。
Z軸が (x, y, z) の方向を向いて欲しいなら、
　　GLfloat m[16]={x0,x1,x2,0, y0,y1,y2,0, x,y,z,0, 0,0,0,1};
　　glMultMatrixf(m);
　　(glutSolidCone...)
て感じ。Cしか知らないので自分で適当にJavaに翻訳してね。

あ、事前に(x0,x1,x2)と(y0,y1,y2)と(x,y,z)は互いに直交するように
かつ正規化されているように設定する必要がありますヨ。

235:デフォルトの名無しさん
07/07/20 00:04:27
ありがとうございます．
調べてやってみたいと思います．

＞234
あ、事前に(x0,x1,x2)と(y0,y1,y2)と(x,y,z)は互いに直交するように
かつ正規化されているように設定する必要がありますヨ。

の部分がはっきりしないのですが，
(x0,x1,x2)と(y0,y1,y2)はどういったベクトルなのでしょうか？

・向かせたい方向(x,y,z)
・直行するベクトル→(x0,x1,x2)と(y0,y1,y2)は
　(x0,y0,z0),(x1,y1,z1)と解釈
でよろしいでしょうか？

かつ，(x,y,z)，(x0,y0,z0)，(x1,y1,z1)はそれぞれ正規化されたベクトル

ただし，今回は(x0,y0,z0)，(x1,y1,z1)は適当に与えればよい．

でよろしいでしょうか？



236:デフォルトの名無しさん
07/07/20 00:13:51
＞234
教えていただいたことで分からない点がもう一つありました．
仕様が違うのかもしれませんが…

「glMultMatrixf(float[],int)は(float)に適用できません」と出てしまいました．
引数で，int型のある数が必要らしいのですが，知っていれば教えていただけませんか？

237:デフォルトの名無しさん
07/07/20 01:10:16
>235
座標変換前のx軸とy軸が座標変換後に向く方向、って意味で(x0,x1,x2),(y0,y1,y2)って
名前にしましたけど、かえって分かりづらかったですか。w
まぁ、名前なんて(x0,x1,x2)だろうが(x0,y0,z0)だろうがどうでもいいんで気にしない方向で。
要は、座標変換後もxyz軸が直交して欲しいなら三つのベクトルを直交させないといけないし、
また座標変換後のxyz軸の大きさが変わらないで欲しいなら三つのベクトルが正規化されてないと
いけないわけです。GLと関係無い、数学の話ですね。

glMultMatrixf()の二番目の引数ってなんだろ。Cにはそんなの無いんですが。
てかAPIのリファレンスとかwebで調べれば良いだけの話では。

238:デフォルトの名無しさん
07/07/20 01:25:37
＞２３７
分かりました，ありがとうございます．
３次元の座標変換というものに慣れていないので，質問しました．
調べてみればみるほど，数学の話になるので仰るとおり理解するには
数学的にしっかり理解しなければいけないようです．

APIの方も見ようと思います．

ありがとうございました．

239:デフォルトの名無しさん
07/07/20 16:00:04
>238
改めて考えてみたら、glMultMatrixを使うのは無駄多いかも。
要するにz軸(0,0,1)を任意の方向(x,y,z)に向けられればいいわけだから・・・
　　Vz=(0,0,1)→V=(x,y,z)
回転軸Vr(rx,ry,rz)は
　　Vr = Vz x V (外積)
回転角度aは
　　a = arccos(Vz･V) (･は内積、Vは単位ベクトルとする)
このVrとaが、そのままglRotateの引数に使える、の、かな。

Vz = (0,0,1)を入れて具体的に計算すると、
　　Vr = (-y, x, 0)
　　a = arccos(z)
これを、速度ベクトル一個ずつに対応して保存しておけば、
描画するときにglRotate(a, Vr.x, Vr.y, Vr.z)でいけるはず。
ただしGLの角度表現はradじゃなく度なので注意。
あとV(x,y,z)がz軸に平行なときは計算が別になるけど、ま、それは分かるでしょ。

240:デフォルトの名無しさん
07/07/20 22:22:24
>236
2 番目の引数は配列のオフセット。
C → glMultMatrixf( m + 10 );
Java → gl.glMultMatrix( m, 10 );

241:デフォルトの名無しさん
07/07/21 00:03:45
>>239
直接基底作ってglMultMatrixのほうが明らかに計算量が少ないと思うが・・・

242:デフォルトの名無しさん
07/07/21 01:25:26
昨日質問した者です．

＞239
なるほど，そういう方法もあるんですね．glRotateの引数には，1.0fか0.0fを
入れる方法しか知りませんでした（汗）

＞240
オフセットですか．APIを見ても？？？という感じでしたが，オフセットで調べたいと
思います．

みなさんありがとうございます．諦めかけていましたが，なんとかなりそうです．

243:デフォルトの名無しさん
07/07/21 02:48:34
>>241
＞glMultMatrixのほうが明らかに計算量が少ない
そうでもない。
・パラメータの転送量が多い
・（OpenGL内部での）逆行列計算が大変
てことで、glMultMatrixは負荷が大きいよ。
対してglTranslate,glScale,glRotateは逆行列の計算が速い。
ま、自分ではベンチとって比べてみたことは無いけど。一般的には、
MultMatrixを使うよりはTranslate/Scale/Rotateを使うべきと言われてるね。

それに事前の計算量もメモリ消費量も、このケースでは
234の方法 > 239の方法 だと思うけど・・・。

244:薄汚い派遣の国、日本
07/07/22 17:53:13
最近、職場で「出戻り寄生派遣」という言葉が囁かれています。
派遣契約を切られたにもかかわらず「次の派遣先でも切られてしまって生活できません」
などと 言って泣き落としで現場責任者に一切話がないまま再契約した派遣のことです。
今月初め、半年前に切った派遣が出社してきてマネージャーも含めみんなびっくりしました。
影でコソコソ偉い人に泣きついて再契約したそうです。同じ部署の人には黙って・・・
そんなことまでして自宅の近くの派遣先にこだわって人間として恥ずかしくないのですか。
派遣でスキルアップ、派遣で収入アップとか言うなら一箇所にしがみつかず
複数の会社を渡り歩いてください。
ひとつの会社で派遣向けの単調な仕事をしていたらスキルアップなんてありえないでしょう。
身分不相応な商品のローンを払うために派遣だと当然足りない収入は親にも寄生して、
いつ切られるんじゃないかとビクビクしながら人事権のある人間とだけ仲良くし、
契約終了を通知されれば泣き落とし。悲惨な人生ですね。
氏んだほうがいいんじゃないですか。


245:デフォルトの名無しさん
07/07/26 14:28:32
XPだとうまく動いてたプログラムが Vista だと glBindTexture での
テクスチャの切り替えがうまくいかねぇ・・・・
ググっても同様の症状は出ないので自分のコードのどこかが
行儀悪いんだろうが何がいけないのやらさっぱり・・・ orz

246:デフォルトの名無しさん
07/07/26 20:39:33
とりあえずOpenGL-D3D Translatorで動かしてみたら？

247:デフォルトの名無しさん
07/07/26 23:59:46
【派遣ネガティブ根性チェック】

3つ以上、チェックがつけばアナタの性格はひん曲がっており、
ネガティブ負け組派遣人生を歩んでいます。

□派遣先正社員の作った糞開発ツールはたとえ腐っててもマンセーして使う
□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□仕様とは正社員から口伝されるものだ
□耳で聞いた仕様を正確に覚えていないのは自分の責任だ
□昼食は必ず派遣先の社員と行くべきだ
□自分の仕事で問題が発生しても解決するのは派遣の仕事ではない
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなくプライベートについてもグイグイ引っ張って欲しい
□奢ってくれる派遣先正社員を尊敬する
□自分の月額金額を知らないのは当然だ、単金を聞いてはいけない
□派遣先正社員より自分の生涯収入が低いのは当然だ
□チビは派遣先にかわいがってもらいやすいから派遣には有利だ


248:デフォルトの名無しさん
07/07/27 00:05:24
>>246
ども。試してみます。

249:デフォルトの名無しさん
07/07/27 09:52:21
>>245
ここにVistaでOpenGLを使う時の注意点があるけどどうだろう
URLﾘﾝｸ(www.opengl.org)
Aeroを使ってたら切って試してみるといいかもしんない

250:デフォルトの名無しさん（245）
07/07/27 10:40:19
245ですが原因わかりました。-_-;..
glBindTexture でテクスチャを切り替える時に、XPだと、

　　glBindTexture( GL_TEXTURE_2D, テクスチャ１ );
　　　　/* テクスチャ１有効 */
　　glBindTexture( GL_TEXTURE_2D, テクスチャ２ );
　　　　/* テクスチャ２有効 */

とダイレクトにバインドして問題ないんだけど、
Vista の場合、

　　glBindTexture( GL_TEXTURE_2D, テクスチャ１ );
　　　　/* テクスチャ１有効 */
　　glBindTexture( GL_TEXTURE_2D, 0 );

　　glBindTexture( GL_TEXTURE_2D, テクスチャ２ );
　　　　/* テクスチャ２有効 */
　　glBindTexture( GL_TEXTURE_2D, 0 );

と、名無しテクスチャに戻してやらないと他のテクスチャにバインドし直せなかったです。

うーん・・・　赤本（原書第５版）の glBindTexture のサンプルコードは上の書き方だったけど
この辺何か文献でてましたっけ。　　勉強が足らんなぁ・・・


>> 249
ｻﾝｸｽ!!
OpenGL描画中にGDIはいじってないので大丈夫そうです。
自分の元のコードが Aero の On/Off に関わらず発症すること、
上記の修正をして Aero の On/Off に関わらず修正されたことを確認しました。

以上、お騒がせしてすんませんでした・・・・ orz

251:デフォルトの名無しさん
07/07/27 11:06:45
>>250
BindTextureに0を指定することって普通無いと思うが、不思議な現象だな
まだVista用のグラフィックドライバがバグってるってだけかもしんないね

252:デフォルトの名無しさん
07/07/27 16:03:10
おいらンとこではBindTextureで0をバインドしなくてもVistaで普通に動いてるよ。
てか今まで特に不具合は出てないな。

253:デフォルトの名無しさん
07/07/27 16:32:41
>>250
定番だけどドライバを更新。もうやってそうだけど。
>>251
無名のテクスチャを指定するときに0を指定するんじゃなかったかな。

254:デフォルトの名無しさん
07/07/27 18:17:26
Vista標準のドライバを使っているといったら、なぐる

255:デフォルトの名無しさん（245）
07/07/29 08:31:17
>>254
とはいえ、標準ドライバでも最低限まともに動くようになってないとね・・
なんせ「標準」ですからね・・

>>252
ですよねぇ。自分のOpenGL作法がおかしいんだろうなぁとは思うんですが、
テクスチャ以外は問題ないし、毎回 gllTexImage2D() する分にも問題ない。
glBindTexture だけが思うように動かない。謎です。

みなさんどもありがとです。m(_ _)m

256:名無しさん＠そうだ選挙に行こう
07/07/29 13:16:20
うちのプロジェクトでは、Vista添付のドライバでOpenGL動かしたら、
WindowsXPのベンダー提供ドライバ時の約6%しか、速度がでなかった。
Vista対応ドライバを入れると、解決した。
よって、Vistaの添付ドライバは全く信用していない

257:名無しさん＠そうだ選挙に行こう
07/07/29 13:37:48
遅いのはD3Dへのtranslatorだからってだけの話
信用云々とかあふぉくさ

258:デフォルトの名無しさん
07/07/30 01:13:23
全然詳しくないので質問させてください。
いつも仕事中にWebばかり見てる派遣クンが
「OpenGLがプログラムどおりに動かない原因を調べるのは僕の仕事ではありません。」
と言っています。
彼のOpenGLプログラムが動かないのを調べるのは誰の仕事なのでしょうか？

259:デフォルトの名無しさん
07/07/30 01:15:03
まともに論破する技量も無いお前の仕事

260:デフォルトの名無しさん
07/07/30 01:18:15
こういうバカを論破しようとチャレンジするなんて尊敬するよ
俺なら論破以前に派遣契約を切るからな

261:デフォルトの名無しさん
07/07/30 01:23:48
それスクリプト

262:デフォルトの名無しさん
07/07/30 01:32:37
>>259-260
論破しようにもそういう奴って話通じないだろ
「僕は言われた通りにやりました！何で僕が調べないといけないんですか！」
なんて言われたひにゃ俺ならマジギレしそう

263:デフォルトの名無しさん
07/07/30 01:50:00
>>262
話通じない奴が居るって時点でお前も話通じなそうだな

264:デフォルトの名無しさん
07/07/30 01:57:43
>>263
日本語をしゃべってれば話が通じるなんて考えは甘いよ。

265:デフォルトの名無しさん
07/07/30 02:04:33
>>263
お前ずいぶん恵まれた環境で仕事してるんだな

266:デフォルトの名無しさん
07/07/30 03:06:58
マ板池

267:デフォルトの名無しさん
07/07/30 05:45:57
>>258は、マルチ

268:デフォルトの名無しさん
07/07/30 07:02:50
契約内容見直せよ。

269:デフォルトの名無しさん
07/07/30 09:20:10
258はDirectXスレでも単語が変わっただけの同じのみたな

270:デフォルトの名無しさん
07/08/04 19:23:43
MacでOpenGLやりたいんだけどXcodeでプログラミングすれば平気？

271:デフォルトの名無しさん
07/08/04 19:28:32
>>270
XCode 使っても良いけど、↓これ見ておけば悩み無用。

URLﾘﾝｸ(www.wakayama-u.ac.jp)

272:デフォルトの名無しさん
07/08/04 23:02:22
CocoaでやんのかCarbonでやんのか知らんがまぁがんばれ

273:デフォルトの名無しさん
07/08/05 23:56:10
今日から始めたんだが解説サイトとかすごく少なくて不安…
日本語で基礎からガッチリ固めたかったらあの高い赤本しかないの？

せめて5000円以下でないだろうか

274:デフォルトの名無しさん
07/08/06 00:13:13
>>258
人材配置を見直してもらうか、仕事振ってるマネージャーを変えてもらえ

275:デフォルトの名無しさん
07/08/06 11:39:09
>>273
学生なら学校の図書館とか、あるいは市町村の図書館でもあたってみては。
無いかもしれんが。
英語でよければ古い版の赤本を無料で読める URLﾘﾝｸ(www.glprogramming.com)

276:デフォルトの名無しさん
07/08/06 16:11:22
やはり英語か…
覚悟きめてがんばるわ

277:デフォルトの名無しさん
07/08/06 20:52:07
古い赤本はほんとうに古いから参考になるかどうか…
図書館は無ければリクエストしてみるといいかも
でも入るまでかなり時間かかるかな

278:デフォルトの名無しさん
07/08/06 21:04:40
日本語の赤本もようやっと原著第５版になってるしね。
英語で格闘する労力と13k円の出費のトレードオフを考えてオレは買った。＞赤本

279:デフォルトの名無しさん
07/08/06 21:09:00
昔の赤本（初版）はもってるんだけど、最近のとどこが違うのでしょうか？



280:デフォルトの名無しさん
07/08/06 21:10:38
図書館てOpenGLみたいなマニアな(?)専門書って置いてるものなの？

281:デフォルトの名無しさん
07/08/06 22:12:54
比較的メジャーなマニア本だからな。

282:デフォルトの名無しさん
07/08/06 22:42:51
>>279
Amazon.co.jp： OpenGLプログラミングガイド 原著第5版: 本: OpenGL策定委員会,松田 晃一
URLﾘﾝｸ(www.amazon.co.jp)

> ■OpenGL バージョン1.5 で追加された以下の新しいコア機能:頂点配列のバッ
> ファオブジェクトへの格納/遮蔽問い合わせ/シャドウマッピング用のテクス
> チャ比較関数の追加/トークンの更新
>
> ■OpenGL バージョン2.0 で追加された以下の新しいコア機能:シェーダ記述言
> 語の追加/プログラマブルシェーダからの複数のカラーバッファへの異なる色の
> 出力/テクスチャマップに関する2 のべき乗のサイズ制限の緩和/テクスチャ
> マップされた点スプライトのレンダリング/前面と背面ポリゴンでのステンシル
> 処理の分離
>
> ■バグ修正

だそうです。
OpenGL1.5とOpenGL2.0についての追加と、訳の見直しが行われている模様。
俺もほしい

283:デフォルトの名無しさん
07/08/06 23:10:14
第2版までは翻訳業者が訳してたから読みにくかったね

284:デフォルトの名無しさん
07/08/06 23:29:29
>>279
・より赤くなった
・1,000円高くなった

285:デフォルトの名無しさん
07/08/07 00:20:48
不覚にも笑ってしまった

しかしせめて8000円ぐらいに…

286:デフォルトの名無しさん
07/08/07 02:27:06
>>284
1.5倍くらいは速くなってんのかな

287:デフォルトの名無しさん
07/08/07 02:39:49
＞ 原著第5版
テクスチャへの描画とか、実際に使う際の普遍的なチップスとかって
載ってますのん？

そういうのは、Game Programming Gems買えって事かな？
（そろえたら、赤本よりたけええけどよぉおぉ）

288:デフォルトの名無しさん
07/08/07 02:52:53
Gems にそんなの載ってたっけ

289:デフォルトの名無しさん
07/08/07 03:18:43
>>287
テクスチャへのレンダリングにはGL_EXT_framebuffer_objectを使う。
この拡張機能はOpenGL 2.0の仕様に含まれていないから当然赤本には載ってない。

290:デフォルトの名無しさん
07/08/07 22:16:01
ああ、使用に含まれてない＝載ってないか・・・
そうだよなあ

291:デフォルトの名無しさん
07/08/07 22:51:14
赤本は昔からextensionには触れないからね

292:デフォルトの名無しさん
07/08/13 18:58:10
The OpenGL ARB officially announced OpenGL 3
URLﾘﾝｸ(www.opengl.org)

293:デフォルトの名無しさん
07/08/19 23:15:27
よしはる別スレに今も登場中

294:デフォルトの名無しさん
07/08/19 23:26:55
スレ違い、こっちでやれ↓

OpenGL 2.0 専用スレ
ｽﾚﾘﾝｸ(tech板)


295:デフォルトの名無しさん
07/08/23 18:42:39
カーマック大失敗ｗ
URLﾘﾝｸ(www.technobahn.com)

296:デフォルトの名無しさん
07/08/23 18:48:33
ｗｗｗｗｗｗｗｗｗｗｗｗ

297:デフォルトの名無しさん
07/08/24 05:32:42
ざまぁｗｗｗ

298:デフォルトの名無しさん
07/08/24 19:51:37
すみません。
OpenGLでなくGLSLでVertex texture fetchをしたいのですが、
テクスチャを取ってくるときの関数はフラグメントシェーダと同じように、
texture2Dやtexture2DRectを使うのでしょうか？


299:デフォルトの名無しさん
07/08/24 21:08:31
>>298
確かそうだったと思う。

300:デフォルトの名無しさん
07/08/26 01:18:20
GeForce8600GTにしてからたまに描画が異様に遅くなるんですが、似たような症状に遭って解決できた方いませんか？

VBOにデータ置いても直らず、シェーダやテクスチャはおろか、ライティングすらしてないモデルでも再現。
WindowsXPで、ドライバは最新(162.18)とベータ版(163.44)両方で発症。
GeForce6000系や7000系では問題は起きませんでした。
プログラムを何度も起動しなおしたら上手くいくこともあるのですが…。

301:デフォルトの名無しさん
07/08/26 01:38:33
>>300
熱暴走してないか疑え

302:デフォルトの名無しさん
07/08/26 21:53:14
盲点でした、が、マシン起動直後でも起きるので、単純に熱だけが原因ではなさそうです。
あとDirectXのゲームとかでは同様の問題は起きず。

# もう検証疲れた…。ドライバが腐ってるせいってことにしたいorz

303:デフォルトの名無しさん
07/08/26 21:58:46
VBOに書き込む際のバッファオーバーランとか

304:デフォルトの名無しさん
07/08/26 22:09:36
glInterleavedArray()/glVertexPointer()系 + VBO使用/未使用の組み合わせ、
glBegin()～glEnd()、の5パターンで同じモデルを描いてみましたが、全てで発症しました。
モデルは立方体を1000個程描いてるだけです。

305:デフォルトの名無しさん
07/08/26 22:12:00
とりあえずプログラムうｐ

306:デフォルトの名無しさん
07/08/26 22:15:40
>>305
ちょっと公開したくない部分があるんで、
問題が起きる最小限のプログラム用意してみます。

307:デフォルトの名無しさん
07/08/26 22:21:12
お、えらい。
大抵公開できない部分があるのでそこを何とかお願いしますとかが多いのに。

308:デフォルトの名無しさん
07/08/27 01:40:12
URLﾘﾝｸ(a-draw.com)
DLKey: 0000

急拵えなんでバグってたらすみません。
グラフの単位はミリ秒で、上限20msです。
good.jpgは正常時、bad.jpgが異常に遅いときのスクリーンショットです。

これ作りながら検証したところ、どうも全体的な負荷が高い時程発症確率が上がってる感じがします。
立方体1000個にしてシェーダ使うと9割以上発症したり。
しかし500個シェーダ無しでも稀に遅くなったりで、根本的な対処法は依然分からず。

309:デフォルトの名無しさん
07/08/27 02:23:56
>>308
解凍できないのは俺だけか？

310:デフォルトの名無しさん
07/08/27 03:34:28
>>309
とりあえず解凍はできたぞ。

311:デフォルトの名無しさん
07/08/27 11:02:23
>>309
安心しろ俺もだ

312:デフォルトの名無しさん
07/08/27 11:40:18
unzip.dllが古いんじゃね

313:デフォルトの名無しさん
07/08/27 12:07:05
WindowsXP標準の圧縮フォルダで展開できるZIP形式でお願いします。

314:デフォルトの名無しさん
07/08/27 17:17:02
そのぐらいじぶんでやれよ

315:デフォルトの名無しさん
07/08/27 19:33:23
>>308
解凍できません

316:デフォルトの名無しさん
07/08/27 20:33:59
そのままで自動ﾀﾞｳｿすると失敗するぽいお
リンク押してﾀﾞｳｿしたら解凍できるんでないか

317:デフォルトの名無しさん
07/08/27 20:47:07
unzip コマンドで普通に展開できたよ

318:デフォルトの名無しさん
07/08/29 21:25:44
>>308
うちのgeforce8800gtxでもbad.jpgと同じぐらいのスピードになった。

GLexpertから何もメッセージがでてない(標準出力は起動時につくられるstdout.txtに出力されるんだよね?)
っぽいし、ソースコードをざっと読んだけど原因はよくわからなかった。

そういえば、geforce6000, 7000で毎framePBOにデータを送るようなプログラムを書いていたときに
数秒後に急に倍近くfpsが上がることがあった。

ドライバが消費電力を低くするために裏で負荷に合わせて使用するシェーダの数を調整したりしてるのか?
教えてエロ詳しい人


319:デフォルトの名無しさん
07/08/30 21:39:21
上のに関連するが、Vista+GeForce8000だとむちゃくちゃ遅くならない？
うちだと>>308のbad.jpgより遅くなってる。

URLﾘﾝｸ(d.hatena.ne.jp)
これとか見ると少なくとも7000だと問題ないみたいだが。
8000はまだOpenGLの実装が不完全と見た方がいいのかね。

320:デフォルトの名無しさん
07/08/31 11:21:10
Vista
yaneurao

321:デフォルトの名無しさん
07/09/01 13:24:30
>>308
ずっとこんな感じで推移。
URLﾘﾝｸ(gamdev.org)

たまにぐっと負荷がかかるようだが、見た目はスムーズ
たぶん常駐が多いせいだと思う

環境は、
CPU: Pen4 2.6GHz
メモリ: 1.5GMB
GPU: Sapphire RADEON X700

今時だと、さすがにプア環境でアレだが


しかし、きれいやねー参考にさせていただこう

322:デフォルトの名無しさん
07/09/01 13:27:04
メンゴ書き忘れ
OS: Windows XP SP2 32bit
GPU DRIVER: ATI ver 8.342.0.0


323:デフォルトの名無しさん
07/09/05 10:52:26
URLﾘﾝｸ(www.inside-games.jp)

すげー

324:デフォルトの名無しさん
07/09/05 11:09:26
OpenGL 3.0て具体的にはどんなんになるんだ。

325:デフォルトの名無しさん
07/09/05 13:29:05
あれだろ
コンセプトだけ言って、具体的には何もできてないっての

326:デフォルトの名無しさん
07/09/05 16:55:37
>>325
それは、もまえ、OpenGL自体を馬鹿にしているのかｗ

327:デフォルトの名無しさん
07/09/06 00:03:47
むしろ、交差とか法線計算とかエッジ検出とか・・自動でやってくれるようにはならんかね。
楽したいんじゃ。ワシャ。
この前セレクション出来るようになったばっかなのに(^ω^;;)

328:デフォルトの名無しさん
07/09/06 02:36:51
>>308
nVidiaのドライバの設定にあるtheaded optimizationがautoになってると遅くなったり速くなったりするようだ。
onにすると常に速く、offにすると遅くなるようだ。
このオプションはマルチコアCPUで複数スレッドを使って高速化するかどうかのオプションらしい。
fpsが60以上になるとだんだんとCPU側がボトルネックになってきてるんかな。

>>327
そういうのはwild magicとかなんとかライブラリを使えばいいんじゃない?

329:308
07/09/06 08:33:45
>>328
うお、ありがとうございます。
ただ、うちだとoffにすると常に速くなるようになりました。
(FPS60超える/超えない関係なく)
なんかこれ不気味なオプションですね…。

330:デフォルトの名無しさん
07/09/23 10:52:18
URLﾘﾝｸ(www.4gamer.net)

331:デフォルトの名無しさん
07/10/06 23:02:51
glGenTextures()してgluBuild2DMipmaps()した画像のテクスチャが、
ウィンドウがリサイズされたときにSDL_setVideoMode()すると画像が無くなってしまうのですが、仕様ですか？
リサイズされたときビューポートをウィンドウと一致させたくて毎回SDL_setVideoMode()しているのですが、
glViewPort()を使ったほうがいいのでしょうか？

332:デフォルトの名無しさん
07/10/06 23:26:38
カラーマップの使い方がいまいちわかりません
おしえてください

333:デフォルトの名無しさん
07/10/06 23:40:53
>>331
ウインドウのサイズが変わるたびにglViewportするべき
だと俺は考える

334:デフォルトの名無しさん
07/10/07 02:53:26
リサイズでビューポートとprojection matrix設定しなおしてるんだけど、
そうするとディスプレイリストが無効になることがあります。
リサイズのときにディスプレイリストを消して作り直すことにして回避したけど、
これはそういうものですか? それともどっかおかしい?

335:デフォルトの名無しさん
07/10/07 03:19:00
>>334
俺の経験上、ウインドウのリサイズでディスプレイリストを作り直すってことは無いな…
glRasterPosとか使ってるのかな？？
>>331ならglTexParameterのGL_TEXTURE_MIN_FILTERなり、GL_TEXTURE_MAG_FILTER
なり
と思ったりするけど、どうなんかなぁ～

336:デフォルトの名無しさん
07/10/07 05:05:44
ウィンドウ全体を FBO あるいは pBuffer でテクスチャに取り込んで、自前でダブルバッファリングをしようと考えています。
しかし、もしウィンドウのサイズが最大テクスチャサイズを超えてしまうとどうしようもありません。そういう場合どうすればいいのでしょうか？

次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch
4293日前に更新/177 KB
担当:undef