出し惜しみせずに3Dの技術を誰かが答えます Part4

**プチ9627ｍ** · 02/05/12 11:50

3D技術の解らないことや気になることを誰かが答えてくれるスレ。

お約束
1. 出し惜しみしないこと。
2. 3Dそのものの是非については議論の対象外とする。
3. いかなる理由があれ、個人叩きは厳重に禁止。
　　（守れない輩は、この板のローカルルール百回読みの刑に処す）

では、ご随意に。

■ 過去スレ
出し惜しみせずに3Dの技術を誰かが答えます Part3
http://game.2ch.net/test/read.cgi/gamedev/1016725546/

**名前は開発中のものです。** · 02/05/16 23:41

>>339
そんなに変わらんと思うぞ。
Matroxの奴はごく標準的なテッセレート(1,4,9,16...)だし、
現状アレ以外の分割手法を採用する利点はないしね。

**名前は開発中のものです。** · 02/05/16 23:45

つか､他は実装するのか？いらねぇだろこんな機能。ハイポリでいいじゃん

**名前は開発中のものです。** · 02/05/16 23:49

>>342
とりあえず､メモリは節約できるし、ローポリで作っとけば表示も軽くできると思うが

**名前は開発中のものです。** · 02/05/16 23:49

342 = フェードアウト組ｹﾃｰｲ

**名前は開発中のものです。** · 02/05/16 23:51

DAKINIスレの山崎厨房をこっちで引き取ってくれ。

**名前は開発中のものです。** · 02/05/16 23:56

>>342
巨大なビデオメモリ積んでテクスチャサイズを増やせばいいじゃんみたいなものだね。
縮小した時激しくエイリアスが発生or巨大なミップマップが必要になるとか、
テクスチャ読み込んだり、転送したりするのに時間がかかるとか考えたこともないのかな。
あるいみ幸せな奴だ。

N-Patchをジオメトリのバイリニアフィルタとするなら、
DisplacementMapはS3TC並みの効果があると思われ。

**名前は開発中のものです。** · 02/05/17 00:04

>>342
そもそも自分たちが今までどのような目的で、形状データをわざわざ
ポリゴンメッシュという形で保持してきたのか、ということを整理して
考えれば良いんじゃないかな。

言い方を変えれば、精細な形状データにまでわざわざ
ポリゴンメッシュを選択するということに、どれだけの
メリットが残されているのか、という。

**名前は開発中のものです。** · 02/05/17 00:13

いや、慢性的に不足気味とはいえ、そんなに帯域不足してんのか？GF4の倍くらい帯域あるよね
それにあのポリゴン数で複数キャラ描画出来んの？

非ゲーム向けといわれりゃそれまでだが

**名前は開発中のものです。** · 02/05/17 00:13

ところでN-Patch化されるモデルデータってどうやってオーサリングするですか？
どうせ細分化（ポリゴンメッシュ化）されるなら普通にオーサリングツールで作れ
るような曲面（もしくはこの部分もプログラマブル化するか）にしてホスイです。
（N-Patchは元々そんなことｷﾆｼﾅｲ!って話もあるけど）

**名前は開発中のものです。** · 02/05/17 03:42

>>349
元データは他の曲面タイプなら、それをポリゴンモデルにコンバート。
n-patchプレビュー結果が納得いくものになるまでトライ＆エラー。鬱。

http://www.ati.com/developer/sdk/Npatch/npatchresource.html
ATIのサイトにある3dsmax用プラグイン。俺が知ってるのはこんぐらい。

**名前は開発中のものです。** · 02/05/17 03:43

×　元データは
○　元データが

**名前は開発中のものです。** · 02/05/17 05:00

問題はデータをどう作るかだなぁ。大変そ。

**名前は開発中のものです。** · 02/05/17 07:51

モデラとプレイヤエンジンは一緒に作らないとダメかね、やっぱ。

**名前は開発中のものです。** · 02/05/17 09:20

n-patchは海外のメーカーにさえマトモに相手にされてない。
エロゲーしかPCゲームがない日本でオーサリングしてるやつなんかいないだろ。

