3Dアルゴリズム全般

ネットなんかやってないで数学勉強してこいよ

2次元しか認めない

※厨房は黙って数学※

３Dで使う数式なんて嵩が知れてるから、実は数学が出来なくても殆ど困らない。
まあ出来ないのレベルにも色々あるだろうが。

むしろ数学アレルギーの方が問題かな。解説書だと簡単な概念でも無理矢理
数式をこねくり回そうとするから、そういうのを軽くいなせる度量が必要。
３Dの参考書を書いてる奴らは数学に劣等感を持っていると気付ければオーケー。

鏡作りたいけどどうしよう

>>5
ttp://homepage1.nifty.com/open-prog/java/tip01x.html

3Dどころか2Dもわからん…。
スプライン曲線の理論を理解したいんだけどな…。

ブレセンハムで線分が引ければ、後はその応用で何とかなると思うよ。
ググれば幾らでも資料は出て来るし。

最初は手で計算して方眼紙塗りつぶしても良い。

Coon 曲面ってしってる？

うん

複雑な数式で説明する香具師はわかってないのをごまかしてるだけの法則

数学の式ってもっとプログラム言語のように分かるように書けよといつも思うんだが、
そんなこというと激しく罵倒されそうだな。w
極度に省略された書き方がどうもしょうにあわん。

3次元多様体を分類するアルゴリズムの議論はここでよろしいですか？

お好きにどうぞ

>>2
http://www.teatime.ne.jp/Set1.html

4x4行列で4x1ベクトルを回転させる時の角度、あれはベクトルからどうやって求めるんでしょうか。

バーカ

>>16
キチガイのような奇怪な質問をするつもりではなかったと思いますが、わけわかりません。

>>16
線形代数の授業をもう一回最初から受けなおしたら
自分の質問がどれだけ意味不明かがわかるかと思います。

いまどき3Dの話で丸大ハムとか言ってるやつは一体何歳だ。

若いの　オラが村では派遣の問題を口にしちゃなんねーだ
お前さんはまだわけぇから言いたいこともあるべぇ
だべな、派遣問題を口にすると怒る者がおるでよぉ
問題の指摘は駄目だっぺぇ
派遣のことは口にしちゃなんねぇ
この村みたいな糞田舎で悲惨な生活するためにはよぉ
駄目のものを駄目と言ってはなんねえだべさ

え？

え、三次元って・・・なにがいいの・・・？

マウスでグリグリ動かせるのが良い
激しく動かして色んな方向から眺めていると興奮してくる

それは単に視覚的な問題であり、ここで話題になっている（というかなるべき）ものは
3次元に対する処理だけ。
さらに突っ込みをするなら、2次元ディスプレイに映像を流す以上内部処理が3次元であろうと、視覚的な定義は2.5次元。

>25
覚えたての厨は黙ってろよ
見てて恥ずかし過ぎ

2.5次元はエロイにおいがする

2.5次元

http://www.teatime.ne.jp/infor/ld2/ld2_top.htm
http://www.youtube.com/watch?v=lduq2xi_6Fo
http://www.youtube.com/watch?v=Dlbwhgs79N4&mode=related&search=

【派遣ネガティブ根性チェック】

3つ以上、チェックがつけばアナタの性格はひん曲がっており、
ネガティブ負け組派遣人生を歩んでいます。

□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□昼食は必ず派遣先の社員と行くべきだ
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなくプライベートについてもグイグイ引っ張って欲しい
□奢ってくれる派遣先正社員を尊敬する
□自分の月額金額を知らないのは当然だ、単金を聞いてはいけない
□派遣先正社員より自分の生涯収入が低いのは当然だ
□派遣先に尻尾を振り、かわいがってもらうことが大切だ

もう3次元より2.5次元の研究したほうが儲かりそうだ。
俺なんか萌え絵も一応描けるし、適任だな。

あげ

>>30
俺を題材にして萌えを描いてくれ
どう思う？

poserとかMakeHumanっていうソフトを使って人体をモデリングし,subsurface-scatteringかトゥーンレンダリングのできるレンダラを使えば可愛い女の子も比較的簡単に作れそうだ。
3D技術が発達すれば2Dで萌え絵を描くよりも簡単に萌え絵,萌え動画を作れるようになるんじゃなかろうか。

そもそも2dの萌え絵に描かれている人体も元々は3次元空間の人体がベースになってるわけでしょ。
萌え絵の人体を人間が認識するときも脳内で一度3Dの物体に変換して形を認識してるんじゃない?
だから萌え絵を生成するには2Dより3Dが適しているような気がする。

衆院選まで、一般大衆が覚えてるもの(抜粋)　　　　　　　　　　　Ver.080919
---------------------------------------------------------------
・年金改ざん(社保庁ぐるみ)
・後期高齢者医療制度(姥捨て山)
・デタラメ建築マンション(姉歯事件)
・消費税の増税推進(どう見ても増税内閣、人権擁護法案内閣)

・「恒久」減税が何故か廃止
・道路族議員の醜さ(特別会計含)
・ガソリン高値(これは敏感に反応するだろうね)全て自公のせいになると思うｗ
・PSE法(電気用品安全法)・WCE法推進(家族団欒法)
・事務所費問題(太田農相ほか)

・ガス田、竹島割譲
・北朝鮮の制裁解除(スパイ船入港)
・自民、移民１０００万人受け入れ推進(外国人の参政権付)

・中国に媚びるだけで、何もしないチンパン
・秋葉原、加藤の乱(奴隷制度)
・創価学会の追求(次期国会)

・毒餃子隠匿
・猛毒米　←　New
・政権を放り投げて茶番劇の総裁選　←　New
・太田農相辞め逃げ　←　New
---------------------------------------------------------------

>>28
いつものパターンのキモいツボ売り神社ゲーだな。

今更だが3Dカスタム少女が大ヒットな件
しまったと思ってるやつは多そうだなｗ

>>33
俺ももうアニメはトゥーンシェードでええやん思ってたけどなあ。
ソウルイーター見たらちょっと傲慢だったかもと思い始めた。話はツマンネだけど。

ソウルイーターの人物はトゥーンシェードじゃないだろう。
人物までトゥーンシェードなのは、デュエルマスターズと
きらりんレボリューションくらいじゃないか？

スカイガールズの飛行中の女の子もトゥーンだ

3Dで表現するどの方向から見ても
違和感がないアニメ顔ってのは難しいと思う

それが難しかったらフィギュアなんて発売されないよ。

サルゲッチュやカービィもトゥーン。
SD ガンダムフォースとか FREEDOM とか、いろいろある。

>>37
ああいや、あのスタイリッシュな動きは3Dでは絶対に無理だなという意味だ。

>>40 いや簡単なら、顔が違うフィギュアが出来たりはしないってw

日本で作ってないのが原因ではあるなｗ

age

age

あげ

age

ボンズ厨きてるな

昆布ポ○酢ハムニダ

ボンズの出塁率は異常

去年の春に、おまえはボンズかと言われた福留も今は見る影もないな
って今年も開幕から打ちまくってるな

海の波紋みたいなのってどうやら出来るん？
http://www.nicovideo.jp/watch/sm5786329のメニュー画面背景みたいなの

どんな複雑な波でも何種類かのsin関数の足し算に分解できるって知らないんだね。
無知っておそろしいわ

リサリサかツェペリに聞け

波じゃなくて集光効果じゃないの？上のウンコレベルのゲームでやってるとは思えないけど。
http://www.dgp.toronto.edu/~stam/INRIA/caustics.html
http://www.dualheights.se/caustics/

>>54
ゲームだとsinを直接使わずに差分方程式使って波を見せることも多いんだが。

無知っておそろしいわ

sinとか差分方程式とかいう以前に、53の動画のはただのテクスチャ
アニメーションだと思うが。

ただのテクスチャｗ　ﾌﾟ

どんな複雑な波でも何種類かのsin関数の足し算に分解できるって知らないんだね。
無知っておそろしいわ

そもそも水面波がsin関数に見えるとかどんだけ池沼なんだよ。
幼稚園児だって、先っぽが尖ったトロコイド曲線っぽいの波の絵を描くぞ。

sin関数に見えてるのはお前だけだよｗｗｗ

>>54=60には>>53のがsin関数に見えるんだぁ・・・

>>59 フォトショで作ったアニメーションにみえるけど。プッ。

まあ正確に言うと市販の動画用素材だろうな。
テクスチャ自作するようなクォリティーじゃない。

sin批判の人達はフーリエ変換とかご存じないのかしら。
この場合関係ないけど。

で、問題のブツだけど、二枚か三枚の半透明画像を重ね合わせている。
そのうちの一枚はただ斜めに UV スクロールしているだけ。
残りは、たとえばこういう
┏┳┳┳┳┓
┣╋╋╋╋┫
┣╋╋╋╋┫
┗┻┻┻┻┛
格子状の平面ポリゴンを、UV スクロールして表示しているのだが、
各頂点が正確に格子状に並んでいないのであのようになる。
隣接した頂点間のxyの距離は違うが uv の距離は同一というように
なっており、それによって同じ絵の中のある部分は伸びて表示され、
ある部分は縮んで表示されるのであのように見える。
PS1 時代の川の表現の定番だ。

これを上手い具合に見せようとするのは、その頂点の位置をどのように
バラケさせるかということにかかってくる。
多分、デザインセンスのある人が試行錯誤するということになるのでは
ないか。
もしかしたら、単にランダムにするだけでも構わないかも知れないが。

それと、もっと長い時間見ないとわからないが、もしかしたら、頂点は
アニメーションして移動しているかもしれない。

この質問は、コッチ
ゲームプログラムなら俺に聞け
http://pc12.2ch.net/test/read.cgi/tech/1230890476/l50
の方が良かったかも。

スレに人が戻ってよかったじゃん

>>66
重なった半透明部分がキラッとなるのはどうやっとんじゃい

>そもそも水面波がsin関数に見えるとかどんだけ池沼なんだよ。

たとえば
z=sin(x+y)を真上から見たことある？
mathematicaで見れるよ。
まあ、マスマティカ持ってないんだろうけどさ。

もし持ってるなら
z=sin(x+y)+4sin(2x*9y)とか色々見てみなよ
海の波に見えると思うよ

あ、エクセルなら持ってるだろ
それで見てみるといい。
やり方はね、x軸を行、y軸を列にしてオートフィルしてグラフウイザードで作るのね。
エクセルの入門書で考えてね。
今はフリーで3次元曲面見れるソフトあるからそれでもいい。

もちろん真上じゃなくてもいい。
むしろ斜めから見たほうが海の波に見えるよ。
無知ってほんとおそろしいわ。

それで、マスマティカとエクセルで斜めから見るのはどうやるの？

液晶によっては、斜めから見れないぞ

このスレは、そんなレベルの話をするスレなのか。
sinのグラフを見てみるとか、中学生レベルだろ。

むしろ既存ツールなんて使ってないで、sinの3Dプロットくらい自分で書く話をしろよ。

>>75
アンタこそ技術ってものを勘違い？
誰もプロット作る技術に関心は無い。

無知って恐ろしい君はまともに水面の波を観察したことがないんだろうと思った。

どんな複雑な波でも何種類かのsin関数の足し算に分解できるって知らないんだね。
無知っておそろしいわ

なんか煽ってるけどみんな適当に言ってるだろｗ

マジレスするとサイン波に分解できる波は
周期的に規則正しく変化するものにかぎられるの
数学では主にそういうものしか扱わないってだけ
CGでは障害物に当たって割れたり風で不規則に乱れたりする
サイン波を合成してそれっぽい形を生成することはあっても
分解できるとかデタラメだから

>>75
中学で三角関数ってお前いつの時代の人間だよｗｗｗ
確か中学で三角関数やってたのは団塊の世代じゃねーのか？ｗｗｗ
今時の人間はな、三角関数は高校でやるんだ。

とりあえずフーリエ変換調べてくれ。フーリエ変換できない関数に当てはまるほうが難しい。
それっぽい形て。
ただ一般的には時間変化をも記述するわけではない。

ただ1値関数の制限は大きいな。
水面が高さとして表されている関数である必要がある。
数学的な波は普通この条件を満たすけど水面は必ずしもそうではない。

波が岩に当たってざぶんと跳ね返ってきて
例えば点(1,1)でzの値が二個ある場合とかは無理だね

