5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

OpenGLスレ Part17

1 :デフォルトの名無しさん: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/

2 :デフォルトの名無しさん:2011/11/15(火) 18:45:55.78
== 過去スレ ==
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 :デフォルトの名無しさん: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

4 :デフォルトの名無しさん:2011/11/15(火) 23:24:15.07
>>1
乙なんだからね

5 :デフォルトの名無しさん: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/


6 :デフォルトの名無しさん:2011/11/16(水) 11:09:44.59
必読書は改定したい。

== 必読書 ==

-- 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 :デフォルトの名無しさん: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 (青本)


8 :デフォルトの名無しさん:2011/11/16(水) 13:00:08.50
赤本を遺物にして、openGLと関係ない本を必読はちょっと賛同できない

9 :デフォルトの名無しさん:2011/11/16(水) 14:38:26.34
赤本なんて2011年にもなって読む本じゃないだろ
訳本はOpenGL 2.1だぞ
古い仕様のOpenGLを学ぶのにもわかりやすい本ではないし。
昔はあれしかなかったからあれを薦めていたが
2011年にもなってあれをすすめるのは老害だけ

10 :デフォルトの名無しさん:2011/11/16(水) 14:41:57.24
俺が今OpenGLの包括的な学習書として1冊すすめるならOpenGL SuperBibleだな
シェーダーベースのモダンなOpenGLでもっとも詳しく解りやすく書かれている。
日本語で読めるいい本はないね。
特にシェーダーベースの本が絶望的にない。

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


11 :デフォルトの名無しさん:2011/11/16(水) 15:37:26.32
>>9
一理あるとは思うけど、
最新を追うだけが全てじゃないよ

12 :デフォルトの名無しさん:2011/11/16(水) 15:46:06.86
ちょっと聞きたいんだが、いまどきの現場では
OpenGLで2Dのゲームを作る場合にもシェーダー使っているんだろうか。

13 :デフォルトの名無しさん:2011/11/16(水) 15:51:47.32
>>11
が、古きを知るために赤本がいいかというと違うと思う。
いずれにせよ赤本は時代遅れ
赤本をすすめる人間は信用できない


14 :デフォルトの名無しさん:2011/11/16(水) 15:55:49.32
そもそも本なんて要らない

15 :デフォルトの名無しさん:2011/11/16(水) 17:34:52.91
>>13
4x1対応の赤本が出たら手のひら返すんでしょ?

16 :デフォルトの名無しさん:2011/11/16(水) 22:20:33.18
>>12
使った方が楽だと思うよ

17 :デフォルトの名無しさん:2011/11/16(水) 22:39:45.63
OpenGLなんて実際に使われているの?

18 :デフォルトの名無しさん:2011/11/16(水) 23:30:32.81
使われてるよ

19 :デフォルトの名無しさん:2011/11/16(水) 23:31:33.30
カーナビとか3Dじゃないけど使ってるねえ
あとCADとか

20 :デフォルトの名無しさん:2011/11/17(木) 23:07:51.76
glVertexAttribPointer()があればglEnableVertexAttribArray()は不要だと思うのですが、どうして分かれているのでしょう?

21 :デフォルトの名無しさん:2011/11/18(金) 00:03:18.19
キーボードのpとoが壊れた時も使えるからかな

22 :デフォルトの名無しさん:2011/11/19(土) 16:30:05.75
へえ

23 :デフォルトの名無しさん:2011/11/19(土) 18:38:02.15
>>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 :デフォルトの名無しさん:2011/11/21(月) 04:44:52.22
C++ と OpenGL, GLUTを利用した3次元の物理現象のプログラムを作成しよう
としているのですが、なかなか上手く出来ません。
http://www.natural-science.or.jp/article/20100818093625.php
作ろうとがんばっているのはまさに↑のようなものです。
出来ればソースコードを全て書き込んでいただければありがたいです。
Microsoft Visual Studio 2008より作成しています。
よろしくおねがいします。

25 :デフォルトの名無しさん:2011/11/21(月) 09:12:31.22
釣り針大き過ぎて無理

26 :デフォルトの名無しさん:2011/11/21(月) 10:18:31.14
>>24
http://www.sgra.co.jp/estimateform.html

27 :デフォルトの名無しさん:2011/11/21(月) 10:35:16.34
>>26
御食事処もあるのか。いい会社だな

28 :デフォルトの名無しさん:2011/11/21(月) 10:55:26.12
天才よ、ぱぱっと書いてやれ

29 :デフォルトの名無しさん:2011/11/21(月) 14:26:08.84
>>24
以前から何度も書き込んでる奴か?
ネタとしても面白くないからいい加減失せてね。

30 :デフォルトの名無しさん:2011/11/21(月) 20:24:08.66
これって物理エンジン使ったら簡単じゃね?

31 :デフォルトの名無しさん:2011/11/22(火) 00:44:48.87
よく見たら2Dだった

32 :デフォルトの名無しさん:2011/11/22(火) 16:41:35.45
GLSL触って間もないんですが
glBlendFuncと同じようなこと(フラグメントシェーダで描画先のピクセルの色を取って合成みたいな)
をGLSLで行いたいんですけどこれってできますか?
「描画先のピクセルの色を取って」の部分がどうすればできるのか分からないんですが

33 :デフォルトの名無しさん:2011/11/22(火) 17:18:16.22
描画先のピクセルを参照することは出来ない。

34 :デフォルトの名無しさん:2011/11/22(火) 17:54:06.50
んなわきゃない。
描画先のメモリを参照すればいいだけだ。

35 :デフォルトの名無しさん:2011/11/22(火) 18:10:07.18
残念ながらできない

36 :デフォルトの名無しさん:2011/11/22(火) 18:19:31.15
君、できないの?

37 :デフォルトの名無しさん:2011/11/22(火) 18:38:47.74
盛り上がってまいりました!

38 :デフォルトの名無しさん:2011/11/22(火) 18:54:38.61
できないことの証明は難しいが、できることの証明は簡単なはずだ

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

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

39 :デフォルトの名無しさん:2011/11/22(火) 21:17:41.33
>>38
ttp://www.opengl.org/wiki/Framebuffer_Object
Feedback Loopsって所を見るとダメかな。Mostly

40 :デフォルトの名無しさん:2011/11/22(火) 21:42:21.46
普通の?画像処理と同じ要領なのね

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

41 :デフォルトの名無しさん:2011/11/23(水) 01:22:37.66
>>32
例外的だけど、tegraとか、一部のタイル系モバイルGPUではできるみたいよ。

参考 : NV_shader_framebuffer_fetch

42 :デフォルトの名無しさん:2011/11/23(水) 04:57:29.73
GLEWライセンス見たけど要は修正BSDライセンス?