**名前は開発中のものです。** · 02/05/17 09:48

それ以前に､商品として成り立たない罠。
全PCの５割がParhelia（つーかDX9対応）になるってんなら
上もディスプレースメントやれってなるだろうけど。

しばらくは実験して遊ぶ＞Webで公開ｵﾅｰﾆしかないのか。

**名前は開発中のものです。** · 02/05/17 10:44

だいたい他社もDirectX9のディスプレースメントマップに追随するかどうかも疑問。
G400のDirectX6の頃のEMBM（NVIDIAにいわせると2Dオフセットマップ）のように
黙殺されない事を祈るよ…。

**名前は開発中のものです。** · 02/05/17 13:00

NV30ですぐに追随する（＆追い越す）から安心しろ

**名前は開発中のものです。** · 02/05/17 13:14

とりあえず、リーク情報では積んでないぞ＞NV30

**名前は開発中のものです。** · 02/05/17 13:16

>>354
フェードアウト組みはエロゲーでも作ってなさいってこった。
製品化されていない＝相手にされていないという短絡的な考えは馬鹿としか言いようがない。
海外でもn-patchなどの細分割曲面について積極的に研究されているよ。
(海外のサイトなんて見ないだろうからわからないだろうけど）
まだ使えるハードウェアが少ないから使用していないだけで、
既にスタティックな分割はQuakeなどでも実現されているしね。

>>355
即商品として成り立つことを要求していれば、何時までたっても新技術は浸透しないよ。
その論理ならピクセルシェーダーすら商品としては成り立たないしね。
ディスプレースメントマップはパイプラインの最上位に位置するから
ソフトウェアで十分エミュレーション可能だし、ピクセルシェーダーよりは使える可能性が高いと思う。

**名前は開発中のものです。** · 02/05/17 14:13

コンシューマで使えない技術は意味なし。
エロゲヲタだけが１０ビットＲＡＭＤＡＣで肌色の表現力が上がることに大感激。

**名前は開発中のものです。** · 02/05/17 14:20

>>360
たぶんSFC時代はポリゴンなんてまともに使えんから意味なしとか
PS時代はPS時代で、そんなもの使えないから意味なしとか同じようなことを言っていたのだろうな。
そしてフェードアウトしていくのさ。

優秀な技術者は先を見越して基礎技術の蓄積に余念がないというのに。

**名前は開発中のものです。** · 02/05/17 14:30

で、おまいら出たら買うのか？

**名前は開発中のものです。** · 02/05/17 14:42

漏れはNV30, R300, P10が出揃うまで松

**名前は開発中のものです。** · 02/05/17 16:01

新製品が出るたびにそう言い続けてきた>>363のPCには
いまだにRIVA TNTが入ってるに10000ﾎﾟﾘｺﾞﾝ

**名前は開発中のものです。** · 02/05/17 16:07

次世代技術はネット。
ＳＣＥがコンシューマ独占してるからグラフィックはもう進歩ないよ。
ディスプレイスメントマッピングなんてシャレたものをＳＣＥがサポートできるわけない。

**名前は開発中のものです。** · 02/05/17 22:56

　どうでもいいが、アンチダキニを隔離できたのはいいが、おかげで
ダキニ病患者が幅を利かせてるようだな。ウザイから氏ね。

>>365

　ＰＳ３も意味不明な方向性だしな。ＰＣがリアルタイムグラフイックの
先端を突っ走る構図はあと数世代は変わるまいて。

**名前は開発中のものです。** · 02/05/17 22:58

　　ヽ:::::::::::::::::::::!:::::|　 N .ノ　 !! ､{　ヽ、 !Nヽ､i ヽ!　　|::ﾉ　　　　　　|　　　　　　　　 |
　　　 `┬--､..__ト__|__,.‐'´　　　　　　　 `ｰ-- ､＿____ jﾉ　　　　　　　|　　　　　　　　 |
　　　　 |　　　| 　　 ,. ==ii'´　　　　　　`'ri=＝＝､､　　 |　　　　　　 |　　　　　　　　 |
　　　　｜　　　| 　,〃 rｧ　　　　　　　　　　 r';ヽ　　ヽ_,,.|　　　　　 |　　　　　　　 |
　　　　｜　 ''=l='"} 　|:l}　　　　　　　　　　 |.lﾉ|　　 ,} =￥　　　　　　|　　　 !　　　　　l
　　　　 |,　　　| ｀~ 　り　　　　　　　　　　{.l;;ﾉ　　´~ |　　　 ,| 　　|　　　 |　　　　　 !i
　　　　　､　　 | ／／／／　　　　　　　　　／／／／＼　_/　　　|　　　　|　　　　 | i
　　　　　＼ー|／／／／　　　　　　　／／／／／／　|￣　　　 |　　　 |　　　|　　| i
　 | 　　 |　ヽ__|　　　　　　　　〈l　　　　　　　　　　　　|　　　　 |　　　 |　　 |　　| l
　l|　　 li|　　　 `　　　　　　　　　　　　　　　　　　　　　　,>,____..　　/|　　　　!　　 |　　| l
　i|　　　i|　　 | 　　` ､　　　　　　　　　　　　　　　　　 ,.'　ゝ,＿_,ノ　|　　　 |　　　|　　| l
　| 　　 |　　 |　　|　　,` ..　T7^～～～～～～~ヽ、／　/　　　　　　|　　　ﾊ　　 |　　| !
../ヽ.___人___人___入_ノ /　`　'-------------- '′ 　／　　　　　　ヽ､__ノ　ヽ__ノ`ｒ-ｒ'′
　　 {ﾐ}　　{ﾐ}　 {ﾐ}　　 ,l　　　　｀ー‐‐-------- ― '´　　　　　　　 {ﾐ}　　　{ﾐ}　 {ﾐ}
ふぇぇぇ・・・もうあたしのこと飽きちゃったの・・・？ふぇぇぇ・・・

**名前は開発中のものです。** · 02/05/17 23:05

>>366 しょぼいコメント　こんなん書いて恥ずかしくないの？

　[ＰＳ３も意味不明な方向性だしな。ＰＣがリアルタイムグラフイックの
先端を突っ走る構図はあと数世代は変わるまいて。]

**名前は開発中のものです。** · 02/05/17 23:13

ダキニ病患者の方もせっかくだから
http://game.2ch.net/test/read.cgi/gamedev/1021476153/
こちらへどーぞ。

**名前は開発中のものです。** · 02/05/17 23:16

リアルタイムグラフィックの先端を突っ走てるのは
いつもワークステーションだ。
ゲームなんぞはリアルタイムグラフィックの用途の一つにすぎん。

**名前は開発中のものです。** · 02/05/17 23:37

そりゃ軍事用にはかなわんよ～

**名前は開発中のものです。** · 02/05/17 23:38

　PCとWSの差もどんどんなくなりつつあるけどね。PS2の親玉みたい
なのでもCG-WSを名乗れちゃうからなんともいえない。

**名前は開発中のものです。** · 02/05/17 23:55

あーあ、また厨が発生した。sagesage

**名前は開発中のものです。** · 02/05/18 01:35

はぁ…。なんかわがままな奴だなぁ。

**名前は開発中のものです。** · 02/05/18 17:32

自力でポリゴンにテクスチャ張りたいんです
長方形に解体できるポリゴンはテクスチャと対応させる
座標を求めるのは簡単なんですが、複雑な形状のポリはどのように座標を計算してるんですか？
D3Dの参考書にはOXマッピングなんたら書いてあるんですが具体的なイメージが沸きません。
ヒントくれ

**名前は開発中のものです。** · 02/05/18 17:55

手作業でテクスチャ座標をいじるのが一番…ってのは無しか。

テクスチャ座標を計算で求める場合は、重心等からの方向ベクトルを使うのが多いね。
重心からのベクトルを使う方法は、球や円柱がポリゴンの周りにあるイメージで。
球の場合はメルカトル図法のテクスチャを使用。

他によく使うのだと、例えば木目とか金太郎飴の場合は頂点のz成分を無視して、
x,yを適当にスケーリングしてそのままテクスチャ座標に使ったり。

**名前は開発中のものです。** · 02/05/18 20:43

>>375
テクスチャ付きポリゴンのソフトレンダラを自作したいということなのか
それとも、ポリゴンモデルの各頂点のテクスチャUV値を自作のプログラム
を使って割り当てたいということなのか。

**名前は開発中のものです。** · 02/05/18 20:48

>>375
こっちのスレで質問したほうが雑音も少なくて更に宜しいのではないだろうか。

■ゲームプログラミング相談室
http://game.2ch.net/test/read.cgi/gamedev/1005040025/

**名前は開発中のものです。** · 02/05/18 21:15

モデラで作ってテクスチャ座標を吐き出してもらう。
以上。

**375** · 02/05/18 21:44

>>376
重心がKeywordですか。そう言えばTEXTのポリも円筒に囲まれてました
>>377
後者です　
>>378
そっちもなかなか面白そうっすね　勉強になります
>>379
本当はそれで十分なんだけど内部で
どんな処理してるのかがわからない
と気持ち悪いんです

**名前は開発中のものです。** · 02/05/18 23:32

・・・・。

**名前は開発中のものです。** · 02/05/19 00:17

>>380
http://www.mext.go.jp/a_menu/shotou/kyoukasho/mokuroku/14/koutou/2suugaku.htm
http://www.mext.go.jp/a_menu/shotou/kyoukasho/tokuyaku/001201.htm

**名前は開発中のものです。** · 02/05/19 00:20

>>380
http://www.amazon.co.jp/exec/obidos/search-handle-url/index=books-jp&field-author=%E7%94%B1%E5%96%9C%E6%86%B2%2C%20%E5%B1%B1%E5%B4%8E/249-8826722-7150738

**名前は開発中のものです。** · 02/05/19 00:22

>>380
http://www.gogo3d.com/products/gems1/

**名前は開発中のものです。** · 02/05/19 02:12

>>380
■ゲームプログラミング相談室
http://game.2ch.net/test/read.cgi/gamedev/1005040025/

**名前は開発中のものです。** · 02/05/19 04:54

あんまり380をいじめんでも、３Ｄ周りの話ならいいんじゃない？
こういう人も受け入れてやらんとネタが無くなるんじゃないかと思うが。

**名前は開発中のものです。** · 02/05/19 08:50

>>386
ほんとだねぇ、出し惜しみまくりですな（笑

**名前は開発中のものです。** · 02/05/19 09:55

・・・・。

**名前は開発中のものです。** · 02/05/19 13:36

>>386
　話が滑り出すとすぐにストッパーかけるヴァカがいるからな。出し惜し
みってよりも、出すモンがないだけちゃうんかと。

**名前は開発中のものです。** · 02/05/19 15:47

（´-`）

**名前は開発中のものです。** · 02/05/19 16:24

http://www.cs.brown.edu/courses/cs123/lectures/Polygons.pdf
英語だけど21頁以降に丁寧な解説付き

**名前は開発中のものです。** · 02/05/19 16:59

(　´∀｀)σ)冫、）　こんな駄スレで何を期待してるのやら
　　　　　　 ` ／

**名前は開発中のものです。** · 02/05/19 17:34

ﾆﾔﾆﾔ

**名前は開発中のものです。** · 02/05/19 17:45

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=00000543&forum=3dtheory&id=-1

**名前は開発中のものです。** · 02/05/19 17:46

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=00000466&forum=3dtheory&id=-1

**名前は開発中のものです。** · 02/05/19 17:55

>>386-387,>>389
よく似合いそうな捨てゼリフも見つけますた。
http://game.2ch.net/test/read.cgi/gamedev/1020652085/51n

**名前は開発中のものです。** · 02/05/19 21:09

　　　　　　　　ついにこの僕が397ゲットですよ？冨樫先生。
　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　∧∧　ｷｭﾜｯ！
　　　　　　　　　　　　ヽ（ﾟ∀ﾟ）ﾉ　　　(´⌒(´
　　　　　　　　　　　　へ(　　 ) 　　≡≡≡(´⌒;;;≡≡≡
　　　　　　　　　　　　　　　 >　　　　(´⌒(´⌒;;
ロケットで突き抜けろ！ロケットで突き抜けろ！ロケットで突き抜けろ！
LIVE LIKE ROCKET！LIVE LIKE ROCKET！LIVE LIKE ROCKET！

モラル欠如者、2getしたくて仕方ないんでしょう>>3さん？
ここで次週予告！！来週は>>4の母が登場！マザー・オブ・ラブでつきぬけろ！→>>4
痛みを知らない>>5が嫌い
心を無くした>>6が嫌い
だが>>7は僕が大人であり子供であることの誇りだ
やさしい>>8が好き　バイバイ
　　　　　　　　　　　　　　　　　　　　　　　キユ

**375** · 02/05/19 21:24

>>391-394-395
ｷﾀー！！！===============(ﾟ∀ﾟ)======================
どもありがとう。これだけ資料が有ったら結構行けそうです(たぶん・・
分からないことが分かるようになるって楽しいね！それじゃ♪

**名前は開発中のものです。** · 02/05/19 22:22

>>397=>>398
なんだよ、結局お前も荒らしかよ。
もう来ないでくれな。頼む。

**名前は開発中のものです。** · 02/05/19 22:35

　隔離先のDAKINIスレが凄い事になってるね。祭り前に切り離せて正解だ
ったやもしれぬ。さて、ブックマークの整理でもしよっかな☆

**名前は開発中のものです。** · 02/05/19 22:51

>>400 糞レスは向こうに書けやチンカス

**名前は開発中のものです。** · 02/05/19 22:59

>>400
　DAKINIネタは持ち込まないでくだちい。そちらのスレは十分ネタとして
楽しんでありますので。

**名前は開発中のものです。** · 02/05/19 23:07

お前らはフェードアウト組だ。

**名前は開発中のものです。** · 02/05/20 11:58

ちょっと気になったんだけど、メタセコ（他のモデラーもそうかもしれんが）で
プレビュー画面のﾎﾟﾘｺﾞﾝの一部が崩れてるのはZBuffer使ってないから？
VRAMきついから　ソートでやってんの？

**名前は開発中のものです。** · 02/05/21 01:37

DAKINI厨房を隔離したら誰も居なくなった。
つまり全員がアンチダキニ。

**名前は開発中のものです。** · 02/05/21 01:45

おいおい、FFXIが出たからって会社休んでまでやるなよ。
そんな奴はさっさと会社やめちまえ。いらねーよ。

**名前は開発中のものです。** · 02/05/21 05:18

>>405
ﾊｧ・・・

**名前は開発中のものです。** · 02/05/21 05:23

>>404
Z-Bufferの精度が足りないと言う可能性がある。
もっとも、その場合は後ろのポリゴンが前に出てくるんだけどな。
（で、チラチラすると。

外してたらスンマソ

**名前は開発中のものです。** · 02/05/21 13:50

http://www5d.biglobe.ne.jp/~twintail/
ここにあるLunaライブラリのソース読んで
ちょっと疑問に思ったので分かる人教えてください。

2Dスプライトの回転描画の透視変換のところなんですけど
LunaSprite.cpp 332行～
わざわざdをでっち上げて、回転行列を求めた後に以下のように変換してます。
vx[i].x = (vec[i].x*d/vec[i].z) + cx - 0.5f;
vx[i].y = (vec[i].y*d/vec[i].z) + cy - 0.5f;
vx[i].z = vec[i].z / d; // 0～1にする
vx[i].w = 1/vx[i].z;

私の足りない頭で考えた変換式は
x' = x * m._11 + y * m._21;
y' = x * m._12 + y * m._22;
z' = z / 2.0f + 0.5f;

v.x = cx + x';
v.y = cy + y';
v.z = z;
v.rhw = 1.0f/z
こうなんですが、もしかして間違ってますか？
もし私の式でもあっているなら、わざわざdをでっち上げる理由を教えてほしいのですが。

**名前は開発中のものです。** · 02/05/21 14:17

http://www.flets.org/saimoe/cgi-bin/img-box/img20020520235520.jpg
http://www.flets.org/saimoe/cgi-bin/img-box/img20020520235343.jpg

ｷﾀ─wwﾍ√ﾚvv～(ﾟ∀ﾟ)─wwﾍ√ﾚvv～─ !!!

**409** · 02/05/21 14:21

ごめんなさい、分かりました。
そもそも私のやり方も思いっきり間違ってました。

**409** · 02/05/21 14:26

>vx[i].z = vec[i].z / d;
でも、たぶんここは違うんじゃないかなって思いました。
D3DでZ値の取りうる値は0.0f～0.99999fで、
上の式のままだとzの配置がいい加減ですよね？

**名前は開発中のものです。** · 02/05/21 14:42

ゆりたんｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!!!!

**名前は開発中のものです。** · 02/05/21 15:14

>>409
SetTransform.*D3DTS_PROJECTION
でgrepかけてみ。

**409** · 02/05/21 16:06

そもそも、2D空間上でのスプライトの透視変換なんて、
正しい値などあるはずもなく、感覚で作るしかないって理解でよろしいでしょうか？

**名前は開発中のものです。** · 02/05/21 17:22

＞感覚で作るしかない
　　　　　,一-、
　　　　 /￣　l |　　　／￣￣￣￣￣￣￣
　　　　■■-っ　＜　んなーこたーない
　　　　´∀｀/ 　　　＼＿＿＿＿＿＿＿
　　＿_／|Ｙ/＼.
　Ё|＿_　| /　　|
　　　　| У..　　|

**409** · 02/05/21 17:33

>>416
どうしたらいいのですか、なんて言うかサッパリです。
パースの掛かり方はz位置に依存するし、
そもそも2D空間上にはz座標なんて無いので、
一意に決定する方法は無いと思うんですが・・・

**名前は開発中のものです。** · 02/05/21 17:41

>>409
君は今まで食べたパンの数を憶えているか？

**409** · 02/05/21 17:56

>>418
覚えてないけど・・・それ、ヒントですか？

**名前は開発中のものです。** · 02/05/21 20:13

>>417
■DirectXのリファレンスぐらい真面目に目を通すように
　　http://www.microsoft.com/japan/developer/library/jpdx8_c/_dx_what_is_the_projection_transformation_graphics.htm
　　http://www.microsoft.com/japan/developer/library/jpdx8_c/_dx_rasterization_graphics.htm
　　http://www.microsoft.com/japan/developer/library/jpdx8_c/_dx_what_are_depth_buffers_graphics.htm

■資料になるページ
　　http://spin.s2c.ne.jp/stoday03.html
　　http://www.cc.rim.or.jp/~devilman/3dCoding/3dPers.html
　　http://www.daionet.gr.jp/~masa/column/98-08-02.html
　　http://www.daionet.gr.jp/~masa/column/98-06-25.html
　　
■２Ｄのアプリの場合、Direct3Dの固定機能T&Lパイプラインを無理に使う必要ない。

　　素直に T&L済み頂点データVertexBufferを使え。
　　アプリ側で各頂点のスクリーン座標を計算して
　　フレーム毎にVertexBufferを書き換える。
　　各頂点のrhw値は天下り式に1/zを入れればいい。
　　このときのz値は
　　例えば2D-STGならば、ゲームの仕様に合わせて

　　弾スプライト用
　　敵機スプライト用
　　自機スプライト用
　　BG用
　　
　　というように区切って、必要な数だけそれぞれに割り当てればいい。

**名前は開発中のものです。** · 02/05/21 20:18

×　各頂点のrhw値は天下り式に1/zを入れればいい。

rhwはz値をそのまま入れていい。パース補正要らないから。

**名前は開発中のものです。** · 02/05/21 20:19

どこまでマジなのか不明なのだが、
Y=aXっていう式に対して、なんでaをわざわざ入れるんですか？
Y=Xでいいじゃないですか？
って聞かれてるような気がするんだが。dは単なる係数でしょ。

**名前は開発中のものです。** · 02/05/21 20:21

テクモはやってくれるな。
http://xboxmovies.ign.com/xbox/video/ninjagaidenxboxmattafact1.mov

**名前は開発中のものです。** · 02/05/21 20:35

>>423
どのへんに「やってくれる」と思った？

**名前は開発中のものです。** · 02/05/21 20:47

氷の人の作品
http://xboxmovies.ign.com/xbox/video/shenmue2_052002_1.mov

**409** · 02/05/21 21:00

>>420-421ありがとう御座います。
z値については、2Dなので基本的に0を入れてたので大丈夫です。
ただ、Lunaのz値の入れ方がおかしいかなって思っただけですので。

rhwはx/y軸に沿って回転させるため、一応パース補正が必要なんですけど・・・
で、rhwは1/zなのは分かりましたが、これは[0,1)に補正されたzでしょうか？
補正前のz(z = 200～500)でも、補正後のzでも(z = 0.0～1.0)出力結果に
差がないので（？）だったんですけど・・・

参考リンク全部読んでみます。
資料ページは一つしか知りませんでした

**名前は開発中のものです。** · 02/05/21 21:43

にゃんでもっと脳を使わないのかにゃ

**名前は開発中のものです。** · 02/05/21 22:28

にゃんこ先生萌え。

**名前は開発中のものです。** · 02/05/21 23:19

にゃにゃん

**名前は開発中のものです。** · 02/05/21 23:53

にゃにゃにゃん

**名前は開発中のものです。** · 02/05/22 00:47

にゃんにゃにゃん

**名前は開発中のものです。** · 02/05/22 00:51

にゃんでもっと脳を使わないのかにゃ

**名前は開発中のものです。** · 02/05/22 01:11

▼ﾟД｡▼にゃん

**名前は開発中のものです。** · 02/05/22 01:27

▼ﾟД｡▼猫たん　フカッ　フカッ

**名前は開発中のものです。** · 02/05/22 01:44

にゃんでもっと脳を使わないのかにゃ

**名前は開発中のものです。** · 02/05/22 02:40

　　　　　　　 ∧＿∧
　　　　＿＿（　´∀｀）にゃん
　　～（　　　　　　）
　　　　ＵＵ￣ＵＵ

**409** · 02/05/22 03:39

あー、馬鹿でｽﾐﾏｾﾝ。何で全然理解できないか分かりました。
DirectXのD3DFVF_XYZRHW、同次座標系での(x, y, z, w)
これらの所為で、３Ｄ座標を(x, y, z, rhw)と訳の分からないとらえ方をしようとしてました。

(x', y', z', 1) = (x/w, y/w,z/w, w/w)
(sx, xy, 1, rhw) = (x'/z, y'/z, z/z, 1/z) #この時点でz=1なので無意味に？

こういう事ですよね？
まだ違ったら目も当てられませんが・・・（涙

**409** · 02/05/22 03:39

s/xy/sy/

**名前は開発中のものです。** · 02/05/22 03:50

>>437 まだ違ったら目も当てられませんが・・・（涙

(´-`)．。oO(目も当てられない)

**名前は開発中のものです。** · 02/05/22 03:57

合体ロボの合体ように、姿勢がばらばらになっているオブジェクトを
それぞれの相対的な姿勢関係の元に回転させたいのですが。

親子関係を持たせて親の姿勢から子へと姿勢を重ねて行くのではなく
全体で無理無く回転させてやりたいのです。
瞬間的に合体するので，最終姿勢のみ必要で，合体中の補間は必要ありません。
おねがいします。

例）2Dの場合 - 角度は絶対的な回転量（姿勢）です
合体前
　objectA＞90°
　objectB＞45°
　objectC＞0°
条件（相対的な姿勢関係）
　A→B 10°
　B→C 10°
合体後
　objectA＞55°
　objectB＞45°
　objectC＞35°