そんなわけで不規則でないと自然にみえないから乱数をまぜることになる
だったらわざわざ重いサイン関数を使う理由はない
周期的関数が必要なら>>66みたいに剰余算で十分
物理演算でサイン関数ならいっぱい出てくるかもしれないが
色収差でも扱うのでなければフーリエ解析なんか知らなくていいよね

そんなわけでってわかってないだろｗ
あとサインが重いとかアホだろ

>>1
人が集まってきてよかったな

>>86
そりゃ浮動小数点プロセッサがありゃたいしたコストじゃないが、
テーブルルックアップとか論理演算や加減算に比べりゃ遅い。
程度問題というものがわからんのか。

>>88
おまえ、昭和何年生まれだ？

64年

>>88
今時、浮動小数点プロセッサがないなんて環境はないだろ。少なくともここで議論する環境は。

昔の人ほど三角関数はテーブルで処理してたと思うけど。

最近のCPUはメモリアクセスより
計算速度の方がめちゃ早いから、テーブル使うより
その場で計算した方が早くて困る。

言えてる（笑）

その場で計算って何をさしてるの？
テイラー展開？

そりゃライブラリのsin呼ぶんだろ。最近はSIMDで最適化されてるし。

なんだ知ったかか

結局、誰もまねできないってこと？

さあ、だんだんと盛り下がって参りました

結局任意の波はサインの和で表せるという命題は真なの？
波がはねかえってzの値が2個以上ある場合は無しで。

音波をsin波で近似するのは、ゲームでも学術でもＯＫ
水面波をsin波で近似するのは、ゲームとか娯楽分野だったらＯＫじゃないの
学術的には、水面波の式は昔から研究されてて、そこでsin波だとかいったら、
かわいそうな子扱いされると思う。

だから周期性のある波ならフーリエ変換すればいいだろ
本格的な流体シミュレーションがしたいならナビエ・ストークス方程式でも計算してろカス

なに言ってんだよ。時代はCIP法だろ？
それ以外の手法はゴミ。

前から疑問だったんだが、なんでsin波なんだ？cos波でもいいじゃん。

水面の問題はナビエストークスだけじゃ解けないけどな。
周期性うんぬんもほとんどの関数で波長を無限大と考えればいいし。
CIPはナビエストークスの代わりのものではないし。

>>104
sinとcosは変換できるだろ。。。
別にcosだって同じことだよ。
変換できるんだから。

じゃsin波にこだわる必要ないしcos波でいいだろ。
おまえやっぱり馬鹿じゃね？

そいえば、離散コサインって聞いたことあるけど
離散サインって聞いたこと無いな
微妙に違うんじゃね？角度とか。

ポイントカードはともかくクレカなんて実際作るの時間かかるから向こうも作られると面倒だろ

基底がズレるだけで離散サイン変換もあるよ。

中身同じだから慣習的にコサインを代表的に扱ってるだけで。

水面つながりで聞くけど
http://www.4gamer.net/specials/3de/hl2/hl2_02.shtml
こういう水面の反射ってどうやるの？
一応、HLSLのreflect()を使うキューブ環境マップはもってるんだけど
これをそのまま使っても、リンク先のようにはならないんだよね。
原因は、ピクセルのWorld空間での位置が考慮されない為だと思うんだけど。

バンプマップじゃないの？

多分そのバンプマップの生成方法を聞いてるんだとおもわれる。

単純なセルオートマトンだと思うけど。
TortoiseSVNのアバウト画面のバナーみたいな。

TortoiseSVNのアバウト画面のバナー？

と思ってアバウト画面出してみたら、、、こんなのあったのかｗ

すいません、リンク先が間違ってました
http://www.4gamer.net/specials/3de/hl2/img/02/14.jpg
こういう感じで、水面に鏡像っていうんですかね
上下逆に写るような
どうやればいいですかね

動的に環境マップつくって動的に水面を生成すれば出来るとは思うけど。
速度やクオリティはやってみなきゃわからんが。

昔からある、スベスベな床にカベや天井が映り込む手法（Ｙ方向を反転させたモデルを描画）
を、水の部分だけでやって、そのあとシェーダで揺らぎを与えているんじゃないかな？

ところでPSMって遠くのシャドウが荒くなるだけのような気がするんだけど
本当に効果あるの？

ニア〜ファーを変換する時、例えばカメラで例えると
1.0〜1000.0の深度(Z)内で、まんべんなくOBJが配置されてるなら逆効果なのは有ってる
しかし通常は遠くの方のOBJなんか少ないが精度は不要(LODとかするくらいだろ)
つまり精度の割合をカメラの近くに使おうぜ、ってのがパースペクティブ変換
普通は良く見えてる手前のOBJに綺麗な影が出ててれば、遠くのOBJに影が汚くても気にならないでしょ？

そのニア寄りの影も大してキレイにならないよねって
言いたいんだと思うが。
PSMの粗さは、視錐台の形に影響するんで
ちゃんと最適な視錐台を作るエンジンだと、効果は薄くなりがち。

つーか、計算量を減らすアルゴリズムで「荒くなるだけ」って馬鹿?
ちゃんと計算量を減らすと言う効果があるわけなんだけど。

>>122
「効果は薄くなりがち」って、書いてるだろ。
視錐台を無駄がないように作るろうとすると、
・ニアとファーの距離が狭くなる
・FOVが狭くなる
結果、視錐台が台形じゃなくて方形に近くなって
PSMの効果が薄れるってこと。

>>123
落ち着け。>122は>119に対して書いているのだと思うぞ。
>122は>122で、計算量に対する言及だけだから言葉が足りないと思うが。

偉そうに書いてるが、LiSPSMとPSMをごっちゃにしてる時点で理屈を分ってない
パースペクティブ変換、アフィン変換、スクリーン変換、その辺りの単語でよ〜くしらべなｗ

面つながりで聞くけど、ファイナルファンタジーのクラウドの髪の毛の面って
どうやって書いてるんでしょうか？

>>125
その辺りがごっちゃになってるんですけど
ネットのサイトで計算式も含めて概要が分かるようなところはないでしょうか？

＞視錐台を無駄がないように作るろうとすると、
＞・ニアとファーの距離が狭くなる
＞・FOVが狭くなる
＞結果、視錐台が台形じゃなくて方形に近くなって
＞PSMの効果が薄れるってこと。

まんまPSMの処理を記述して、PSMの効果が薄れるって…
これだからライブラリ使うだけの奴はｗ

>>121も頓珍漢な事言ってるしｗ
効果が薄れるんじゃなくて、不都合や対処しきれない問題があるだけで
視錐台のニア付近を拡大してる時点で効果が出るだろ
ちゃんとニア付近の影はきれいになってるんだよ

お前が言いたいのは(最大限に好意的に見て)、ニア付近に上手くOBJが無い場合だろｗ

>>127
t-pot
+
もんしょの巣穴
なんか良いんじゃねｗ

またマニアックですな

>>128
だから、俺の主張は終始一貫してるじゃん。
効果は薄いってさ。

＞t-pot
このサイトは、全体的に良いんだけど
PSMのだけはお勧めできないね。
汎用性無いし、そんなに単純じゃないし。

俺はGPUGEMS1読んで実装した。
http://developer.download.nvidia.com/books/HTML/gpugems/gpugems_ch14.html

頓珍漢を具体的に指摘しないと認めないとｗ

＞PSMの粗さは、視錐台の形に影響するんで
＞ちゃんと最適な視錐台を作るエンジンだと、効果は薄くなりがち。

SMに比べてPSMは効果は出ます
PSMを適応するシーンによって効果が薄くなる場合があるのであって
PSMの理屈が効果薄いわけないだろってツッコミだよ

DIBゲームを前提にして、ダブルバッファって効果薄いよね
って言ってるようなもんだｗｗ

しかも

＞ちゃんと最適な視錐台を作る

これがPSMのキモなんですけど？ｗ
それがPSMじゃないかの如く発言して、それをするとPSMの効果が薄れるって
Gemsもソースコピペされるだけ為に理屈解説して可哀相だなｗ

百聞は一見にしかず。
>>131の為に、十分な検証用画像を用意した。
PSMとSMに殆ど差がないことをおわかり頂けただろうか。
http://www.dotup.org/uploda/www.dotup.org9078.jpg.html

>>132
原理を知ってれば、結果だけ見て差がないとか言う恥ずかしい事は言わない
単に差出ない条件で実験をしてるに過ぎない
ってのを何度言えば理解するの

だからソースコピペで理解してないって話になるんだよｗ

例えるなら
1+1を整数型と倍精度浮動少数型で計算して、結果が同じ2だから
整数型も倍精度浮動少数型も差がない、とか言ってるレベルなんだよ

＞十分な検証用画像を用意した。

久し振りに噴いたｗ
まずもって、同じ形で影落せてないじゃんｗｗ

こう言うコピペで動かしてるようなレベルの奴が、
勘違い思い込みの理屈を主張しだすと現場は良い迷惑なんだよな

>>132

お前痛すぎ

＞＞t-pot
＞このサイトは、全体的に良いんだけど
＞PSMのだけはお勧めできないね。
＞汎用性無いし、そんなに単純じゃないし。

＞十分な検証用画像を用意した。

こんな事口走るなら、シャドウマップのサイズ変えた毎の、同じ場面の影の比較くらい出せ
t-potじゃやってるだろ

>>132
つか地面に付いてる足の影だけ見ても十分にPSMの方が綺麗だろ…？
只のSMの方は足の影がガクガクじゃんｗ

主観で差が無いとか言っちゃってるだけじゃん…

あいよ。

ライトスペース・パースペクティブ・シャドウマップ技法〜デプスシャドウ技法の改良版その第2形態
ttp://journal.mycom.co.jp/column/graphics/026/index.html

Light Space Perspective Shadow Map
ttp://monsho.hp.infoseek.co.jp/dx/dx80.html

Perspective Shadow Maps
ttp://asura.iaigiri.com/OpenGL/gl54.html

ttp://homepage3.nifty.com/sweeper/gun/handgun/psm.htm

ttp://www.wolfvision.com/japan/download/psm10ecm_JP.html

解説WEBや本は沢山あるのに、肝心のゲームプログラマが理解出来ないんですね…
ソースコピペってプログラマの利点でもあり弊害でもあると

>>138
そうかねー
>>137のソースをコピペすれば出来るって？
まず君が読むことをお勧めする

>>139
あのさ、どんだけ読解力無いのｗ

アンタじゃ無いかも知れないが、散々偉そうに書いて、間違い突っ込まれて消えた
>>121>>123>>130>>132見たいな奴が居る事実を認識すれば？

Gemsで読んだって言って、
全然間違った理屈を吠えてれば、付属のCDサンプルのコピーと言われてもしょうが無いじゃんｗｗ

>>140
いやそれ全部俺っす
っていうか、君と俺のやりとりだろそれ、違う？

＞散々偉そうに書いて、間違い突っ込まれて消えた
まともに相手してないから

痛いな

下半身丸出しで、ちん○出てるぞって指摘に、ちん○丸出しで
そんなの出てない、まともに相手してないから
と言ってるようだ

すいません、FFのクラウドの髪の毛はどうやって書くのでしょうか？

これからPSM勉強しようと思ってるんですけど
要するにシャドウマップの計算に使う行列に
カメラの透視行列を加えるだけですよね？

>>144
ここで偉そうにしてる奴曰く

＞PSMの粗さは、視錐台の形に影響するんで
＞ちゃんと最適な視錐台を作るエンジンだと、効果は薄くなりがち。

＞視錐台を無駄がないように作るろうとすると、
＞・ニアとファーの距離が狭くなる
＞・FOVが狭くなる
＞結果、視錐台が台形じゃなくて方形に近くなって
＞PSMの効果が薄れるってこと。

＞PSMとSMに殆ど差がないことをおわかり頂けただろうか。

らしいので、PSMは勉強しなくて良いよ
きとんと視錐台つくる勉強しなよｗ

まだ続いてたのか。
いっそのことスレ建てたらどうだ？隔離スレ。

3Dの話題なんだからスレ違いではないだろ
疎いことに変わりはないが

隔離とか疎い以前に話に入れないんだろ？

すみません、クラウドの髪の毛はどうやって書いてあるのでしょうか？

どのクラウドだよｗ
�Zならポリゴンとテクスチャだｗｗ

レイトレーシングの実装方法を解説してるサイトってありませんか？

