現在のバージョンは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/
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
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
乙なんだからね
== チュートリアルサイト ==
床井研究室: 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/
== 必読書 ==
-- CG入門 --
OpenGL以前の普遍的なCGの概念。
CG-ARTS協会の３冊は初心者向け。あとの２冊は上級者向け。
・コンピュータグラフィックス (CG-ARTS協会)
・ビジュアル情報処理 (CG-ARTS協会)
・ディジタル映像表現 (CG-ARTS協会)
・ゲーム制作者になるための３Dグラフィックス技術
・ビジュアルコンピューティング ３次元CGによる画像生成
-- 初心者用 --
・GLUTによるOpenGL入門
・GLUTによるOpenGL入門2 テクスチャマッピング
・OpenGL ES 2.0 プログラミングガイド
-- 上級者用 --
・OpenGL Shading Language （橙本）
・Shader Xシリーズ
・GPU Gemsシリーズ
・GPU Proシリーズ
-- モダンな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 （青本）
訳本はOpenGL 2.1だぞ
古い仕様のOpenGLを学ぶのにもわかりやすい本ではないし。
昔はあれしかなかったからあれを薦めていたが
２０１１年にもなってあれをすすめるのは老害だけ
シェーダーベースのモダンなOpenGLでもっとも詳しく解りやすく書かれている。
日本語で読めるいい本はないね。
特にシェーダーベースの本が絶望的にない。
というわけで床井先生頼んだ！！
一理あるとは思うけど、
最新を追うだけが全てじゃないよ
OpenGLで2Dのゲームを作る場合にもシェーダー使っているんだろうか。
が、古きを知るために赤本がいいかというと違うと思う。
いずれにせよ赤本は時代遅れ
赤本をすすめる人間は信用できない
4x1対応の赤本が出たら手のひら返すんでしょ？
使った方が楽だと思うよ
あとCADとか
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
としているのですが、なかなか上手く出来ません。
http://www.natural-science.or.jp/article/20100818093625.php
作ろうとがんばっているのはまさに↑のようなものです。
出来ればソースコードを全て書き込んでいただければありがたいです。
Microsoft Visual Studio 2008より作成しています。
よろしくおねがいします。
http://www.sgra.co.jp/estimateform.html
御食事処もあるのか。いい会社だな
以前から何度も書き込んでる奴か？
ネタとしても面白くないからいい加減失せてね。
glBlendFuncと同じようなこと（フラグメントシェーダで描画先のピクセルの色を取って合成みたいな）
をGLSLで行いたいんですけどこれってできますか？
「描画先のピクセルの色を取って」の部分がどうすればできるのか分からないんですが
描画先のメモリを参照すればいいだけだ。
まあGLSLで出来るかはわからないが描写先をフレームバッファオブジェクトにしておけば、
そしてテクスチャーバッファーにしておけば、普通にアクセスできるはず
これレンダーバッファーではできないよね？レンダーバッファーは普通のGL関数でアクセスする専用ってことかね
ttp://www.opengl.org/wiki/Framebuffer_Object
Feedback Loopsって所を見るとダメかな。Mostly
やりたいことがわからないけど、まあそれがわかれば解決策も容易にわかるはず
例外的だけど、tegraとか、一部のタイル系モバイルGPUではできるみたいよ。
参考 : NV_shader_framebuffer_fetch
現在のほとんどのハードウェアでは出来ない。
>>41のような例外は、レンダーバッファ(の一部)がシェーダから近い位置にレイアウトされているから。
あと、OpenGLのDirectX11相当の機能についてよいリンクなどあったら教えてください。
ありがとうございます、32ではありません。
EXT_shader_image_load_storeという拡張が欲しい仕様にみえます、OpenGL拡張の仕様書ページみながら頑張ってみます。
しかしNvidia拡張の魔改造ぶりはすごいですね、NV_shader_buffer_store...
と言うか、大昔はハードウェアごとに全部ソフトウェアとか違ってた訳ですし
次のプロファイルではARBのシェーダでもポインタとか使えるようになっているといいな。
わざわざ逆順に掛けて行く必要があるしC++のoperatorとも相性悪いしどうしても解せません
OpenGLはC++のoperatorの定義なんてしてないし
気に入らないなら適当なラッパー書けばいいだけ
右手系左手系は関係ないけど転置してるから右から掛けないといけないですよね
C++のoperator、例えば*は左結合なので右から掛けるという規則がすごく気持ち悪いです
確かに数学で出てくるアフィン変換行列と同じ形式ですがプログラミング言語から使うんだから
わざわざ扱いにくい形式を採用しなくても良かったのでは？と疑問に思っています
なんでこんなことに？
CPUでなにを計算するかなんてOpenGLの知ったこっちゃないよ
この辺読むと良いと思うよ。
http://steve.hollasch.net/cgindex/math/matrix/column-vec.html
右から掛ける、左から掛けるってのは、計算を数式で記述する仕方の問題だけ。
OpenGLの計算も、ベクトルを行ベクトルと見て行列を左から掛けるのだと解釈する事もできるんだから
そうしたいならそうすればいいんだよ。
「行列を左から掛けるのだと」のくだりは、ベクトルに対して行列を左から掛けるって意味じゃなく、
v'=vMに対してさらにローカルな変換を追加するときに新しい行列Nを v'=vNM とMの左に掛けるって意味でした。
全てglLoadMatrixd*/glMultMatrix*で自前でするということ？
とりあえず自分でコード書いて確かめてみなよ
なんかそもそも行列の演算とその使い方が分かってない感じ・・・かな。
もっと具体的に、どういう事をしたい時にどう困ってるのかが分かれば、
解決策も出ると思うんだけど。
とりあえずOpenGL(DirectX)の行列に関する仕様はおおかたの使い方において
妥当なようになっているし、大半の人は（多分）困ってないよ。
そろそろ OpenGL の行列関数は使わない方がいいような気はする
GLSL側でcolumn-majorで定義したのが許せない
せっかく０から定義したのになぜバカな仕様を引きずるのか...
glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので
自前で右へ右へ掛けていくために行ベクトル用の行列を作って掛けていったものに対して使うと当然結果おかしくなっちゃいますよね？
うわあめんどい・・・
自分のソースのglRotateしてる部分を回転行列の転置行列をgMultiMatrixするように置き換えれば使えない理由が分かります確かめてください
俺は何も困ってないし、何一つ疑問は無いので確かめないよ？ｗ
右手左手座標系の違いはあるけど、
glTranslatef( x, y, 0 );
って書く替わりに
D3DXMATRIX mat;
D3DXMatrixTranslation( &mat, x, y, 0 );
glMultMatrixf(&mat.m[0][0]);
って書いても動くよね。
逆だ転置だって言うけど、どっちもマトリックスのメモリ配置は同じでxが入るのは*(m+12)
自分で書くなら、自分が使いやすいように実装したらいいんじゃね
＞glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので
違います。
＞自前で右へ右へ掛けていくために行ベクトル用の行列を作って掛けていったものに対して使うと当然結果おかしくなっちゃいますよね？
おかしいのはあなたの考え方です。
58のURLは読みましたか？
その内容は理解できますか？できませんか？どっち？？
>>58はoperatorの解釈を変えるだの変換をかませだの書いてありますが
言ってることはそれでOKですか？
列中心か行中心かはデータの話でマトリクスの掛け算の定義は変わらないのは当たり前の話で
その上で自前の行中心の行列をかけてる途中で列中心の行列を掛けてしまうglRotate*をそのまま呼び出すことは出来ないよね？めんど。って話をしてるんですけどちゃんと聞いてますか？
自前の行列をそのままglRotatefを呼べるようなデータの配列順にしとけばめんどくないよって話
理解できてない人に理解できてるかどうか聞いても意味無かった。
しかしこれどう言えば分かってもらえるのか分からん・・・。
＞>>58はoperatorの解釈を変えるだの変換をかませだの書いてありますが
＞言ってることはそれでOKですか？
違います。
というかそんなことはどうでもいいです。
えっと確認なんですが、英語は読めますか？
＞列中心か行中心かはデータの話でマトリクスの掛け算の定義は変わらないのは当たり前の話で
「データの話で」の意味が不明。
＞その上で自前の行中心の行列をかけてる途中で列中心の行列を掛けてしまうglRotate*をそのまま呼び出すことは出来ないよね？めんど。って話をしてるんですけどちゃんと聞いてますか？
それが誤解なのだと、58に貼ったURLに書いてあるんですが…。
何一つ情報増えてないよね
自分で説明できないなら書かなきゃいいのに。
58に十分な情報があるのに。
ええとまず、そうだな、最低限のところだけ言うとすると、
glRotate(やその他)は、列優先の行列を掛けるのではないし、列ベクトルに掛けるための行列を作るのでもない。
まずここが分からないと話にならないんだけど・・・
なぜあなたは、OpenGLの行列命令が扱う行列は列優先で、列ベクトルに掛けるものだと思っているのですか？
v'=Mvという変換の状態に対してglRotate系を発行すると、生成された行列Rが v'=MRv と掛かるコト
（>>53,56は v'=RMv となって欲しいと思っている）なんじゃないかと・・・。
じゃあglRotateのあとにglMultiMatrixすりゃいいんじゃねえの？
自作予定のMatrixクラスではx軸回転する場合DirectX(行中心行列)のように
|1 0 0|
|0 cos sin|
|0 -sin cos|
を掛けるのに対して、OpenGL(列中心行列)のglRotateは
|1 0 0|
|0 cos -sin|
|0 sin cos|
を掛けやがるから共存できねー って話です。
glLoadMatrixする直前に変換行列を転置させるから
glFlush直前ならOKなんですけど、変換途中に使うとなると
行列のLoadとGet時で転置を計2回やる必要があってやっぱり不便だなーと
o 描画関数呼び出し前
だからその配列を同じにすれば共存できるでしょって話でしょ
上は
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は同じなんだよ。
そもそもの話だけど行列そのものには行優先も列優先も無くて
2次元の行列を1次元の配列に格納するのが行優先なのか列優先なのかって話なので、
「行中心行列」「列中心行列」みたいな単語を使ってる点を見るに、根本的な勘違いがあるんじゃないかなぁと。
（ちょっと余計な話すると、独自の用語を使う人は、まず大抵その分野について
初歩的な理解ができてないです。きちんと意味を調べて、正しい用語を使いましょう。）
DirectX（のドキュメント）はベクトルを行ベクトルで書いて、ベクトルの変換は行列を右に掛ける形で表すから
X軸回転の行列は>>79の上の行列の形になるけど、DirectXのドキュメントを列ベクトルで書いて
ベクトルの変換は行列をベクトルの左に掛ける形で書き直すと、DirectXのX軸回転の行列も
>>79の下の行列の形になりますよ。>>82も言ってるけど、両者は同じものなんですよ。
何の話題で盛り上がってるのかようやく理解できたｗ
>>82や>>83で「同じ」と言ってるのは、何が「同じ」なのかというと、行列演算の「仕様」。
で、「仕様」と、その「数学的記述」は区別しないといけない。
OpenGL（の主なドキュメント）では仕様を、列ベクトルと左から掛ける行列で記述してるし、
DirectX（の主なドキュメント）では仕様を、行ベクトルと右から掛ける行列で記述してる。
同じ仕様を違う方法で記述してるだけだから、記述自体は相互に変換可能。
OpenGLもDirectXも仕様が同じなんだから、行列演算部分に関しては、同じプログラムがそのまま使える。
ってコトなんですよ。
行ベクトルに対するアフィン変換行列を行中心行列
列ベクトルに対するアフィン変換行列を列中心行列
というんだと思っていました。
一般的にはどう呼ばれているんでしょう
58のrow major、 column major？
左から掛ければ一緒というのはわかります
ただ右から掛けたい(*1)というのが独自で行列計算する動機なので左から掛ければ一緒はNGなんです
*1
左から掛ける場合Matrixクラスに対してoperator*=を定義できないため
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=が余計に発生
Matrix t = x1;
t *= m;
Matrix t2 = x2;
t2 *= t;
m = t2;
>>79の上のつもりで作った配列は右から掛けてok
できた配列は左版の転置になってると思うだろうけど、
それはそのまま直接OpenGLでもDirectXでも使えるメモリ配置になっている
実際にやってみたらわかると思うよ
>>87-88の言わんとしてることはわかるけど、最近のコンパイラの最適化的にどうなんだろね
グラフィック系のオーバーヘッドはそこには全く現れないと思うけど。でも気持ちはわかる
ああ、確かに反対の反対で同じになりますね。
安心して寝れます。
> Matrix m; // ワールド座標系への変換行列
> Matrix x1, x2; // 回転行列等
> // M*=x1 は 意味的にM=M*x1なので使えない
これが嘘だな。operator*=を定義すれば使える
同じ3Dを扱う物だからな
ただ、DirectXはC++の配列の並びがそのまま使えるように左手座標系になってる
OpenGLの場合はあらゆるプラットフォーム、言語で使うために右手座標系になっている
ただ単にそれだけの事だ
あなたのコードをメンテする人がかわいそうなのでプログラミングしないでください
右手系左手系と配列の並びは関係ないよ。
あるよ
ちゃう
OGL＝数理重視
D3D＝感覚・実用重視にしたら左手座標系になった
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
【Google】Androidアプリ作成part13 (294)
OpenGLスレ Part17 (925)
【】configure大嫌い【RMS】 (482)
Emacs Lisp 3 (773)
Perlについての質問箱 51箱目 (412)
オブジェクト指向の弊害 (131)
--log9.info------------------
【メガネ】めがねの通信販売8【眼鏡】【通販】 (809)
【復活】ソフトコンタクトレンズ ケア用品総合 (456)
通販メガネとドリームコンタクトのスレ (129)
◎●カラーコンタクト Part 10●◎ (288)
眼科医のイメージが超最悪なんだが (360)
レーシック 視力回復 LASIK 総合スレッド (211)
【中古】誠ってどうよ【めがね】 (287)
【既に発狂中】レーシック難民予備軍13【自詐欺】 (184)
【金】 ドクターアイズ 【買取】 (328)
●眼鏡店オグラ● (772)
タナーカメーガネッってどうですか (417)
眼科でむちゃくちゃな眼鏡処方をされたことある？ (619)
ピックアップ版【眼科まだまだ儲かる！みんな来い】 (221)
John Lennonの眼鏡 (465)
無印メガネ2 (588)
◆◆◆ 初診料不正 ◆◆◆ (522)
--log55.com------------------
【松戸の雄】専大松戸part5【専松】
岐阜県の高校野球 part48
鳥取の高校野球Part47
【野球王国】千葉県の高校野球【臥薪嘗胆】 part716
【地方大会もいよいよ佳境】甲子園へ行こうpart97【56校の代表決定へ】
常総学院Part76
【阪神】甲子園の売り子総合スレッド13【高校野球】
岡山の高校野球 168