43 :デフォルトの名無しさん:2011/11/23(水) 08:50:37.04
結局フラグメントシェーダからレンダーバッファを参照するのは不可能、でFA?

44 :デフォルトの名無しさん:2011/11/23(水) 11:08:38.69
>>43
現在のほとんどのハードウェアでは出来ない。
>>41のような例外は、レンダーバッファ(の一部)がシェーダから近い位置にレイアウトされているから。

45 :デフォルトの名無しさん:2011/11/23(水) 11:45:12.47
OpenGLでOIT実装したいとおもってるんですが、DirectXでいうところのAppendBufferってOpenGLだとなにになりすか?

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

46 :デフォルトの名無しさん:2011/11/23(水) 13:06:25.29
32=45? A-Bufferとかで検索すればヒントが得られるんじゃないかな

47 :デフォルトの名無しさん:2011/11/23(水) 13:53:18.91
>>46
ありがとうございます、32ではありません。
EXT_shader_image_load_storeという拡張が欲しい仕様にみえます、OpenGL拡張の仕様書ページみながら頑張ってみます。

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

48 :デフォルトの名無しさん:2011/11/23(水) 14:31:31.68
もうデファクトスタンダードでいいよ

49 :デフォルトの名無しさん:2011/11/23(水) 15:11:23.55
魔改造と言うか、元々HWベンダですし
と言うか、大昔はハードウェアごとに全部ソフトウェアとか違ってた訳ですし


50 :デフォルトの名無しさん:2011/11/23(水) 18:02:50.64
それは規格がなかった時代の話で今はOpenGLという規格があるのに自分勝手にはみ出してるって話だろ

51 :デフォルトの名無しさん:2011/11/23(水) 18:21:51.42
まぁクロノスがグラボ作ってる訳でもないしな。

52 :デフォルトの名無しさん:2011/11/23(水) 20:03:14.51
あ、魔改造は褒め言葉です。;-/
次のプロファイルではARBのシェーダでもポインタとか使えるようになっているといいな。

53 :デフォルトの名無しさん:2011/11/24(木) 23:50:04.22
なぜOpenGLは行列を逆ハンドサイドから掛けないといけない仕様にしたんでしょうか?
わざわざ逆順に掛けて行く必要があるしC++のoperatorとも相性悪いしどうしても解せません

54 :デフォルトの名無しさん:2011/11/25(金) 01:00:53.28
あっちが逆なんだよ

55 :デフォルトの名無しさん:2011/11/25(金) 01:01:35.18
行列を掛ける方向と右手系左手系は関係ないし
OpenGLはC++のoperatorの定義なんてしてないし
気に入らないなら適当なラッパー書けばいいだけ

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

57 :デフォルトの名無しさん:2011/11/25(金) 01:36:12.62
なら転地しないで左から掛ければいいじゃない。
CPUでなにを計算するかなんてOpenGLの知ったこっちゃないよ

58 :デフォルトの名無しさん:2011/11/25(金) 02:25:19.54
>>53,56
この辺読むと良いと思うよ。
http://steve.hollasch.net/cgindex/math/matrix/column-vec.html

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

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

60 :デフォルトの名無しさん:2011/11/26(土) 07:38:37.40
ということはその場合はglRotate*等は混在できなくて
全てglLoadMatrixd*/glMultMatrix*で自前でするということ?

61 :デフォルトの名無しさん:2011/11/26(土) 08:23:02.42
なんで突然glRotateが使えなくなんの。
とりあえず自分でコード書いて確かめてみなよ

62 :デフォルトの名無しさん:2011/11/26(土) 09:05:39.27
>>60
なんかそもそも行列の演算とその使い方が分かってない感じ・・・かな。
もっと具体的に、どういう事をしたい時にどう困ってるのかが分かれば、
解決策も出ると思うんだけど。
とりあえずOpenGL(DirectX)の行列に関する仕様はおおかたの使い方において
妥当なようになっているし、大半の人は(多分)困ってないよ。

63 :デフォルトの名無しさん:2011/11/26(土) 14:39:58.94
それはともかく
そろそろ OpenGL の行列関数は使わない方がいいような気はする

64 :デフォルトの名無しさん:2011/11/26(土) 17:32:55.68
使わないっていうか今の4.x系列は使えないだろ
GLSL側でcolumn-majorで定義したのが許せない
せっかく0から定義したのになぜバカな仕様を引きずるのか...



65 :デフォルトの名無しさん:2011/11/26(土) 18:33:03.16
>>62
glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので
自前で右へ右へ掛けていくために行ベクトル用の行列を作って掛けていったものに対して使うと当然結果おかしくなっちゃいますよね?
うわあめんどい・・・

66 :デフォルトの名無しさん:2011/11/26(土) 18:42:06.05
>>61
自分のソースのglRotateしてる部分を回転行列の転置行列をgMultiMatrixするように置き換えれば使えない理由が分かります確かめてください

67 :デフォルトの名無しさん:2011/11/26(土) 19:06:54.41
>>66
俺は何も困ってないし、何一つ疑問は無いので確かめないよ?w

68 :デフォルトの名無しさん: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)
自分で書くなら、自分が使いやすいように実装したらいいんじゃね

69 :デフォルトの名無しさん:2011/11/26(土) 22:18:06.69
>>65
>glRotate*等が内部で掛けている行列は列ベクトルへ掛ける用なので
違います。

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

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

70 :デフォルトの名無しさん:2011/11/26(土) 22:54:45.46
>>69
>>58はoperatorの解釈を変えるだの変換をかませだの書いてありますが
言ってることはそれでOKですか?
列中心か行中心かはデータの話でマトリクスの掛け算の定義は変わらないのは当たり前の話で
その上で自前の行中心の行列をかけてる途中で列中心の行列を掛けてしまうglRotate*をそのまま呼び出すことは出来ないよね?めんど。って話をしてるんですけどちゃんと聞いてますか?

71 :デフォルトの名無しさん:2011/11/26(土) 23:25:10.25
>>70
自前の行列をそのままglRotatefを呼べるようなデータの配列順にしとけばめんどくないよって話

72 :デフォルトの名無しさん:2011/11/26(土) 23:28:26.54
うん、マジでゴメン。
理解できてない人に理解できてるかどうか聞いても意味無かった。
しかしこれどう言えば分かってもらえるのか分からん・・・。

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

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

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

73 :デフォルトの名無しさん:2011/11/26(土) 23:38:30.10
>>72
何一つ情報増えてないよね
自分で説明できないなら書かなきゃいいのに。


74 :デフォルトの名無しさん:2011/11/26(土) 23:50:45.58
65 の人の誤解を言葉で正すことは不可能だと思うな。

75 :デフォルトの名無しさん:2011/11/26(土) 23:53:28.22
自分が理解できないからって情報が無いと考えるのはダメだよ。
58に十分な情報があるのに。

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