最近発売されたブルーレイのクラウドです。
髪の毛が一本づつなびいてるやつです＞150

セグメントを持った立方体に始点と終点となる面を定義して
レンダリング時にラインを描画する感じだったと思う。
数年前のCGWorldにちょこっと載ってたよ。

>>151
本買え

>>152
手っ取り早いのはテクスチャ貼った板を沢山挿す。
まともにやるならGPU Gems2を読むべし。

みなさんありがとうございます
あと、クラウドは何言語で書かれているのでしょうか？

釣りはスルーの方向でお願いします

釣ルーします。

任意のおうとつは三角関数の和で表せるって知らないんだね
無知っておそろしいわ。

それもう結論でてるぞ恥ずかしいやつだな

任意のクラウドは三角関数の和で表せることを知らないんだね。
無知っておそろしいわ。

クラウドコンピューティング？

うまいな。
お前クラスで人気者だろ。

なんか間違って覚えてる人がいるね。
大事なことなのでもう一度言っておくよ。
どんな複雑な波でも何種類かのsin関数の足し算に分解できるって知らないんだね。
無知っておそろしいわ

>>156
プログラマよりデザイナの方が重要だから。
どれだけプログラムの勉強しても仕方ないよ。

>>164
矩形波を正確に実現するには、周波数が無限大の領域まで必要だけどな。
わかってるのかなwwwwwwwwwwwww

>>164
波を数学的に定義してみて

またこの話題かよ
流体シミュレーションとかじゃない限り、適当にフーリエ変換した波で十分だろ

時間発展はどういう計算になるわけ？

>>166
また鼻糞かよ
おまえの脳味噌に蛆でも湧いてるんじゃねの？

>>170

ボーンデジタルのReal-Time Shader Programming 日本語版って
どの程度のレベルの本か分かりますか？
できれば目次とか知りたいんですけど、どこかに載ってないかな

>>172
なんでそのまんまの言葉でググってみないの？

すみません。クラウドのような顔を書きたいのですが
フラッシュで作れますでしょうか？
あれは何で書いてあるのでしょうか？
よろしくお願いいたします。

シャドウマップで作った影のソフトシャドウってVSM以外で良い方法はありませんか

>>174
CG 板へ池
http://pc11.2ch.net/cg/

【初心者も】CG板総合質問スレ【こちら】Part14
http://pc11.2ch.net/test/read.cgi/cg/1232511462/l50

いい加減煽りに反応しなさんな

>>175
VSM以外だとESMとか？

東京行ったついでに寄った本屋でGemsを立ち読みしたら、
（LBSと比較し）関節をつぶさない変形のテクニックとして、
球面関節ブレンド処理（名称違うかも）っていうのが載っていたのですが、
これはDouble Quaternionとかその辺と同じものなのでしょうか？

時間が無くてちゃんと読めませんでして、もし違うなら大枚はたいて取り寄せてみようかなと。
ぐぐっても名称が違うのか出てきませんで、ご存知の方いらしたらおながいします。

>>179
球面関節ブレンド処理については知らないですが、
GPU Gems1から3まではnvidiaの開発者向けサイトで無料で読めますよ。

違うGems本だったらごめんなさい。

>>180
すいません、そういやそのGemsもありましたね。
Game Programing Gemsの方でしたが、そちらがネットで読めるとは知りませんでした。
これはこれで嬉しい。貴重な情報ありがとうございます。

最新の情報を追いかけていたいなら
田舎なんか棄てて、東京に来ればいいのに

皆が皆東京に住めるわけでもないだろ
これだから50Hzで炊いた飯食ってる奴は・・・

最新の情報を追いたいなら英語のサイトを巡回しまくるのが一番効果的。
東京来いなんて馬鹿馬鹿しいこと言うなよ。これ以上住みにくくしてどうすんだ。

いやいや、先進的で有能な奴は東京に来ればいいし
そのように在りたい奴も東京に来ればいい
東京から脱落した者が田舎に住めばいい

現に、そういう体制は整いつつあるわけだし
その方が色々と効率的だし
この流れは誰にも止められんと思うがねえ

ニュ速+のスレだからすぐに落ちると思うけど

【社会】農家深刻！ニセ“嫁”詐欺…悪質お見合い業者の実態
http://tsushima.2ch.net/test/read.cgi/newsplus/1245067936/

東京からの交付金を貰って、やってる事は詐欺とレイプ
農家ってのはいいご身分だね

こいつ日本語読めないの？

まあ、変な人はあまり相手にしないほうがいい
疲れるし、時間ももったいないしね

東京に住んでるというだけで優越感感じるタイプだな。まあザコキャラ

CGのために引っ越せるならアメリカに引っ越すといいよ

三角形と直線が交差しているか判定する手法を調べていて、
↓のような論文を見つけたのですが、section3に出てくるcullingとはなんですか？
http://www.cs.virginia.edu/~gfx/Courses/2003/ImageSynthesis/papers/Acceleration/Fast%20MinimumStorage%20RayTriangle%20Intersection.pdf

自分は物理のシミュレーションをやっている学生でコンピュータ・グラフィックのことは良く知らないので、
そんな人間にも解る様に教えてもらえるとうれしいです。

見てないけどcullingといったら通常ポリゴンの裏は描画しないこと

>>191
その論文の中でback face cullingって書いてあるじゃん。意味は>>192の通り。
その他にもview frustum culling, occlusion culling, portal culling等
色々あるけどね。

http://gamealgorithms.tar.hu/
ここの １３章近辺に書いてある

なるほど、わかりました。
ありがとございます！！

LLLアルゴリズムをCでプログラミングしてます。
参考ページや本を見ているのですが、
二次行列で書いてあったり一次行列で書いてあったりしてよく分かりません。
ヒントをください。

> 二次行列で書いてあったり一次行列で書いてあったりしてよく分かりません

この時点で丁寧に説明してもムダな気しかしない

すみません…。
行と列を入れ替える作業があるから、２次行列だと思ってたんです。
そしたら、別の本にはＬ＝｛b1、b2…｝みたいに書いてあって。
混乱してます。

ＬＬＬアルゴリズムは、実数を出来るだけ高さの低い有理数で近似するものだということ。
Ｌ＝｛b1、b2…｝っていうのは、基底列ベクトルで、これから直交基底を求めるんですか？
あと、携帯からでアドレスコピペできませんが、［指定されたμ(k、l)について絶対値μ(k、l)＜＝１／２を満たすようにする］って意味がわかりません。

4次元同次座標から3次元座標への変換について質問です。

通常4次元同次座標から3次元座標へ変換する場合、

V = (x/w, y/w, z/w)

としますが、wが負の値になったときもこれで問題ないのでしょうか?

現在勉強のためにスキャンラインレンダラを書いているのですが、どうも座標変換時に
wが負の値になると描画結果がおかしくなってしまい、ポリゴンがひっくり返ってしまいます。
また、wが負の値になった時点でポリゴンを消すようにすると、該当する頂点が含まれる
ポリゴンが完全にニアクリップ面を通り過ぎる前に消えてしまいます。

OpenGLに変換行列を入れて描画したり、座標変換後の同次座標をglVertex4で描画してみると
正しく描画されるので、使用する行列が間違っているというわけではなさそうですが…

「ｗ <= 0.0」はカメラの前にピクセルがないって事だぞ。

追記
カメラのニア平面でポリゴンをシザリングしない限りは
ポリゴンごと描画を省くしかない（例：初代プレステ）

>>200,201
ありがとうございます。
シザリングについて調べてみて、どういったことを行うか、というのは理解できたのですが、
4次元同次座標のまま平面との交差判定を行うにはどうしたらいいのでしょうか?
wが負の値の場合、3次元座標に変換した時点ですでにおかしくなってしまうので、
4次元同次座標のまま交差判定を行う必要があると思うのですが、調べ方が悪いのか、
やり方が出てきません。

普通にカメラ空間で平面と直線の判定してポリゴン分割しろ。
ただの空間図形の話だ。

>>202
あるプロジェクション空間の座標が画面内にあるかどうかは、
w*画面サイズ と比べればよい。
またいでいたら交差している。
できれば、プロジェクション空間を ( -1, -1, 0 ) - ( 1, 1, 1 ) と
しておくと、画面サイズを乗算する必要が無くなる。
他にも理由があるので、画面サイズを乗ずるのはラスタライザ
に送った後の方が良いと思う。
プロジェクション空間への変換マトリクスが適当なら、Z がニア
平面にあるときに w が 0 にならないはずだから、三角形の
どれかの辺が (-w, -w, 0 ) - ( w, w, w ) をまたいだら、その点
でカットすればよい。ただしここで頂点ごとに w が異なることに
注意。x なり y なり z なりが、w だったり -w だったり 0 だった
りになる点である。
なお、この処理は平面方程式を構築した後にスキャンライン
ごとに行っても構わない。
（もしかしてパースペクティブコレクションはまだだったりする
　のだろうか）

何か少し自信ない。勘違いや漏れがあったら申し訳ない。

>>203,204
返事が遅くなってしまい申し訳ありません。
いろいろ試したところ、どうにか>>203の方法でシザリングすることが出来ました。
ありがとうございました。

>>204
一応テクスチャとテクスチャのパースペクティブコレクションは先に実装してました。
現在は変形終了後に画面サイズに合わせていますが、ラスタライザに送ってから画面サイズを
掛ける方がいいというのはどのような理由があるのでしょうか?

2D Spriteライブラリ作りたいです
なにすればいいの？

スタディとコーディングかな

>>207
参考文献じょうほうよこしやがれください

ポリゴンにテクスチャ貼ればいい。

googleに知りたい言葉を並べればおｋ

>>208
鼻糞死ね

>>208
一冊で用が済む本は無いから、目に付く限り近場の図書館にリクエスト出して全部読みなさい。

age

過疎ってるな

こんな過疎っているときは
レイトレvsラスタライザ
格子法vs粒子法
GPUレンダリングvsCPUレンダリング

みたいな熱く盛り上がる議論を繰り広げたら楽しいんじゃないだろうか。

格子法vs粒子法希望

gems6ほしい

格子法は粒子法と比較すると計算しやすそうだけど、流体、気体のシミュレーションにしか使えないというイメージがある。
粒子法は近くにある粒子や接触している粒子のペアを探したりするのが大変そう。

その２つは根本的に計算の方法が違うんですか？
その計算手法の特性に合わせるだけでしょうし。

またもや知ったかか

過疎ってるっていうから書き込んでみたのに早速それか。何が議論だおまえはアホかｗ

>>219
根本的に違うよ。
格子法は空間を規則的に分割して計算。
粒子法はシミュレーションしたい物体を分割して計算。
レイトレとラスタライズ並みに違う計算方法なんだよ。

格子法でも剛体シミュや布シミュが絶対無理ってわけではないけど
実用的に使うには無理というか、無駄が大きくい。

h木で不均一空間分割すればそれなりに軽くなるけど粒子法がいい場合もあるね

>>222
ならその２つで何の議論ができるというんだ？

4x4の行列からx,y,z の回転角度を求めるにはどうすればいいのでしょうか？

何故、4x4かを考える。
ヒント）クォータニオン

すげー

重み付きのサブディビジョンサーフェイスの
効率いいアルゴリズムがピクサーに特許取られててムカツク。

ってのはひょっとして時代遅れ？
何か代わりになるアルゴリズムってある？

至高のシーン管理術について

struct node
{
virtual void draw() = 0;
std::vector<node*> children;
};

std::vector<node> scene;

しーん

>>230
これ最高だな。
nodeのインスタンスはどっか適当なメモリプール作ってallocator作ればいいわけだし。

なぜ
std::vector<node*> scene;
ではいけないのですか

>>233
特にそれでも問題はないよ。

シーンマネージャーを作って、ゲームループから帰ってきたScene*を次に実行させる
面倒なのでスマポで管理させて古いシーンは上書きで勝手に消えるようにする

ｶﾞｯ

??????

はぁ･･･
シーンを現す変数はいらねーから、

誰一人そこまでたどり着いていないとかゴミかよ、ゴミが

とりあえずツリー構造の管理方法考えてみればぁ？？？ｗｗＷＷｗｗ

シーン管理、ツリー構造は3D関連のアルゴリズムではない。

>>204
↑ハァァアァァァァァァァァアァァァァアァアァアァアァァ？？？？？
さっさと死ねばいいんじゃね？
マジでゴミなんだな

