1read 100read
2012年3月プログラム82: OpenGLスレ Part17 (925)
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▼
BREW(Binary Runtime Environment for Wireless) 11 (512)
CVS導入スレ〜 Rev.3 (835)
【Java】DIコンテナって本当に便利か? (453)
Visual Studio 2005 Part 27 (113)
Visual Studio IDE環境 (541)
Visual Studio 2005 Part 27 (113)
OpenGLスレ Part17
1 :11/11/15 クロスプラットフォームの3D API OpenGLに関する話題を扱うスレッド。 現在のバージョンは4.1 http://www.opengl.org/ == OpenGLと一緒に使われるツール&ライブラリ == 苦労したくなかったらとりあえず入れとけ。 ・glx: XからOpenGLを使うためのライブラリ。普通は直接は使わず意識する事はない ・glut: クロスプラットフォームなツールキット。でもさすがに古くさい ・glew: これを入れないと拡張機能が使えないor使いにくい ・glxgears: 歯車が回るベンチマーク。-infoでOpenGLのバージョンが見られる。OpenGLの動作確認はこれで ・glxinfo: 自分の使っているカードのOpenGLの機能が全てリストアップされる。 ・OpenTK C#からOpenGLを簡単に使えるようになる。VC#の強力なIntellisenseとあわせてサクサク開発可能。 == 必読書 == ・OpenGLプログラミングガイド 原著第5版 (通称赤本) ・OpenGL(R) Reference Manual (通称青本) ・OpenGL Shading Language (通称だいだい本) ・OpenGL(R) SuperBible: Comprehensive Tutorial and Reference ・OpenGL ES 2.0 プログラミングガイド ・GLUTによるOpenGL入門 ・GLUTによるOpenGL入門2 テクスチャマッピング あると便利。 ・ゲームプログラミングのための3Dグラフィックス数学 == チュートリアルサイト == 床井研究室: http://marina.sys.wakayama-u.ac.jp/~tokoi/oglarticles.html OpenGL de プログラミング: http://wiki.livedoor.jp/mikk_ni3_92/ NeHe: http://nehe.gamedev.net/ == 前スレ == OpenGLスレ Part16 http://hibari.2ch.net/test/read.cgi/tech/1309182662/
2 :11/11/15 == 過去スレ == Part16: http://hibari.2ch.net/test/read.cgi/tech/1309182662/ Part15: http://hibari.2ch.net/test/read.cgi/tech/1289992928/ Part14: http://hibari.2ch.net/test/read.cgi/tech/1263901596/ Part13: http://pc12.2ch.net/test/read.cgi/tech/1247349324/ Part12: http://pc12.2ch.net/test/read.cgi/tech/1221215309/ Part11: http://pc11.2ch.net/test/read.cgi/tech/1177523018/ Part10: http://pc11.2ch.net/test/read.cgi/tech/1141034983/ Part 9: http://pc8.2ch.net/test/read.cgi/tech/1132403929/ Part 8: http://pc8.2ch.net/test/read.cgi/tech/1126267690/ Part 7: http://pc8.2ch.net/test/read.cgi/tech/1118151979/ Part 6: http://pc8.2ch.net/test/read.cgi/tech/1105612993/ Part 5: http://pc5.2ch.net/test/read.cgi/tech/1100085657/ Part 4: http://pc5.2ch.net/test/read.cgi/tech/1091724463/ Part 3: http://pc5.2ch.net/test/read.cgi/tech/1067529308/ Part 2: http://pc2.2ch.net/test/read.cgi/tech/1039984523/ Part 1: http://pc3.2ch.net/tech/kako/981/981044659.html (dat落ち) == C/C++以外から使うには == Rubyから --> ruby-opengl Pythonから --> PyOpenGL Javaから --> JOGL JavaScriptから --> ??? Haskellから --> ??? C#等、.NET系 --> OpenTK
3 :11/11/15 == 追記 == OpenGL.org wiki: http://www.opengl.org/wiki/Main_Page OpenSceneGraph: OpenGL を高度に抽象化し、利便性を高めたラッパー。C++ ライブラリ http://www.openscenegraph.org/ OpenGL Mathematics (GLM): GLSL 文法ライクの C++ 数学ライブラリ http://glm.g-truc.net/ == Quick Reference Card == OpenGL 4.1 API Quick Reference Card http://www.khronos.org/files/opengl41-quick-reference-card.pdf OpenGL 3.2 API Quick Reference Card http://www.khronos.org/files/opengl-quick-reference-card.pdf OpenGL ES 2.0 API Quick Reference Card http://www.khronos.org/opengles/sdk/docs/reference_cards/OpenGL-ES-2_0-Reference-card.pdf WebGL 1.0 API Quick Reference Card http://www.khronos.org/files/webgl/webgl-reference-card-1_0.pdf
4 :11/11/15 >>1 乙なんだからね
5 :11/11/16 2つ追加した == チュートリアルサイト == 床井研究室: http://marina.sys.wakayama-u.ac.jp/~tokoi/oglarticles.html NeHe: http://nehe.gamedev.net/ OpenGL de プログラミング: http://wiki.livedoor.jp/mikk_ni3_92/ OpenGL Step By Step: http://ogldev.atspace.co.uk/ OpenGL Samples Pack: http://ogl-samples.g-truc.net/
6 :11/11/16 必読書は改定したい。 == 必読書 == -- CG入門 -- OpenGL以前の普遍的なCGの概念。 CG-ARTS協会の3冊は初心者向け。あとの2冊は上級者向け。 ・コンピュータグラフィックス (CG-ARTS協会) ・ビジュアル情報処理 (CG-ARTS協会) ・ディジタル映像表現 (CG-ARTS協会) ・ゲーム制作者になるための3Dグラフィックス技術 ・ビジュアルコンピューティング 3次元CGによる画像生成 -- 初心者用 -- ・GLUTによるOpenGL入門 ・GLUTによるOpenGL入門2 テクスチャマッピング ・OpenGL ES 2.0 プログラミングガイド -- 上級者用 -- ・OpenGL Shading Language (橙本) ・Shader Xシリーズ ・GPU Gemsシリーズ ・GPU Proシリーズ
7 :11/11/16 -- モダンなOpenGL -- シェーダーベースの最新のOpenGLの学習 ・OpenGL 4.0 Shading Language Cookbook ・OpenGL SuperBible: Comprehensive Tutorial and Reference ・OpenGL 4.0 グラフィックシステム -- 数学 -- ・ゲームプログラミングのための3Dグラフィックス数学 ・実例で学ぶゲーム3D数学 ・ゲーム開発のための数学・物理学入門 -- 過去の遺物 -- 有名だが古いバージョンのOpenGLをもとに書かれているためすでに時代遅れ 通常は買う必要はない ・OpenGLプログラミングガイド 原著第5版 (赤本) ・OpenGL Reference Manual (青本)
8 :11/11/16 赤本を遺物にして、openGLと関係ない本を必読はちょっと賛同できない
9 :11/11/16 赤本なんて2011年にもなって読む本じゃないだろ 訳本はOpenGL 2.1だぞ 古い仕様のOpenGLを学ぶのにもわかりやすい本ではないし。 昔はあれしかなかったからあれを薦めていたが 2011年にもなってあれをすすめるのは老害だけ
10 :11/11/16 俺が今OpenGLの包括的な学習書として1冊すすめるならOpenGL SuperBibleだな シェーダーベースのモダンなOpenGLでもっとも詳しく解りやすく書かれている。 日本語で読めるいい本はないね。 特にシェーダーベースの本が絶望的にない。 というわけで床井先生頼んだ!!
11 :11/11/16 >>9 一理あるとは思うけど、 最新を追うだけが全てじゃないよ
12 :11/11/16 ちょっと聞きたいんだが、いまどきの現場では OpenGLで2Dのゲームを作る場合にもシェーダー使っているんだろうか。
13 :11/11/16 >>11 が、古きを知るために赤本がいいかというと違うと思う。 いずれにせよ赤本は時代遅れ 赤本をすすめる人間は信用できない
14 :11/11/16 そもそも本なんて要らない
15 :11/11/16 >>13 4x1対応の赤本が出たら手のひら返すんでしょ?
16 :11/11/16 >>12 使った方が楽だと思うよ
17 :11/11/16 OpenGLなんて実際に使われているの?
18 :11/11/16 使われてるよ
19 :11/11/16 カーナビとか3Dじゃないけど使ってるねえ あとCADとか
20 :11/11/17 glVertexAttribPointer()があればglEnableVertexAttribArray()は不要だと思うのですが、どうして分かれているのでしょう?
21 :11/11/18 キーボードのpとoが壊れた時も使えるからかな
22 :11/11/19 へえ
23 :11/11/19 >>22 http://hibari.2ch.net/test/read.cgi/tech/1261676778/213 http://hibari.2ch.net/test/read.cgi/tech/1272358443/83 http://hibari.2ch.net/test/read.cgi/tech/1321350331/22 http://hibari.2ch.net/test/read.cgi/tech/1318935200/82 http://hibari.2ch.net/test/read.cgi/tech/1290415962/444 http://hibari.2ch.net/test/read.cgi/tech/1314133332/444 http://hibari.2ch.net/test/read.cgi/tech/1315141054/25 http://hibari.2ch.net/test/read.cgi/tech/1321282584/4 http://hibari.2ch.net/test/read.cgi/tech/1156332916/186 http://hibari.2ch.net/test/read.cgi/tech/1177431417/279 http://hibari.2ch.net/test/read.cgi/tech/1295493964/744 http://hibari.2ch.net/test/read.cgi/tech/1300000513/237 http://hibari.2ch.net/test/read.cgi/tech/1163319215/911
24 :11/11/21 C++ と OpenGL, GLUTを利用した3次元の物理現象のプログラムを作成しよう としているのですが、なかなか上手く出来ません。 http://www.natural-science.or.jp/article/20100818093625.php 作ろうとがんばっているのはまさに↑のようなものです。 出来ればソースコードを全て書き込んでいただければありがたいです。 Microsoft Visual Studio 2008より作成しています。 よろしくおねがいします。
25 :11/11/21 釣り針大き過ぎて無理
26 :11/11/21 >>24 http://www.sgra.co.jp/estimateform.html
27 :11/11/21 >>26 御食事処もあるのか。いい会社だな
28 :11/11/21 天才よ、ぱぱっと書いてやれ
29 :11/11/21 >>24 以前から何度も書き込んでる奴か? ネタとしても面白くないからいい加減失せてね。
30 :11/11/21 これって物理エンジン使ったら簡単じゃね?
31 :11/11/22 よく見たら2Dだった
32 :11/11/22 GLSL触って間もないんですが glBlendFuncと同じようなこと(フラグメントシェーダで描画先のピクセルの色を取って合成みたいな) をGLSLで行いたいんですけどこれってできますか? 「描画先のピクセルの色を取って」の部分がどうすればできるのか分からないんですが
33 :11/11/22 描画先のピクセルを参照することは出来ない。
34 :11/11/22 んなわきゃない。 描画先のメモリを参照すればいいだけだ。
35 :11/11/22 残念ながらできない
36 :11/11/22 君、できないの?
37 :11/11/22 盛り上がってまいりました!
38 :11/11/22 できないことの証明は難しいが、できることの証明は簡単なはずだ まあGLSLで出来るかはわからないが描写先をフレームバッファオブジェクトにしておけば、 そしてテクスチャーバッファーにしておけば、普通にアクセスできるはず これレンダーバッファーではできないよね?レンダーバッファーは普通のGL関数でアクセスする専用ってことかね
39 :11/11/22 >>38 ttp://www.opengl.org/wiki/Framebuffer_Object Feedback Loopsって所を見るとダメかな。Mostly
40 :11/11/22 普通の?画像処理と同じ要領なのね やりたいことがわからないけど、まあそれがわかれば解決策も容易にわかるはず
41 :11/11/23 >>32 例外的だけど、tegraとか、一部のタイル系モバイルGPUではできるみたいよ。 参考 : NV_shader_framebuffer_fetch
42 :11/11/23 GLEWライセンス見たけど要は修正BSDライセンス?
43 :11/11/23 結局フラグメントシェーダからレンダーバッファを参照するのは不可能、でFA?
44 :11/11/23 >>43 現在のほとんどのハードウェアでは出来ない。 >>41 のような例外は、レンダーバッファ(の一部)がシェーダから近い位置にレイアウトされているから。
45 :11/11/23 OpenGLでOIT実装したいとおもってるんですが、DirectXでいうところのAppendBufferってOpenGLだとなにになりすか? あと、OpenGLのDirectX11相当の機能についてよいリンクなどあったら教えてください。
46 :11/11/23 32=45? A-Bufferとかで検索すればヒントが得られるんじゃないかな
47 :11/11/23 >>46 ありがとうございます、32ではありません。 EXT_shader_image_load_storeという拡張が欲しい仕様にみえます、OpenGL拡張の仕様書ページみながら頑張ってみます。 しかしNvidia拡張の魔改造ぶりはすごいですね、NV_shader_buffer_store...
48 :11/11/23 もうデファクトスタンダードでいいよ
49 :11/11/23 魔改造と言うか、元々HWベンダですし と言うか、大昔はハードウェアごとに全部ソフトウェアとか違ってた訳ですし
50 :11/11/23 それは規格がなかった時代の話で今はOpenGLという規格があるのに自分勝手にはみ出してるって話だろ
51 :11/11/23 まぁクロノスがグラボ作ってる訳でもないしな。
52 :11/11/23 あ、魔改造は褒め言葉です。;-/ 次のプロファイルではARBのシェーダでもポインタとか使えるようになっているといいな。
53 :11/11/24 なぜOpenGLは行列を逆ハンドサイドから掛けないといけない仕様にしたんでしょうか? わざわざ逆順に掛けて行く必要があるしC++のoperatorとも相性悪いしどうしても解せません
54 :11/11/25 あっちが逆なんだよ
55 :11/11/25 行列を掛ける方向と右手系左手系は関係ないし OpenGLはC++のoperatorの定義なんてしてないし 気に入らないなら適当なラッパー書けばいいだけ
56 :11/11/25 >>55 右手系左手系は関係ないけど転置してるから右から掛けないといけないですよね C++のoperator、例えば*は左結合なので右から掛けるという規則がすごく気持ち悪いです 確かに数学で出てくるアフィン変換行列と同じ形式ですがプログラミング言語から使うんだから わざわざ扱いにくい形式を採用しなくても良かったのでは?と疑問に思っています なんでこんなことに?
57 :11/11/25 なら転地しないで左から掛ければいいじゃない。 CPUでなにを計算するかなんてOpenGLの知ったこっちゃないよ
58 :11/11/25 >>53 ,56 この辺読むと良いと思うよ。 http://steve.hollasch.net/cgindex/math/matrix/column-vec.html 右から掛ける、左から掛けるってのは、計算を数式で記述する仕方の問題だけ。 OpenGLの計算も、ベクトルを行ベクトルと見て行列を左から掛けるのだと解釈する事もできるんだから そうしたいならそうすればいいんだよ。
59 :11/11/25 あ、ごめん、言葉足らずで変な言い方になった・・・。 「行列を左から掛けるのだと」のくだりは、ベクトルに対して行列を左から掛けるって意味じゃなく、 v'=vMに対してさらにローカルな変換を追加するときに新しい行列Nを v'=vNM とMの左に掛けるって意味でした。
60 :11/11/26 ということはその場合はglRotate*等は混在できなくて 全てglLoadMatrixd*/glMultMatrix*で自前でするということ?
61 :11/11/26 なんで突然glRotateが使えなくなんの。 とりあえず自分でコード書いて確かめてみなよ
62 :11/11/26 >>60 なんかそもそも行列の演算とその使い方が分かってない感じ・・・かな。 もっと具体的に、どういう事をしたい時にどう困ってるのかが分かれば、 解決策も出ると思うんだけど。 とりあえずOpenGL(DirectX)の行列に関する仕様はおおかたの使い方において 妥当なようになっているし、大半の人は(多分)困ってないよ。
63 :11/11/26 それはともかく そろそろ OpenGL の行列関数は使わない方がいいような気はする
64 :11/11/26 使わないっていうか今の4.x系列は使えないだろ GLSL側でcolumn-majorで定義したのが許せない せっかく0から定義したのになぜバカな仕様を引きずるのか...
65 :11/11/26 >>62 glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので 自前で右へ右へ掛けていくために行ベクトル用の行列を作って掛けていったものに対して使うと当然結果おかしくなっちゃいますよね? うわあめんどい・・・
66 :11/11/26 >>61 自分のソースのglRotateしてる部分を回転行列の転置行列をgMultiMatrixするように置き換えれば使えない理由が分かります確かめてください
67 :11/11/26 >>66 俺は何も困ってないし、何一つ疑問は無いので確かめないよ?w
68 :11/11/26 >>66 右手左手座標系の違いはあるけど、 glTranslatef( x, y, 0 ); って書く替わりに D3DXMATRIX mat; D3DXMatrixTranslation( &mat, x, y, 0 ); glMultMatrixf(&mat.m[0][0]); って書いても動くよね。 逆だ転置だって言うけど、どっちもマトリックスのメモリ配置は同じでxが入るのは*(m+12) 自分で書くなら、自分が使いやすいように実装したらいいんじゃね
69 :11/11/26 >>65 >glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので 違います。 >自前で右へ右へ掛けていくために行ベクトル用の行列を作って掛けていったものに対して使うと当然結果おかしくなっちゃいますよね? おかしいのはあなたの考え方です。 58のURLは読みましたか? その内容は理解できますか?できませんか?どっち??
70 :11/11/26 >>69 >>58 はoperatorの解釈を変えるだの変換をかませだの書いてありますが 言ってることはそれでOKですか? 列中心か行中心かはデータの話でマトリクスの掛け算の定義は変わらないのは当たり前の話で その上で自前の行中心の行列をかけてる途中で列中心の行列を掛けてしまうglRotate*をそのまま呼び出すことは出来ないよね?めんど。って話をしてるんですけどちゃんと聞いてますか?
71 :11/11/26 >>70 自前の行列をそのままglRotatefを呼べるようなデータの配列順にしとけばめんどくないよって話
72 :11/11/26 うん、マジでゴメン。 理解できてない人に理解できてるかどうか聞いても意味無かった。 しかしこれどう言えば分かってもらえるのか分からん・・・。 >>>58 はoperatorの解釈を変えるだの変換をかませだの書いてありますが >言ってることはそれでOKですか? 違います。 というかそんなことはどうでもいいです。 えっと確認なんですが、英語は読めますか? >列中心か行中心かはデータの話でマトリクスの掛け算の定義は変わらないのは当たり前の話で 「データの話で」の意味が不明。 >その上で自前の行中心の行列をかけてる途中で列中心の行列を掛けてしまうglRotate*をそのまま呼び出すことは出来ないよね?めんど。って話をしてるんですけどちゃんと聞いてますか? それが誤解なのだと、58に貼ったURLに書いてあるんですが…。
73 :11/11/26 >>72 何一つ情報増えてないよね 自分で説明できないなら書かなきゃいいのに。
74 :11/11/26 65 の人の誤解を言葉で正すことは不可能だと思うな。
75 :11/11/26 自分が理解できないからって情報が無いと考えるのはダメだよ。 58に十分な情報があるのに。 ええとまず、そうだな、最低限のところだけ言うとすると、 glRotate(やその他)は、列優先の行列を掛けるのではないし、列ベクトルに掛けるための行列を作るのでもない。 まずここが分からないと話にならないんだけど・・・ なぜあなたは、OpenGLの行列命令が扱う行列は列優先で、列ベクトルに掛けるものだと思っているのですか?
76 :11/11/27 数学の話とAPIの話とC言語の話と好みの話がごっちゃになってるんだな
77 :11/11/27 薄々感じるのは、>>53 ,56が問題にしたいのは実は行だの列だのって話じゃなくて、 v'=Mvという変換の状態に対してglRotate系を発行すると、生成された行列Rが v'=MRv と掛かるコト (>>53 ,56は v'=RMv となって欲しいと思っている)なんじゃないかと・・・。
78 :11/11/27 「自前の行列」ってことはどっかでglLoadMatrixしてんでしょ じゃあglRotateのあとにglMultiMatrixすりゃいいんじゃねえの?
79 :11/11/27 面倒なので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 >>78 glLoadMatrixする直前に変換行列を転置させるから glFlush直前ならOKなんですけど、変換途中に使うとなると 行列のLoadとGet時で転置を計2回やる必要があってやっぱり不便だなーと
81 :11/11/27 x glFlush直前 o 描画関数呼び出し前
82 :11/11/27 >>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 >>79 そもそもの話だけど行列そのものには行優先も列優先も無くて 2次元の行列を1次元の配列に格納するのが行優先なのか列優先なのかって話なので、 「行中心行列」「列中心行列」みたいな単語を使ってる点を見るに、根本的な勘違いがあるんじゃないかなぁと。 (ちょっと余計な話すると、独自の用語を使う人は、まず大抵その分野について 初歩的な理解ができてないです。きちんと意味を調べて、正しい用語を使いましょう。) DirectX(のドキュメント)はベクトルを行ベクトルで書いて、ベクトルの変換は行列を右に掛ける形で表すから X軸回転の行列は>>79 の上の行列の形になるけど、DirectXのドキュメントを列ベクトルで書いて ベクトルの変換は行列をベクトルの左に掛ける形で書き直すと、DirectXのX軸回転の行列も >>79 の下の行列の形になりますよ。>>82 も言ってるけど、両者は同じものなんですよ。
84 :11/11/27 >>82-83 何の話題で盛り上がってるのかようやく理解できたw
85 :11/11/27 うーん、もうちょっと補足した方がいいだろうか。 >>82 や>>83 で「同じ」と言ってるのは、何が「同じ」なのかというと、行列演算の「仕様」。 で、「仕様」と、その「数学的記述」は区別しないといけない。 OpenGL(の主なドキュメント)では仕様を、列ベクトルと左から掛ける行列で記述してるし、 DirectX(の主なドキュメント)では仕様を、行ベクトルと右から掛ける行列で記述してる。 同じ仕様を違う方法で記述してるだけだから、記述自体は相互に変換可能。 OpenGLもDirectXも仕様が同じなんだから、行列演算部分に関しては、同じプログラムがそのまま使える。 ってコトなんですよ。
86 :11/11/27 >>83 行ベクトルに対するアフィン変換行列を行中心行列 列ベクトルに対するアフィン変換行列を列中心行列 というんだと思っていました。 一般的にはどう呼ばれているんでしょう 58のrow major、 column major? 左から掛ければ一緒というのはわかります ただ右から掛けたい(*1)というのが独自で行列計算する動機なので左から掛ければ一緒はNGなんです *1 左から掛ける場合Matrixクラスに対してoperator*=を定義できないため
87 :11/11/27 >>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 もしくはむりやり Matrix t = x1; t *= m; Matrix t2 = x2; t2 *= t; m = t2;
89 :11/11/27 >>87 >>79 の上のつもりで作った配列は右から掛けてok できた配列は左版の転置になってると思うだろうけど、 それはそのまま直接OpenGLでもDirectXでも使えるメモリ配置になっている 実際にやってみたらわかると思うよ >>87-88 の言わんとしてることはわかるけど、最近のコンパイラの最適化的にどうなんだろね グラフィック系のオーバーヘッドはそこには全く現れないと思うけど。でも気持ちはわかる
90 :11/11/27 >>89 ああ、確かに反対の反対で同じになりますね。 安心して寝れます。
91 :11/11/27 > ・column majorの場合 > Matrix m; // ワールド座標系への変換行列 > Matrix x1, x2; // 回転行列等 > // M*=x1 は 意味的にM=M*x1なので使えない これが嘘だな。operator*=を定義すれば使える
92 :11/11/27 DirectXもOpenGLも結局は同じ 同じ3Dを扱う物だからな ただ、DirectXはC++の配列の並びがそのまま使えるように左手座標系になってる OpenGLの場合はあらゆるプラットフォーム、言語で使うために右手座標系になっている ただ単にそれだけの事だ
93 :11/11/27 右手座標だとそういう壁が超えられて左手だと超えられないの?
94 :11/11/27 >>91 あなたのコードをメンテする人がかわいそうなのでプログラミングしないでください
95 :11/11/27 >>92 右手系左手系と配列の並びは関係ないよ。
96 :11/11/27 >>95 あるよ
97 :11/11/27 ないよ
98 :11/11/27 単にSGI-GLが右手座標系だったので、DirectXは左手にしてみましたみたいことじゃないの
99 :11/11/27 >>98 ちゃう OGL=数理重視 D3D=感覚・実用重視にしたら左手座標系になった
100read 1read 1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
★★ Java の宿題ここで答えます Part 71 ★★ (917)
言語ってObjective-Cだけでよくね (630)
BASICの宿題はお前にまかせた (550)
pythonがこの先生きのこるには (790)
Eclipse統合M32【Java/C++/Ruby/Python/Perl】 (719)
ポインタを難しいと言う奴が理解できない (797)
--log9.info------------------
◇◆西鉄バス北九州 9◆◇ (922)
【E甲】ヤサカ観光バス1号車【】 (455)
都営バス車両スレ20 (322)
★京浜急行バス乗務員スレッドPart5★ (489)
【バイパス本山】西肥自動車Part7【シルバーボウル前】 (221)
呉市営バス (698)
【西鉄IC】nimocaカード【ニモカ】 (525)
海外(製)のバス (966)
連節バススレッド 2 (490)
【外車大好き】日の丸自動車興業【スカイバス】 (747)
【送迎バス】京都急行バスを語るスレ【路線バス】 (484)
広島バススレッド2 (622)
箱根登山バス・伊豆箱根バス6 (362)
【案外】筑後地区のバスを語る【広範囲】Part6 (498)
福島交通を語ろう Part3 (&福島県バス総合スレ) (842)
昭和バス (181)
--log55.com------------------
【経済】日本株に迫る「屈辱の日」 夢なき市場に未来なし
【企業】パイオニア、新社長矢原氏が会見--「モノからコト」ではなくて「モノ&コト」
【半導体】3ナノ半導体どちらが先に出すか? サムスンとTSMCの3ナノ量産戦争
【航空】737 MAX、今年半ば運航再開目指す ボーイングが声明
【IT】MS、「Office 365 ProPlus」でデフォルト検索を「Bing」に--ユーザー怒る
【実業家】ココイチ創業者 服全身3万円
【経済】日銀総裁、「マイナス成長の可能性」
【MRJ】三菱旅客機納入、来年以降に 延期6度目、試験遅れ