76 :デフォルトの名無しさん:2011/11/27(日) 00:39:25.54
数学の話とAPIの話とC言語の話と好みの話がごっちゃになってるんだな

77 :デフォルトの名無しさん:2011/11/27(日) 00:47:34.43
薄々感じるのは、>>53,56が問題にしたいのは実は行だの列だのって話じゃなくて、
v'=Mvという変換の状態に対してglRotate系を発行すると、生成された行列Rが v'=MRv と掛かるコト
>>53,56は v'=RMv となって欲しいと思っている)なんじゃないかと・・・。

78 :デフォルトの名無しさん:2011/11/27(日) 01:37:06.74
「自前の行列」ってことはどっかでglLoadMatrixしてんでしょ
じゃあglRotateのあとにglMultiMatrixすりゃいいんじゃねえの?

79 :デフォルトの名無しさん:2011/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 :デフォルトの名無しさん:2011/11/27(日) 02:12:17.59
>>78
glLoadMatrixする直前に変換行列を転置させるから
glFlush直前ならOKなんですけど、変換途中に使うとなると
行列のLoadとGet時で転置を計2回やる必要があってやっぱり不便だなーと

81 :デフォルトの名無しさん:2011/11/27(日) 02:18:50.55
x glFlush直前
o 描画関数呼び出し前

82 :デフォルトの名無しさん: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は同じなんだよ。


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

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

84 :デフォルトの名無しさん:2011/11/27(日) 02:56:14.58
>>82-83
何の話題で盛り上がってるのかようやく理解できたw

85 :デフォルトの名無しさん:2011/11/27(日) 02:57:29.17
うーん、もうちょっと補足した方がいいだろうか。
>>82>>83で「同じ」と言ってるのは、何が「同じ」なのかというと、行列演算の「仕様」。

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

86 :デフォルトの名無しさん:2011/11/27(日) 03:12:20.63
>>83
行ベクトルに対するアフィン変換行列を行中心行列
列ベクトルに対するアフィン変換行列を列中心行列
というんだと思っていました。
一般的にはどう呼ばれているんでしょう
58のrow major、 column major?

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

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

87 :デフォルトの名無しさん: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=が余計に発生

88 :デフォルトの名無しさん:2011/11/27(日) 03:27:09.26
もしくはむりやり
Matrix t = x1;
t *= m;
Matrix t2 = x2;
t2 *= t;
m = t2;

89 :デフォルトの名無しさん:2011/11/27(日) 03:36:38.97
>>87
>>79の上のつもりで作った配列は右から掛けてok
できた配列は左版の転置になってると思うだろうけど、
それはそのまま直接OpenGLでもDirectXでも使えるメモリ配置になっている
実際にやってみたらわかると思うよ

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


90 :デフォルトの名無しさん:2011/11/27(日) 04:04:55.62
>>89
ああ、確かに反対の反対で同じになりますね。
安心して寝れます。

91 :デフォルトの名無しさん:2011/11/27(日) 07:36:36.42
> ・column majorの場合
> Matrix m; // ワールド座標系への変換行列
> Matrix x1, x2; // 回転行列等
> // M*=x1 は 意味的にM=M*x1なので使えない

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

92 :デフォルトの名無しさん:2011/11/27(日) 08:25:29.34
DirectXもOpenGLも結局は同じ
同じ3Dを扱う物だからな
ただ、DirectXはC++の配列の並びがそのまま使えるように左手座標系になってる
OpenGLの場合はあらゆるプラットフォーム、言語で使うために右手座標系になっている
ただ単にそれだけの事だ

93 :デフォルトの名無しさん:2011/11/27(日) 09:27:29.43
右手座標だとそういう壁が超えられて左手だと超えられないの?

94 :デフォルトの名無しさん:2011/11/27(日) 09:56:25.12
>>91
あなたのコードをメンテする人がかわいそうなのでプログラミングしないでください

95 :デフォルトの名無しさん:2011/11/27(日) 11:40:12.59
>>92
右手系左手系と配列の並びは関係ないよ。

96 :デフォルトの名無しさん:2011/11/27(日) 12:11:24.06
>>95
あるよ

97 :デフォルトの名無しさん:2011/11/27(日) 12:47:10.53
ないよ

98 :デフォルトの名無しさん:2011/11/27(日) 13:02:36.59
単にSGI-GLが右手座標系だったので、DirectXは左手にしてみましたみたいことじゃないの


99 :デフォルトの名無しさん:2011/11/27(日) 14:07:37.62
>>98
ちゃう
OGL=数理重視
D3D=感覚・実用重視にしたら左手座標系になった

100 :デフォルトの名無しさん:2011/11/27(日) 15:07:49.26
右手はマウス握ってるから、左手系にしといたほうが実用的だよなw

101 :デフォルトの名無しさん:2011/11/27(日) 15:46:52.27
>>100
おまえ天才じゃね?

102 :デフォルトの名無しさん:2011/11/27(日) 16:02:27.53
>>99
ちがう

なんでもいいからOpenGL と変えたかっただけ。
共通規格が成立するのを邪魔するのが、マイクロソフトの仕事だから。


103 :デフォルトの名無しさん:2011/11/27(日) 16:10:13.82
DirectXが左手系を採用した理由を、設計者に本音で聞いてみたいよねw

しかし左手系が実用性重視だのCの配列と相性がいいだの言ってる人は、
一体何を根拠にしてるんだろ? ワケ分からん。

104 :デフォルトの名無しさん:2011/11/27(日) 16:21:09.24
OpenGL右手座標系のはずなのに左手でCoordinate作ってしまう
x:中指,y:人差し指,z:親指

105 :デフォルトの名無しさん:2011/11/27(日) 16:36:09.96
でも XNA で用意されている関数は右手系なんだよな

何がしたいのか分からん

106 :デフォルトの名無しさん:2011/11/27(日) 16:55:40.42
MS のこれまでの所業を見て >>102 以外の理由があるかというと


107 :デフォルトの名無しさん:2011/11/27(日) 18:51:36.50
3DCGに関わって15年になるけどどっちでもいい

108 :デフォルトの名無しさん:2011/11/27(日) 18:54:03.23
7. OpenGL does not force left- or right-handedness on any of its coordinates

109 :デフォルトの名無しさん:2011/11/27(日) 19:01:14.11
あほか
DirectXはとにかく速度重視したからC++の配列に合わせて左手座標にしたのだ
転置する必要をなくすためにな

110 :デフォルトの名無しさん:2011/11/27(日) 19:05:43.44
右手座標だって転置する必要ないじゃん

111 :デフォルトの名無しさん:2011/11/27(日) 19:09:14.52
してないように見えて実はハードウェア内部でしてる

112 :デフォルトの名無しさん:2011/11/27(日) 19:13:56.24
>>111