>>239
データ構造はアルゴリズムの実装のし易さや、実行効率に影響するかもしれないので
まったくアルゴリズムに関係無いとは言い切れないだろう。

アルゴリズムとデータ構造は切っても切り離せない関係なんだょ

zバッファを拡張して透明とか表現できんですかね？

透明「感」を出すだけ、ならたやすいけど
ちゃんとやりだすと光線追跡になるのでたいへん。

CG って高校幾何で済む部分と、
学部生でも工夫でどうにかなる部分と
現実的な時間でテキパキ処理するためのアルゴリズムみたいに博士論文テーマになりそうな部分やら・・
どこまでやるか、で悩むよね。自分は第２で止まってしまった。

t

>>242
どういう風に拡張するの？

透明なポリゴンはZバッファに描画しないとか、
透明フラグも立てて、最後まで残っていたらそこんところをぼやかすとか
透明ポリゴンだけソートして最後に描く(?)とか。
AAも絡むと凄く面倒だと思う。

>>246
ハードの話なのかソフトの話なの？
どこのレイヤの話で、それで誰がどういう場面で得するの？

なんか小難しいコト言ってみたかっただけなんでしょ？

代表的なライブラリとかハードウェアの実装を調べてみようとかいう気なんてサラサラないよね。
面倒だもんね。

でもそれでいいんだよ。
2chなんだから。
そういう下らないこと沢山書いていきなよ。
ついでに気が向いたら PowerVR のことでも調べてみなよ。

246=242と言うわけでもあるまいに。

242じゃないよ。
PowerVRはＺバッファ持たないだろ。
ぜんじーの本でも読むよ。

>>249
チップ内に少なくともタイル１枚分はあるだろ。

242のはAバッファのことをいってるのか？

242に聞けよ

order independent transparencyの話かと思ったけどそうではない?
ttp://www.geeks3d.com/20100610/3d-programming-fast-a-buffer-algorithm-demo-using-opengl-4-0/

あそびでやってるだけでことごとく自作コードなので
ライブラリな事はしらないけど・・・

とある要素を描くときに、その時点で
一番手前にあれば、0.5 x (その要素の色) + 0.5 x (それまでの色) 、
そうでなければ 0.1 x (その要素の色) + 0.9 x (それまでの色)
とかすればzbuff 法でつくったものにすこし手を加えるだけで、
順番不問でいちおう透明感を出せるコードは作れると思うが。比率は適当にいじって。

バカ発見

世の中のほとんどは馬鹿なんだが
実際問題として
自分がその馬鹿の一人だと
気付いてる香具師は少ない

かっこいい！
ってレスが欲しいのだろうか・・・・へんなの

>>253
本当にそれやってるの？
だったらおかしいところに気づくよね？

阿呆言う香具師が阿呆

>>253 のやり方でそれっぽいのは作れた。
・・ポリゴンの数増やしたらぼやけまくりになったがｗ
少数ならこれでいいとおもうよ。>>257 は複雑な状況を考えてるの?

馬鹿発見

ハフマン木を作成する際、偏ったデータの場合、枝の階層が深くなってしまい、結果刈りを行う処理が発生するということですが
その理由を説明してもらえませんか？

>>281です、スレチでしたごめん

3Dグラフィックスのための数学[改訂版]　大川善邦
っていう本読んだ人いないかな？
70ページの問題3.12の回答のマトリックスの2行目ってこれであってるの？

本を特定せず、わからないことを3行にまとめて聞いたほうがいい

{ cos(b), 0, -sin(b) }{ cos(c), sin(c), 0 }
{ sin(a)sin(b), cos(a), sin(a)cos(b) }{ -sin(b), cos(c), 0 }
{ cos(a)sin(b), -sin(a), cos(a)cos(b) }{ 0, 0, 1 }
すいません、正しい書き表し方がわからないんですが
3*3の2つの行列の積のつもりです
この計算結果を教えて頂きたいです
童貞は排除していただいてかまいません

>>263
3.10 と 3.13 は間違ってるみたいよ
ttp://www.kohgakusha.co.jp/support/3dgmath/index.html

>>265の解答が
{ cos(b)cos(c), cos(b)sin(c), -sin(b) }
{ sin(a)sin(b)cos(c), -cos(a)sin(c), sin(a)sin(b) }
{ cos(a)sin(b)cos(c)+sin(a)sin(c), cos(a)sin(b)sin(c)-sin(a)cos(c), cos(a)cos(b) }
なんだけど2行目ってコレであってる？

>>265
> { sin(a)sin(b), cos(a), sin(a)cos(b) }{ -sin(b), cos(c), 0 }

これ { -sin(c), cos(c), 0 } じゃねーの？

どっちにしろ>>267は変だけど

>>268
のとおりだと思う
cos(b)cos(c), cos(b)sin(c), -sin(b)
sin(a)sin(b)cos(c)-cos(a)sin(c), sin(a)sin(b)sin(c)-cos(a)cos(c), sin(a)cos(b)
cos(a)sin(b)cos(c)+sin(a)sin(c), cos(a)sin(b)sin(c)-sin(a)cos(c), cos(a)cos(b)

>>268
> { sin(a)sin(b), cos(a), sin(a)cos(b) }{ -sin(b), cos(c), 0 }
すいません-sin(b)は自分のタイプミスでした・・・
{ sin(a)sin(b), cos(a), sin(a)cos(b) }{ -sin(c), cos(c), 0 }
正しくはこうです
>>269
計算ありがとうございます
自分もそのような解答になりました。
とりあえず本の解答は誤字っぽいのでスルーして進めようと思います。

これ見ただけでどんな変換しようとしてるのかわかる人

Z軸回転じゃん。

aとbは

レベル低すぎ
出直して来い

>>273
極座標だろ

ただの行列計算に親切に回答してあげる人もいる

Maxima使っとけ

回転を表したクオータニオンから逆に各軸X・Ｙ・Ｚを基点にした３方向の角度はどうやったら計算出来ますか？

ただし、クオータニオンの軸は0,0,0を通るはず

適当な数字を回転させてみればいいのか

クオータニオンで行列を回転させる式、で、
1 0 0
0 1 0
0 0 1 を回転されたもの、が求めてるものかな？

それともオイラー角を求めたい？

オイラー角とか言われてもよくわからないんだけどっていうレベルなんですが
飛行機を飛ばすゲームみたいなユーザー操作でぐるんぐるん回すやつだと
クオータニオンの方が管理しやすいらしくてクオータニオンでやってるけど
簡易マップみたいなのに今どこにいてどの方角を向いてるのかを表示したくて
そうするとＹ軸まわりの回転角度が欲しいんですよね

281じゃないが、
その飛行機がZ軸向いてるなら、クオータニオンの行列で(0,0,1)を変換すれば向いている方向は出るし
ロールが欲しければ(1,0,0)を変換すればいい

>>278
右手系か左手系か、
オイラーで回す軸の順番とかでいろいろ変わる。

左手系 x-y-z でよければ
http://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles
参照

アルゴリズムにもよるけど、
右に100度向いているクォータニオンをオイラー角に直したら、
左80度向いて180度宙返りあーんどバレルロールとか
アクロバチックなオイラー角になる可能性もあるので注意。

方位計が目的ならこれは問題あり。

こんにちは。
メッシュの覆う直方体を求めたいのですが、
その体積を一番小さい直方体を求める手法というのは
あるのでしょうか？

各軸の最小値と最大値を求めるだけだろ

>>286
常に最適なものが見つかるアルゴリズムはない。
ゲームプログラミングのための3Dグラフィックス数学
4939007375
に、頂点の分布から主要な軸を推定する方法が載ってたような。

>>287
説明が足りませんでした。
各軸ですと例えば乾電池が斜め向いていると、囲む直方体が大きくなってしまいます。
乾電池は円柱ですからほぼ同じ大きさになるような直方体の求め方があるのかなと思い
質問させていただきました。

>>289
その件が>>288が紹介した本に書いてある
「主成分分析　3Dグラフィックス数学」でググるといくつか見つかるかも

>>289
その辺の話は、AABB OBBでググるがよろし。
剛体なら先に求めておくといい。

スケーリングや回転を適用したままエクスポートされた３Ｄモデルがあるんですが、
ゲームで使う前に頂点データにそのモデルの変換行列を適用して単位行列にしたたほうがいいですか？

>>292
どちらでもいい

ロードしてゲームで処理するシステムを作る側の人間が
使いやすいと思う方でやるべき

>>293
ありがとうございます＾＾

誰か教えてください。
アルゴリズム入門の授業なんですが
・性の小数部分を求めるサブルーチンＤＥＣのフローチャートを書け
・サブルーチンＤＥＣとサブルーチンＩＮＴを使って入力した正の実数の小数点以下を切り上げた
　整数を表示するフローチャートを書け
お願いします

金払って入門してるんだから、わからないことは教師に聞くべき

>>296
その教師だったりして

「性の小数部分」が気になる件。
それで3Dなんだろ？なんか燃える

マジな話、>295の条件だけでフローチャートなんて書けないよね。
小数部分を求めるのに使えるサブルーチンが提示されていないんだから。
例えば整数化のサブルーチンを使えるかどうかさえ分からない。
それにしても、なんでDECなんだろう……

decimal representationからかねえ＞DEC
これチャートつーか、分岐ある？

ビット演算すればいいのでは？
まあCPU指定しないと、いけないけど

1未満になるまで1を引きまくればいい

オブジェクトの向いてる方向をベクトルで表現したい場合って
オブジェクトの前方向と右方向の２つのベクトルで十分だよね？３つめの上方向のベクトルまで必要なときってある？

>>303
「向き」は球面座標系で表現できるから、情報量としては２次元で十分

向いてる方向と直行する面上に回転させた「姿勢」も表現したいのなら、
３次元分の情報が必要

>>303
表現するだけなら2つで十分。
外積一発で出るんだし、ついでに出しとけって感じなんだろう。

そのオブジェクトの向いている方向に座標系変換するなら、連立方程式にするのが簡便なので、その成分として3つ目のベクトルも使う。

前と右よりは、前と上のことが多いと思う。

>>303
冗長な表現を用いる場合は、誤差が蓄積して破綻しないように正規化が必要になる。
ベクトル2本や3本だと、それらが直行するように常に保たないといけない。

まぁ、そんなこと気にするのは固定少数使ってた時代の話かもしれんがw
floatなら正規化なしで1日くらい回し続けても、目に見える破綻が起きたことはないな。

自分で計算して作った3Dポリゴンを3Dファイルにして他のソフトに渡したいんですが、
何かいいライブラリか参考サイトありませんか？
なるべく多くのソフトで使われていて簡単に扱えるフォーマットがありがたいです。
環境はDirectX9とC++です。

>>307
X
OBJ
COLLADA

この辺りじゃないか

紅だー！！！！！

>>308
ありがとうございます。
COLLADA DOMとかいうのがあるみたいなので、それを調べてみます。

【速報】２ｃｈ全鯖死亡　（※嫌儲以外） ★2
http://awabi.2ch.net/test/read.cgi/poverty/1327139457/


【速報】韓国からの攻撃だったことが判明！！！！！
http://awabi.2ch.net/test/read.cgi/poverty/1327146261/

★414 名前：ポンギツ★[sage] 投稿日：2012/01/21(土) 20:01:08 ID:????
韓国から過剰のアクセスがあるみたいです。
今。対応中です。

3Dの2つのベクトルから回転角度と回転方向を得るにはどうすれば良いですか？

>>312
回転軸は外積で、2つのベクトルがなす角は内積で得られるよ。

>>313
a.x=0.0f;
a.y=1.0f;
a.z=0.0f;

b.x=1.0f;
b.y=0.0f;
b.z=0.0f;

これの外積は全て0.0fになってしまってうまく行きません。

>>314
その場合外積は0にならんでしょ。

>>315
？
具体的な計算手順を教えてくれませんか？
どうやっても0になる

二次元ベクトルの外積をそのみまま拡張して使ってる？
三次元ベクトルの外積はxyzwの結果になるやつだよ
式はググれ

>>314
c.x = a.y * b.z - a.z * b.y = 1 * 0 - 0 * 0 = 0
c.y = a.z * b.x - a.x * b.z = 0 * 1 - 0 * 0 = 0
c.z = a.x * b.y - a.y * b.x = 0 * 0 - 1 * 1 = -1

ありがとうございます。

