981コメント284KB

OpenGLスレ Part17

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2011/11/15(火) 18:45:31.83

クロスプラットフォームの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/

0002デフォルトの名無しさん

2011/11/15(火) 18:45:55.78

0003デフォルトの名無しさん

2011/11/15(火) 18:46:32.70

== 追記 ==
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

0004デフォルトの名無しさん

2011/11/15(火) 23:24:15.07

>>1
乙なんだからね

0005デフォルトの名無しさん

2011/11/16(水) 10:44:28.29

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/

0006デフォルトの名無しさん

2011/11/16(水) 11:09:44.59

必読書は改定したい。

== 必読書 ==

-- 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シリーズ

0007デフォルトの名無しさん

2011/11/16(水) 11:10:00.04

-- モダンな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 （青本）

0008デフォルトの名無しさん

2011/11/16(水) 13:00:08.50

赤本を遺物にして、openGLと関係ない本を必読はちょっと賛同できない

0009デフォルトの名無しさん

2011/11/16(水) 14:38:26.34

赤本なんて２０１１年にもなって読む本じゃないだろ
訳本はOpenGL 2.1だぞ
古い仕様のOpenGLを学ぶのにもわかりやすい本ではないし。
昔はあれしかなかったからあれを薦めていたが
２０１１年にもなってあれをすすめるのは老害だけ

0010デフォルトの名無しさん

2011/11/16(水) 14:41:57.24

俺が今OpenGLの包括的な学習書として１冊すすめるならOpenGL SuperBibleだな
シェーダーベースのモダンなOpenGLでもっとも詳しく解りやすく書かれている。
日本語で読めるいい本はないね。
特にシェーダーベースの本が絶望的にない。

というわけで床井先生頼んだ！！

0011デフォルトの名無しさん

2011/11/16(水) 15:37:26.32

>>9
一理あるとは思うけど、
最新を追うだけが全てじゃないよ

0012デフォルトの名無しさん

2011/11/16(水) 15:46:06.86

ちょっと聞きたいんだが、いまどきの現場では
OpenGLで2Dのゲームを作る場合にもシェーダー使っているんだろうか。

0013デフォルトの名無しさん

2011/11/16(水) 15:51:47.32

>>11
が、古きを知るために赤本がいいかというと違うと思う。
いずれにせよ赤本は時代遅れ
赤本をすすめる人間は信用できない

0014デフォルトの名無しさん

2011/11/16(水) 15:55:49.32

そもそも本なんて要らない

0015デフォルトの名無しさん

2011/11/16(水) 17:34:52.91

>>13
4x1対応の赤本が出たら手のひら返すんでしょ？

0016デフォルトの名無しさん

2011/11/16(水) 22:20:33.18

>>12
使った方が楽だと思うよ

0017デフォルトの名無しさん

2011/11/16(水) 22:39:45.63

OpenGLなんて実際に使われているの？

0018デフォルトの名無しさん

2011/11/16(水) 23:30:32.81

使われてるよ

0019デフォルトの名無しさん

2011/11/16(水) 23:31:33.30

カーナビとか3Dじゃないけど使ってるねえ
あとCADとか

0020デフォルトの名無しさん

2011/11/17(木) 23:07:51.76

glVertexAttribPointer()があればglEnableVertexAttribArray()は不要だと思うのですが、どうして分かれているのでしょう？

0021デフォルトの名無しさん

2011/11/18(金) 00:03:18.19

キーボードのpとoが壊れた時も使えるからかな

0022デフォルトの名無しさん

2011/11/19(土) 16:30:05.75

へえ

0023デフォルトの名無しさん

2011/11/19(土) 18:38:02.15

0024デフォルトの名無しさん

2011/11/21(月) 04:44:52.22

C++ と OpenGL, GLUTを利用した３次元の物理現象のプログラムを作成しよう
としているのですが、なかなか上手く出来ません。
http://www.natural-science.or.jp/article/20100818093625.php
作ろうとがんばっているのはまさに↑のようなものです。
出来ればソースコードを全て書き込んでいただければありがたいです。
Microsoft Visual Studio 2008より作成しています。
よろしくおねがいします。