してないよ
>>68見ればわかるけど、D3DXMATRIXとOpenGLのマトリックスは全く同じ配列なんだよ

113 :デフォルトの名無しさん:2011/11/27(日) 19:18:29.09
>>109
右手系と左手系の話と転置は関係ないから

http://msdn.microsoft.com/ja-jp/library/bb204853%28v=vs.85%29.aspx
>ビュー行列に使用している D3DMATRIX 構造体の _31、_32、_33、および _34 メンバーの符号を反転させます。

変換するには符号を反転させるだけなので

114 :デフォルトの名無しさん:2011/11/27(日) 19:21:46.88
そりゃ一回Translationしただけなら転置の必要はないわな。

115 :デフォルトの名無しさん:2011/11/27(日) 19:24:18.76
>>112
DirectXの場合はScaleしてからRotateしてTranslateするけど
OpenGLで、その順番でやってみなよ君

116 :デフォルトの名無しさん:2011/11/27(日) 19:53:38.92
>>113
大いにあるぞ

そのページの最後
>>これらの操作を組み合わせると、結果は可換的ではなくなり、行列を乗算する順序が重要となります。

http://msdn.microsoft.com/ja-jp/library/bb206269(v=vs.85).aspx
>>作成した行列の種類にかかわらず、期待どおりのエフェクトを実現するには、左から右へのルールが適用されることを忘れないでください。


117 :デフォルトの名無しさん:2011/11/27(日) 19:58:23.06
基本的なことを聞くけど

・座標系の左右と、行列の積の結合の左右
・座標系の左右と、行ベクトルか列ベクトルか
・座標系の左右と、乗算すべき行列が概念的なスタックに積まれる順番

これらは本質的に無関係だよな

118 :デフォルトの名無しさん:2011/11/27(日) 20:06:52.73
そもそもDirect3Dが左手だってのはどこから来てるの?
算術関数も両方用意されてるじゃん


119 :デフォルトの名無しさん:2011/11/27(日) 20:15:09.91
>>115
自分で行列逆に掛け算してSetTransformしてんじゃないの
MultiplyTransformで掛けこんでいったらDirectXもTrans Rotate Scaleの順だったが

120 :デフォルトの名無しさん:2011/11/27(日) 20:20:55.20
昔は左手座標しか無かったんだよ
DirectX5時代の話だけど

121 :デフォルトの名無しさん:2011/11/27(日) 20:26:04.68
>>119
ちゃんとLH使ってんのか?

122 :デフォルトの名無しさん:2011/11/27(日) 20:45:35.44
なんかglLoadMatrixに渡す行列のレイアウトがD3DXと同じなのに
glRotate/Translate/Scaleの変換の適用順がD3DXの乗算と逆なあたりが混乱の元凶な気がするんだが


123 :デフォルトの名無しさん:2011/11/27(日) 20:54:28.93
>>122
それこそが右手座標と左手座標の最大の違いなのだよ
行列データそのものは同じでも意図する合成行列を作るには
乗算順序を変えなければならない

http://www.c3.club.kyutech.ac.jp/gamewiki/index.php?3D%BA%C2%C9%B8%CA%D1%B4%B9
ここ見るとわかるかもしれない

124 :デフォルトの名無しさん:2011/11/27(日) 21:02:58.86
>今までの行列演算でおかしいと思った方がいたらすばらしいです。
>実はDirectXでは通常の数学とは行列の演算順序を逆にしてるんですよね。
>数学では座標 * 行列の演算順序であるのに、DirectXでは行列 * 座標の
>演算順序で表しています。

>迷惑な話ですが、このようなことで配列を効率よく使うことができ、
>メモリ効率が上がるらしいです。
>ただ、これだと行列の演算順序が変わると結果が変わってしまいます。
>そこで、DirectXでは行列を転置させて結果を変えないようにしています。
>ややっこしい。

125 :デフォルトの名無しさん:2011/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 :デフォルトの名無しさん:2011/11/27(日) 21:05:26.53
>>125
下の3行はMultiplyTransformの間違い。
あと掛ける前にD3DXMatrixIdentityで作ったので初期化(glLoadIdentity同等)する必要もある

127 :デフォルトの名無しさん:2011/11/27(日) 21:05:55.72
>>125
>>124

128 :デフォルトの名無しさん:2011/11/27(日) 21:08:24.04
列優先だか行優先だか右手回転系だか左手回転系だか
どれをなんて呼ぶのかよく覚えてねえけどさ

z軸の符号が異なるだけの右手左手系は全然関係ねえでしょ? 
D3DXのLHとRHの結果の相違は転置してるだけ? 違うでしょ?

129 :デフォルトの名無しさん:2011/11/27(日) 21:21:40.54
おまえ、SetTransformは行列スタックじゃねぇか
D3DXMatrixMultiplyでやってみろ

130 :デフォルトの名無しさん:2011/11/27(日) 21:27:17.48
D3DXMatrixTranslation
D3DXMatrixRotation
D3DXMatrixScaling
でやってみたの?

131 :デフォルトの名無しさん:2011/11/27(日) 21:37:58.12
>>125
お前どうしようもないな
v' = S * R * T * v

S,R,T,vの順にかける

132 :デフォルトの名無しさん:2011/11/27(日) 22:07:26.37
>>117
@座標系の左右と、行列の積の結合の左右
座標系の左右と行列の積の結合の左右は関係ない

A座標系の左右と、行ベクトルか列ベクトルか
少なくとも数学では右手座標と列ベクトルを用いることが定まっている
そしてOpenGLはそれを採用
DirectXでは左手座標と行ベクトルを採用していた(当初)
理由として
2Dの場合画面左上が原点になる
C++配列と相性が良い

B座標系の左右と、乗算すべき行列が概念的なスタックに積まれる順番
座標系の左右と、乗算すべき行列が概念的なスタックに積まれる順番は関係ない

133 :デフォルトの名無しさん:2011/11/27(日) 22:15:21.94
>>131
DirectXでは(紙の上ではOpenGLとは逆に) v' = v * M;
つか今回の話の発端はここでしょ

134 :デフォルトの名無しさん:2011/11/27(日) 22:36:05.24
ちみがいいたいのは平行移動行列と回転行列、拡大縮小行列は同じって事だろ
そう、同じだよ
でもDirectXとOpenGLが同じかと問われたら、それは全然違うと答えるよ

135 :デフォルトの名無しさん:2011/11/27(日) 22:41:53.93
C++配列と相性が良いってどういうことよ
まさかメモリ効率云々を曲解してるんじゃないよな

136 :デフォルトの名無しさん:2011/11/27(日) 22:43:00.64
>>133
線形代数やり直して来い

137 :デフォルトの名無しさん:2011/11/27(日) 22:48:08.63
>>136
線形代数がどうだろうと、実装はMSがしてんだからしょうがないだろ
http://msdn.microsoft.com/ja-jp/library/bb206269%28v=vs.85%29.aspx
v' = v * M