AABBで各頂点を比較するやり方だと互いに突き抜けている箱の
当り判定を正確に行えませんよね？

>>320
ちゃんと、
AABBとAABB
AABBとOBB
AABBと凸面体一般
AABBとポリゴン
AABBとその他
のどの交差検出の話なのか明確にしてから質問しないと誰も答えてくれないよ。
Separating axis theoremとかGJKでググっておけばいいと思うけど。

AABBのやりかた間違ってるだけじゃね
何にたいしてどんな比較やってるか書いて

AABBとAABBです。
なんて言えばいいんですかね。
十字架のようにクロスしていて片方はちょっと大きいです。
そうすると頂点は一切接触していないので当たっていると判定されないのです。

AABBだよね？
a.min.x<b.max.x かつb.min.x<a.max.x
yとzも含め全ての軸で同様の状態なら重なってる
違ったら重なってない
終わり

http://www.dotup.org/uploda/www.dotup.org2597301.png.html

だから、その方法だとこういうのは当たってると判定されないよねって聞いてんの

判定されるだろ

>>320
判定されないという計算を晒してみた方が早いと思う

２次元に落としてロジックを試してみろ

これくらいも自分で解決出来ないのなら正直3Dとか向いてないからさっさと手を洗った方がいいぞ
人間には適性てのがあって努力してもできない事があることを理解したほうがいい

>>329
性格の腐った奴だな
お前は今まで多くの人間が携わって蓄積されてきた様々な3D技術を一人で開発出来たのか？
出来たという自信が無いなら3Dなんてやめろ

AABBの衝突判定は蓄積とか3D技術とか言うレベルじゃないと思うが…
自分の頭で衝突してる・してないが判断できるんだからそれを式で表現するだけじゃん。
いやもちろん、自分の頭で判断できるけど式ではどうしようかっていうのが
世の中にはたくさんあるけど、これはね。というわけで327が近道かと。

>>330
劣等感の強い奴は常に誰かを批判や恫喝していないと、
アイデンティティを保てなくて死んでしまうらしいよ。

子供の頃のイジメ役の子供も、劣等感の裏返しからイジメている奴は、
3, 40の大人になった時に鬱になって、自殺することが多いらしい。

こいつもきっと劣等感の裏返しだから、その内、この世から居なくなるよ。
自分で勝手に。

だから、無視無視。

これだけの話で「性格の腐った奴」とか「劣等感の強い奴」とか言っちゃう人達って……
つーか、>330=>332?

>>330
優しくしてほしかったら2chになんてくるなよ。

>329 == >333 == >334　は、Trueだよな！

よく手を洗え

３Dに向き不向きとか言ってるアホがいる事に戦慄を覚えた

ぶっちゃけ根気良くやってりゃ誰でも出来るよな

根気よくやってもできない奴には不向き

普通、大人になってからは、できないものを根気よく続けられない

従って、根気よくやれているのなら、できていない事はあり得ない
他人よりも進むスピードが遅いだけ、前へは進んでいるから安心して良い

それでも、もう少しスピードを上げたいのなら、急がば回れだ
基礎中の基礎から勉強し直してみて、
ひとつひとつ、どこまで理解できてどこから分からないか、
全方位、理解の最前線を確認して明確にすべし
そこを明確にすれば、次に何をどう勉強すれば前進できるか分かるから、
計画も立てられてスピードアップすること間違いない

確かに、ベクトルを理解するのに、中学の幾何を復習するのは実のあることだ！

空間内で、多角形と直方体の交差判定をしたいです。
直方体の方は各辺が軸に平行として構いません。
今のところ多角形を三角形分割して三角形と直方体の交差判定をする
しかないかと思っていますが、三角形と直方体の交差判定も、
いまいちな方法しか思いつきません（三角形を「ペイント」する方法）。
定番の方法などあれば教えてほしいです。

前にこういうの参考にいろいろやったりして、リアルタイムにハードもソフトも進化してく時期だったから楽しかったんだけど
最近はなんか新しいのが無いなって
http://www.t-pot.com/program/history.html

今は何が熱いんだ？

>>342
GJKとか三角形vs三角形でやる方法とか

gjk
http://angra.blog31.fc2.com/blog-entry-115.html

俺のソースコード晒そうか？AABBツリーでしかも交差した線をなぞってわっかを取得できるやつ
Delphiだけど

問題点は浮動小数点だから、整合性が保たれないことがあるんだよな。わっかがわっかにならないことがある
これに対処するアルゴリズムはいまだ思いつかない

つまり浮動小数点の比較回数を理論上の最小にすれば解決するんだよな

こっちの線 vs 三角形とこっちの線 vs 三角形が浮動小数点の誤差で別の方向に転がると破綻する

eri-45.3>or>45.35=uiui

>>345
いやさ。三角形と直線と判定するときに
ある三角形と直線が交差したとする(でも線上でぎりぎり)

隣の三角形と直線を判定するときに、一辺に関してはもうどっち側か判定してあるわけじゃん
この例だと向こう側。だからその二度目の比較を回避しないといけないなって

ちょっと考えてたらアルゴリズム思いついた。久しぶりに書こうかな

いや・・・　DirextX (左手系)だろうが、OpenGL(右手系)だろうが
なかなか超えられない壁がある。

クオータニオンのi,j,kはどの座標系の基底ベクトルに対応してるのか、
とか基底変換行列、回転変換行列、座標変換行列の関係とか。
の違い

>>347

ごめん.最後の行はゴミ

誤爆じゃないのかよwww何に対してのレスだ？

>>343
> 最近はなんか新しいのが無いなって

新しいというのが何を指しているのか分からないが、
たとえば下記のブログの「Programming」カテゴリーで紹介されてのは、
その時々での結構新しい技術だと思う
http://masafumi.cocolog-nifty.com/masafumis_diary/

ただ、そこのは紹介だけだから、実際のコード例なんかは
紹介してる技術のキーワードを元に海外のサイトを探した方が早いと思う

あとは、SIGGRAPH なんかを追ってもいいと思う

西川善司、手術成功しちゃったのか。

>>351
ゼンジーのひと手術したのか。
シェーダー本買ったけど、初心者にわかりやすくてよかったんで、もっと書いて欲しい。。

>>344 ありがとうございます。gjkのサイトわかりやすい。知らなかっ
たので勉強になります。考えているのは多面体同士でなくて片方多
角形なんですが、多分gjk使えますね。 直方体にgjkは大掛かりな気
もしますが、ミンコフスキー差を使うのは簡明なので、これで考え
てみます。

Delphiでわっかの取得というのも魅力的ですが、Delphiはわっから
ないので今回はお気持ちだけ受け取りました。

Geometric Tools for Computer Graphics
っていう本に書いてあったseparating axis theoremの方がGJKよりシンプルな気がする。
片方の図形がAABBなら計算を簡単にできそうだし。

このサイトにあるライブラリには
よく使う図形の交差検出や距離を計算する機能がまとまっているので
使えるかも。
http://www.geometrictools.com/

GJKもseparating axis theoremも凸面体の交差判定に使うアルゴリズムだと思うけど
どう使いわけたらいいんでしょうか？

separating axis theoremってOBB同士でやったことがある。GJKは理解不能
そりゃあ原理を理解することはできるけど、それを速くコーディングするのはちょっとアクロバティックじゃないか？

三角形vs線分でやるのが無難。凹凸考えなくていいし

OBBは直方体だからseparatingなんちゃらで射影する計算が少し減るんだよな

>>354 http://www.geometrictools.com/ すごいですね。サンプルコー
ドに数学の説明もあればもっと嬉しいですが。現状では、AABBと多
角形の交差判定の、次の方針を考えています。間違えてなければい
いんですが。

(1) 多角形がz軸に平行ではないときのみ考える。そうでなければ軸の役割を交換。
(2) 多角形の載る平面Pの方程式にAABBの8頂点を代入し、
符号を比較することでAABBと平面Pの交差判定をする。
(3) 交差していれば、平面PとAABBの12辺との交点をあれば求め、それらを
xy平面に正射影し、その凸包Xを求める (XはAABBの平面Pによる切断面の正射影)。
(4) 多角形のxy平面への正射影Qと、凸包Xの交差判定をする。

凸包の求め方と(4)の判定をまだ考えていませんが、2次元に落ちて
いますし勉強してみます。

>>357
ここに説明全部あるぞ
http://www.geometrictools.com/Documentation/Documentation.html

なんでAABBと判定するんだ？AABBの利点って回転ごとに計算しないといけない代わりに
AABB同士だと爆速ってことにあるんだけど、AABB vs 三角形だとそこまで速くはならない
6回の比較で済むんだよ。18命令くらいで終わる、しかも分岐無し

汎用的な、三角形vs線分の関数をまず作って組み合わせたほうが楽だし、この場合オーバーヘッドもそんなに無い

dependency chainも無しな。cpuによるけど、20クロックじゃないかなって予想

>>358
bounding boxを考えたわけではないので、AABBという語は誤解させ
てしまいました。辺が軸と平行な直方体と読みかえて下さい。それ
しか考えていません。

> 汎用的な、三角形vs線分の関数をまず作って組み合わせたほうが楽だし、

について、直方体として、頂点が (a,b,c) (a,b,cは0または1) とい
う1辺が1の立方体を考えたとき、
三角形 (1/3, 1/3, 1/2), (2/3, 1/3, 1/2), (1/3, 2/3, 1/2) とか、
三角形 (-1/3, 1/3, 1/2), (4/3, 1/3, 1/2), (1/2, 4/3, 1/2) とかも、
立方体と交差していると判定するわけですが、これらも含む一般の
場合に、三角形とどの線分との交点を調べるのか理解できていませ
ん。あまり考えていませんが自分で考えろってことですね。

それが分からないで3Dやるのはきついぞ。高校1でも分かる

そういうことか

直方体を三角形の集合としてみるじゃん
つまり一般に三角形の多面体同士の交差判定するのよ

ふたつの多面体をAとBとしたときに

Aの三角形全て vs Bの線分全て
Aの線分全て vs Bの三角形全て

を調べればいい。交点もついでに全部計算できる

直方体(AABB)の内部に三角形がすっぽり入っていて
三角形とAABBの面の重なりが無い場合は?

>>362
理解できました。ありがとうございます。しかし、>>360 の1つ目の
例、つまり、直方体の内部に完全に三角形が含まれる場合は交差と
判定されません。

しかし、実際に交差するものの、三角形が直方体の内部、外部にま
たがらなくて交差と判定されないのは、こういった完全に含まれる
場合だけですから、それを別にチェックしておけばいいだけですね。
がんばってやってみます。

あう、リロードしてなかった。眠い

一般に、点が多面体内にあるかどうかを判定する関数を作る
実装は、その点から任意の直線を引いて交差するか調べる。面の向きが分かってるから内外が分かる

そして多面体A上のどこかの点を選んでBの中にあるかどうか判定する

質問ですが、ある物体がx=30,y=50,z=0の位置にあるとします。
それに回転行列を掛けた後の3次元位置をどうやって算出するのかわからないのですが、
教えてください。

回転行列を T とすると、行列の乗算 [30 50 0]T をするわけだけど、
この説明じゃわからんだろうし、そもそも何がわかんないわけ？

ある行列AとBがあって、Aは

1,0,0,0
0,1,0,0
0,0,1,0
30,50,0,1

Bは

0.921061,0.389418,0.,0
-0.389418,0.921061,0,0
0,0,1,0
30,50,0,1.000000

Aの三次元位置は30,50,0ですぐわかるんですがBの三次元位置はどうやって算出するのかわからないのです。

>>367
普通に位置ベクトルと行列の乗算をするだけ。
高校あたりの数学で習う行列の計算そのもの。

ただ、実際には3D関係だと計算の都合で行列は4*4を使うことが多いので
その場合は位置ベクトルをx,y,z,1に拡張して使う。

1点補足。

ベクトルと行列の乗算をした後に、ベクトルの4番目の成分が1以外になったら
全ての成分をその値で割る必要がある。4番目が常に1になるようにする。
単なる回転や平行移動では1のまま変化することはない。

詳しい話は、同次座標系でググって。

この場合は

30,50,0,1　に　

0.921061,0.389418,0,0
-0.389418,0.921061,0,0
0,0,1,0
30,50,0,1

を掛けるんですか？
それとも

0.921061,0.389418,0,0
-0.389418,0.921061,0,0
0,0,1,0
0,0,0,1