0025デフォルトの名無しさん

2011/11/21(月) 09:12:31.22

釣り針大き過ぎて無理

0026デフォルトの名無しさん

2011/11/21(月) 10:18:31.14

>>24
http://www.sgra.co.jp/estimateform.html

0027デフォルトの名無しさん

2011/11/21(月) 10:35:16.34

>>26
御食事処もあるのか。いい会社だな

0028デフォルトの名無しさん

2011/11/21(月) 10:55:26.12

天才よ、ぱぱっと書いてやれ

0029デフォルトの名無しさん

2011/11/21(月) 14:26:08.84

>>24
以前から何度も書き込んでる奴か？
ネタとしても面白くないからいい加減失せてね。

0030デフォルトの名無しさん

2011/11/21(月) 20:24:08.66

これって物理エンジン使ったら簡単じゃね？

0031デフォルトの名無しさん

2011/11/22(火) 00:44:48.87

よく見たら2Dだった

0032デフォルトの名無しさん

2011/11/22(火) 16:41:35.45

GLSL触って間もないんですが
glBlendFuncと同じようなこと（フラグメントシェーダで描画先のピクセルの色を取って合成みたいな）
をGLSLで行いたいんですけどこれってできますか？
「描画先のピクセルの色を取って」の部分がどうすればできるのか分からないんですが

0033デフォルトの名無しさん

2011/11/22(火) 17:18:16.22

描画先のピクセルを参照することは出来ない。

0034デフォルトの名無しさん

2011/11/22(火) 17:54:06.50

んなわきゃない。
描画先のメモリを参照すればいいだけだ。

0035デフォルトの名無しさん

2011/11/22(火) 18:10:07.18

残念ながらできない

0036デフォルトの名無しさん

2011/11/22(火) 18:19:31.15

君、できないの？

0037デフォルトの名無しさん

2011/11/22(火) 18:38:47.74

盛り上がってまいりました!

0038デフォルトの名無しさん

2011/11/22(火) 18:54:38.61

できないことの証明は難しいが、できることの証明は簡単なはずだ

まあGLSLで出来るかはわからないが描写先をフレームバッファオブジェクトにしておけば、
そしてテクスチャーバッファーにしておけば、普通にアクセスできるはず

これレンダーバッファーではできないよね？レンダーバッファーは普通のGL関数でアクセスする専用ってことかね

0039デフォルトの名無しさん

2011/11/22(火) 21:17:41.33

>>38
ttp://www.opengl.org/wiki/Framebuffer_Object
Feedback Loopsって所を見るとダメかな。Mostly

0040デフォルトの名無しさん

2011/11/22(火) 21:42:21.46

普通の？画像処理と同じ要領なのね

やりたいことがわからないけど、まあそれがわかれば解決策も容易にわかるはず

0041デフォルトの名無しさん

2011/11/23(水) 01:22:37.66

>>32
例外的だけど、tegraとか、一部のタイル系モバイルGPUではできるみたいよ。

参考 : NV_shader_framebuffer_fetch

0042デフォルトの名無しさん

2011/11/23(水) 04:57:29.73

GLEWライセンス見たけど要は修正BSDライセンス？

0043デフォルトの名無しさん

2011/11/23(水) 08:50:37.04

結局フラグメントシェーダからレンダーバッファを参照するのは不可能、でFA？

0044デフォルトの名無しさん

2011/11/23(水) 11:08:38.69

>>43
現在のほとんどのハードウェアでは出来ない。
>>41のような例外は、レンダーバッファ(の一部)がシェーダから近い位置にレイアウトされているから。

0045デフォルトの名無しさん

2011/11/23(水) 11:45:12.47

OpenGLでOIT実装したいとおもってるんですが、DirectXでいうところのAppendBufferってOpenGLだとなにになりすか？