138 :デフォルトの名無しさん:2011/11/27(日) 22:56:42.21
Direct3DとOpenGLの座標系における明確な違いなんて

o 非同次射影空間のz値のクリッピング範囲が[-1,+1]と[0,+1]
o 補助関数(D3DX、glu)を比較するとむしろOpenGLが右手座標系しか選択肢が無いと言うべき

くらいで後はどうでもいい。
というか後者もどうでもいいか。

139 :デフォルトの名無しさん:2011/11/27(日) 22:58:41.62
あとテクスチャのピクセルが0.5ずれてるんだっけ

140 :デフォルトの名無しさん:2011/11/27(日) 23:00:08.09
列優先設定でのDirect3D持ち出したらお前が言い出した>>125のOpenGLとDirect3Dが一緒って主張がトリビアルでアホ丸出しだったってことになるんだが

141 :デフォルトの名無しさん:2011/11/27(日) 23:14:03.72
阿呆は今のことろ行列の合成順に右手左手言いだしたヤツだけだょ

142 :デフォルトの名無しさん:2011/11/27(日) 23:19:23.56
>>135
転置行列を作成しなくてもよい=無駄なメモリ使わないしスピードも速い
物凄く効率的じゃないですか?

143 :デフォルトの名無しさん:2011/11/27(日) 23:21:58.43
>>142
右手座標系(OpenGL)でプログラムする場合に、
どこで、何の理由で転置行列を作る必要があるのでしょうか

144 :デフォルトの名無しさん:2011/11/27(日) 23:23:01.60
>>142
何か勘違いしてるようだけど

145 :デフォルトの名無しさん:2011/11/27(日) 23:29:09.11
>>139
D3D10からはずれていないと思った。


146 :デフォルトの名無しさん:2011/11/27(日) 23:36:26.58
なんでズレてんの?

147 :デフォルトの名無しさん:2011/11/27(日) 23:38:06.08
つーか今のDirect3Dでは、D3D9で生にシェーダ定数渡す時も
D3D10以降の定数バッファに渡す時もD3DXの行列は転置する必要があるんだけどねw

D3DXの行列レイアウトの何が効率的なの昔からよくわからんのだが
焼き直しのXNA Mathでも同じだしSIMD有利なのけ?

148 :デフォルトの名無しさん:2011/11/27(日) 23:45:03.20
なんだったかな
とにかく速度優先にしたらDirectXの実装になったんだよ
ゲームSDKとしてOpenGLより速く表示する必要があったから
決してOpenGLの逆にしたいとか下らない理由では無かったと思う

149 :デフォルトの名無しさん:2011/11/27(日) 23:46:04.00
>>145
10で変わったのか、知らなかった。そういう仕様を変えちゃうってもすごいな。

150 :デフォルトの名無しさん:2011/11/27(日) 23:57:14.57
>>148
説得力が無い

行列同士の積も、行列とベクトルの積も、
右手座標系と左手座標系で計算量は変わらんと思うが

列同士の積の場合にCPUの積和演算器を活用するなら、
右手でも左手でもどちらかの行列を転置しないといけないし

151 :デフォルトの名無しさん:2011/11/27(日) 23:58:16.62
>>150
すまん、紛らわしいミスをした

> 列同士の積の場合にCPUの積和演算器を活用するなら、

行列同士の積の場合にCPUの積和演算器を活用するなら、

152 :デフォルトの名無しさん:2011/11/28(月) 00:13:23.85
>>150
説得力が無いと言いたいだけか
気になるならよく事情わからない名無しよりMSに問い合わせればいい

153 :デフォルトの名無しさん:2011/11/28(月) 01:35:46.83
http://marupeke296.com/DXG_No15_AttentionCoordinate.html

@ どうして左手系なのか?

>そもそも、左手系と右手系の2つある中でDirectXが左手系を選んだのは
>なぜなのでしょうか?私たちは小さい時から右方向がX軸、上方向がY軸の
>2Dのグラフを見てきました。
>そしてごく普通にアニメや漫画のキャラクタは上方向であるY軸に頭を向けて立ちます。
>さてこの状態で3Dになった時、キャラクタの目線は画面の奥に向かうのが自然でしょう。
>そうすれば、キャラクタの目線方向とプレーヤーの目線方向も合います。
>「前へ進め!」とボタンを押したとき、画面の奥に向かっていくのが自然なのです。
>Z軸が画面の奥へ進む座標系は『左手系』です。
>この自然な成り行きでDirectXなどの3Dゲームは左手系座標を採用しています。


http://www.arakin.dyndns.org/gl_coord.php

>しかし、私がよく使用しているペイントソフトのPictBearやGIMP、そして、あの有名な
>Photoshopも左上が原点です。
>私自身が慣れているのは左上原点であり、これまでアップしたきたサンプルも
>左上原点なのですが、やはり、OpenGLのプログラムをする時は、左下を原点にした方が
>分かりやすいため、左下で統一することにしました。ということで、多くのサンプルを
>一部変更しました。


直感的で自然でわかりやすいからというのが理由だろうな
本当の所はわからんが

154 :デフォルトの名無しさん:2011/11/28(月) 01:47:09.77
自然だの直感的だのは人によって違うからねぇ。

ところで、左手系の方が効率が良いとかまことしやかな噂を聞く割には、
具体的にどの部分でどう効率が良くなるのかっていう説明は目にしないよね。
不思議だよねw

155 :デフォルトの名無しさん:2011/11/28(月) 01:55:37.98
NDAを結ばないと見れない資料だったんじゃないの。
だとしたら不思議じゃないけど。

156 :デフォルトの名無しさん:2011/11/28(月) 02:06:59.57
ギャグかそれ

157 :デフォルトの名無しさん:2011/11/28(月) 20:40:54.65
setPlaymodeからsetPlayModeに勝手に変えんなよ糞osgが

158 :デフォルトの名無しさん:2011/11/28(月) 21:41:31.81
OSGすげー汚くない?
適当にドキュメント読んだだけだけどあれ使う気にならんわ

159 :デフォルトの名無しさん:2011/11/28(月) 23:33:36.48
OSsanGeyか

160 :デフォルトの名無しさん:2011/11/29(火) 20:08:17.28
osgはシーングラフ完全特化というのと微妙にゆるい命名規約がいいな
glutよりは好きかも

161 :デフォルトの名無しさん:2011/11/30(水) 00:11:51.92
glutとosgを比べるのはちょっと無理があるだろ

162 :デフォルトの名無しさん:2011/11/30(水) 01:58:42.93
私もosgのおかげで偏頭痛が軽減しました

163 :デフォルトの名無しさん:2011/12/01(木) 20:34:41.74
左手座標が速いってのは上手くやれば視体積0.0〜1.0の範囲に収まるって事かな?
その場合、マイナスの演算が無くなるから速くなるかもね