を掛けるのかな？

ここで聞くことじゃないんだよね。3Dじゃなくて数学の話でしょ？それも高校生レベルの
どの分野でも文系って害悪。理系でオーディオの迷信信じる奴は皆無だし
信じてたらそれすなわち文系だしなwww

30 50 0 1 が縦か横かで、そもそもどっちか片方からしか掛けられんだろ？
アメリカとヨーロッパで流儀が違うから、使ってる教科書か何かで確認しろ。

とりあえず行列のかけ算覚えよう。
手計算させたら理系でも泣き出すぐらいの、たぶん思ってる以上に結構面倒な計算だぞ？

次に座標を行列にする方法を覚えよう。極座標じゃないぞ直交座標だぞ？
行ベクトルと列ベクトルがあるが、掲示板で説明求めるなら列ベクトルにしとき。

回転行列が行ベクトル用か列ベクトル用なのか書いてない奴のWebサイトは相手しなくていい。

原発は再稼動すべきだよな

黙れ朝鮮人

>>369
Ｂは位置30,50,0で回転している。物体の原点(0,0,0,1)を掛けてみればいい

クォータニオンで検索すれば良いのでは？

>>379 余計混乱するからやめれ

アホみたいなこと言わせたら俺なかなかのもんだが、
クォータニオンみたいなもん思いつく学者さんってスゲーな。
しかもそれが、良く分からんけど便利に使えてるっていう現実。
人間スゲーな。

そのあたり興味あれば「ハミルトンの四元数」って本がお勧め

スキンメッシュの頂点を移動させるには同次座標変換を使うのかな？

お前らって本当数学苦手なのな
なんで3Dのスレで数学の話題になるのwww

計算量がどうだのキャッシュがどうだのGPUとの転送速度がどうだのならまだ分かるが

ゴミ溜めでまともなレベルの議論期待すんな

3D のアルゴリズムで数学の話が出ないわけがないだろ。
これだから厨ジサカーは困る。

アイデア -> 数学でごにょごにょ -> 実装
数学でつっかかってたらきついだろ

アルゴリズムのスレじゃないのかよ！転送速度とかなんじゃそりゃ

動けばいいってもんでもないでしょ

答えられないからって話題をすり替えんなよな

答えるってどれに？

>>383

>>392
なにいってるのかさっぱりわからない
ボーンの仕組みわかってるのか？

頂点座標を幾何変換で
頂点座標×ボーンオフセット行列×座標変換行列×逆ボーンオフセット行列
するんだよね？

いくつかの行列を線形結合するだけじゃん。同字だのなんだの考えなくても、線形ってことだけ知ってれば

文系は何やらせても邪魔

>>394
判ってるのになんで聞くの？

c++用obbtreeのpublic domainなclassソースってどこにあります？

今はまだない

あるベクトルzが与えられたとき、ベクトルxとyを求めたい。
ただしx,y,zは互いに垂直であること。

要は1本のベクトルをz軸としてローカル座標空間を作りたい。
何か良い方法はありませんか？

適当なベクトルvを作る (ただしz≠v)
zとvを外積してxを作る
zとxを外積してyを作る

>>401
そのvはどうやって作れば良いと思いますか？
z=vだったとき、何からv2を作れば良いでしょうか

昔のメモを持ってきた。

X cTh　　　0　　-sTh
Y -sTh*sPh　cPh　-cTh*sPh
Z sTh*cPh　sPh　cTh*cPh

sTh,cPh とかは、sinθ、cosφね。
ベクトルZ からθ、φを求めれば、互いに直交するX、Zを得られる。

カメラワークとかによく利用してたな。

> 直交するX、Zを

X、Yね。

>>402
とりあえず適当なベクトル v を使った >>401 の計算をノートにいっぱい書いてみろ。
そうすれば v をどう選べば最終的にどういうローカル座標系ができるか分るようになる。

あと、>>401 は明言していないが、外積を計算する際、被演算子の順は全ての例で統一しろよ。
でないと混乱するからな。

質問したら良い方法が浮かびました。
とりあえず{1,0,0} {0,1,0} {0,0,1}の3ベクトルと内積をとり
絶対値が最も小さいものをvとします。

>>403
最もスマートそうな方法ですが、角度を求める方法がわからないので
次のステップで挑戦します。ありがとうございました。

>>405
そうします、ありがとうございました。

> 最もスマートそうな方法ですが、角度を求める方法がわからない

おいおい

単位ベクトル同士の内積が何を示すか知らないだなんて

>>406
その方法だとｚが変化したとき、最小のｖが変わるとローカル座標系が大幅に変わる
vを(0,1,0)にしとけばx軸は必ずXZ平面にあるとか、やりたいことに合わせて考えたほうがいいんじゃないかな

なぜみんな、CかC++を使うのでしょうか？

スキルが未熟で、アセンブリで書けないからです

アセンブリでプログラミングしてどうするの？
今日日、そんな餌で釣れると思ったのか！！

あ、オレがつれてる...

立体をワールド空間に配置する場合どちらの方法が良いとされていますか？

移動行列A （中心座標XYZ)
回転行列B
拡大行列C
の情報を与えて(0,0,0)を中心とする頂点群に(CBA)を乗じる

中心座標(x,y,z)
回転行列P
(0,0,0)→(x,y,z)行列Q
(x,y,z)→(0,0,0)行列R
を使ってある位置に存在している頂点群に(RPQ)を乗じる

仮にDrawCube(x, y, z, 2w, 2h, 2d, rotx, roty, rotz)という関数を呼んだとすると
前者の頂点は(-0.5,-0.5,-0.5)と(0.5,0.5,0.5)を対角とし
後者の頂点は(x-w, y-h, z-d)と(x+2, y+h, z+d)を対角とします

別に良いも悪いもないよ
例えば太陽の周りを回る地球の動きを再現するには
前者と後者両方必要だろ

おまいら頭いいな

おまいらえらそうに言ってるけど
今回の日食がなぜ東からじゃなくて
西から順番に起こってるか説明出来ないんだろ

そっちの方が食べやすかったんだろ

俺もクッキー食べる時は西からだし

？　太陽と比べ月は遅いんだし、影が太陽の動きと逆なのは当然じゃん？

いやバターたっぷりのクッキーはおいしいだろ

金星の太陽面通過は、地球の北半球から見て金星は左から右に横切った。
これは、それぞれの公転軌道上の速度で金星が地球より速く、
文字通り金星が地球を追い越したからである。

一方、金環日食の場合は、地球の北半球から見て月は右から左に横切った。
これは、地球の公転方向とは逆方向に月が地球の周りを公転しているからであり、
かつ、月の公転速度が地球の自転速度より速いためである。

3次元NURBS曲面を２次元平面に投影した時の輪郭線を表す2次元NURBS曲線って計算できるものなの？

それっぽい論文を探してるんだけど、なかなか見つからない

>>421
ごめん、なんか紛らわしいな
次のように変えて読んでくれ

3次元NURBS曲面 --> N次 x M次NURBS曲面
2次元NURBS曲線 --> L 次NURBS曲線

まぁ要するに適当なNURBS曲面を平面に投影した影の輪郭線を求めたい

オートトレースのアルゴリズムとかで何とかなるんじゃないの？

>>423
オートトレースのアルゴリズムというのは、
平面に投影した後の図形から輪郭線を求めるアルゴリズムだよね。

それは投影したNURBS曲面の輪郭線と（数学的には）完全に一致するものなの？

俺の調べ方が悪いのかも知れないけど、
オートトレースって一度ラスター化してピクセル間を線で繋ぐか、
特徴をよく表す代表点を選んでそれらを線で繋ぐという方法しか分らなかった。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1488984684

韓国のコミュニティ・サイト「ポンプ」は、多くの書き込みが寄せられる掲示板サイトだ。書き込みには
日本に関するものも多く、韓国人の日本人に対する本音を垣間見ることができる。

「最近また反日が強まっているようですね。名古屋市長南京大虐殺否定発言で…」と題したスレッドには、
「今日本の語学学校ですが、中国人が一番多いです。台湾人は完全親日」「台湾人はおかしいです。
なぜそんなに日本が好きなのか。台湾だって植民地だったでしょう。日本から何かこぼれてくるのを
期待しているだろう」など、日本に滞在している韓国人から、台湾人の“親日”を不思議がる書き込みが
多く寄せられている。

また、こうした反日系スレッドは数多く、「同じ書き込みが繰り返されていると思うのは私だけか…」といった
指摘も――。さらに、同スレッドでは、韓国における反中や台湾に対する議論も行われ、「日本だけでなく、
中国や台湾も嫌い」など、論点が定まる様子はなかった。

http://news.livedoor.com/article/detail/6649300/

ν速にそっくりだなw

>>400
(1, 0, 0)との外積

安定のために(z = vに近いときやばい)、(1, 0, 0)と(0, 1, 0)のがいせきで大きいほうを取る

お前ら高校レベルの数学でつまづくとかレベル低すぎだろ

被写界深度のアルゴリズムってどこまで進化してるの？
いいの思いついたから実装してみるけど再発明なのかな

基本的なアイデアは、少しずつカメラをずらしてレンダリングする(実際はレンズのシミュレーションだけどイメージとして)
それらの平均を取る
これを高速に計算する方法思いついた

>>421
超難しい問題だな。三角形のポリゴンでも難しい
いくつかのNURBS曲線の集まりになるだろうな

>>429
それはリアルタイムなのか、非リアルタイムなのか

大事なところだったな。リアルタイムだよ
みんなどのくらいのgpu持ってるの？

>>432
もちろん 「"depth of field" "real-time"」 でググったり、
SIGGRAPH の論文を漁ったりしたんだよな？

あんまりあさってないけど
ほとんどが一回だけ描画して後は深度バッファを見てうまいこと計算する方式だよな

それだと最初に描画したときに見えなかったものは切り捨てられる
ちゃんとポリゴンを毎回変換して積分すれば正しい結果になる
人間がどの程度違いを感じるか分からないけど、物理的にはリアル

違いの出る例
遠くに点光源があったとして、それにピントを合わせたとする
そして、目の前に小さい遮蔽物を用意してその点光源を覆うようにすると
従来手法だとボケもろとも見えなくなる。

多分ボケに対して十分小さい物体をたくさん描画すると、従来手法だとノイズみたいなのが出る

高速な「つもり」ですねわかります。

>>434
ネットで論文が幾らでも読める時代だし、調べ続けてるときりない
ちょっとしたアイディアなら車輪の再発明を恐れず、さっさと実装すべき

>>434
> 違いの出る例

そのレベルの違いも問題にするのなら、
たしかに深度を元にポストエフェクトで処理するDOFでは
求めるクォリティにするのが難しい。

ただ、フルHD 60fps でそのクォリティを求めるのか？
DOF のために何回フルシーンをレンダリングする必要があるのか知らんが。

実際にリアルタイム処理をプログラムする前に、
Blenderなどの3DCGソフトを使ってカメラをずらして何枚かレンダリングして、
それらを合成して、本当に求めるクォリティが得られるか確認した方が良いぞ。

どれくらいずらして何枚レンダリングすればいいか、
合成はただの平均でいいのか、ガウシアンで加重平均した方がいいのか・・・
3DCGソフトなら簡単に確認できるから。

おれは、積分計算の処理よりも、複数回のレンダリングの処理の方が
圧倒的に時間がかかると思う。
積分計算を高速にしたところで、付け焼き刃ではないかと思うんだが。


ちなみに、リアルタイムでDOFが必要なシーンは俺はゲームでしか知らないが、
ゲーム中に遠くの点光源が見えない云々が問題として意識されるとは思えない。

>>434
遠くの物が手前のもので遮蔽されたら、遠くの物のボケが見えなくなって正解じゃないのか？
それとも遠くにピントが合ってるってことは手前にある遮蔽物のボケの話？

>>438

>>434 の違いの出る例で提示された問題が、
隔てられた点光源が見えなくなるという意味なら、
DOF との直接の関係はないと思う。

ピントが合うということは、
物体から拡散した光がカメラのレンズのどこを通っても、
撮像部（正式はなんて言うんだっけ）で一点に交わるということ。

従来の3DCGのような理想的なピンホールカメラなら、
物体から拡散した光の束の中からたった1本の光線だけが
ピンホールの穴を通って撮像部に到達するから、
その1本が射影物で隔てられれば写らなくなる。