あと、OpenGLのDirectX11相当の機能についてよいリンクなどあったら教えてください。

0046デフォルトの名無しさん

2011/11/23(水) 13:06:25.29

32=45? A-Bufferとかで検索すればヒントが得られるんじゃないかな

0047デフォルトの名無しさん

2011/11/23(水) 13:53:18.91

>>46
ありがとうございます、32ではありません。
EXT_shader_image_load_storeという拡張が欲しい仕様にみえます、OpenGL拡張の仕様書ページみながら頑張ってみます。

しかしNvidia拡張の魔改造ぶりはすごいですね、NV_shader_buffer_store...

0048デフォルトの名無しさん

2011/11/23(水) 14:31:31.68

もうデファクトスタンダードでいいよ

0049デフォルトの名無しさん

2011/11/23(水) 15:11:23.55

魔改造と言うか、元々HWベンダですし
と言うか、大昔はハードウェアごとに全部ソフトウェアとか違ってた訳ですし

0050デフォルトの名無しさん

2011/11/23(水) 18:02:50.64

それは規格がなかった時代の話で今はOpenGLという規格があるのに自分勝手にはみ出してるって話だろ

0051デフォルトの名無しさん

2011/11/23(水) 18:21:51.42

まぁクロノスがグラボ作ってる訳でもないしな。

0052デフォルトの名無しさん

2011/11/23(水) 20:03:14.51

あ、魔改造は褒め言葉です。;-/
次のプロファイルではARBのシェーダでもポインタとか使えるようになっているといいな。

0053デフォルトの名無しさん

2011/11/24(木) 23:50:04.22

なぜOpenGLは行列を逆ハンドサイドから掛けないといけない仕様にしたんでしょうか？
わざわざ逆順に掛けて行く必要があるしC++のoperatorとも相性悪いしどうしても解せません

0054デフォルトの名無しさん

2011/11/25(金) 01:00:53.28

あっちが逆なんだよ

0055デフォルトの名無しさん

2011/11/25(金) 01:01:35.18

行列を掛ける方向と右手系左手系は関係ないし
OpenGLはC++のoperatorの定義なんてしてないし
気に入らないなら適当なラッパー書けばいいだけ

0056デフォルトの名無しさん

2011/11/25(金) 01:24:53.10

>>55
右手系左手系は関係ないけど転置してるから右から掛けないといけないですよね
C++のoperator、例えば*は左結合なので右から掛けるという規則がすごく気持ち悪いです
確かに数学で出てくるアフィン変換行列と同じ形式ですがプログラミング言語から使うんだから
わざわざ扱いにくい形式を採用しなくても良かったのでは？と疑問に思っています
なんでこんなことに？

0057デフォルトの名無しさん

2011/11/25(金) 01:36:12.62

なら転地しないで左から掛ければいいじゃない。
CPUでなにを計算するかなんてOpenGLの知ったこっちゃないよ

0058デフォルトの名無しさん

2011/11/25(金) 02:25:19.54

>>53,56
この辺読むと良いと思うよ。
http://steve.hollasch.net/cgindex/math/matrix/column-vec.html

右から掛ける、左から掛けるってのは、計算を数式で記述する仕方の問題だけ。
OpenGLの計算も、ベクトルを行ベクトルと見て行列を左から掛けるのだと解釈する事もできるんだから
そうしたいならそうすればいいんだよ。

005958

2011/11/25(金) 02:30:02.56

あ、ごめん、言葉足らずで変な言い方になった・・・。
「行列を左から掛けるのだと」のくだりは、ベクトルに対して行列を左から掛けるって意味じゃなく、
v'=vMに対してさらにローカルな変換を追加するときに新しい行列Nを v'=vNM とMの左に掛けるって意味でした。

0060デフォルトの名無しさん

2011/11/26(土) 07:38:37.40

ということはその場合はglRotate*等は混在できなくて
全てglLoadMatrixd*/glMultMatrix*で自前でするということ？

