11/11/16 15:51:47.32
>>11
が、古きを知るために赤本がいいかというと違うと思う。
いずれにせよ赤本は時代遅れ
赤本をすすめる人間は信用できない
14:デフォルトの名無しさん
11/11/16 15:55:49.32
そもそも本なんて要らない
15:デフォルトの名無しさん
11/11/16 17:34:52.91
>>13
4x1対応の赤本が出たら手のひら返すんでしょ？
16:デフォルトの名無しさん
11/11/16 22:20:33.18
>>12
使った方が楽だと思うよ
17:デフォルトの名無しさん
11/11/16 22:39:45.63
OpenGLなんて実際に使われているの？
18:デフォルトの名無しさん
11/11/16 23:30:32.81
使われてるよ
19:デフォルトの名無しさん
11/11/16 23:31:33.30
カーナビとか3Dじゃないけど使ってるねえ
あとCADとか
20:デフォルトの名無しさん
11/11/17 23:07:51.76
glVertexAttribPointer()があればglEnableVertexAttribArray()は不要だと思うのですが、どうして分かれているのでしょう？
21:デフォルトの名無しさん
11/11/18 00:03:18.19
キーボードのpとoが壊れた時も使えるからかな
22:デフォルトの名無しさん
11/11/19 16:30:05.75
へえ
23:デフォルトの名無しさん
11/11/19 18:38:02.15
>>22
ｽﾚﾘﾝｸ(tech板:213番)
ｽﾚﾘﾝｸ(tech板:83番)
ｽﾚﾘﾝｸ(tech板:22番)
ｽﾚﾘﾝｸ(tech板:82番)
ｽﾚﾘﾝｸ(tech板:444番)
ｽﾚﾘﾝｸ(tech板:444番)
ｽﾚﾘﾝｸ(tech板:25番)
ｽﾚﾘﾝｸ(tech板:4番)
ｽﾚﾘﾝｸ(tech板:186番)
ｽﾚﾘﾝｸ(tech板:279番)
ｽﾚﾘﾝｸ(tech板:744番)
ｽﾚﾘﾝｸ(tech板:237番)
ｽﾚﾘﾝｸ(tech板:911番)
24:デフォルトの名無しさん
11/11/21 04:44:52.22
C++ と OpenGL, GLUTを利用した３次元の物理現象のプログラムを作成しよう
としているのですが、なかなか上手く出来ません。
URLﾘﾝｸ(www.natural-science.or.jp)
作ろうとがんばっているのはまさに↑のようなものです。
出来ればソースコードを全て書き込んでいただければありがたいです。
Microsoft Visual Studio 2008より作成しています。
よろしくおねがいします。
25:デフォルトの名無しさん
11/11/21 09:12:31.22
釣り針大き過ぎて無理
26:デフォルトの名無しさん
11/11/21 10:18:31.14
>>24
URLﾘﾝｸ(www.sgra.co.jp)
27:デフォルトの名無しさん
11/11/21 10:35:16.34
>>26
御食事処もあるのか。いい会社だな
28:デフォルトの名無しさん
11/11/21 10:55:26.12
天才よ、ぱぱっと書いてやれ
29:デフォルトの名無しさん
11/11/21 14:26:08.84
>>24
以前から何度も書き込んでる奴か？
ネタとしても面白くないからいい加減失せてね。
30:デフォルトの名無しさん
11/11/21 20:24:08.66
これって物理エンジン使ったら簡単じゃね？
31:デフォルトの名無しさん
11/11/22 00:44:48.87
よく見たら2Dだった
32:デフォルトの名無しさん
11/11/22 16:41:35.45
GLSL触って間もないんですが
glBlendFuncと同じようなこと（フラグメントシェーダで描画先のピクセルの色を取って合成みたいな）
をGLSLで行いたいんですけどこれってできますか？
「描画先のピクセルの色を取って」の部分がどうすればできるのか分からないんですが
33:デフォルトの名無しさん
11/11/22 17:18:16.22
描画先のピクセルを参照することは出来ない。
34:デフォルトの名無しさん
11/11/22 17:54:06.50
んなわきゃない。
描画先のメモリを参照すればいいだけだ。
35:デフォルトの名無しさん
11/11/22 18:10:07.18
残念ながらできない
36:デフォルトの名無しさん
11/11/22 18:19:31.15
君、できないの？
37:デフォルトの名無しさん
11/11/22 18:38:47.74
盛り上がってまいりました!
38:デフォルトの名無しさん
11/11/22 18:54:38.61
できないことの証明は難しいが、できることの証明は簡単なはずだ
まあGLSLで出来るかはわからないが描写先をフレームバッファオブジェクトにしておけば、
そしてテクスチャーバッファーにしておけば、普通にアクセスできるはず
これレンダーバッファーではできないよね？レンダーバッファーは普通のGL関数でアクセスする専用ってことかね
39:デフォルトの名無しさん
11/11/22 21:17:41.33
>>38
URLﾘﾝｸ(www.opengl.org)
Feedback Loopsって所を見るとダメかな。Mostly
40:デフォルトの名無しさん
11/11/22 21:42:21.46
普通の？画像処理と同じ要領なのね
やりたいことがわからないけど、まあそれがわかれば解決策も容易にわかるはず
41:デフォルトの名無しさん
11/11/23 01:22:37.66
>>32
例外的だけど、tegraとか、一部のタイル系モバイルGPUではできるみたいよ。
参考 : NV_shader_framebuffer_fetch
42:デフォルトの名無しさん
11/11/23 04:57:29.73
GLEWライセンス見たけど要は修正BSDライセンス？
43:デフォルトの名無しさん
11/11/23 08:50:37.04
結局フラグメントシェーダからレンダーバッファを参照するのは不可能、でFA？
44:デフォルトの名無しさん
11/11/23 11:08:38.69
>>43
現在のほとんどのハードウェアでは出来ない。
>>41のような例外は、レンダーバッファ(の一部)がシェーダから近い位置にレイアウトされているから。
45:デフォルトの名無しさん
11/11/23 11:45:12.47
OpenGLでOIT実装したいとおもってるんですが、DirectXでいうところのAppendBufferってOpenGLだとなにになりすか？
あと、OpenGLのDirectX11相当の機能についてよいリンクなどあったら教えてください。
46:デフォルトの名無しさん
11/11/23 13:06:25.29
32=45? A-Bufferとかで検索すればヒントが得られるんじゃないかな
47:デフォルトの名無しさん
11/11/23 13:53:18.91
>>46
ありがとうございます、32ではありません。
EXT_shader_image_load_storeという拡張が欲しい仕様にみえます、OpenGL拡張の仕様書ページみながら頑張ってみます。
しかしNvidia拡張の魔改造ぶりはすごいですね、NV_shader_buffer_store...
48:デフォルトの名無しさん
11/11/23 14:31:31.68
もうデファクトスタンダードでいいよ
49:デフォルトの名無しさん
11/11/23 15:11:23.55
魔改造と言うか、元々HWベンダですし
と言うか、大昔はハードウェアごとに全部ソフトウェアとか違ってた訳ですし
50:デフォルトの名無しさん
11/11/23 18:02:50.64
それは規格がなかった時代の話で今はOpenGLという規格があるのに自分勝手にはみ出してるって話だろ
51:デフォルトの名無しさん
11/11/23 18:21:51.42
まぁクロノスがグラボ作ってる訳でもないしな。
52:デフォルトの名無しさん
11/11/23 20:03:14.51
あ、魔改造は褒め言葉です。;-/
次のプロファイルではARBのシェーダでもポインタとか使えるようになっているといいな。
53:デフォルトの名無しさん
11/11/24 23:50:04.22
なぜOpenGLは行列を逆ハンドサイドから掛けないといけない仕様にしたんでしょうか？
わざわざ逆順に掛けて行く必要があるしC++のoperatorとも相性悪いしどうしても解せません
54:デフォルトの名無しさん
11/11/25 01:00:53.28
あっちが逆なんだよ
55:デフォルトの名無しさん
11/11/25 01:01:35.18
行列を掛ける方向と右手系左手系は関係ないし
OpenGLはC++のoperatorの定義なんてしてないし
気に入らないなら適当なラッパー書けばいいだけ
56:デフォルトの名無しさん
11/11/25 01:24:53.10
>>55
右手系左手系は関係ないけど転置してるから右から掛けないといけないですよね
C++のoperator、例えば*は左結合なので右から掛けるという規則がすごく気持ち悪いです
確かに数学で出てくるアフィン変換行列と同じ形式ですがプログラミング言語から使うんだから
わざわざ扱いにくい形式を採用しなくても良かったのでは？と疑問に思っています
なんでこんなことに？
57:デフォルトの名無しさん
11/11/25 01:36:12.62
なら転地しないで左から掛ければいいじゃない。
CPUでなにを計算するかなんてOpenGLの知ったこっちゃないよ
58:デフォルトの名無しさん
11/11/25 02:25:19.54
>>53,56
この辺読むと良いと思うよ。
URLﾘﾝｸ(steve.hollasch.net)
右から掛ける、左から掛けるってのは、計算を数式で記述する仕方の問題だけ。
OpenGLの計算も、ベクトルを行ベクトルと見て行列を左から掛けるのだと解釈する事もできるんだから
そうしたいならそうすればいいんだよ。
59:58
11/11/25 02:30:02.56
あ、ごめん、言葉足らずで変な言い方になった・・・。
「行列を左から掛けるのだと」のくだりは、ベクトルに対して行列を左から掛けるって意味じゃなく、
v'=vMに対してさらにローカルな変換を追加するときに新しい行列Nを v'=vNM とMの左に掛けるって意味でした。
60:デフォルトの名無しさん
11/11/26 07:38:37.40
ということはその場合はglRotate*等は混在できなくて
全てglLoadMatrixd*/glMultMatrix*で自前でするということ？
61:デフォルトの名無しさん
11/11/26 08:23:02.42
なんで突然glRotateが使えなくなんの。
とりあえず自分でコード書いて確かめてみなよ
62:デフォルトの名無しさん
11/11/26 09:05:39.27
>>60
なんかそもそも行列の演算とその使い方が分かってない感じ・・・かな。
もっと具体的に、どういう事をしたい時にどう困ってるのかが分かれば、
解決策も出ると思うんだけど。
とりあえずOpenGL(DirectX)の行列に関する仕様はおおかたの使い方において
妥当なようになっているし、大半の人は（多分）困ってないよ。
63:デフォルトの名無しさん
11/11/26 14:39:58.94
それはともかく
そろそろ OpenGL の行列関数は使わない方がいいような気はする
64:デフォルトの名無しさん
11/11/26 17:32:55.68
使わないっていうか今の4.x系列は使えないだろ
GLSL側でcolumn-majorで定義したのが許せない
せっかく０から定義したのになぜバカな仕様を引きずるのか...
65:デフォルトの名無しさん
11/11/26 18:33:03.16
>>62
glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので
自前で右へ右へ掛けていくために行ベクトル用の行列を作って掛けていったものに対して使うと当然結果おかしくなっちゃいますよね？
うわあめんどい・・・
66:デフォルトの名無しさん
11/11/26 18:42:06.05
>>61
自分のソースのglRotateしてる部分を回転行列の転置行列をgMultiMatrixするように置き換えれば使えない理由が分かります確かめてください
67:デフォルトの名無しさん
11/11/26 19:06:54.41
>>66
俺は何も困ってないし、何一つ疑問は無いので確かめないよ？ｗ
68:デフォルトの名無しさん
11/11/26 19:33:56.21
>>66
右手左手座標系の違いはあるけど、
glTranslatef( x, y, 0 );
って書く替わりに
D3DXMATRIX mat;
D3DXMatrixTranslation( &mat, x, y, 0 );
glMultMatrixf(&mat.m[0][0]);
って書いても動くよね。
逆だ転置だって言うけど、どっちもマトリックスのメモリ配置は同じでxが入るのは*(m+12)
自分で書くなら、自分が使いやすいように実装したらいいんじゃね
69:デフォルトの名無しさん
11/11/26 22:18:06.69
>>65
＞glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので
違います。
＞自前で右へ右へ掛けていくために行ベクトル用の行列を作って掛けていったものに対して使うと当然結果おかしくなっちゃいますよね？
おかしいのはあなたの考え方です。
58のURLは読みましたか？
その内容は理解できますか？できませんか？どっち？？
70:デフォルトの名無しさん
11/11/26 22:54:45.46
>>69
>>58はoperatorの解釈を変えるだの変換をかませだの書いてありますが
言ってることはそれでOKですか？
列中心か行中心かはデータの話でマトリクスの掛け算の定義は変わらないのは当たり前の話で
その上で自前の行中心の行列をかけてる途中で列中心の行列を掛けてしまうglRotate*をそのまま呼び出すことは出来ないよね？めんど。って話をしてるんですけどちゃんと聞いてますか？
71:デフォルトの名無しさん
11/11/26 23:25:10.25
>>70
自前の行列をそのままglRotatefを呼べるようなデータの配列順にしとけばめんどくないよって話
72:デフォルトの名無しさん
11/11/26 23:28:26.54
うん、マジでゴメン。
理解できてない人に理解できてるかどうか聞いても意味無かった。
しかしこれどう言えば分かってもらえるのか分からん・・・。
＞>>58はoperatorの解釈を変えるだの変換をかませだの書いてありますが
＞言ってることはそれでOKですか？
違います。
というかそんなことはどうでもいいです。
えっと確認なんですが、英語は読めますか？
＞列中心か行中心かはデータの話でマトリクスの掛け算の定義は変わらないのは当たり前の話で
「データの話で」の意味が不明。
＞その上で自前の行中心の行列をかけてる途中で列中心の行列を掛けてしまうglRotate*をそのまま呼び出すことは出来ないよね？めんど。って話をしてるんですけどちゃんと聞いてますか？
それが誤解なのだと、58に貼ったURLに書いてあるんですが…。
73:デフォルトの名無しさん
11/11/26 23:38:30.10
>>72
何一つ情報増えてないよね
自分で説明できないなら書かなきゃいいのに。
74:デフォルトの名無しさん
11/11/26 23:50:45.58
65 の人の誤解を言葉で正すことは不可能だと思うな。
75:デフォルトの名無しさん
11/11/26 23:53:28.22
自分が理解できないからって情報が無いと考えるのはダメだよ。
58に十分な情報があるのに。
ええとまず、そうだな、最低限のところだけ言うとすると、
glRotate(やその他)は、列優先の行列を掛けるのではないし、列ベクトルに掛けるための行列を作るのでもない。
まずここが分からないと話にならないんだけど・・・
なぜあなたは、OpenGLの行列命令が扱う行列は列優先で、列ベクトルに掛けるものだと思っているのですか？
76:デフォルトの名無しさん
11/11/27 00:39:25.54
数学の話とAPIの話とC言語の話と好みの話がごっちゃになってるんだな
77:デフォルトの名無しさん
11/11/27 00:47:34.43
薄々感じるのは、>>53,56が問題にしたいのは実は行だの列だのって話じゃなくて、
v'=Mvという変換の状態に対してglRotate系を発行すると、生成された行列Rが v'=MRv と掛かるコト
（>>53,56は v'=RMv となって欲しいと思っている）なんじゃないかと・・・。
78:デフォルトの名無しさん
11/11/27 01:37:06.74
「自前の行列」ってことはどっかでglLoadMatrixしてんでしょ
じゃあglRotateのあとにglMultiMatrixすりゃいいんじゃねえの？
79:デフォルトの名無しさん
11/11/27 01:41:37.61
面倒なので3x3行列で書きます。
自作予定のMatrixクラスではx軸回転する場合DirectX(行中心行列)のように
|1 0 0|
|0 cos sin|
|0 -sin cos|
を掛けるのに対して、OpenGL(列中心行列)のglRotateは
|1 0 0|
|0 cos -sin|
|0 sin cos|
を掛けやがるから共存できねー って話です。
80:デフォルトの名無しさん
11/11/27 02:12:17.59
>>78
glLoadMatrixする直前に変換行列を転置させるから
glFlush直前ならOKなんですけど、変換途中に使うとなると
行列のLoadとGet時で転置を計2回やる必要があってやっぱり不便だなーと
81:デフォルトの名無しさん
11/11/27 02:18:50.55
x glFlush直前
o 描画関数呼び出し前
82:デフォルトの名無しさん
11/11/27 02:18:58.64
>>79
だからその配列を同じにすれば共存できるでしょって話でしょ
上は
m[0]=1; m[1]= 0; m[2]= 0;
m[3]=0; m[4]= c; m[5]= s;
m[6]=0; m[7]=-s; m[8]= c;
下は
m[0]=1; m[3]= 0; m[6]= 0;
m[1]=0; m[4]= c; m[7]=-s;
m[2]=0; m[5]= s; m[8]= c;
全く一緒
実際DirectXとOpenGLは同じなんだよ。
83:デフォルトの名無しさん
11/11/27 02:29:22.83
>>79
そもそもの話だけど行列そのものには行優先も列優先も無くて
2次元の行列を1次元の配列に格納するのが行優先なのか列優先なのかって話なので、
「行中心行列」「列中心行列」みたいな単語を使ってる点を見るに、根本的な勘違いがあるんじゃないかなぁと。
（ちょっと余計な話すると、独自の用語を使う人は、まず大抵その分野について
初歩的な理解ができてないです。きちんと意味を調べて、正しい用語を使いましょう。）
DirectX（のドキュメント）はベクトルを行ベクトルで書いて、ベクトルの変換は行列を右に掛ける形で表すから
X軸回転の行列は>>79の上の行列の形になるけど、DirectXのドキュメントを列ベクトルで書いて
ベクトルの変換は行列をベクトルの左に掛ける形で書き直すと、DirectXのX軸回転の行列も
>>79の下の行列の形になりますよ。>>82も言ってるけど、両者は同じものなんですよ。
84:デフォルトの名無しさん
11/11/27 02:56:14.58
>>82-83
何の話題で盛り上がってるのかようやく理解できたｗ
85:デフォルトの名無しさん
11/11/27 02:57:29.17
うーん、もうちょっと補足した方がいいだろうか。
>>82や>>83で「同じ」と言ってるのは、何が「同じ」なのかというと、行列演算の「仕様」。
で、「仕様」と、その「数学的記述」は区別しないといけない。
OpenGL（の主なドキュメント）では仕様を、列ベクトルと左から掛ける行列で記述してるし、
DirectX（の主なドキュメント）では仕様を、行ベクトルと右から掛ける行列で記述してる。
同じ仕様を違う方法で記述してるだけだから、記述自体は相互に変換可能。
OpenGLもDirectXも仕様が同じなんだから、行列演算部分に関しては、同じプログラムがそのまま使える。
ってコトなんですよ。
86:デフォルトの名無しさん
11/11/27 03:12:20.63
>>83
行ベクトルに対するアフィン変換行列を行中心行列
列ベクトルに対するアフィン変換行列を列中心行列
というんだと思っていました。
一般的にはどう呼ばれているんでしょう
58のrow major、 column major？
左から掛ければ一緒というのはわかります
ただ右から掛けたい(*1)というのが独自で行列計算する動機なので左から掛ければ一緒はNGなんです
*1
左から掛ける場合Matrixクラスに対してoperator*=を定義できないため
87:デフォルトの名無しさん
11/11/27 03:23:28.28
>>86の補足です
operator*=を定義できない、ではなく「効率的に定義できない」です
・row majorの場合
Matrix m; // ワールド座標系への変換行列
Matrix x1, x2; // 回転行列等
m *= x1;
m *= x2;
・column majorの場合
Matrix m; // ワールド座標系への変換行列
Matrix x1, x2; // 回転行列等
// M*=x1 は 意味的にM=M*x1なので使えない
m = x1 * m; // operator=が余計に発生
m = x2 * m; // operator=が余計に発生
88:デフォルトの名無しさん
11/11/27 03:27:09.26
もしくはむりやり
Matrix t = x1;
t *= m;
Matrix t2 = x2;
t2 *= t;
m = t2;
89:デフォルトの名無しさん
11/11/27 03:36:38.97
>>87
>>79の上のつもりで作った配列は右から掛けてok
できた配列は左版の転置になってると思うだろうけど、
それはそのまま直接OpenGLでもDirectXでも使えるメモリ配置になっている
実際にやってみたらわかると思うよ
>>87-88の言わんとしてることはわかるけど、最近のコンパイラの最適化的にどうなんだろね
グラフィック系のオーバーヘッドはそこには全く現れないと思うけど。でも気持ちはわかる
90:デフォルトの名無しさん
11/11/27 04:04:55.62
>>89
ああ、確かに反対の反対で同じになりますね。
安心して寝れます。
91:デフォルトの名無しさん
11/11/27 07:36:36.42
> ・column majorの場合
> Matrix m; // ワールド座標系への変換行列
> Matrix x1, x2; // 回転行列等
> // M*=x1 は 意味的にM=M*x1なので使えない
これが嘘だな。operator*=を定義すれば使える
92:デフォルトの名無しさん
11/11/27 08:25:29.34
DirectXもOpenGLも結局は同じ
同じ3Dを扱う物だからな
ただ、DirectXはC++の配列の並びがそのまま使えるように左手座標系になってる
OpenGLの場合はあらゆるプラットフォーム、言語で使うために右手座標系になっている
ただ単にそれだけの事だ
93:デフォルトの名無しさん
11/11/27 09:27:29.43
右手座標だとそういう壁が超えられて左手だと超えられないの？
94:デフォルトの名無しさん
11/11/27 09:56:25.12
>>91
あなたのコードをメンテする人がかわいそうなのでプログラミングしないでください
95:デフォルトの名無しさん
11/11/27 11:40:12.59
>>92
右手系左手系と配列の並びは関係ないよ。
96:デフォルトの名無しさん
11/11/27 12:11:24.06
>>95
あるよ
97:デフォルトの名無しさん
11/11/27 12:47:10.53
ないよ
98:デフォルトの名無しさん
11/11/27 13:02:36.59
単にSGI-GLが右手座標系だったので、DirectXは左手にしてみましたみたいことじゃないの
99:デフォルトの名無しさん
11/11/27 14:07:37.62
>>98
ちゃう
OGL＝数理重視
D3D＝感覚・実用重視にしたら左手座標系になった
100:デフォルトの名無しさん
11/11/27 15:07:49.26
右手はマウス握ってるから、左手系にしといたほうが実用的だよなｗ
101:デフォルトの名無しさん
11/11/27 15:46:52.27
>>100
おまえ天才じゃね？
102:デフォルトの名無しさん
11/11/27 16:02:27.53
>>99
ちがう
なんでもいいからOpenGL と変えたかっただけ。
共通規格が成立するのを邪魔するのが、マイクロソフトの仕事だから。
103:デフォルトの名無しさん
11/11/27 16:10:13.82
DirectXが左手系を採用した理由を、設計者に本音で聞いてみたいよねw
しかし左手系が実用性重視だのCの配列と相性がいいだの言ってる人は、
一体何を根拠にしてるんだろ？ ワケ分からん。
104:デフォルトの名無しさん
11/11/27 16:21:09.24
OpenGL右手座標系のはずなのに左手でCoordinate作ってしまう
x:中指,y:人差し指,z:親指
105:デフォルトの名無しさん
11/11/27 16:36:09.96
でも XNA で用意されている関数は右手系なんだよな
何がしたいのか分からん
106:デフォルトの名無しさん
11/11/27 16:55:40.42
MS のこれまでの所業を見て >>102 以外の理由があるかというと
107:デフォルトの名無しさん
11/11/27 18:51:36.50
3DCGに関わって15年になるけどどっちでもいい
108:デフォルトの名無しさん
11/11/27 18:54:03.23
7. OpenGL does not force left- or right-handedness on any of its coordinates
109:デフォルトの名無しさん
11/11/27 19:01:14.11
あほか
DirectXはとにかく速度重視したからC++の配列に合わせて左手座標にしたのだ
転置する必要をなくすためにな
110:デフォルトの名無しさん
11/11/27 19:05:43.44
右手座標だって転置する必要ないじゃん
111:デフォルトの名無しさん
11/11/27 19:09:14.52
してないように見えて実はハードウェア内部でしてる
112:デフォルトの名無しさん
11/11/27 19:13:56.24
>>111
してないよ
>>68見ればわかるけど、D3DXMATRIXとOpenGLのマトリックスは全く同じ配列なんだよ
113:デフォルトの名無しさん
11/11/27 19:18:29.09
>>109
右手系と左手系の話と転置は関係ないから
URLﾘﾝｸ(msdn.microsoft.com)
＞ビュー行列に使用している D3DMATRIX 構造体の _31、_32、_33、および _34 メンバーの符号を反転させます。
変換するには符号を反転させるだけなので
114:デフォルトの名無しさん
11/11/27 19:21:46.88
そりゃ一回Translationしただけなら転置の必要はないわな。
115:デフォルトの名無しさん
11/11/27 19:24:18.76
>>112
DirectXの場合はScaleしてからRotateしてTranslateするけど
OpenGLで、その順番でやってみなよ君
116:デフォルトの名無しさん
11/11/27 19:53:38.92
>>113
大いにあるぞ
そのページの最後
>>これらの操作を組み合わせると、結果は可換的ではなくなり、行列を乗算する順序が重要となります。
URLﾘﾝｸ(msdn.microsoft.com)(v=vs.85).aspx
>>作成した行列の種類にかかわらず、期待どおりのエフェクトを実現するには、左から右へのルールが適用されることを忘れないでください。
117:デフォルトの名無しさん
11/11/27 19:58:23.06
基本的なことを聞くけど
・座標系の左右と、行列の積の結合の左右
・座標系の左右と、行ベクトルか列ベクトルか
・座標系の左右と、乗算すべき行列が概念的なスタックに積まれる順番
これらは本質的に無関係だよな
118:デフォルトの名無しさん
11/11/27 20:06:52.73
そもそもDirect3Dが左手だってのはどこから来てるの？
算術関数も両方用意されてるじゃん
119:デフォルトの名無しさん
11/11/27 20:15:09.91
>>115
自分で行列逆に掛け算してSetTransformしてんじゃないの
MultiplyTransformで掛けこんでいったらDirectXもTrans Rotate Scaleの順だったが
120:デフォルトの名無しさん
11/11/27 20:20:55.20
昔は左手座標しか無かったんだよ
DirectX5時代の話だけど
121:デフォルトの名無しさん
11/11/27 20:26:04.68
>>119
ちゃんとLH使ってんのか？
122:デフォルトの名無しさん
11/11/27 20:45:35.44
なんかglLoadMatrixに渡す行列のレイアウトがD3DXと同じなのに
glRotate/Translate/Scaleの変換の適用順がD3DXの乗算と逆なあたりが混乱の元凶な気がするんだが
123:デフォルトの名無しさん
11/11/27 20:54:28.93
>>122
それこそが右手座標と左手座標の最大の違いなのだよ
行列データそのものは同じでも意図する合成行列を作るには
乗算順序を変えなければならない
URLﾘﾝｸ(www.c3.club.kyutech.ac.jp)
ここ見るとわかるかもしれない
124:デフォルトの名無しさん
11/11/27 21:02:58.86
>今までの行列演算でおかしいと思った方がいたらすばらしいです。
>実はDirectXでは通常の数学とは行列の演算順序を逆にしてるんですよね。
>数学では座標 * 行列の演算順序であるのに、DirectXでは行列 * 座標の
>演算順序で表しています。
>迷惑な話ですが、このようなことで配列を効率よく使うことができ、
>メモリ効率が上がるらしいです。
>ただ、これだと行列の演算順序が変わると結果が変わってしまいます。
>そこで、DirectXでは行列を転置させて結果を変えないようにしています。
>ややっこしい。
125:デフォルトの名無しさん
11/11/27 21:03:00.58
>>123
＞ matWorld = matScale * matRot * matTrans;
v' = v * S * R * T
なんだから
デバイスのポインタ->SetTransform(D3DTS_WORLD,&matWorld);
をMultiplyTransformで書き換えれば、
デバイスのポインタ->SetTransform(D3DTS_WORLD,&matTrans);
デバイスのポインタ->SetTransform(D3DTS_WORLD,&matRot);
デバイスのポインタ->SetTransform(D3DTS_WORLD,&matScale);
になる。OpenGLと一緒。
126:デフォルトの名無しさん
11/11/27 21:05:26.53
>>125
下の３行はMultiplyTransformの間違い。
あと掛ける前にD3DXMatrixIdentityで作ったので初期化(glLoadIdentity同等）する必要もある
127:デフォルトの名無しさん
11/11/27 21:05:55.72
>>125
>>124
128:デフォルトの名無しさん
11/11/27 21:08:24.04
列優先だか行優先だか右手回転系だか左手回転系だか
どれをなんて呼ぶのかよく覚えてねえけどさ
z軸の符号が異なるだけの右手左手系は全然関係ねえでしょ？
D3DXのLHとRHの結果の相違は転置してるだけ？ 違うでしょ？
129:デフォルトの名無しさん
11/11/27 21:21:40.54
おまえ、SetTransformは行列スタックじゃねぇか
D3DXMatrixMultiplyでやってみろ
130:デフォルトの名無しさん
11/11/27 21:27:17.48
D3DXMatrixTranslation
D3DXMatrixRotation
D3DXMatrixScaling
でやってみたの？
131:デフォルトの名無しさん
11/11/27 21:37:58.12
>>125
お前どうしようもないな
v' = S * R * T * v
S,R,T,vの順にかける
132:デフォルトの名無しさん
11/11/27 22:07:26.37
>>117
①座標系の左右と、行列の積の結合の左右
座標系の左右と行列の積の結合の左右は関係ない
②座標系の左右と、行ベクトルか列ベクトルか
少なくとも数学では右手座標と列ベクトルを用いることが定まっている
そしてOpenGLはそれを採用
DirectXでは左手座標と行ベクトルを採用していた(当初)
理由として
2Dの場合画面左上が原点になる
C++配列と相性が良い
③座標系の左右と、乗算すべき行列が概念的なスタックに積まれる順番
座標系の左右と、乗算すべき行列が概念的なスタックに積まれる順番は関係ない
133:デフォルトの名無しさん
11/11/27 22:15:21.94
>>131
DirectXでは（紙の上ではOpenGLとは逆に) v' = v * M;
つか今回の話の発端はここでしょ
134:デフォルトの名無しさん
11/11/27 22:36:05.24
ちみがいいたいのは平行移動行列と回転行列、拡大縮小行列は同じって事だろ
そう、同じだよ
でもDirectXとOpenGLが同じかと問われたら、それは全然違うと答えるよ
135:デフォルトの名無しさん
11/11/27 22:41:53.93
C++配列と相性が良いってどういうことよ
まさかメモリ効率云々を曲解してるんじゃないよな
136:デフォルトの名無しさん
11/11/27 22:43:00.64
>>133
線形代数やり直して来い
137:デフォルトの名無しさん
11/11/27 22:48:08.63
>>136
線形代数がどうだろうと、実装はMSがしてんだからしょうがないだろ
URLﾘﾝｸ(msdn.microsoft.com)
v' = v * M
138:デフォルトの名無しさん
11/11/27 22:56:42.21
Direct3DとOpenGLの座標系における明確な違いなんて
o 非同次射影空間のz値のクリッピング範囲が[-1,+1]と[0,+1]
o 補助関数(D3DX、glu)を比較するとむしろOpenGLが右手座標系しか選択肢が無いと言うべき
くらいで後はどうでもいい。
というか後者もどうでもいいか。
139:デフォルトの名無しさん
11/11/27 22:58:41.62
あとテクスチャのピクセルが0.5ずれてるんだっけ
140:デフォルトの名無しさん
11/11/27 23:00:08.09
列優先設定でのDirect3D持ち出したらお前が言い出した>>125のOpenGLとDirect3Dが一緒って主張がトリビアルでアホ丸出しだったってことになるんだが
141:デフォルトの名無しさん
11/11/27 23:14:03.72
阿呆は今のことろ行列の合成順に右手左手言いだしたヤツだけだょ
142:デフォルトの名無しさん
11/11/27 23:19:23.56
>>135
転置行列を作成しなくてもよい＝無駄なメモリ使わないしスピードも速い
物凄く効率的じゃないですか？
143:デフォルトの名無しさん
11/11/27 23:21:58.43
>>142
右手座標系（OpenGL）でプログラムする場合に、
どこで、何の理由で転置行列を作る必要があるのでしょうか
144:デフォルトの名無しさん
11/11/27 23:23:01.60
>>142
何か勘違いしてるようだけど
145:デフォルトの名無しさん
11/11/27 23:29:09.11
>>139
D3D10からはずれていないと思った。
146:デフォルトの名無しさん
11/11/27 23:36:26.58
なんでズレてんの？
147:デフォルトの名無しさん
11/11/27 23:38:06.08
つーか今のDirect3Dでは、D3D9で生にシェーダ定数渡す時も
D3D10以降の定数バッファに渡す時もD3DXの行列は転置する必要があるんだけどねｗ
D3DXの行列レイアウトの何が効率的なの昔からよくわからんのだが
焼き直しのXNA Mathでも同じだしSIMD有利なのけ？
148:デフォルトの名無しさん
11/11/27 23:45:03.20
なんだったかな
とにかく速度優先にしたらDirectXの実装になったんだよ
ゲームSDKとしてOpenGLより速く表示する必要があったから
決してOpenGLの逆にしたいとか下らない理由では無かったと思う
149:デフォルトの名無しさん
11/11/27 23:46:04.00
>>145
10で変わったのか、知らなかった。そういう仕様を変えちゃうってもすごいな。
150:デフォルトの名無しさん
11/11/27 23:57:14.57
>>148
説得力が無い
行列同士の積も、行列とベクトルの積も、
右手座標系と左手座標系で計算量は変わらんと思うが
列同士の積の場合にCPUの積和演算器を活用するなら、
右手でも左手でもどちらかの行列を転置しないといけないし
151:デフォルトの名無しさん
11/11/27 23:58:16.62
>>150
すまん、紛らわしいミスをした
> 列同士の積の場合にCPUの積和演算器を活用するなら、
行列同士の積の場合にCPUの積和演算器を活用するなら、
152:デフォルトの名無しさん
11/11/28 00:13:23.85
>>150
説得力が無いと言いたいだけか
気になるならよく事情わからない名無しよりMSに問い合わせればいい
153:デフォルトの名無しさん
11/11/28 01:35:46.83
URLﾘﾝｸ(marupeke296.com)
① どうして左手系なのか？
>そもそも、左手系と右手系の2つある中でDirectXが左手系を選んだのは
>なぜなのでしょうか？私たちは小さい時から右方向がX軸、上方向がY軸の
>2Dのグラフを見てきました。
>そしてごく普通にアニメや漫画のキャラクタは上方向であるY軸に頭を向けて立ちます。
>さてこの状態で3Dになった時、キャラクタの目線は画面の奥に向かうのが自然でしょう。
>そうすれば、キャラクタの目線方向とプレーヤーの目線方向も合います。
>「前へ進め！」とボタンを押したとき、画面の奥に向かっていくのが自然なのです。
>Z軸が画面の奥へ進む座標系は『左手系』です。
>この自然な成り行きでDirectXなどの3Dゲームは左手系座標を採用しています。
URLﾘﾝｸ(www.arakin.dyndns.org)
>しかし、私がよく使用しているペイントソフトのPictBearやGIMP、そして、あの有名な
>Photoshopも左上が原点です。
>私自身が慣れているのは左上原点であり、これまでアップしたきたサンプルも
>左上原点なのですが、やはり、OpenGLのプログラムをする時は、左下を原点にした方が
>分かりやすいため、左下で統一することにしました。ということで、多くのサンプルを
>一部変更しました。
直感的で自然でわかりやすいからというのが理由だろうな
本当の所はわからんが
154:デフォルトの名無しさん
11/11/28 01:47:09.77
自然だの直感的だのは人によって違うからねぇ。
ところで、左手系の方が効率が良いとかまことしやかな噂を聞く割には、
具体的にどの部分でどう効率が良くなるのかっていう説明は目にしないよね。
不思議だよねｗ
155:デフォルトの名無しさん
11/11/28 01:55:37.98
NDAを結ばないと見れない資料だったんじゃないの。
だとしたら不思議じゃないけど。
156:デフォルトの名無しさん
11/11/28 02:06:59.57
ギャグかそれ
157:デフォルトの名無しさん
11/11/28 20:40:54.65
setPlaymodeからsetPlayModeに勝手に変えんなよ糞osgが
158:デフォルトの名無しさん
11/11/28 21:41:31.81
OSGすげー汚くない？
適当にドキュメント読んだだけだけどあれ使う気にならんわ
159:デフォルトの名無しさん
11/11/28 23:33:36.48
OSsanGeyか
160:デフォルトの名無しさん
11/11/29 20:08:17.28
osgはシーングラフ完全特化というのと微妙にゆるい命名規約がいいな
glutよりは好きかも
161:デフォルトの名無しさん
11/11/30 00:11:51.92
glutとosgを比べるのはちょっと無理があるだろ
162:デフォルトの名無しさん
11/11/30 01:58:42.93
私もosgのおかげで偏頭痛が軽減しました
163:デフォルトの名無しさん
11/12/01 20:34:41.74
左手座標が速いってのは上手くやれば視体積0.0～1.0の範囲に収まるって事かな？
その場合、マイナスの演算が無くなるから速くなるかもね
164:デフォルトの名無しさん
11/12/01 20:59:44.34
何言ってんのこの人
165:デフォルトの名無しさん
11/12/01 21:23:24.34
ネタに突っ込んでやるなよ
166:デフォルトの名無しさん
11/12/01 21:24:16.91
流石にこれは本当に 何いってんの？だと思った
煽る訳じゃないが、普通に思った
167:デフォルトの名無しさん
11/12/01 21:36:39.41
>>163
大変興味深い
もう少し具体的な数値を出して、
マイナスの演算が無くなって速くなる事を例示してみてはどうだろう
ネタとか言ってる愚民どもを黙らせることができるかも知れん
168:デフォルトの名無しさん
11/12/01 21:41:19.54
自演なのかな。
それとも病人が二人いるのかな。
169:デフォルトの名無しさん
11/12/01 21:46:32.16
三人だ。ようこそ。
170:デフォルトの名無しさん
11/12/01 21:51:11.86
いや >>167 はどう見てもひねくれた突っ込み
171:デフォルトの名無しさん
11/12/02 18:21:41.12
アセンブラだと乗算は9clock、除算は46clockだっけ。
加算と減算はどうなんだ？
172:デフォルトの名無しさん
11/12/02 18:55:49.24
addとsubは同じ
ただsignedとunsignedの乗算はまず、どちらかにそろえる必要があるから
signedが増えると若干プロセスが増えるのは確か
173:デフォルトの名無しさん
11/12/02 19:09:48.55
浮動小数点の話じゃないの？
174:デフォルトの名無しさん
11/12/02 19:13:12.62
>>138の言ってる事だろ
Direct3Dのビューボリュームが0～1の範囲になってるのはそういう事だったのか
175:デフォルトの名無しさん
11/12/02 19:34:48.97
URLﾘﾝｸ(www.daionet.gr.jp)
行列式で見てもDirectXの方が速いな。
176:デフォルトの名無しさん
11/12/02 19:40:31.58
分かってるだろうが敢えて言う
行列式じゃなくて行列の式な
意味全然違うから
177:デフォルトの名無しさん
11/12/02 20:02:25.03
>>175
contentヘッダがplain/text返すhtmlファイルってどうよ？
178:デフォルトの名無しさん
11/12/02 22:08:28.97
これで左手座標系の方が速くなる理由がわかったな。
それ以外にもDirectXはZバッファリングを適当にごまかして処理を端折ってるからな。
179:デフォルトの名無しさん
11/12/02 22:39:02.21
そうですか
180:デフォルトの名無しさん
11/12/02 23:05:41.03
左手座標系関係無いじゃんｗ
181:デフォルトの名無しさん
11/12/02 23:12:54.04
てか、そんな速度差も１００：１ほどあるなら話は別だが、
そうでないなら、自分の書く処理に集中するべき
私の書いたプログラムの、本当に注力するべき部分、
速度に関しても本当にボトルネックになっている部分、
それが本当に問題になっているなら、そこを洗って正すべき
182:デフォルトの名無しさん
11/12/02 23:52:30.60
>>181
言ってることは至極もっともだが、論点がずれてる
183:デフォルトの名無しさん
11/12/03 00:56:27.37
175の式見てDirectXの方が速いとか言ってる人達は、
1フレームに何万回と射影行列を作るんですかね。
184:デフォルトの名無しさん
11/12/03 01:05:57.56
行列1つについて話してるのになんで出てきちゃったの？
185:デフォルトの名無しさん
11/12/03 01:27:22.90
行列一つの話をしてどうすんのさ。
元々は、DirectXは速度優先のために左手系を採用したとかいう話だったわけでしょ。
それともDirectXは行列一つを速く計算するために左手系を採用したの？
186:デフォルトの名無しさん
11/12/03 01:59:58.68
175は行列の話なのに他の話と混ざっちゃったの？
187:デフォルトの名無しさん
11/12/03 02:21:00.84
つまり175は、DirectXが左手系を採用した理由とは関係無いし、
左手系の方が速いっていう都市伝説とも関係の無い、
射影行列を作るならDirectXの方がちょっとだけ速いよっていうだけの話、って事？
だったらここで出す事に何の意味が・・・まぁいいか。
188:デフォルトの名無しさん
11/12/03 02:54:30.80
誰かベンチマーク
189:デフォルトの名無しさん
11/12/03 10:31:57.68
あの、左手系とか言ってる人はどの概念にその呼称を割り当ててるの？
z軸が反転してること？
メモリ配置の違いによる行列の合成順のこと？
190:デフォルトの名無しさん
11/12/03 12:52:55.68
メモリ配置とか言ってる人は数学ベースで考えられない人？
191:デフォルトの名無しさん
11/12/03 13:05:51.83
>>190
数学ベースなら右手も左手も全く同じ計算量なんだから、
あとはメモリ配置とかCPU命令、GPUの仕組みやドライバなどで考えるしかないような・・・
192:デフォルトの名無しさん
11/12/03 13:06:46.36
>>190
お前もう黙れよ低脳。 数学的に考えたら速度差の話に答えが出せるっての？
193:デフォルトの名無しさん
11/12/03 13:51:14.07
>>192
メモリ配置って言ってるのが恥ずかしくなった？
194:デフォルトの名無しさん
11/12/03 13:54:23.43
>>53以降、馬鹿が目立つな。
195:デフォルトの名無しさん
11/12/03 14:08:57.53
190みたいな、具体的な話は何もできないくせにさも何かを知ってる風にしたがる厨二はどこにでもいるわけで・・・
相手にしたところで、空っぽなところからは何も引き出せないんだから、熱くならないことをお勧め致しますよ。 >>192
196:デフォルトの名無しさん
11/12/03 14:22:51.37
>>193
なんで >>191 には反論しないの？
197:デフォルトの名無しさん
11/12/03 14:58:24.48
>>193
何言ってんの？低脳は黙ってろよ
198:デフォルトの名無しさん
11/12/03 18:01:02.61
射影行列って言っても、1秒60フレームなら60回分は速くなるわけな。
メモリ効率が良いってのはなんなんだ？
GPUに転送する時に何かあるのか？
199:デフォルトの名無しさん
11/12/03 18:17:44.85
メモリ上で連続に配置されてるほうがキャッシュに乗りやすいから早い
200:デフォルトの名無しさん
11/12/03 18:37:02.66
ほうほう。左手座標は連続してて右手座標は連続してないのか。
201:デフォルトの名無しさん
11/12/03 18:52:53.65
>>199
それは確かにそうだが、
行列1つを行優先で配置しようが列優先で配置しようが、
普通のライブラリならどちらも連続的に配置する（ことを要求してくる）
採用している座標系の右手左手に関係なく
そして、行列同士の演算や行列とベクトルの演算において、
ある行や列は計算に不要ということはなく、全ての要素が計算対象となる
だから、行優先でも列優先でも、ましてjpgみたいに斜めに配置しようと、
連続的に配置されているのなら、1回の演算におけるキャッシュ効率は全く同じ
ちなみに、行列1つにつき32ビット浮動小数点16個分で、たった64バイト
ライン長64バイトのキャッシュメモリの場合、
行列の要素をメモリ上にどのように並べようが連続してさえいれば、
１行１列目にアクセスした時点で全要素キャッシュにロードされる
202:デフォルトの名無しさん
11/12/03 19:51:25.43
しかも64バイトの配列の並びは行優先と列優先の転置では同じでしょ
DirectXのx行目y列目とOpenGLのy行目x列目は共にm[ x * 4 + y ]
203:デフォルトの名無しさん
11/12/03 22:07:36.25
メモリ配置厨涙目ｗ
204:デフォルトの名無しさん
11/12/03 22:18:59.02
なんか痛々しいのが多いな
205:デフォルトの名無しさん
11/12/03 22:21:48.17
それ誰に対して言ってるの？
206:デフォルトの名無しさん
11/12/03 23:21:20.71
散々関係ないって言ってるのに
いまだに右手だの左手だのほざいてるアホにでしょう
207:デフォルトの名無しさん
11/12/04 04:05:23.61
ポリゴンの一面単位でなく、頂点単位でglRotate～などの変換を適用させる方法がわかりません
頂点データを毎回変更させてから描画するしかないのでしょうか？
208:デフォルトの名無しさん
11/12/04 04:23:58.39
>>207
それは例えば 「鋭く尖ったウニみたい五芒星を、まるっこい五角形に」 みたいな話？
頂点更新して再適用（ glMapBuffer～頂点更新～glUnmapBuffer ）するか、
または頂点シェーダで
209:デフォルトの名無しさん
11/12/04 04:37:03.43
>>208
そのような描画をしたいんですが、どうやら毎回更新するしかなさそうですね
ありがとうございました
210:デフォルトの名無しさん
11/12/04 12:06:31.69
>>209
ちなみに一つだけ老婆心で書いておくと、上の話を踏まえた場合、
＞頂点単位でglRotate～などの変換を
頂点の移動は glScale/glRotate/glTranslate でなく、自分で数学的に計算すること
何故って自分で持ってるデータを書き換えて、再送信だから
211:デフォルトの名無しさん
11/12/05 20:47:51.51
みんなツールキットは何を使ってるん？
212:デフォルトの名無しさん
11/12/05 22:41:26.19
普通wgl
213:デフォルトの名無しさん
11/12/05 22:46:46.19
Linuxでも使えたっけ wgl
214:デフォルトの名無しさん
11/12/06 00:17:56.36
まともな環境なら大抵はね
215:デフォルトの名無しさん
11/12/06 01:23:57.38
SDL
androidに移植できるらしいが情報が全然なくて途方に暮れてる
216:デフォルトの名無しさん
11/12/06 01:38:36.17
SDLはライセンスに注意
217:デフォルトの名無しさん
11/12/06 03:29:32.31
GPL混ざってる？
218:デフォルトの名無しさん
11/12/06 11:05:49.93
>>211
好きなの選べ
URLﾘﾝｸ(www.opengl.org)
さすがにSDLは時代遅れだろう
GLFWとかの方がいい
219:デフォルトの名無しさん
11/12/06 12:34:32.43
SDLとGLFWとでは抽象レベルが全然違うような気がする
220:デフォルトの名無しさん
11/12/06 12:45:26.92
SDL使うぐらいならSFMLを使ったほうがいい
221:デフォルトの名無しさん
11/12/06 21:39:43.13
GLEWで音楽再生とかどうやるの？
222:デフォルトの名無しさん
11/12/06 22:23:01.91
恥ずかしながらSFMLって初めて聞いた
面白そうだけど日本語情報が少ないから大変そうだ……
223:デフォルトの名無しさん
11/12/06 22:30:46.33
>>221
GLFW 自体には音楽再生用の仕組みは用意されていないから、
別のライブラリやAPIを使う
play 関数を呼べば stop 関数を呼ぶまで再生し続ける関数があるなら、
それを適当なタイミングで呼べばいい
再生用バッファにwavデータを少しずつ放り込むタイプなら、
毎フレームにおいてバッファの様子を調べて適当にデータを放り込め
224:デフォルトの名無しさん
11/12/06 22:39:54.84
>>218
横からだけど、glutしか使ってなかった
glfwまじで使いやすかったわ・・・ガチでありがとう
225:224
11/12/06 22:40:46.98
テンプレに入れて欲しいくらいだ
226:デフォルトの名無しさん
11/12/06 23:23:03.87
フレームワークだけは自作じゃないと落ち着かない
227:デフォルトの名無しさん
11/12/06 23:43:21.70
>>224
glutと比べてどこらへんが使いやすい感じなの？
228:デフォルトの名無しさん
11/12/07 07:26:32.42
>>227
・ちゃんとメインループから帰ってくる
・tgaのテクスチャなら作るのラクチン
・glutくらいシンプル
229:デフォルトの名無しさん
11/12/07 16:18:16.17
GLUTによる「手抜き」OpenGL入門を見てアニメーションを作っているのですがこのやり方で一定の動きをした後同じオブジェクトに違う動きをさせるアニメーションを作るにはどうすればいいでしょうか？
230:デフォルトの名無しさん
11/12/07 17:24:24.21
どこのopenglのバージョンの境かしらないが
０サイズのテクスチャーをFBOにアタッチしてOKだったりエラーだったりするのな
焦らせやがって全くｗ
231:デフォルトの名無しさん
11/12/07 19:04:32.62
>>229
それは GLUT や OpenGL とは何の関係もない
「一定の条件を満たしたかどうか」を判定する方法と、
判定した結果に応じて「状態を遷移させる」方法があればできる
if (一定の動きをしたか？) then 違う動き else 同じ動き
とか
void anim1 () { 同じ動き }
void anim2 () { 違う動き }
--------
a = anim1 // 初期化
if (一定の動きをしたか？) then a = anim2
とか、方法はいろいろある
232:デフォルトの名無しさん
11/12/07 19:43:08.10
いつも省略してたからthenっていう書き方が斬新に見えた
本来は if then elseなんだな
233:デフォルトの名無しさん
11/12/07 19:45:51.25
>>232
スマン
>>231 は擬似コードのつもりだ
234:デフォルトの名無しさん
11/12/08 23:59:15.80
ES 2.0でglEnable/glDisableのGL_MULTISAMPLEがなくなってますが、
途中でマルチサンプルのON/OFFを切り替えるのって
もうできなくなってしまったんでしょうか？
235:デフォルトの名無しさん
11/12/09 21:31:02.67
スレチだけど状態遷移書いてるとyieldとか手軽につかえたらなーと思うなぁ
236:デフォルトの名無しさん
11/12/10 00:43:40.49
long jumpでええやん
237:デフォルトの名無しさん
11/12/10 03:28:12.94
libpclマジオススメ
238:デフォルトの名無しさん
11/12/10 16:16:42.39
>>231
ありがとうございます。また質問させてください。
239:デフォルトの名無しさん
11/12/10 20:23:17.92
>>236-237
うーんなるほど・・・
240:デフォルトの名無しさん
11/12/10 21:11:47.73
これまでの流れで自分の理解度が不安になったんで質問します。
質問1)
OpenGL の行列が C=CM なので
原点から10離れた位置でZ軸で45度回転する場合の行列を求めるには
紙の上では
C:カレント行列 R:Z軸で45度回転 T:X軸に10移動 I:単位行列
C=I
C=C * R ローカル座標のZ軸で45度回転
C=C * T ローカル座標のZ軸で45度回転したX軸で10移動
C=((IR)T)=(I(RT))
コーディングでは
C=I
C=C * T or C *= T ローカル座標のX軸で10移動
C=C * R or C *= R X軸で10移動したローカル座標のZ軸で45度回転
C=((IT)R)=(I(TR)) or C= I * T * R
つまり、紙の上では C=IRT コーディングは C=ITR
で、正しいですか？
241:デフォルトの名無しさん
11/12/10 21:12:29.51
質問2)
OpenGL の行列が C=CM なので
原点から10離れた位置でZ軸で45度回転する場合の行列を求めるには
C:カレント行列 R:Z軸で45度回転 T:X軸に10移動 I:単位行列
紙の上では
C=I
C=T * C 絶対座標系のX軸で10移動
C=R * C 絶対座標系のZ軸で45度回転
C =((RT)I)=(R(TI))
コーディングでは
C=I
C=C * T or C *= T 絶対座標系のX軸で10移動
C=C * R or C *= R X軸で10移動した絶対座標系のZ軸で45度回転
C=((IT)R)=(I(TR)) or C= I * T * R
つまり、紙の上では C=RTI コーディングは C=ITR
で、正しいですか？
紙の上ではC=MC をコーディングではC=CM で計算しているので
行列の計算順は質問1）と同じですが、行列TやRの算出方法は
今回はたまたま同じ行列TやRが使えるだけで 質問1）と異なりますよね?
242:デフォルトの名無しさん
11/12/11 09:54:37.99
＞つまり、紙の上では C=IRT コーディングは C=ITR
＞で、正しいですか？
正しいわけないだろ
243:デフォルトの名無しさん
11/12/11 12:28:27.29
>>240-241
紙の上ってどういう意味？
>>242
何が悪いか言わずに正しいわけないだけ言うのって内容を理解してない人間がよくやる
244:デフォルトの名無しさん
11/12/11 12:40:56.23
今からまた行ベクトルだ列だ転置だ左手だってはじめるのかｗ
245:デフォルトの名無しさん
11/12/11 12:49:30.33
はあフレームバッファの始点を左上にしたい
246:デフォルトの名無しさん
11/12/11 14:16:09.57
また阿呆が暴れてるのか。消えろよ 240
247:デフォルトの名無しさん
11/12/11 14:47:23.17
紙の上ってのが良くわからんが C=IRT コーディングは C=TRI じゃねぇの？
右から計算するなら
248:デフォルトの名無しさん
11/12/11 14:58:12.26
一部のandroid機種だとGL_INFO_LOG_LENGTHの値って常に0が返ってくるのね…
おのれー！
249:デフォルトの名無しさん
11/12/11 16:29:34.26
紙の上＝学校で習った数学での習慣を使った手計算の時の順序では、
ってことじゃないの？
ここは勉強出来ない、数学出来ない、ライブラリのリファレンス読んでわかったつもりの
ニートとクズの吹き溜まりだから、真面目な質問しても答え返ってこないよ
>>242-247 みたいなレスしか返せない。 さらにバカだと >>246 みたいな頭のおかしいレスになるし。
ちなみに俺は、数学弱いのでよくわからないｗ
250:デフォルトの名無しさん
11/12/11 16:49:04.80
>>249はなんで書き込んだんだ？
251:デフォルトの名無しさん
11/12/11 17:17:43.47
>>240
紙のRやTもOpenGLでは転置になるから同じR T ではない点に注意
(R * T)の転置 ＝ Ｔの転置 * Rの転置
という関係があるので逆になるように見える。
縦書きと横書きの違いでしかない
つかずっと同じ話してるので、自分で実際にプログラム作って確認してみたらいいよ
252:デフォルトの名無しさん
11/12/11 18:17:41.79
>>251
OpenGLでは転置になるとかウソ書くからまた混乱する初心者が増えるんだよ・・・。
OpenGLの主な(?)ドキュメントは列ベクトル表記を採用しているというだけの話だろ。
253:デフォルトの名無しさん
11/12/11 18:33:20.71
>>252
その通りです。すいません。
254:デフォルトの名無しさん
11/12/11 19:32:11.05
>>247は合ってると思うけどｗ
学校で習った数学での習慣を使った手計算の時の順序が
OpenGLでは逆になるという事だ
255:デフォルトの名無しさん
11/12/11 19:48:22.38
紙の上とは
>>249氏のとうりです。
>紙の上＝学校で習った数学での習慣を使った手計算の時の順序では、
>>247
確かにです。
>>254
皆さん、有難うございます。
256:デフォルトの名無しさん
11/12/11 20:05:03.67
数学こそ列ベクトルが基本じゃないか
写像 f1, f2, f3 (対応する変換行列は M1, M2, M3)を考えたときに
列ベクトル [x; y] に f1, f2, f3 を順番に適用すると、
[x'; y'] = f3(f2(f1([x; y])))
= M3 M2 M1 [x; y]
同様のことを行ベクトルで書くと、
[x' y'] = [x y] t(M1) t(M2) t(M3) t(・)は転置
というだけの話だろ
というか、変換行列であることを無視して単なる行列演算の話をしても無意味
257:デフォルトの名無しさん
11/12/11 20:14:05.98
数学、OpenGL＝列ベクトル
C/C++の配列＝行ベクトル
だから逆順に掛けるんだよ
258:デフォルトの名無しさん
11/12/11 22:50:04.22
>>257
ハァ？？？？？？
259:デフォルトの名無しさん
11/12/12 00:19:00.50
ここは自分の中の知識を相手に伝えることの出来ない人間と相手の言っていることを理解しようともしない人間の巣窟ですね
260:デフォルトの名無しさん
11/12/12 00:21:37.57
さすがに>>257は、わざわざ頓珍漢な事を書いて場を荒らそうとしてるとしか思えないレベル。
261:デフォルトの名無しさん
11/12/12 17:02:57.84
glutで作った二つのウィンドウに，
glDrawArraysを用いて全く同じ物を描画しようとすると，
エラーでプログラムが落ちてしまいます．
ウィンドウが一つの時は問題なく描画できています．
頂点の数は2^24個程なのですが，何か制限があるのでしょうか？
頂点の数を減らしても駄目でした．
262:デフォルトの名無しさん
11/12/12 17:53:24.12
>>261
昔のことなんで間違ってるかもしれないが
テクスチャとか頂点配列ってウィンドウごとに固有じゃなかったっけ
263:デフォルトの名無しさん
11/12/12 22:12:10.54
２つのスレッドが同じ所を参照しようとして… とか
いや適当だが
264:デフォルトの名無しさん
11/12/12 22:52:59.22
クリティカルセクション
265:デフォルトの名無しさん
11/12/12 23:00:25.39
wglShareLists
266:デフォルトの名無しさん
11/12/13 00:38:39.68
glutでウィンドウ2つ作れることに驚いた
267:261
11/12/14 10:56:15.94
返信ありがとうございました．
検討したところ，>>262の方の言う通りでした．
VBOを二つ用意しても，予め二つ確保した場合では描画されず，
もう一つのウィンドウを作成したあとにもう一つのVBOを確保してやる必要がありました．
皆様，御助言ありがとうございました．
268:デフォルトの名無しさん
11/12/14 14:49:13.76
>>267
それを共有するようにするのが>>265のwglShareListsだったり
glut使ってるとすんなりは無理かもしれないけど
269:デフォルトの名無しさん
11/12/14 17:02:23.81
三次元中にGL_QUADSにglcolorで色をつけて描画したいのですが
線のみ色が変わります。塗りつぶすにはどうすればいいでしょうか？
270:デフォルトの名無しさん
11/12/14 17:15:35.56
glPolygonMode 辺りを
271:デフォルトの名無しさん
11/12/14 17:47:43.58
C#でOpenGLを使うのも悪くないと思えてきてしまった。
少なくとも、MFCで四苦八苦するのはもうイヤだし。
OpenGL Menu URLﾘﾝｸ(t.co)
272:デフォルトの名無しさん
11/12/14 18:24:05.83
>>270
それを使って塗りつぶせました。
ありがとうございます。
273:デフォルトの名無しさん
11/12/14 20:50:01.98
短縮URLやめようぜ
274:デフォルトの名無しさん
11/12/14 21:19:57.20
なんで？
275:デフォルトの名無しさん
11/12/14 21:50:46.83
>>271
MFC使わなきゃいいだけじゃね
stl と boost と自分の過去資産（win32ハンドリング含む）があればまったく不要
と言う俺は最近 Python+OpenGLが楽しい。直書きそのまま実行でGLSLのテスト出来るってのが、
スクラッチ＆ビルドで実験コード書いてる時、超絶楽ちんぽん
276:デフォルトの名無しさん
11/12/15 03:07:36.75
>>274
文字数にシビアな制限があるわけでもないし、
短縮だとどこへのリンクかURLから予測できないからクリックしずらい
277:デフォルトの名無しさん
11/12/15 09:16:56.06
t.coだからtwitterのつぶやきをコピペしたんだろ。
278:デフォルトの名無しさん
11/12/16 18:14:51.33
OpenGLって、ジオメトリインスタンシングを自動でやるのですか。
ディスプレイリストだったら、APIの仕様としてまとめて送るというのは知ってますが
ジオメトリまでやってるとは聞いた事がありません。
279:デフォルトの名無しさん
11/12/16 18:29:18.90
glDrawElementsInstanced
280:デフォルトの名無しさん
11/12/16 19:30:39.69
インスタンシングを勉強すると、1体しか出なくても
それで出してしまう
関数ポインタを習った後、何でもかんでも関数ポインタ使って実装したのと同じ
281:デフォルトの名無しさん
11/12/16 19:51:58.10
インスタンシングが必要ない程度には早いって大昔に聞いたけど専用の拡張もできてたんだな
282:デフォルトの名無しさん
11/12/16 20:02:18.47
やっぱ効果あるよ
30フレームすら維持できないくらいに頂点を増した状態でインスタンシングすると
60フレームにビターッと張り付く
283:デフォルトの名無しさん
11/12/18 09:37:33.50
自分はカメラは3次元空間に配置するオブジェクトだからモデルビューに置くものだと思ってるけど
みんなはプロジェクションビューとモデルビューどっちに置く？
284:デフォルトの名無しさん
11/12/18 10:15:36.87
お前は一体何を逝ってるんだw
285:デフォルトの名無しさん
11/12/18 12:02:02.53
>>283
曖昧にしか理解していないか、
またはもの凄く話しを省略して話している？
自分が言った内容の詳細を説明してみろ
286:デフォルトの名無しさん
11/12/18 14:07:21.36
ジオメトリだけ考えるならカメラ操作を投影行列の方でやってもいいんだろうけど、
それだとライティングやクリッピングその他、色々うまく動かなくなるよね。
287:デフォルトの名無しさん
11/12/18 14:17:20.92
283=286だな
お前の理解はまったくダメダメなので
あと３回OpenGLの教科書を読み直せ
288:デフォルトの名無しさん
11/12/18 18:05:43.34
>>286
まさかとは思うが、モデルビューとプロジェクションビューって言う、
プログラム的にまったく作りの異なる別の何かが存在してるとか思ってる？
あと、まさかカメラって言う、プログラム的に独立した、
何か曖昧なオブジェクトが存在してると思ってる？
289:286
11/12/18 18:28:08.72
いや283じゃありませんが。
お二人とも、想像力豊かなコトでw
290:デフォルトの名無しさん
11/12/18 18:59:56.56
つかプロジェクションビューってなに
291:デフォルトの名無しさん
11/12/18 20:02:32.63
「ここは茶臼山でしょうか？」
↓
関西人「ちゃうス」
292:デフォルトの名無しさん
11/12/18 20:20:45.45
今どきのOpenGLで
自前で行列管理してる話とかじゃないのかしら
293:デフォルトの名無しさん
11/12/18 22:51:23.18
こうするか
glMatrixMode(GL_PROJECTION);
gluLookAt(up_.x, up_.y, up_.x, eye_.x, eye_.y, eye_.z, center_.x, center_.y, center_.z);
こうするかって話じゃねーの？
glMatrixMode(GL_MODELVIEW);
gluLookAt(up_.x, up_.y, up_.x, eye_.x, eye_.y, eye_.z, center_.x, center_.y, center_.z);
294:デフォルトの名無しさん
11/12/18 22:52:00.44
いや違うか
295:デフォルトの名無しさん
11/12/19 08:43:44.81
いやそうでしょ
多分
296:デフォルトの名無しさん
11/12/19 11:40:52.17
・glx: XからOpenGLを使うためのライブラリ。普通は直接は使わず意識する事はない
・glut: クロスプラットフォームなツールキット。でもさすがに古くさい
・glew: これを入れないと拡張機能が使えないor使いにくい
・glxgears: 歯車が回るベンチマーク。-infoでOpenGLのバージョンが見られる。OpenGLの動作確認はこれで
・glxinfo: 自分の使っているカードのOpenGLの機能が全てリストアップされる。
・OpenTK C#からOpenGLを簡単に使えるようになる。VC#の強力なIntellisenseとあわせてサクサク開発可能。
OpenGLちゅんは、なんでこんなに分家しとるん？
いちいちめんどくさいだろ。
1つで全部できるようなもんないのか
297:デフォルトの名無しさん
11/12/19 11:50:10.15
いや違うカテゴリーのものを一緒にされてもw
298:デフォルトの名無しさん
11/12/19 11:56:34.57
>>296
一人や一箇所が全部作ってる訳じゃないから。 分家してるとか、そういう事じゃないんだよ。LinuxやUnixのOSとかもそうだけど。
コンピュータの世界にあるライブラリや製品の多くがそうなように、それぞれバラバラに、
誰かがいつか思いついて開発して、そして増えて広がっただけ。 またはプロダクトの設計上、疎結の関係にして切り離したりしてるだけ
俺らが、他人の生み出した物を使わせてもらう分際で、それすらめんどくさいと思うのなら、
むしろ自分で一つにまとめたライブラリでも作って自分で使うか、または世界に発表して、標準化しておくれ。
誰にでもそうやって、高名を得るチャンスは平等にあるんだから
299:デフォルトの名無しさん
11/12/19 12:04:05.26
>>296 阿呆か。
300:デフォルトの名無しさん
11/12/19 12:16:28.84
分家というならESの方よね
301:デフォルトの名無しさん
11/12/19 13:23:01.03
>>296
わらったｗ
302:デフォルトの名無しさん
11/12/19 15:19:18.34
今は glm なんかもあるしなあ。
303:デフォルトの名無しさん
11/12/19 18:32:49.87
これってnvidiaドライバのバグ？
glGetActiveUniformARBでシェーダ側の変数名を得ると
シェーダ側の変数が"uniform mat4 JointTransform[62];"の時
amd "JointTransform"
nvidia "JointTransform[0]"
と返ってくる
304:デフォルトの名無しさん
11/12/19 20:35:01.94
>>296
>1つで全部できるようなもんないのか
いいとこに気がついたね
誰もそういうのを作ってないんだよ お前が作ればいいじゃん
305:デフォルトの名無しさん
11/12/20 08:14:09.99
>>303
バグかどうか知らんけどうちでもそうなる。
もう随分前からずっとそうなので、そういうもんだと思ってやってる。
306:デフォルトの名無しさん
11/12/20 10:50:30.42
>>304
だな。
そしてglなんとかがまた一つ増えるｗ
307:デフォルトの名無しさん
11/12/21 05:31:10.57
魔方陣GLGL
308:デフォルトの名無しさん
11/12/21 12:54:40.15
でも何で「glなんとか」なのか＿＿＿
接頭詞としてglつけろ”という決まりでもあるのか。
glグレネードランチャーとかいうの作ったら、略称がglglになるじゃねえか。
309:デフォルトの名無しさん
11/12/21 13:41:33.49
ARB48
310:デフォルトの名無しさん
11/12/21 23:23:43.19
メンバーが抜けたり消えたりする
311:デフォルトの名無しさん
11/12/21 23:52:38.10
えっ、それ減る一方
312:デフォルトの名無しさん
11/12/22 01:45:12.94
SDLだってSFMLだってあるんですよ！
つかSFMLすげえな。SDLだったらSDL_imageやSDL_mixerが必要なところをこれひとつで全部賄えるなんて
313:デフォルトの名無しさん
11/12/22 09:41:14.44
GLSLのfragment shaderでmain関数の中のfor文の打ち切り条件式に
uniform変数を使うと挙動がおかしくなるんですけど
uniform int n;
for(int i = 0 ; i < n ; i++){...
こんなの
これなんなんでしょうね
main関数以外でも同じようなことやってるんですがそっちは別段なんともないんですよね
314:デフォルトの名無しさん
11/12/22 09:57:30.13
floatでシェーダーに渡して中でintにキャストしたら安定した
なんだこれ・・・
315:デフォルトの名無しさん
11/12/22 10:37:55.73
Uniform変数にintって使えたっけ？
標準では無理だった気がする。まだベンダー拡張じゃなかったか
316:デフォルトの名無しさん
11/12/22 11:16:54.55
あ、一応glew使ってます
あとGLSLは#version 120
317:デフォルトの名無しさん
11/12/22 18:47:56.90
1.2じゃ駄目だった気が
318:デフォルトの名無しさん
11/12/24 03:01:22.09
glGetUniformLocation
glUniform
319:デフォルトの名無しさん
11/12/25 02:25:27.39
シェーダで使うライトの数はコンパイル時に決定するから外部変数にはできないのかー
なんか回避方法ないかねこれ
320:デフォルトの名無しさん
11/12/25 09:35:52.68
floatで渡せよ。何いってんだ
321:デフォルトの名無しさん
11/12/25 11:30:17.68
普通(?)のGLSLのライトの数はfloatで渡せばいいんだけど、
WebGLのGLSLはループ回数(の上限)がコンパイル時に決まらないといけないから
for (int i=0; i<8; ++i) {
if (i >= num_lights) continue;
...
}
みたいな書き方になったりする。
322:デフォルトの名無しさん
11/12/25 12:06:40.62
>>321
WebGL って OpenGL を JavaScript から使うバインダか何かじゃなかったか。
Python から OpenGL を使う PyOpenGL みたいな、要は
ほにゃららから OpenGL を使う 何とか、みたいなそういう立場の物。
なので、先に WebGL の話だけど、って前提置いてから話さないと、
君が一人で思ってる事なんて、誰にも伝わらないよ
323:デフォルトの名無しさん
11/12/25 12:19:42.96
使う上限を予め決めといてライティング結果をライト毎に加算すればいい
使わないライトは0になる値を入れておけば問題ない
324:デフォルトの名無しさん
11/12/25 12:22:04.66
素人考えだけど、テクスチャマップのファイルに
データとしてライトの情報を入れて、シェーダー側で参照ってできんの？
325:デフォルトの名無しさん
11/12/25 12:29:37.33
ライトマップか投影テクスチャのどっちの意味かわからんけどできるよ
326:321
11/12/25 12:29:58.56
>>322
何を勘違いしてるのか知らないけど。
俺は319じゃないし、単にこういうこともあるって書いただけだよ。
>>324
できる。
327:デフォルトの名無しさん
11/12/25 12:33:44.10
>>324
浮動小数点フォーマットのテクスチャファイルに、長い行列の要素放り込んで
シェーダ側でそれを参照、とかは珍しくない話。だが、
＞データとしてライトの情報を入れて
これがどこまでを想定してるのが曖昧なので、YesともNoとも言いにくい
自分が使いたい情報で、かつUniform変数で渡してられないほどの分量があった時、
かつ浮動小数点フォーマットのテクスチャが使える環境なら、そういう手段を取る事もあるでしょう、って話
328:デフォルトの名無しさん
11/12/25 12:36:30.60
>>326
じゃあそれを最初に言えよ。>>319-321 の流れみたら、普通に本人だと思うだろうが。
なんでお前も前提置いて話せないの？
お前が一人で思ってる事なんて、誰にも伝わらな… あれ？デジャブ？
329:デフォルトの名無しさん
11/12/25 12:47:04.90
>>328
恥ずかしかったのは分かるがそう開き直られてもな。
お前みたいなアホの事まで考慮して書き込む気は無い。
330:デフォルトの名無しさん
11/12/25 12:47:16.38
>>321
どうでもいいけどそこはbreakじゃだめなん？用途しだいか？でもcontinueである場合ってないよな？
331:デフォルトの名無しさん
11/12/25 12:50:47.04
>>330
なんだったけかな…よく覚えてないけど、breakだとうまく動かなかったような。
332:デフォルトの名無しさん
11/12/25 12:57:26.07
>>329
いやアホはどう見てもお前。狭い了見の自己中。
それに気づいていないで開き直ってるお前が、まさにアホ
333:デフォルトの名無しさん
11/12/25 13:01:15.59
アホと言うより、１０代くらいのガキだと思う
334:デフォルトの名無しさん
11/12/25 13:03:43.79
>>321
ちょっとそんな抜け道がと思ってやってみたがなんでか駄目だった
break continueどっちも試したが反応なしというか
335:デフォルトの名無しさん
11/12/25 13:20:41.56
>>332
横から口挟むけど>>319は環境については触れていないのに>>321で突然WebGLに話が具体化
この流れはどう見ても本人が情報後出ししたケースの流れ
国語の勉強の話しになるけど本来は「WebGLのこと言ってるなら」とか書くべき
ちょっと脳内スキップ発揮しすぎかと
オフでも多分周りの人間はあなたの話しについて行けてないと思う
336:デフォルトの名無しさん
11/12/25 13:23:30.95
予想だが、GLSLが使うライトの数を評価するのは
uniform変数は0
for文のイテレーター変数は増えない
0番目のライトのみデフォルトで取得
この条件下で行われるのかもしれない
337:デフォルトの名無しさん
11/12/25 13:24:51.04
>>335
安価先、>>321 >>326 >>329 宛てだなそれ
338:デフォルトの名無しさん
11/12/25 13:25:52.34
>>336
あーいや、２番目おかしいな
もうわかんねえなこれ
339:デフォルトの名無しさん
11/12/25 13:44:16.46
>>325,326,327
ありがと
340:デフォルトの名無しさん
11/12/25 14:07:50.08
>>334
じゃあ
for (int i=0; i<8; ++i) {
if (i < num_lights) {
...
}
}
みたいな感じではどう？
それでダメならプログラム間違ってるんじゃないかとｗ
「反応なし」の意味がちょっと分からないけど。
341:デフォルトの名無しさん
11/12/25 14:15:34.88
>>319は回避方法ない？って聞いてて
>>321は回避方法を書いてる
という状況で、>>321が>>319本人だと誤認するロジックが分からん。
国語の勉強の問題なの？
342:デフォルトの名無しさん
11/12/25 15:39:15.12
>>341
>>321 が >>319 の回避方法じゃなくて、追加情報と解釈してしまったのだと思う
つまり、>>321 の方法しかないのか？ もっといい方法無いの？ と質問しているように取ったと
たぶん、これがロジックだと思う
国語の勉強の問題なのかどうかは分からないし、このスレとは何の関係もない
余計な煽りをしないで、双方さっさと誤解を解いて話を続けた方が良い
343:デフォルトの名無しさん
11/12/25 15:43:06.37
>>341
ついでに言うと、>>321 の前に >>320 があることも誤解を生んだ原因かと
>>319 の質問に対して >>320 が答え、そうなんだけどさと>>321（>>319）が追加質問
のように見えてしまったんだろ
344:デフォルトの名無しさん
11/12/25 16:01:47.10
>>326 と >>321が別人という可能性もある
つか結局WebGLの話なのか？
345:デフォルトの名無しさん
11/12/25 16:43:27.97
お前ら面白いなぁ
346:デフォルトの名無しさん
11/12/25 17:12:26.45
>>340
それで効きました
ただ・・・なんか動作が全部チェックしているときの重さと変わらない感じ
for(int i = 0 ; i < gl_MaxLights ; ++i){...
プログラムはコメントアウトしたりして比較しているので間違っては無いと思いたい
反応なしは、１個目０番のライトだけアクティブで他のライトが反応しない状態
なんかもうライトの変数なんて高が知れてるから全部uniform化させてしまおうと思えてきた
347:デフォルトの名無しさん
11/12/25 17:21:40.56
>>342-343
まったくその通り
348:デフォルトの名無しさん
11/12/25 17:32:06.25
>>346
だから「ライトが反応しない」じゃ意味分からないってばｗ
built-in変数に値が設定できてないとか？
349:デフォルトの名無しさん
11/12/25 17:41:38.20
>>348
そういうことです
350:デフォルトの名無しさん
11/12/25 18:35:38.68
常々思ってるけどID出ない板って色々不便ね。
351:デフォルトの名無しさん
11/12/25 19:01:12.87
IDあってもID変えただけの同一人物だろｗとか言い出す馬鹿もいるけど
352:デフォルトの名無しさん
11/12/25 19:49:07.95
floatに頼子だ割ったプログラムソースを目指す人のためのブランド「float志向」
353:デフォルトの名無しさん
11/12/25 20:23:30.41
フロシコ
354:デフォルトの名無しさん
11/12/25 20:27:13.65
誤字が何もかも台無しにしている
355:デフォルトの名無しさん
11/12/26 03:17:34.79
シェーダーの最適化は、GLSLが吐くオペコード数を減らす事とほぼ同義
つまり、固定数ループのfor文で、ループ中で条件かけても
条件が変数でコンパイラが事前に分からないなら
吐き出されるオペコードは、個定数ループを処理する長さと同じ
例え条件で、ジャンプして処理を多少飛ばした所で
シェーダーのオペコード数は同じなんだから大して軽くならない
マジで最適化かけるなら
#if や #ifdef 等でコードをライト数分用意して
動的に切り替わる仕組みを入れないと駄目なんじゃないかな？
356:355
11/12/26 03:29:13.26
昔々のシェーダーモデルのバージョンが低い頃は
if文は重たいなんて言われてたでしょ、そんなイメージ
因みに、うちの会社のライブラリは、シェーダー内に
#if や #ifdef なんかが可読性を殺す程入ってて
バカにしてたけど、シェーダー最適化の説明を聞いて納得した
例を挙げると、シェーダー初期化前にライト数を決めると
そのライト数を処理するシェーダーコードになる仕組み、見たいな
(実行中に変えると、シェーダーの再初期化が入るので非推奨って感じ)
357:355
11/12/26 03:39:33.79
要はシェーダー構文だけで、
ライト数に応じて可変の最軽量負荷のコードを吐くのは無理かと思われる
一番簡単なのは、一番バカっぽいけど
ライト数文のシェーダーファイル(コード？)を用意して
ライト数に応じて、各シェーダーを適応すれば良い
シェーダーやシステムをスッキリさせるか、最適化シェーダーを目指すかは
仕組みを理解して、自分でバランスを決めて実装するしかないと思うよ
確か、GLSLコンパイラでシェーダーアセンブラを吐く機能があったから
まずはそれから試してみなよ
358:デフォルトの名無しさん
11/12/26 04:35:52.19
うおぉ
ためになる話ありがとうございます
シェーダアセンブラは初めて聞きました、敷居高そうですが心に留めておきます
359:デフォルトの名無しさん
11/12/26 17:07:26.71
敷居が高いというか、HLやGL+しゅっしゅっぽっぽぅができるまでは
みんなそれでやっていた。
360:デフォルトの名無しさん
11/12/26 17:07:59.22
そこはCgというべきだったか
HLSLはCgの無断モロパクリだからな
361:デフォルトの名無しさん
11/12/26 20:28:19.01
なんかi286以前の頃に戻った気分だ
クロック数とか気にしちゃう系
362:デフォルトの名無しさん
11/12/27 01:12:18.27
みんなPTXとかILとか読んでないの？
363:デフォルトの名無しさん
11/12/27 18:17:59.29
>>350
この板が扱う話題の性質上、IDが出ると
必死チェッカーで照らしあわせれば
どこの企業(大学)に属してて何をやってるのかとか、おぼろげながら分かってしまうからな
364:デフォルトの名無しさん
11/12/27 18:22:37.44
はぁ？
365:デフォルトの名無しさん
11/12/27 19:14:22.55
触らないで、その人は病気なの
366:デフォルトの名無しさん
11/12/29 23:14:58.13
誰か扱いやすいライト管理クラスください
367:デフォルトの名無しさん
11/12/29 23:28:26.28
どういう事ができると「扱いやすい」と思えるの？
368:デフォルトの名無しさん
11/12/29 23:33:56.77
(○○) ライト、ついてますか
369:デフォルトの名無しさん
11/12/29 23:42:03.72
こないだ無灯火でチャリこいでたらおまわりに注意された
370:デフォルトの名無しさん
11/12/30 05:08:09.06
glColor3fで色指定してるのに白になるのですが何処が悪いですか？
ライト使ったらGL_QUADSの方もマテリアル設定しないといけないとか？
URLﾘﾝｸ(ideone.com)
371:デフォルトの名無しさん
11/12/30 09:14:32.68
試す前に人に訊くバカ
372:デフォルトの名無しさん
11/12/30 10:53:42.16
glMaterialしろよ...
あと頂点ライティングだからピクセル単位でグラデーションは出ないのを忘れるな
373:デフォルトの名無しさん
11/12/30 11:33:21.25
>>371
馬鹿じゃないもん＞＜
374:デフォルトの名無しさん
11/12/30 13:11:28.82
阿呆だもん！
375:デフォルトの名無しさん
11/12/31 04:20:20.59
かわいい
376:デフォルトの名無しさん
12/01/04 00:09:50.53
3D空間上にサイズ不定の画像を表示させたいんですが、どうすれば効率よく出来ますか？
今は各ピクセルの色取り出してglVertex3dで描画みたいな効率の悪いことやってる
377:デフォルトの名無しさん
12/01/04 00:12:22.21
テクスチャー使えよって話？
378:デフォルトの名無しさん
12/01/04 00:36:39.41
VisualBasic で GetPixel や SetPixel やってるようなモンか
379:デフォルトの名無しさん
12/01/04 00:41:22.60
>>377
テクスチャって2のn乗じゃないと駄目なんだよね？
800*600とか色々なサイズに対応したいからそこで困ってる
380:デフォルトの名無しさん
12/01/04 00:44:05.04
いや、それかなり古いバージョンのOpenGLだよ
どっからか走らないが最近のはどんなサイズにも対応してるはず
381:デフォルトの名無しさん
12/01/04 00:50:12.44
たとえ2のn乗じゃないと駄目でも、
800*600なら1024*1024のテクスチャ使えばいいじゃん
382:デフォルトの名無しさん
12/01/04 00:54:28.16
ありがとう、初めてテクスチャ使ってみるわ
383:デフォルトの名無しさん
12/01/04 00:55:39.85
今時はiPhoneですら都合の良いサイズのテクスチャ使えるよ。
きっと2のn乗の方が効率は良いんだろうけど、他のやり方するよりはずっとましだと思う。
384:デフォルトの名無しさん
12/01/04 01:39:23.43
ポリ側を800*600の部分で切ったらええやん
385:デフォルトの名無しさん
12/01/04 12:45:07.50
制限聞いただけで思考停止するのがよくないな
386:デフォルトの名無しさん
12/01/04 13:49:48.65
俺は元画像を縦横拡大して2^nサイズにあわせてテクスチャ化しといて元の縦横比でポリ描画してるけど
メモリの無駄感は否めない
387:デフォルトの名無しさん
12/01/04 13:56:06.40
gluBuild2DMipmapsってみんな使わないの？
388:デフォルトの名無しさん
12/01/04 15:39:21.85
gluLookAtの引数のeyeとupをcenterを向いたままcenter中心でupに対して水平、垂直それぞれの方向に
θ度回転させた結果のeyeとupのベクトルを得たいんだけどどんな行列かければいい？
389:デフォルトの名無しさん
12/01/04 15:46:17.79
>>388
脳が拒否する文面なのでまず正確な文章がかければいい
390:デフォルトの名無しさん
12/01/04 15:58:39.65
gluLookAtの引数であるeye, up, centerについて
eye, upを変化させて対象物(centerの座標)を中心に回転させたいです。
イメージとしてはcenterとeye間をヒモで繋いでぐるぐる回す感じです。
回転させる向きは以下の通り
１．upベクトル方向
２．upベクトルと(center-eye)ベクトルの外積方向
１．、２．についてθ度回転させたeye, upを得るためにはeye, upにどんな行列、
を掛ければいいでしょうか。
391:デフォルトの名無しさん
12/01/04 16:11:41.18
openGL的にはeyeをcenter分引いてオブジェクト座標系？に持ってきて回転行列か
でもこれは回転方向と軸方向を一致させないと駄目っぽいか
数学できるならURLﾘﾝｸ(www.cg.info.hiroshima-cu.ac.jp)
このへん見ながら直接eye upを操作させるとか
なんか俺がOpenGL使えてない気がしてきた
392:デフォルトの名無しさん
12/01/04 16:12:43.36
簡単に言うと、
カメラの方向ベクトルを軸にして、θ度回転させたい
＝ とある任意の軸を中心にθ度回転させたい、って話だろ？
って、くるとクォータニオンの得意分野
393:デフォルトの名無しさん
12/01/04 16:19:22.38
反応が早くて助かります。ありがとうございます。
>>392
クォータニオン・・・がんばります
>>391
このサイトいいですね参考にさせていただきます
394:デフォルトの名無しさん
12/01/05 06:23:42.38
OpenGLの左手座標系を、右手座標系に変換したいときって、
glScalef(1.0f, 1.0f, -1.0f) もしくは、
glScalef(-1.0f, 1.0f, 1.0f) で出来ますよね？間違っていたら指摘お願いします。
で、今Javaで、OpenGL使っているので、JOGLを使っています。
JOGLのバージョンは、Jogamp v2.0 rc5なのですけど、z軸を-1.0倍すると何も映らなくなって、x軸を-1.0倍した結果と違ってしまいます。
これってバグでしょうか？私の勘違いでしょうか？コレだけの情報ではわからないでしょうか？
URLﾘﾝｸ(ideone.com)
97、98行目です。
395:デフォルトの名無しさん
12/01/05 07:10:25.05
DEPTH_TESTをenableにしてZをひっくり返してるからじゃないのかな
396:デフォルトの名無しさん
12/01/05 11:08:29.92
もしくはカメラも反転してるとか
397:デフォルトの名無しさん
12/01/05 17:58:00.95
Xを-1して左手系を右手系なんて聞いたことないな
Zを-1するのだって、行列等の諸々の結果に対して有効であって
途中の計算とかあるなら、Zを-1した所でおかしくなるだけ
詳細を伝えない＆自分が理解してないでZに-1スケールしてるだけなら、
聞いた所でちゃんとした挙動にならない＆理解出来ないんじゃない？
行列と3D処理を理解して、ちゃんと行列処理を右手系にかえるしかないと思うが？
398:デフォルトの名無しさん
12/01/05 18:51:55.10
Zを-1倍したら奥にあるものがカメラの後ろにくるんだぞ？
カメラの方向変えないとな。
399:デフォルトの名無しさん
12/01/05 19:23:45.21
それはTransrateが入った場合
リンク先を見る限り、Rotationしかしてない
＞OpenGLの左手座標系を、右手座標系に変換したいときって、
この質問の仕方で、全然理解してないのが分かる
左手系、右手系とは行列処理の事だろ
例えば左手系前提で作られたモデルがあり、右手系の行列処理でレンダリングしたら
ポリゴンが裏向きになってカリングされてしまうとかの場合
よって最後にスケールZ-1をする事で左手系のモデルを右手系で描画する
とかの場合に、Z-1とかにするんだよ
つかもともとOpenGLの行列処理は右手系
何が左手系なんだ？
頂点って言うんだったら、処理は右手系のまま頂点の2番目と3番目を入れ替えてみれば
CWがCCW、もしくはCCWがCWになって上手く行くかもね
400:デフォルトの名無しさん
12/01/05 19:47:08.18
ハァ？
401:デフォルトの名無しさん
12/01/05 20:08:53.67
そこはハァじゃなく、知りたいことをはっきり訊いた方がいいぞ
402:デフォルトの名無しさん
12/01/05 23:19:02.81
ソースがくさいのだけはわかった
403:デフォルトの名無しさん
12/01/05 23:46:52.62
>>399
俺モデルデータをファイルから読込みむ時に頂点順序反転する処理入れてた・・・・・
scaleで行けたのか・・・・・・・・・・・
404:デフォルトの名無しさん
12/01/06 00:17:02.70
glFrontFace(GL_CCW), glFrontFace(GL_CW)
でいいと思うけど。
405:デフォルトの名無しさん
12/01/06 01:04:12.77
モデルデータを右手系で出力すればおけ
406:デフォルトの名無しさん
12/01/06 09:50:22.84
まあ１年に３回ぐらいはどちらかに統一しろよとは思うよな
407:デフォルトの名無しさん
12/01/06 20:55:06.19
元々、右手系しかなかったのにDirectXが左手系で超速いもんだから一気に広まった。
現在では速度差はあまりないが。
最近ではOpenGLの方が活気付いているけど、DirectX9.0cまでは付け入る隙など無かった。
408:デフォルトの名無しさん
12/01/07 01:06:28.22
左手系で超速い
だってさww
409:デフォルトの名無しさん
12/01/07 03:33:19.15
いつものバカだろ。放っておけ
410:スーパーレフト ◆WIIamZako.
12/01/07 03:46:11.57
もう スーパーレフト ってコテ名乗れよ
酉やるからほら
スーパーレフト#孰扞wPSX
411:デフォルトの名無しさん
12/01/07 10:38:51.16
3D界のレフティという名を名乗っていいぞ。俺が許可する
412:デフォルトの名無しさん
12/01/07 12:58:18.97
>>408
そこは、左手系だから超速いと言いたいんじゃないと思うぞ
当時のOpenGLよりもゲーム向き（＝速い）なライブラリだったからみんなが使って、
それがたまたま左手系だったから「左手系」が一気に広まった事を言いたいのだと思う
あくまで、一気に広まった要因は速かったからで、左手系だからと言いたいわけではないだろ
すぐ後で、現在では速度差はあまりないがとも言ってるし
と、俺は読み取ったが、どうだうか
413:デフォルトの名無しさん
12/01/07 13:33:00.52
むしろ「左手系だから速い」って読み取るほうが難しいわ
414:デフォルトの名無しさん
12/01/07 15:43:16.42
左手系の方が速い、とか言ってたやつが最近出没していたからなあ。
「左手系だから超速い」と読み取るのが自然かと。
>>412
それならば、
DirectXが左手系で超速い、ではなく、左手系のDirectXが超速い
にしないと、意味が正しく伝わらない。
複数の意味に取れる文章を書いてはダメって、大学で教わらなかったのか？
415:デフォルトの名無しさん
12/01/07 15:47:36.96
>>414
曖昧な文章だとは思うよ
でも、相手がどう読み取って欲しいのか、は何故か分かってしまう場合が多い
それを分かってて逆に取って馬鹿にするのが 2ch の遊び方の一種なのも知ってる
416:デフォルトの名無しさん
12/01/07 17:44:53.99
>>414
いや、お前の読解力がおかしいだけだろ
「『DirectXは左手系で』超速い」は普通の日本語なら「『DirectXは左手系だから』超速い」という意味には読まないぞ
417:デフォルトの名無しさん
12/01/07 17:58:59.51
書き手がそういうふうに書くアホかもしれない、と考えるとこっちの読解力だけではもう面倒みきれなくなるから最初に感じたままでええのよ
418:デフォルトの名無しさん
12/01/07 19:17:28.54
右手左手DirectXが超速い
ここ一ヶ月のスレの流れ読めばスーパーレフトさんが来たと思うのも自然だろう
419:デフォルトの名無しさん
12/01/07 19:21:38.58
俺は右足系が好きかな。
420:デフォルトの名無しさん
12/01/07 20:12:26.13
百足系の方が
421:デフォルトの名無しさん
12/01/07 20:39:58.82
ここ国語弱い人間いるよな
外人か普段人と接してない人間と睨んでる
422:デフォルトの名無しさん
12/01/07 21:21:08.63
OpenGL の上位ライブラリで、
マルチウィンドウ機能をデフォルトで装備するものってある？
少なくとも GLFW はウィンドウひとつしかサポートしない
GLUT はやってみた人がいるようだが、公式サポートではないらしく注意が多い
423:デフォルトの名無しさん
12/01/07 21:45:23.85
GLUT やら OSG やら Coin3D やら幾らでもあるけど、
> GLUT はやってみた人がいるようだが、公式サポートではないらしく注意が多い
とか言ってるお前にゃ無理だな
424:デフォルトの名無しさん
12/01/07 21:53:02.78
>>423
OS の API や環境に依存しそうな部分はできるだけ触りたくない
しっかりとラッピングしておいてほしいんだ
Haskellでプログラムしてるから、
Haskell用ラッパーの作成にも時間を取られる
GUI構築よりも本来注力したい仕事にさっさと取りかかりたいんだよ
> とか言ってるお前にゃ無理だな
無理だったら別の方法を考えるから、とにかく OSG や Coin3D を調べてみるよ
ありがと
425:デフォルトの名無しさん
12/01/07 21:57:53.94
glutSetWindow つかってるけど簡単実装には便利だよ
426:デフォルトの名無しさん
12/01/07 22:20:59.69
>>425
GLUTは一度入ったメインループから抜け出せない仕様が扱いにくいんだが、
今は背に腹は替えられない状況なんで検討してみる
ありがと
427:デフォルトの名無しさん
12/01/07 22:46:59.29
時々聴くけどglutでMainLoopから抜けたい時ってどんな時なのかな
428:デフォルトの名無しさん
12/01/07 23:04:27.61
終了ボタンでいきなり終了されたら困る時
429:デフォルトの名無しさん
12/01/07 23:24:40.52
まさにそれ。
APIHookするしかないのか
430:デフォルトの名無しさん
12/01/07 23:30:58.53
windowsならatexit()でいけそう
431:デフォルトの名無しさん
12/01/08 00:31:31.41
javaれ
432:デフォルトの名無しさん
12/01/08 10:28:56.50
メモリーリーク検出のために正しい手順で終わりたい時
ってかglutリークもOpenGLもメモリリークしてるがな...
433:デフォルトの名無しさん
12/01/08 11:01:33.55
ペイントソフトとか作ってファイルを保存してないのに終了ボタン押されたら困るだろ？
そういう時にファイル保存の処理をするんだよ
434:デフォルトの名無しさん
12/01/08 11:21:31.83
終了ボタンを自分で作ってるなら、マウスが終了ボタンを押した時の処理をMouseFuncに書けばいいんじゃないの
windowのXボタンのことならatexitで処理すればいいし
435:デフォルトの名無しさん
12/01/08 12:08:01.39
>>434
終了しますか？(はい／いいえ)
って聞かれたことない？
それは置いといて実用目的でGLUT使うのは間違ってる
436:デフォルトの名無しさん
12/01/08 12:12:36.11
Haskell限定だが
GLUTがメインループを持ってるせいで、
一部の同じくメインループを持つFRPライブラリと相性が悪い
またGLUTがイベントドリブンなのも、
いくつかのFRPライブラリとの相性を悪くしてる
437:デフォルトの名無しさん
12/01/08 12:34:06.91
マルチウィンドウを管理して欲しいけどメインループは持たないでくれってのは難しいんじゃないのか
いっそ表示とそれ以外にスレッド分けたほうがスッキリしそう
438:デフォルトの名無しさん
12/01/08 18:56:40.03
atexitだとまたメインループに戻る処理が出来ないだろ馬鹿
439:デフォルトの名無しさん
12/01/08 22:08:21.43
>>438
馬鹿で悪かったな。そんな押されちゃ困るＸボタンなら消しときゃいいだろ
440:デフォルトの名無しさん
12/01/09 04:45:06.23
人のことをすぐ罵る男の人って
441:デフォルトの名無しさん
12/01/09 15:32:24.70
ポチっとな
442:デフォルトの名無しさん
12/01/09 17:37:55.40
glutを使ったこんなかっこいいPC demoがあるんだぜ
URLﾘﾝｸ(www.pouet.net)
でも商用ソフトとかでglutを使うのはちょっとどうかと思うよ。
OpenSceneGraphとかUDKとかのゲームエンジンの方がもっと機能が多いよ。
443:デフォルトの名無しさん
12/01/09 18:07:36.17
>>442
＞OpenSceneGraphとかUDKとかのゲームエンジンの方がもっと機能が多いよ
レイヤが違うんだから当たり前だろ。せめて理解してから喋れ
444:デフォルトの名無しさん
12/01/11 03:20:30.85
すみません
GLSLを使ってメッシュを表示しているのですが、
2台のＰＣで結果を確認すると、一方では正常に表示されるのに、もう一方では何も表示されません。
ダメなＰＣ（デスク）
Win7 32bit
RADEON HD5750
正常なＰＣ(ノート)
Win7 64biy
intel HD3000
デバッグするとどちらもＧＬＳＬのコンパイルは正常に完了しており、レンダリング中に何のエラーもありません。
ただ、スプライト（板ポリ）を表示する簡単なシェーダだけはＲＡＤＥＯＮでも正常に動きます。
ポリゴンを表示するシェーダだけがＲＡＤＥＯＮで動かないのは何が原因でしょう？
445:デフォルトの名無しさん
12/01/11 03:42:34.81
RADEONで動かないシェーダーに原因があるでしょう
446:デフォルトの名無しさん
12/01/11 10:43:26.92
バグがないと仮定したらテクスチャーモードを設定してないとか
確かATI系だけは設定しないと表示されなかったはず
447:デフォルトの名無しさん
12/01/11 18:17:40.41
RADEONってほんとプログラマー泣かせだよな
448:デフォルトの名無しさん
12/01/11 18:30:00.84
そんな事はない。ATIの方が仕様に正しく実装されている
作ったとおりに動くのがATI。正しく作らなかったら正しく動かないのがいい
NVIDIAはわりといい加減に作っても動くけど、それは正しい動作ではない
449:デフォルトの名無しさん
12/01/11 18:39:28.91
／）
／／／）
／,.=ﾞ''"／
／ i f ,.r='"-‐'つ＿＿＿_ こまけぇこたぁいいんだよ！！
/ / _,.-‐'~／⌒ ⌒＼
／ ,i ,二ﾆ⊃（ ●）. （●）＼
/ ﾉ ilﾞフ::::::⌒（__人__）⌒::::: ＼
,ｲ｢ﾄ､ ,!,!| |r┬-| |
/ iﾄヾヽ_/ｨ"＼ `ー'´ ／
nvidia
450:デフォルトの名無しさん
12/01/11 19:00:10.69
せっかくこの話題になったから聞いておきたいんだけど
ATIで動いたシェーダはNVIDIAでも動くってのは正解？
つまり開発環境としてはRADEONの方が無難？
451:デフォルトの名無しさん
12/01/11 20:15:32.80
どちらでも動くソフトを作るならRADEONで動作チェックするしかないな
っていうか融通がきかないんだよRADEONは
452:デフォルトの名無しさん
12/01/11 21:48:35.36
>>444
OpenGLのエラーが出てないか調べたら良いかも。GL_ARB_debug_outputとか。
又は、gDebuggerとか今はタダだから使ってなかったら試してみたらコード変更しなくてもエラーが見つけられるかも。
453:デフォルトの名無しさん
12/01/11 21:49:13.24
3D空間に文字を出力する出来るだけ簡単な方法教えてください
ここの方法を参考に弄ってやってみようとしたけど、できん
URLﾘﾝｸ(www21.atwiki.jp)
454:デフォルトの名無しさん
12/01/11 21:51:39.99
>>450
ドライバの出来次第では？
古いNVのドライバだと対応してないテクスチャフォーマットがあったりもしたよ。
455:デフォルトの名無しさん
12/01/11 21:52:19.33
お前の環境は何だとか一々きかせるな
456:デフォルトの名無しさん
12/01/11 22:03:23.31
>>453
予め必要な文字を描いておいたテクスチャの一部をビルボードに貼って表示すれば良い
これが一番簡単だ
文字の形をした立体オブジェクトを表示させたいのなら、
FreeFontでも使ってフォントのアウトライン(ベジェ曲線)を得て、
それをtrianglizeして表示すれば良い