164 :デフォルトの名無しさん:2011/12/01(木) 20:59:44.34
何言ってんのこの人

165 :デフォルトの名無しさん:2011/12/01(木) 21:23:24.34
ネタに突っ込んでやるなよ

166 :デフォルトの名無しさん:2011/12/01(木) 21:24:16.91
流石にこれは本当に 何いってんの?だと思った
煽る訳じゃないが、普通に思った

167 :デフォルトの名無しさん:2011/12/01(木) 21:36:39.41
>>163
大変興味深い

もう少し具体的な数値を出して、
マイナスの演算が無くなって速くなる事を例示してみてはどうだろう

ネタとか言ってる愚民どもを黙らせることができるかも知れん

168 :デフォルトの名無しさん:2011/12/01(木) 21:41:19.54
自演なのかな。
それとも病人が二人いるのかな。

169 :デフォルトの名無しさん:2011/12/01(木) 21:46:32.16
三人だ。ようこそ。

170 :デフォルトの名無しさん:2011/12/01(木) 21:51:11.86
いや >>167 はどう見てもひねくれた突っ込み


171 :デフォルトの名無しさん:2011/12/02(金) 18:21:41.12
アセンブラだと乗算は9clock、除算は46clockだっけ。
加算と減算はどうなんだ?

172 :デフォルトの名無しさん:2011/12/02(金) 18:55:49.24
addとsubは同じ
ただsignedとunsignedの乗算はまず、どちらかにそろえる必要があるから
signedが増えると若干プロセスが増えるのは確か

173 :デフォルトの名無しさん:2011/12/02(金) 19:09:48.55
浮動小数点の話じゃないの?

174 :デフォルトの名無しさん:2011/12/02(金) 19:13:12.62
>>138の言ってる事だろ
Direct3Dのビューボリュームが0〜1の範囲になってるのはそういう事だったのか

175 :デフォルトの名無しさん:2011/12/02(金) 19:34:48.97
http://www.daionet.gr.jp/~masa/column/2000-07-20.html

行列式で見てもDirectXの方が速いな。

176 :デフォルトの名無しさん:2011/12/02(金) 19:40:31.58
分かってるだろうが敢えて言う

行列式じゃなくて行列の式な
意味全然違うから

177 :デフォルトの名無しさん:2011/12/02(金) 20:02:25.03
>>175
contentヘッダがplain/text返すhtmlファイルってどうよ?

178 :デフォルトの名無しさん:2011/12/02(金) 22:08:28.97
これで左手座標系の方が速くなる理由がわかったな。
それ以外にもDirectXはZバッファリングを適当にごまかして処理を端折ってるからな。

179 :デフォルトの名無しさん:2011/12/02(金) 22:39:02.21
そうですか

180 :デフォルトの名無しさん:2011/12/02(金) 23:05:41.03
左手座標系関係無いじゃんw

181 :デフォルトの名無しさん:2011/12/02(金) 23:12:54.04
てか、そんな速度差も100:1ほどあるなら話は別だが、
そうでないなら、自分の書く処理に集中するべき

私の書いたプログラムの、本当に注力するべき部分、
速度に関しても本当にボトルネックになっている部分、
それが本当に問題になっているなら、そこを洗って正すべき


182 :デフォルトの名無しさん:2011/12/02(金) 23:52:30.60
>>181
言ってることは至極もっともだが、論点がずれてる

183 :デフォルトの名無しさん:2011/12/03(土) 00:56:27.37
175の式見てDirectXの方が速いとか言ってる人達は、
1フレームに何万回と射影行列を作るんですかね。

184 :デフォルトの名無しさん:2011/12/03(土) 01:05:57.56
行列1つについて話してるのになんで出てきちゃったの?

185 :デフォルトの名無しさん:2011/12/03(土) 01:27:22.90
行列一つの話をしてどうすんのさ。
元々は、DirectXは速度優先のために左手系を採用したとかいう話だったわけでしょ。
それともDirectXは行列一つを速く計算するために左手系を採用したの?

186 :デフォルトの名無しさん:2011/12/03(土) 01:59:58.68
175は行列の話なのに他の話と混ざっちゃったの?

187 :デフォルトの名無しさん:2011/12/03(土) 02:21:00.84
つまり175は、DirectXが左手系を採用した理由とは関係無いし、
左手系の方が速いっていう都市伝説とも関係の無い、
射影行列を作るならDirectXの方がちょっとだけ速いよっていうだけの話、って事?
だったらここで出す事に何の意味が・・・まぁいいか。

188 :デフォルトの名無しさん:2011/12/03(土) 02:54:30.80
誰かベンチマーク

189 :デフォルトの名無しさん:2011/12/03(土) 10:31:57.68
あの、左手系とか言ってる人はどの概念にその呼称を割り当ててるの?
z軸が反転してること? 
メモリ配置の違いによる行列の合成順のこと?

190 :デフォルトの名無しさん:2011/12/03(土) 12:52:55.68
メモリ配置とか言ってる人は数学ベースで考えられない人?

191 :デフォルトの名無しさん:2011/12/03(土) 13:05:51.83
>>190
数学ベースなら右手も左手も全く同じ計算量なんだから、
あとはメモリ配置とかCPU命令、GPUの仕組みやドライバなどで考えるしかないような・・・

192 :デフォルトの名無しさん:2011/12/03(土) 13:06:46.36
>>190
お前もう黙れよ低脳。 数学的に考えたら速度差の話に答えが出せるっての?


193 :デフォルトの名無しさん:2011/12/03(土) 13:51:14.07
>>192
メモリ配置って言ってるのが恥ずかしくなった?

194 :デフォルトの名無しさん:2011/12/03(土) 13:54:23.43
>>53以降、馬鹿が目立つな。

195 :デフォルトの名無しさん:2011/12/03(土) 14:08:57.53
190みたいな、具体的な話は何もできないくせにさも何かを知ってる風にしたがる厨二はどこにでもいるわけで・・・
相手にしたところで、空っぽなところからは何も引き出せないんだから、熱くならないことをお勧め致しますよ。 >>192



196 :デフォルトの名無しさん:2011/12/03(土) 14:22:51.37
>>193
なんで >>191 には反論しないの?

197 :デフォルトの名無しさん:2011/12/03(土) 14:58:24.48
>>193
何言ってんの?低脳は黙ってろよ


198 :デフォルトの名無しさん:2011/12/03(土) 18:01:02.61
射影行列って言っても、1秒60フレームなら60回分は速くなるわけな。
メモリ効率が良いってのはなんなんだ?
GPUに転送する時に何かあるのか?

199 :デフォルトの名無しさん:2011/12/03(土) 18:17:44.85
メモリ上で連続に配置されてるほうがキャッシュに乗りやすいから早い