0061デフォルトの名無しさん

2011/11/26(土) 08:23:02.42

なんで突然glRotateが使えなくなんの。
とりあえず自分でコード書いて確かめてみなよ

0062デフォルトの名無しさん

2011/11/26(土) 09:05:39.27

>>60
なんかそもそも行列の演算とその使い方が分かってない感じ・・・かな。
もっと具体的に、どういう事をしたい時にどう困ってるのかが分かれば、
解決策も出ると思うんだけど。
とりあえずOpenGL(DirectX)の行列に関する仕様はおおかたの使い方において
妥当なようになっているし、大半の人は（多分）困ってないよ。

0063デフォルトの名無しさん

2011/11/26(土) 14:39:58.94

それはともかく
そろそろ OpenGL の行列関数は使わない方がいいような気はする

0064デフォルトの名無しさん

2011/11/26(土) 17:32:55.68

使わないっていうか今の4.x系列は使えないだろ
GLSL側でcolumn-majorで定義したのが許せない
せっかく０から定義したのになぜバカな仕様を引きずるのか...

0065デフォルトの名無しさん

2011/11/26(土) 18:33:03.16

>>62
glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので
自前で右へ右へ掛けていくために行ベクトル用の行列を作って掛けていったものに対して使うと当然結果おかしくなっちゃいますよね？
うわあめんどい・・・

0066デフォルトの名無しさん

2011/11/26(土) 18:42:06.05

>>61
自分のソースのglRotateしてる部分を回転行列の転置行列をgMultiMatrixするように置き換えれば使えない理由が分かります確かめてください

0067デフォルトの名無しさん

2011/11/26(土) 19:06:54.41

>>66
俺は何も困ってないし、何一つ疑問は無いので確かめないよ？ｗ

0068デフォルトの名無しさん

2011/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)
自分で書くなら、自分が使いやすいように実装したらいいんじゃね

0069デフォルトの名無しさん

2011/11/26(土) 22:18:06.69

>>65
＞glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので
違います。

＞自前で右へ右へ掛けていくために行ベクトル用の行列を作って掛けていったものに対して使うと当然結果おかしくなっちゃいますよね？
おかしいのはあなたの考え方です。

58のURLは読みましたか？
その内容は理解できますか？できませんか？どっち？？

0070デフォルトの名無しさん

2011/11/26(土) 22:54:45.46

>>69
>>58はoperatorの解釈を変えるだの変換をかませだの書いてありますが
言ってることはそれでOKですか？
列中心か行中心かはデータの話でマトリクスの掛け算の定義は変わらないのは当たり前の話で
その上で自前の行中心の行列をかけてる途中で列中心の行列を掛けてしまうglRotate*をそのまま呼び出すことは出来ないよね？めんど。って話をしてるんですけどちゃんと聞いてますか？

0071デフォルトの名無しさん

2011/11/26(土) 23:25:10.25

>>70
自前の行列をそのままglRotatefを呼べるようなデータの配列順にしとけばめんどくないよって話

0072デフォルトの名無しさん

2011/11/26(土) 23:28:26.54

うん、マジでゴメン。
理解できてない人に理解できてるかどうか聞いても意味無かった。
しかしこれどう言えば分かってもらえるのか分からん・・・。

＞>>58はoperatorの解釈を変えるだの変換をかませだの書いてありますが
＞言ってることはそれでOKですか？
違います。
というかそんなことはどうでもいいです。
えっと確認なんですが、英語は読めますか？

＞列中心か行中心かはデータの話でマトリクスの掛け算の定義は変わらないのは当たり前の話で
「データの話で」の意味が不明。

＞その上で自前の行中心の行列をかけてる途中で列中心の行列を掛けてしまうglRotate*をそのまま呼び出すことは出来ないよね？めんど。って話をしてるんですけどちゃんと聞いてますか？
それが誤解なのだと、58に貼ったURLに書いてあるんですが…。