一方、現実のカメラはある程度大きさのあるレンズを使ってて、
物体から拡散した光はたった1本だけでなく、
広がりのある束になってレンズの至る所を通り一点で交わる。

その物体とカメラとの間に小さな遮蔽物がある場合、
物体から拡散した光の何割かはその遮蔽物に隔てられても、
残りの何割かはカメラのレンズに到達し、一点で交わる。

この場合、先の状態よりも到達した光の量が減るから、いくらか暗く写る。
（ピント自体はあってるから、ボケはしない）

これは >>429 のように少しずつずらしてレンダリングすれば、
うまく表現できる。

>>439
＞目の前に小さい遮蔽物を用意してその点光源を覆うようにすると
って書いてあるんだし、やりたいことは違うだろう

うん、俺も何が本当に問題になっているのか実はよく分かっていない。

覆うとかボケもろともとか曖昧な表現は使わず、
もう少し詳しく丁寧に問題を説明してほしいというのが正直なところ。

何度もレンダリングするのはオーバーヘッドが多すぎる
リアルタイムDOFなら普通に深度バッファ使えばいいし
今は近傍点をサンプリングするより、スプライトを使った方法が主流だ

どの道それで再現されるのはレンズの大きいカメラのDOFでしょ。
人間の目の瞳孔はとても小さいので、そういったことは余り起こらない。
リアルタイムって事はたぶんゲームだと思うけど、そうだったら人間の目にあわせたほうがよい。

>>429
少しずつカメラをずらしてレンダリングする事で解決するだろうと予測する、
深度バッファを使う方法の不満点を、深刻度の高い順にいくつか列挙してみてくれ。
（と言っても、多くて5個くらいで十分だが）

こういう状況で、本当はこうなってほしいのに、
深度バッファ使う方法だとこうなってしまう、
だがカメラずらし法ならこう解決できる、
という感じで挙げてみてくれ。

そうすれば、それについてまともに議論できる。

まさか、不満点が >>434 の違いの出る例にあるたった１個じゃあるまい。

深度バッファ使う方法だと、カメラに近いピクセルをぼかすと
後ろも一緒にボケてしまうってのが一番大きなデメリットじゃないの？
つってもGPUGems3の方法しか知らないから今は改善可能なのか知らんが

今のDOFは深度バッファ見て条件付でぼかすから、
ボケが手前に回り込んだりしないよ。

お前ら>>429に釣られるとかレベル低すぎだろ

釣られるとか、議論のきっかけなんてどうでも良くないか？

>>432
俺のはintel GM915とか910とかいうchipsetについてるやつ
ピクセルシェーダーが使える

さすがにそこは盲点だったわ

トゥーンレンダリングは作画と比べると違和感があるがなぜそうなるの?
作画と見分けつかないほどのレンダリング技術の開発は難しいの?

>>451
君がどのトゥーンレンダリングとどの作画を比較して、
どういった違和感を感じているのかを丁寧に説明してくれないと、
「なぜそうなるのか」という説明はできません。

あと、トゥーンレンダリングに限らず、何かを模倣する技術全般について、
それをちゃんと理解したいのなら、模倣する元をある程度は身につける必要があります。

なので、ちゃんと理解したいのなら、まず自分で漫画やアニメを描いてみるといいです。

>>451
アニメーターの頭の中にあるスプライトを無理矢理3Dモデル化し、
それをレンダリングすることになるんだから劣化するのは当然だろ。

作画だと思ってたものがレンダリングだったりしてるかもよ。
見分けがつかないってことはそういうことだから

>>451
色彩設計がおかしいからだよ。
あと、出てはいけない線とか影とかが制御できてないから。じゃないかな。

絵描きのデッサンが狂ってるから。

今年のCEDECでプリキュアダンスの技術的な話があった。
俺は行ってないから、記事でしか読んでないけど。

たとえばキャラの関節について、
アニメでは腕を曲げるときは本来よりも少し短く描く。
CGでもこれをやらないと、アニメ本編との整合性が保てないそうだ。
（つまり、作画と比べると違和感がある）

この辺りの話はなるほどと思ったな。
まぁ、この道のプロにはよく知られた当たり前のことかもしれんが。

>>452
ヌルヌルした表現になる
影とかハイライトの表現がおかしい
いらない部分で線が出たり、いる部分で線が出なかったりする
布の表現が布ぽっくない
布の皺があまり描かれてない
セルのようにべったりとしていない
これぐらいかな

お前は何故トゥーンレンダリングが作画と同じに描画できると思い込んでるのか。

トゥーンレンダリングに作画が合わせれば違和感が無いのに。
CGと見分けがつかないほどの作画技術は難しいの？

最近のゲームだとほとんどイラストが動いてるみたいなのもあるが
ttp://www.4gamer.net/games/150/G015067/20120530020/SS/016.jpg

ゲームの所謂トゥーンレンダリングされたキャラで、
おれが一番違和感を感じるのは髪の毛。

記号としての 3DCG キャラなら全然違和感ないのだが、
アニメチックな絵にしようとする意図が見えた途端にものすごく変に見える。

輪郭線の色と奇妙なアンチエイリアスが違和感感じるかも。

影が問題なんじゃね？

アニメの作画はもっとひどいのがあるだろうｗ

アニメの場合は多少デッサンが狂ってるくらいは個性で済みそうだよなぁ。

あぁ、>>463はつーんしぇーだーの場合の話ね。>>461はすごい綺麗だと思う。
ゲームの名前知ってたら教えて欲しい。

頑張って検索したら出てきたわ。アトリエすごいね。
PS３あるから、廉価版出たら買ってみようかな。

>>467
アトリエシリーズは作を重ねるごとにイラストよりの 3D CG になってて綺麗ですよ。
http://www.youtube.com/watch?v=gWYwPFxRxms

あとちょっと違ったアプローチだけど、これも技術的に面白い。

2Dによる立体表現を可能にする世界初の描画技術「Live2D」 #DigInfo - YouTube
http://www.youtube.com/watch?v=qNMSF0-BxIg