200 :デフォルトの名無しさん:2011/12/03(土) 18:37:02.66
ほうほう。左手座標は連続してて右手座標は連続してないのか。

201 :デフォルトの名無しさん:2011/12/03(土) 18:52:53.65
>>199
それは確かにそうだが、
行列1つを行優先で配置しようが列優先で配置しようが、
普通のライブラリならどちらも連続的に配置する(ことを要求してくる)
採用している座標系の右手左手に関係なく

そして、行列同士の演算や行列とベクトルの演算において、
ある行や列は計算に不要ということはなく、全ての要素が計算対象となる

だから、行優先でも列優先でも、ましてjpgみたいに斜めに配置しようと、
連続的に配置されているのなら、1回の演算におけるキャッシュ効率は全く同じ

ちなみに、行列1つにつき32ビット浮動小数点16個分で、たった64バイト

ライン長64バイトのキャッシュメモリの場合、
行列の要素をメモリ上にどのように並べようが連続してさえいれば、
1行1列目にアクセスした時点で全要素キャッシュにロードされる


202 :デフォルトの名無しさん:2011/12/03(土) 19:51:25.43
しかも64バイトの配列の並びは行優先と列優先の転置では同じでしょ
DirectXのx行目y列目とOpenGLのy行目x列目は共にm[ x * 4 + y ]

203 :デフォルトの名無しさん:2011/12/03(土) 22:07:36.25
メモリ配置厨涙目w

204 :デフォルトの名無しさん:2011/12/03(土) 22:18:59.02
なんか痛々しいのが多いな

205 :デフォルトの名無しさん:2011/12/03(土) 22:21:48.17
それ誰に対して言ってるの?

206 :デフォルトの名無しさん:2011/12/03(土) 23:21:20.71
散々関係ないって言ってるのに
いまだに右手だの左手だのほざいてるアホにでしょう

207 :デフォルトの名無しさん:2011/12/04(日) 04:05:23.61
ポリゴンの一面単位でなく、頂点単位でglRotate〜などの変換を適用させる方法がわかりません
頂点データを毎回変更させてから描画するしかないのでしょうか?

208 :デフォルトの名無しさん:2011/12/04(日) 04:23:58.39
>>207
それは例えば 「鋭く尖ったウニみたい五芒星を、まるっこい五角形に」 みたいな話?
頂点更新して再適用( glMapBuffer〜頂点更新〜glUnmapBuffer )するか、
または頂点シェーダで

209 :デフォルトの名無しさん:2011/12/04(日) 04:37:03.43
>>208
そのような描画をしたいんですが、どうやら毎回更新するしかなさそうですね
ありがとうございました

210 :デフォルトの名無しさん:2011/12/04(日) 12:06:31.69
>>209
ちなみに一つだけ老婆心で書いておくと、上の話を踏まえた場合、
>頂点単位でglRotate〜などの変換を
頂点の移動は glScale/glRotate/glTranslate でなく、自分で数学的に計算すること
何故って自分で持ってるデータを書き換えて、再送信だから

211 :デフォルトの名無しさん:2011/12/05(月) 20:47:51.51
みんなツールキットは何を使ってるん?

212 :デフォルトの名無しさん:2011/12/05(月) 22:41:26.19
普通wgl

213 :デフォルトの名無しさん:2011/12/05(月) 22:46:46.19
Linuxでも使えたっけ wgl

214 :デフォルトの名無しさん:2011/12/06(火) 00:17:56.36
まともな環境なら大抵はね

215 :デフォルトの名無しさん:2011/12/06(火) 01:23:57.38
SDL
androidに移植できるらしいが情報が全然なくて途方に暮れてる

216 :デフォルトの名無しさん:2011/12/06(火) 01:38:36.17
SDLはライセンスに注意


217 :デフォルトの名無しさん:2011/12/06(火) 03:29:32.31
GPL混ざってる?

218 :デフォルトの名無しさん:2011/12/06(火) 11:05:49.93
>>211
好きなの選べ
http://www.opengl.org/resources/libraries/windowtoolkits/

さすがにSDLは時代遅れだろう
GLFWとかの方がいい

219 :デフォルトの名無しさん:2011/12/06(火) 12:34:32.43
SDLとGLFWとでは抽象レベルが全然違うような気がする

220 :デフォルトの名無しさん:2011/12/06(火) 12:45:26.92
SDL使うぐらいならSFMLを使ったほうがいい

221 :デフォルトの名無しさん:2011/12/06(火) 21:39:43.13
GLEWで音楽再生とかどうやるの?

222 :デフォルトの名無しさん:2011/12/06(火) 22:23:01.91
恥ずかしながらSFMLって初めて聞いた
面白そうだけど日本語情報が少ないから大変そうだ……

223 :デフォルトの名無しさん:2011/12/06(火) 22:30:46.33
>>221
GLFW 自体には音楽再生用の仕組みは用意されていないから、
別のライブラリやAPIを使う

play 関数を呼べば stop 関数を呼ぶまで再生し続ける関数があるなら、
それを適当なタイミングで呼べばいい

再生用バッファにwavデータを少しずつ放り込むタイプなら、
毎フレームにおいてバッファの様子を調べて適当にデータを放り込め

224 :デフォルトの名無しさん:2011/12/06(火) 22:39:54.84
>>218
横からだけど、glutしか使ってなかった
glfwまじで使いやすかったわ・・・ガチでありがとう

225 :224 :2011/12/06(火) 22:40:46.98
テンプレに入れて欲しいくらいだ

226 :デフォルトの名無しさん:2011/12/06(火) 23:23:03.87
フレームワークだけは自作じゃないと落ち着かない

227 :デフォルトの名無しさん:2011/12/06(火) 23:43:21.70
>>224
glutと比べてどこらへんが使いやすい感じなの?

228 :デフォルトの名無しさん:2011/12/07(水) 07:26:32.42
>>227
・ちゃんとメインループから帰ってくる
・tgaのテクスチャなら作るのラクチン
・glutくらいシンプル

229 :デフォルトの名無しさん:2011/12/07(水) 16:18:16.17
GLUTによる「手抜き」OpenGL入門を見てアニメーションを作っているのですがこのやり方で一定の動きをした後同じオブジェクトに違う動きをさせるアニメーションを作るにはどうすればいいでしょうか?

230 :デフォルトの名無しさん:2011/12/07(水) 17:24:24.21
どこのopenglのバージョンの境かしらないが
0サイズのテクスチャーをFBOにアタッチしてOKだったりエラーだったりするのな
焦らせやがって全くw

231 :デフォルトの名無しさん:2011/12/07(水) 19:04:32.62
>>229
それは GLUT や OpenGL とは何の関係もない