0073デフォルトの名無しさん

2011/11/26(土) 23:38:30.10

>>72
何一つ情報増えてないよね
自分で説明できないなら書かなきゃいいのに。

0074デフォルトの名無しさん

2011/11/26(土) 23:50:45.58

65 の人の誤解を言葉で正すことは不可能だと思うな。

0075デフォルトの名無しさん

2011/11/26(土) 23:53:28.22

自分が理解できないからって情報が無いと考えるのはダメだよ。
58に十分な情報があるのに。

ええとまず、そうだな、最低限のところだけ言うとすると、
glRotate(やその他)は、列優先の行列を掛けるのではないし、列ベクトルに掛けるための行列を作るのでもない。
まずここが分からないと話にならないんだけど・・・
なぜあなたは、OpenGLの行列命令が扱う行列は列優先で、列ベクトルに掛けるものだと思っているのですか？

0076デフォルトの名無しさん

2011/11/27(日) 00:39:25.54

数学の話とAPIの話とC言語の話と好みの話がごっちゃになってるんだな

0077デフォルトの名無しさん

2011/11/27(日) 00:47:34.43

薄々感じるのは、>>53,56が問題にしたいのは実は行だの列だのって話じゃなくて、
v'=Mvという変換の状態に対してglRotate系を発行すると、生成された行列Rが v'=MRv と掛かるコト
（>>53,56は v'=RMv となって欲しいと思っている）なんじゃないかと・・・。

0078デフォルトの名無しさん

2011/11/27(日) 01:37:06.74

「自前の行列」ってことはどっかでglLoadMatrixしてんでしょ
じゃあglRotateのあとにglMultiMatrixすりゃいいんじゃねえの？

0079デフォルトの名無しさん

2011/11/27(日) 01:41:37.61

0080デフォルトの名無しさん

2011/11/27(日) 02:12:17.59

>>78
glLoadMatrixする直前に変換行列を転置させるから
glFlush直前ならOKなんですけど、変換途中に使うとなると
行列のLoadとGet時で転置を計2回やる必要があってやっぱり不便だなーと

0081デフォルトの名無しさん

2011/11/27(日) 02:18:50.55

x　glFlush直前
o　描画関数呼び出し前

0082デフォルトの名無しさん

2011/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は同じなんだよ。

0083デフォルトの名無しさん

2011/11/27(日) 02:29:22.83

>>79
そもそもの話だけど行列そのものには行優先も列優先も無くて
2次元の行列を1次元の配列に格納するのが行優先なのか列優先なのかって話なので、
「行中心行列」「列中心行列」みたいな単語を使ってる点を見るに、根本的な勘違いがあるんじゃないかなぁと。
（ちょっと余計な話すると、独自の用語を使う人は、まず大抵その分野について
初歩的な理解ができてないです。きちんと意味を調べて、正しい用語を使いましょう。）

DirectX（のドキュメント）はベクトルを行ベクトルで書いて、ベクトルの変換は行列を右に掛ける形で表すから
X軸回転の行列は>>79の上の行列の形になるけど、DirectXのドキュメントを列ベクトルで書いて
ベクトルの変換は行列をベクトルの左に掛ける形で書き直すと、DirectXのX軸回転の行列も
>>79の下の行列の形になりますよ。>>82も言ってるけど、両者は同じものなんですよ。

0084デフォルトの名無しさん

2011/11/27(日) 02:56:14.58

>>82-83
何の話題で盛り上がってるのかようやく理解できたｗ

0085デフォルトの名無しさん

2011/11/27(日) 02:57:29.17

うーん、もうちょっと補足した方がいいだろうか。
>>82や>>83で「同じ」と言ってるのは、何が「同じ」なのかというと、行列演算の「仕様」。