　　　　　　　　　　／　　　　　　　 , 　 　 　 ::|　|ヽ＼　　　 ＼
　　　　　　　　　 /　 　　　　/ 　/ |　 　 　::/| :|　`､`､　　　　ヽ
　　　　 　 　 　 /　　　　　 /　 /　|　　　 ::/ |::|　　`､',ヽ　 ',　　', 　　　　　　　 r┐　r┐ヾ>
　　　　　　　　 ,'　　 i　　　|　:/'　 | |　　::/　i:|　　　 ', i ヽ　 i　　',.　　　　　　　| |　lﾆ　ｺ
　　　　　　　　,'　　 | 　 　 ! :,'　　 i||　 ::/　 ||　　　　 ||　`､　|　| |　　　　　　　 | ﾚ!　_| |.
　　　　　 　　 |　　 |　　　 |｀i'-,,,　| | ::/　　 |　　　　　|　　',　|　| |　　　　　　　 ヽ/（___ﾒ>
　　　 　 　 　 |　　 |　　　 ||.|　　｀二＝,,__,,,　　　　　,,,__... -!´ﾄ, | |　　　　　　　　　,､
　　　　　　.　 | . 　 i　　　 | |　 ／／:::C,　　　　　　 7::c＼　||ﾍ.| |　　　　　　　　（（
　　　 　 　 　 |　 　.| 　 　 | ／　 {::::::::::::} 　 　 　 　 {::::::::}`､ ,' .|　i　　　　　　 　　））
　　　　　　　　|　/´'| 　 　 | 　 　 ヽ::::::ノ　　　　　　 ヾ::ノ 　.|　 　|　　　　　　　　（（
　　　　　　　　|　{　 |　　　 |::::::::　　　　　　　　　,　　　　....　|　　 |　　　　　　　　　））
　　　　　　　　|　 ＼',　　　'','''''　　　＿＿　　　　　　　::::::::: |　　 i　 　 　　 　 　　（（
　　　　　　　　|　　 .:::',　　　',　　 ／　　　 ｀ ー --、　　　　|　　 |　 　 　 　 　 　　））
　　　　　　　　/　 .:::::::', ::　　',　 /　　　　　　　　　 }　　　　/　　 |　　　　　　　　　（（
　　　　　　 ／　...:::::::::::'､::. 　 ',､（　　　　　　　　　 /　　,イ|:: : 　 |　　　　　　　　　　`
　　　　　／　 ..:::::::::::／'`､:::..　',｀'' - ,,＿＿＿＿ノ,,ィ::´:::i ',:::|::　|　　　　　　　　　/ 7
｀-ー-´／　/:::::::::／　 　 `､､　',　　　/`､＼:::::::::::::::,':::::::,'　|::||:: |　　　　　　　┌‐'　'ｰ┐ﾄ､
￣￣／ 　./:::::,-{　　　　 　 ＼ `､、　　 /　 ＼::::::::,'::::::/ 　.|:i'|: |　　　　　　　　7 /_7 / ｣__〉
　 ／　　 /／　　＼　　　　　　 ＼ ヽ／　　　　}::::/:::::/　　 |　|:|　　　　　　 　〈_/ヽ_/

ああ、このAA、他のスレでは煽りのタイミングで出てたからそういう意図だと思ったが、ただのコピペ荒らしだったのか。

ハッキリ言おう
荒らしの判断もできない奴はクズであると！

>>468
おぉ〜〜。これすげー。
んでも、ポリゴン貼ってくのは結構たいへんそうだな。
日本の絵の基本はだまし絵だからねぇ。特定の角度以外からは破綻してる絵が多いよね。
それをロジック化するってすごい挑戦だと思う。期待！

真面目に全周囲対応させようとしたら普通に3Dモデル作ったほうが楽ってことになるんじゃないだろうか

アイマスのトゥーンレンダリングと作画アニメのアイマスを比べると差が随分違うんだけど、なんでこんなに違うの?
トゥーンレンダリングで作画レベルまでいくことはできないの?

リアルタイムのゲームと比べても。方向性は違うけどディズニーとかがんばってるよ

とりあえずここはプログラミングする人の板だから、そういう質問は他でやってほしい。

ソニックやカービィやキティちゃんとか、奴らなら
やろうと思えば作画と同等なトゥーンレンダできそう

アニメには立体感が少ない
立体感を無くすレンダリングをしないと

>>474
むしろアニメーターの力量が低くて3DCGの品質を再現できていないのではないか？

作画(原画・動画)、演出
モデリング、モーション
これらを分けて分析できない馬鹿ばっかりﾜﾛﾀ

そういう分析するスレじゃねーし

ゲームだったら、ゲームキューブのゼルダが結構雰囲気は良かった。だいぶん前のだけど。。。

>>478
>アニメには立体感が少ない
>立体感を無くすレンダリングをしないと

どんなレンダリング手法を使えばいいの?

>>463
> 輪郭線の色と奇妙なアンチエイリアスが違和感感じるかも。
奇妙なアンチエイリアスってどういうことなの?

>>484
うーん。あえて言うなら、汚い中間色かなぁ。

最近のセルシェーディングはきれいだねー。
ttp://gigazine.net/news/20120827-precure-endingdance-cedec2012/

>>485
改善するにはどうすればいいの?

馬鹿には無理

>>487
ご自分でお考えになって！

>アニメには立体感が少ない
>立体感を無くすレンダリングをしないと

この手法考えてくれ

逆の発想で、こういうシェーダー書けば多少立体感削れるんじゃないかと思っている。
ttp://www1.axfc.net/uploader/Img/so/148968.png&key=2ch
ちなみにこれ、DXSDKのチュートリアル5のシェーダーいじって作った。
作ったのが2年前のようだから概要を殆ど覚えてない。が、算数でできるよ。
あ、ソースコード100万円ね！！（＾q＾

後は小細工だけど、五平餅みたいに対象のモデルをカメラに向かって潰すとかすればいい感じに平らになると思う。
セル画ってレイヤーだから平面をレイアウターで配置してるようなもんなんだよな。
そしたら、おかしなパースの立体画になるよね。

>>491
その画像をいろんな人に見せて、どっちが立体的？ と訊いて回っても、
大半の人はどちらも同程度に立体的に見えると言うのではないか。

>>492
もちろん適応範囲は変えれるよ。
>>491の画像で216色相当だけど、もうちょっと荒くしたりはできるよ。
それと、その画像が立体視できるんであれば、線の直線とかを歪ませて崩さないと厳しいんじゃないの？
輪郭から推測してそう見えるんでしょ？

つまり、役立たずだな

まー、そのうち自分で使って結果を見ようと思ってるからいいんだ。
俺の技術力では10年くらい先の話だけどね・・・。Orz

あと、役立たずでごめんね〜。
>>494にはライセンスしないから、ぜひ我道を行ってくれ。

>>495
自分には10年早いと自覚している技術を他人にライセンスするつもりだったか、
それとも別の何かをライセンスするつもりだったのか。

>>490
人工知能でなんとかできないの?

藤阪シェーダーというのがあったな。あれを応用すればいいの?

藤阪シェーダーはどんなアルゴリズムを使っているのだろうか?

>>468
画はいいけどキャラデザに魅力が無くなってるな
なんだろうこの空虚な感じ
なんかそれぞれの存在感が薄いんだよ

スポットライトでパースペクティブシャドウマップを使う場合、
カメラの射影空間内でスポットライトの視錐台を作る必要があるが
どう作るのが良いか。

今はワールド空間のスポットライト視錐台の頂点を
カメラ射影空間にトランスフォームし、それを包み込むように
視錐台を作っているが、これだと誤差のせいか
影の質が悪くなるケースがある。

分割して遠近用の視錐台を用意しないといけないケース

それはカスケードシャドウマップを使えということ？
やっぱりパースペクティブシャドウマップは
発想は良いが、実際にはNGパターンが多くて
使えない技術なんだな。

3dに興味を持って、今は用語を勉強し複数の座標系が関わっている事を知った段階なんですが、
ワールド座標の大きさってどのぐらい取る物なんでしょうか？

回転の計算やらに、三角関数が関わってくるので小数点や誤差が入ると思うのですが、
ワールド座標を大きめに取る事で誤差を少なくしたりとか出来る物ですか？？

実用上、32ないし64bit浮動小数点数で、適当に1を取って充分。

1cmとか1mとかわかりやすい単位で好きなものをどうぞ

「ワールド座標を大きめに取る」という事の意味がよくわかりませんが、
浮動小数点数計算における有効桁数を考慮する事で誤差を小さくする事は可能です。

計算のしやすさで言えば1.0lf(100%)になんの単位を割り振るかっていうのが問題だな。
浮動少数の誤差の話は計算機の計算の話になっちゃうのでそっちを参照したほうが早いんじゃないかな。

32bit単精度の1.0が1mってことで、赤血球から入道雲までカバーできると思うよ

皆さんの回答を見るに物凄い勘違いをしているんじゃないかと言う気がしてきています。

私の頭の中では3次元の直交座標が有り、小数点は無い状態なのですが、
このイメージは根本的に間違っているのでしょうか？

スケーリング行列・回転行列・平行移動行列の引数もfloat型になっていますし、
少し混乱しています。

マップ作製をしてポリゴンを配置する時はint型の方が都合が良い気もしているので、
どっちのイメージを持つべきか良く分かりません。

物理座標と論理座標があることは理解してる？
論理座標は考えるときに都合のいい座標系で物理座標は実際表示するときに使う数字。
論理座標で考えて物理座標にマップしてスケールするっていうのが一般的だと思うよ。
数学を扱うときは割合を扱うことが多いので少数で出てくる解答をそのまま使いまわしたほうが効率いいんだ。

まぁ、
640*480って物理座標があったとしてそれを一般的な論理座標で表すと1.0*1.0または2.0*2.0なんよ。
どういうことかわっかるっかな？

ちなみに、
物理座標が800*600でも論理座標は1.0*1.0または2.0*2.0です〜。

>>511
どうなのかな？>>510を読んだ時はそれとはまた違うこと考えてるように見えた。
>>510はfloatで表現できることはintで表現できると考えているように見える。

…といいつつ、それらの表現の幅がどれだけ違うのかは、俺考えたこと無いｗ
intは4294967295種類を表現できるが、floatは何種類の数を表現できる？
有効桁数は七桁、というふうなのは聞くが、七桁あるとどれくらい表現できてる？

コンピュータの少数は単精度で7桁程度*10の±127乗程度の表現力がある。

ということは、やっぱ同じビット幅の変数でも、
浮動小数点数のほうが圧倒的に表現の幅があるってことでつよね？

物理座標と論理座標・・・
理解できていないかもしれません。

下記のサイトを参考にプロジェクション座標変換の前後で、
実データと画面表示用のデータで違いが有ると言うのは認識できたんですが、
それとは別の話ですよね？？

ttp://www.c3.club.kyutech.ac.jp/gamewiki/index.php?3D%BA%C2%C9%B8%CA%D1%B4%B9
ttp://hakuhin.jp/as3/projection.html

>>510読みなおした。
直交座標はある。
INTで計算したら最大値は一般的に32ビットだが、少数で計算したら一般的にどの状態でも-1.0〜1.0だ。
どういうことかというと、数学は論理座標で計算した後、相似形を当てはめてスケールするんだよ。
綺麗に計算するコツは、最後の最後まで単位変換しないこと。

>>515
コンピュータの少数は誤差が出るので表現幅だけがあっても嬉しいとは限らない。
銀行とかでは誤差が出たら業務が止まる。
まぁ、振り幅が大きいだけで保持できる数字自体は小さい。

>>516
それの話。プロジェクションってどういう意味だと思う？
投影だけど、何に投影するかって言うと、目の前のディスプレイに投影してマップするんだよ。
それは物理的制約であってソフトウエア的な制約ではないんだよ。ソフトウエアはもっと自由だ。
だから、ソフトウエアの領域で考えたものをどうやってリアライズするかっていうのが、プロジェクション。

0.0〜1.0の範囲はスケールが百回以上変化するので、
1.0〜2.0の同一スケールに納めるという割り切りもある

>>519
その話はすごく面白い。
不動小数点数についてシッカリ理解してないので俺今は何一つ分からないが…。

>>519
俺が一般的に扱ってる座標と違うので何を言ってるのかわからないが興味アルな。

ボクセル群を回転させて新たなボクセル群を切り直したいという話なのでわ・・・

中心はどうやって取るの？

>>518
三次元の元データを1280+768なりの二次元の領域に落とし込むからまるで別の物って感じの理解です。
最終的には画素の数に対応した物まで変わりますが本当に全然別概念。

FFタクティクスのマスみたいな概念でint型の直交座標を考えていて、
精度をテレビの画素とインチの関係の様に考えて、
x、y、ｚ軸をそれぞれどのぐらいのマス目で取れば良いのか疑問になりまして。

実際に32bitを計算して4294967296^3の直交座標ならとんでもない精度だなと思いましたが。
ノートに一次方程式書いてる感覚で居たのが悪かったような気もしています。

Final Fantasy Tactics 30 リオファネス城城内
ttp://www.youtube.com/watch?v=Do4FozWJXEk

ワールド座標系（範囲は自分で決める）
↓
正規化デバイス座標系(-1.0〜1.0)
↓
ウィンドウ座標系（640*480など）

>>525
正規化デバイス座標系
この名前初めて見たかもしれません、微妙に意思の疎通が出来てない気がしたのは、
これを明確に認識できていなかったからかもしれません。

自分は、変換後の変化考えるのが面倒なので最初から正規化して考えるなー。

>>519
0.0〜1.0だと、指数部がいろいろの値を取るけど
1.0〜2.0だと、指数部は固定って事かな？
テーブル参照とか整数化の時便利そうだね。

>>528
指数部が固定ということは上位9ビットが固定ということなので、
数値の大小比較を整数値としても行なえるということ。
また、下位23ビットを取り出してそのまま整数値とすれば、
0-8388607の値となるので整数変換も楽。

>>529
浮動小数点って、符号さえ同じなら整数で大小比較できるんじゃ無かったっけ？
裏ｵｰﾎﾞｴすまんこ

浮動小数点について一度最初から学びなおしたい、
それは自分の力になるから、と毎年一度以上思うが何もしないという伝統。

http://ja.wikipedia.org/wiki/%E5%9F%BA%E6%95%B0%E3%82%BD%E3%83%BC%E3%83%88
> IEEEフォーマット の場合は、float a, b が与えられたとき、a>b>0なら*(int*)&a>*(int*)&bとなるため、指数部と仮数部に分ける必要も、整数に近似する必要もない。

切頂六面体、切頂八面体をプログラムを用いて、
各頂点の位置を求めて描く方法を教えてください。

>>533
その過程のどこが分からないの?
全て分からないと言うのなら、そもそも教わるのが無理な話。

>>530
言葉が足りてなかった。>532の通り、問題ないね。
差分同士の比較も整数値として行なえることを言いたかった。
例えば、1.25 - 1.125 も 1.125 - 1.0 も 0x100000になる。
一方、1.0 - 0.875 は 0x200000になってしまう。

>>533
頂点は頑張って求めろー。
正四面体、正六面体、正八面体に特化した
簡素な隠面消去アルゴリズムはたぶんあるはずなのでこれを流用しよう。

凸な多面体なら、視点の方に向いている（法線ベクトルと視線ベクトルの内積で...）ポリゴンは
描画する、反対を向いてるのは描画しない、だけでok

凹んでるやつもそれでいいんじゃね？

よく見たら凸っていう字は凹んでる部分があるな

>>533
http://github.com/kloffy/kaleido/

>>538
よくない。
凹なら下北半島と津軽半島のどっちを先に描画すべきか判断する必要が出てくる。
凸多面体ならそういうのも気にせず>>537の通りでいい。

あっ、「先に」という表現はちょっと考え方が古い（80年か90年代くらい？）かもしれないけどまあいいや。

奥に
ですね
わかります

ペインターズアルゴリズムなら「先」だぬ

>>543-544
そうそう、そんな感じです。
ペインターズアルゴリズムって言葉を初めて知ったor完全に忘れてた…。

グーグルの検索エンジンアルゴリズム
http://webblogsakusei.main.jp/seo_taisaku_syukyaku.html

最低でも高校理系数学程度の知識がないと3Dは無理。

その高校理数系数学というのが，最近のゆとり教育では幻滅されているようで‥

今高校で行列って習うのか？

やったりやらなかったり

今年の春の大学入試試験が行列の出る最後の試験だったらしい
もう高校では基本教えないだろう

嘘だと言ってくれ。日本を壊滅させる気か、自民党は。

行列って高校数学よりは大学のほうがやりやすいとは思うけどね。
コンピュータ前提でガリガリ計算させるにしても、理論寄りで数式で完結するにしても。

高校数学や大学入試の枠で「生徒の力を評価する」のがやりにくいと思う、行列って。
いやもちろん中身はすごく重要だと思うんだけどさ。

だから行列削って別のもの教えますっていうならいいと思うんだけど単に削っただけなんかね。

まあ必要なら大学一年に線形代数学でジョルダンの標準形まで習うでしょ

そうか‥二次正方行列の範囲で固有値固有ベクトルまでやっていたのも夢となったのか‥

積に順序があることを教えるのも行列やベクトルが良い例だけど
最近の教育ではなんかスカラー積にまで順序を強制してるんだよな

「算数の掛け算で順序逆にしたら×もらった」って話は
そういう気違い教師がたまにいるってだけだろ

ベネッセはきちがい
http://togetter.com/li/723999
http://ja.wikipedia.org/wiki/%E3%81%8B%E3%81%91%E7%AE%97%E3%81%AE%E9%A0%86%E5%BA%8F%E5%95%8F%E9%A1%8C

そんな議論あったんだ
70年代からあるようだが聞いたことなかった

日本の教師は不正な縁故採用だらけだからな。

へー

>>560の言っていることは正しい。

昔のCG資格の教科書資料とかプログラミング専門雑誌の3D解説記事でも行列関係は間違い多くて怪しかったけどな。
95-2003年頃のはなし。

数学の教え方が駄目なのは判ってない人が教えるからだ。昔から受験数学と本当の数学は違うと言われてる。
ゆとりも文部省や現場の先生は反対なのに、内閣直属の自称識者なんとか教育国民会議の圧力で教育が駄目になったと聞いた。
官僚は悪くないよ。
有名企業で第一線で活躍したエンジニアが子供の数学力低下に驚いて塾やってるくらいだから。

孔明党ですね
わかります

はわわ

官僚は悪くないよ。
官僚は悪くないよ。
官僚は悪くないよ。
官僚は悪くないよ。
官僚は悪くないよ。
官僚は悪くないよ。
官僚は悪くないよ。