「一定の条件を満たしたかどうか」を判定する方法と、
判定した結果に応じて「状態を遷移させる」方法があればできる

if (一定の動きをしたか?) then 違う動き else 同じ動き

とか

void anim1 () { 同じ動き }
void anim2 () { 違う動き }
--------
a = anim1 // 初期化

if (一定の動きをしたか?) then a = anim2

とか、方法はいろいろある

232 :デフォルトの名無しさん:2011/12/07(水) 19:43:08.10
いつも省略してたからthenっていう書き方が斬新に見えた
本来は if then elseなんだな

233 :デフォルトの名無しさん:2011/12/07(水) 19:45:51.25
>>232
スマン

>>231 は擬似コードのつもりだ

234 :デフォルトの名無しさん:2011/12/08(木) 23:59:15.80
ES 2.0でglEnable/glDisableのGL_MULTISAMPLEがなくなってますが、
途中でマルチサンプルのON/OFFを切り替えるのって
もうできなくなってしまったんでしょうか?

235 :デフォルトの名無しさん:2011/12/09(金) 21:31:02.67
スレチだけど状態遷移書いてるとyieldとか手軽につかえたらなーと思うなぁ

236 :デフォルトの名無しさん:2011/12/10(土) 00:43:40.49
long jumpでええやん

237 :デフォルトの名無しさん:2011/12/10(土) 03:28:12.94
libpclマジオススメ

238 :デフォルトの名無しさん:2011/12/10(土) 16:16:42.39
>>231
ありがとうございます。また質問させてください。

239 :デフォルトの名無しさん:2011/12/10(土) 20:23:17.92
>>236-237
うーんなるほど・・・

240 :デフォルトの名無しさん:2011/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 :デフォルトの名無しさん:2011/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 :デフォルトの名無しさん:2011/12/11(日) 09:54:37.99
>つまり、紙の上では C=IRT コーディングは C=ITR
>で、正しいですか?

正しいわけないだろ

243 :デフォルトの名無しさん:2011/12/11(日) 12:28:27.29
>>240-241
紙の上ってどういう意味?

>>242
何が悪いか言わずに正しいわけないだけ言うのって内容を理解してない人間がよくやる

244 :デフォルトの名無しさん:2011/12/11(日) 12:40:56.23
今からまた行ベクトルだ列だ転置だ左手だってはじめるのかw


245 :デフォルトの名無しさん:2011/12/11(日) 12:49:30.33
はあフレームバッファの始点を左上にしたい

246 :デフォルトの名無しさん:2011/12/11(日) 14:16:09.57
また阿呆が暴れてるのか。消えろよ 240

247 :デフォルトの名無しさん:2011/12/11(日) 14:47:23.17
紙の上ってのが良くわからんが C=IRT コーディングは C=TRI じゃねぇの?
右から計算するなら

248 :デフォルトの名無しさん:2011/12/11(日) 14:58:12.26
一部のandroid機種だとGL_INFO_LOG_LENGTHの値って常に0が返ってくるのね…

おのれー!

249 :デフォルトの名無しさん:2011/12/11(日) 16:29:34.26
紙の上=学校で習った数学での習慣を使った手計算の時の順序では、
ってことじゃないの?

ここは勉強出来ない、数学出来ない、ライブラリのリファレンス読んでわかったつもりの
ニートとクズの吹き溜まりだから、真面目な質問しても答え返ってこないよ
>>242-247 みたいなレスしか返せない。 さらにバカだと >>246 みたいな頭のおかしいレスになるし。

ちなみに俺は、数学弱いのでよくわからないw

250 :デフォルトの名無しさん:2011/12/11(日) 16:49:04.80
>>249はなんで書き込んだんだ?

251 :デフォルトの名無しさん:2011/12/11(日) 17:17:43.47
>>240
紙のRやTもOpenGLでは転置になるから同じR T ではない点に注意
(R * T)の転置 = Tの転置 * Rの転置
という関係があるので逆になるように見える。
縦書きと横書きの違いでしかない
つかずっと同じ話してるので、自分で実際にプログラム作って確認してみたらいいよ

252 :デフォルトの名無しさん:2011/12/11(日) 18:17:41.79
>>251
OpenGLでは転置になるとかウソ書くからまた混乱する初心者が増えるんだよ・・・。
OpenGLの主な(?)ドキュメントは列ベクトル表記を採用しているというだけの話だろ。

253 :デフォルトの名無しさん:2011/12/11(日) 18:33:20.71
>>252
その通りです。すいません。

254 :デフォルトの名無しさん:2011/12/11(日) 19:32:11.05
>>247は合ってると思うけどw
学校で習った数学での習慣を使った手計算の時の順序が
OpenGLでは逆になるという事だ

255 :デフォルトの名無しさん:2011/12/11(日) 19:48:22.38
紙の上とは
>>249氏のとうりです。
>紙の上=学校で習った数学での習慣を使った手計算の時の順序では、

>>247
確かにです。

>>254
皆さん、有難うございます。


256 :デフォルトの名無しさん:2011/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 :デフォルトの名無しさん:2011/12/11(日) 20:14:05.98
数学、OpenGL=列ベクトル
C/C++の配列=行ベクトル
だから逆順に掛けるんだよ

258 :デフォルトの名無しさん:2011/12/11(日) 22:50:04.22
>>257
ハァ??????

259 :デフォルトの名無しさん:2011/12/12(月) 00:19:00.50
ここは自分の中の知識を相手に伝えることの出来ない人間と相手の言っていることを理解しようともしない人間の巣窟ですね

260 :デフォルトの名無しさん:2011/12/12(月) 00:21:37.57
さすがに>>257は、わざわざ頓珍漢な事を書いて場を荒らそうとしてるとしか思えないレベル。

261 :デフォルトの名無しさん:2011/12/12(月) 17:02:57.84
glutで作った二つのウィンドウに,
glDrawArraysを用いて全く同じ物を描画しようとすると,
エラーでプログラムが落ちてしまいます.
ウィンドウが一つの時は問題なく描画できています.
頂点の数は2^24個程なのですが,何か制限があるのでしょうか?
頂点の数を減らしても駄目でした.

262 :デフォルトの名無しさん:2011/12/12(月) 17:53:24.12
>>261
昔のことなんで間違ってるかもしれないが
テクスチャとか頂点配列ってウィンドウごとに固有じゃなかったっけ

263 :デフォルトの名無しさん:2011/12/12(月) 22:12:10.54
2つのスレッドが同じ所を参照しようとして… とか
いや適当だが

264 :デフォルトの名無しさん:2011/12/12(月) 22:52:59.22
クリティカルセクション

265 :デフォルトの名無しさん:2011/12/12(月) 23:00:25.39
wglShareLists

266 :デフォルトの名無しさん:2011/12/13(火) 00:38:39.68
glutでウィンドウ2つ作れることに驚いた

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)