で、「仕様」と、その「数学的記述」は区別しないといけない。
OpenGL（の主なドキュメント）では仕様を、列ベクトルと左から掛ける行列で記述してるし、
DirectX（の主なドキュメント）では仕様を、行ベクトルと右から掛ける行列で記述してる。
同じ仕様を違う方法で記述してるだけだから、記述自体は相互に変換可能。
OpenGLもDirectXも仕様が同じなんだから、行列演算部分に関しては、同じプログラムがそのまま使える。
ってコトなんですよ。

0086デフォルトの名無しさん

2011/11/27(日) 03:12:20.63

>>83
行ベクトルに対するアフィン変換行列を行中心行列
列ベクトルに対するアフィン変換行列を列中心行列
というんだと思っていました。
一般的にはどう呼ばれているんでしょう
58のrow major、 column major？

左から掛ければ一緒というのはわかります
ただ右から掛けたい(*1)というのが独自で行列計算する動機なので左から掛ければ一緒はNGなんです

*1
左から掛ける場合Matrixクラスに対してoperator*=を定義できないため

0087デフォルトの名無しさん

2011/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=が余計に発生

0088デフォルトの名無しさん

2011/11/27(日) 03:27:09.26

もしくはむりやり
Matrix t = x1;
t *= m;
Matrix t2 = x2;
t2 *= t;
m = t2;

0089デフォルトの名無しさん

2011/11/27(日) 03:36:38.97

>>87
>>79の上のつもりで作った配列は右から掛けてok
できた配列は左版の転置になってると思うだろうけど、
それはそのまま直接OpenGLでもDirectXでも使えるメモリ配置になっている
実際にやってみたらわかると思うよ

>>87-88の言わんとしてることはわかるけど、最近のコンパイラの最適化的にどうなんだろね
グラフィック系のオーバーヘッドはそこには全く現れないと思うけど。でも気持ちはわかる

0090デフォルトの名無しさん

2011/11/27(日) 04:04:55.62

>>89
ああ、確かに反対の反対で同じになりますね。
安心して寝れます。

0091デフォルトの名無しさん

2011/11/27(日) 07:36:36.42

> ・column majorの場合
> Matrix m; // ワールド座標系への変換行列
> Matrix x1, x2; // 回転行列等
> // M*=x1 は意味的にM=M*x1なので使えない

これが嘘だな。operator*=を定義すれば使える

0092デフォルトの名無しさん

2011/11/27(日) 08:25:29.34

DirectXもOpenGLも結局は同じ
同じ3Dを扱う物だからな
ただ、DirectXはC++の配列の並びがそのまま使えるように左手座標系になってる
OpenGLの場合はあらゆるプラットフォーム、言語で使うために右手座標系になっている
ただ単にそれだけの事だ

0093デフォルトの名無しさん

2011/11/27(日) 09:27:29.43

右手座標だとそういう壁が超えられて左手だと超えられないの？

0094デフォルトの名無しさん

2011/11/27(日) 09:56:25.12

>>91
あなたのコードをメンテする人がかわいそうなのでプログラミングしないでください

0095デフォルトの名無しさん

2011/11/27(日) 11:40:12.59

>>92
右手系左手系と配列の並びは関係ないよ。

0096デフォルトの名無しさん

2011/11/27(日) 12:11:24.06

>>95
あるよ

0097デフォルトの名無しさん

2011/11/27(日) 12:47:10.53

ないよ

0098デフォルトの名無しさん

2011/11/27(日) 13:02:36.59

単にSGI-GLが右手座標系だったので、DirectXは左手にしてみましたみたいことじゃないの

0099デフォルトの名無しさん

2011/11/27(日) 14:07:37.62

>>98
ちゃう
OGL＝数理重視
D3D＝感覚・実用重視にしたら左手座標系になった

0100デフォルトの名無しさん

2011/11/27(日) 15:07:49.26

右手はマウス握ってるから、左手系にしといたほうが実用的だよなｗ

0101デフォルトの名無しさん

2011/11/27(日) 15:46:52.27

>>100
おまえ天才じゃね？

■ このスレッドは過去ログ倉庫に格納されています