物理エンジン　AGEIA PhysX

**名前は開発中のものです。** · 2007/10/17(水) 23:41:16

ttp://www.ageia.com/
建てちゃった・・

**名前は開発中のものです。** · 2007/10/18(木) 00:31:44

そういえばこんなんあったなー（遠い目）

**名前は開発中のものです。** · 2007/10/18(木) 00:58:06

マルチコアCPUとか普及してるしPhysXチップ意味なしじゃん
ってことで自作PC板では脂肪判定。とっくの昔にスレ消滅

破片とか煙が増えるだけだろ？マルチで不利じゃん
ってことでPCアクション板でも脂肪判定。スレも立たない

PhysX-APIって標準的な地位を築けずにこのまま滅びそうだけど大丈夫？
てことでゲームプログラマにもいまいち受けが良くない

AGEIAは果たしてこの先生きのこれるのか

**名前は開発中のものです。** · 2007/10/18(木) 18:01:28

板チガイ

**名前は開発中のものです。** · 2007/10/18(木) 20:03:52

板違いじゃないがPhysX(NovodeX)限定でお先真っ暗なスレだね

**名前は開発中のものです。** · 2007/10/20(土) 06:17:23

３Dゲーにおける物理計算のスレとしては再利用できない？

**名前は開発中のものです。** · 2007/10/20(土) 21:47:13

http://www.watch.impress.co.jp/game/docs/20060325/physx.htm
面白そうじゃん

**名前は開発中のものです。** · 2007/10/21(日) 17:59:46

俺もこういう自作魂が疼くパーツは期待大なのだが
記事の日付を見る限り古いし、自分の記憶でも初出は相当前だしな。

いまとなってはGPGPUなんて言葉が出てきたように
2枚目のGPUに任せる方向性で物理エンジン専門は消えていくんじゃないだろうか。
非常に残念ではあるけどな。

**名前は開発中のものです。** · 2007/10/21(日) 20:34:16

SDKに認証が必要ってだけで
失敗確定だっつーの

**名前は開発中のものです。** · 2007/10/21(日) 20:48:41

メール送るだけだろ？

**名前は開発中のものです。** · 2007/10/22(月) 01:48:00

メインメモリ→PhysXカード→メインメモリ→ビデオカード
っていう冗長な形でデータ転送をしなきゃならん時点で
あの専用カードは死相が出てた

最低でもPhysXカード(PCI-E)⇔ビデオカード(PCI-E)で
直接データ転送できるような仕組みを作るべきだったね

**名前は開発中のものです。** · 2007/10/22(月) 21:10:13

でも、データ転送速度は問題にならないとか>> 7に書いてあるけど

**名前は開発中のものです。** · 2007/10/22(月) 23:08:01

っていうか、物理エンジン->描画エンジンへのデータの流れは特にないよな
今まで、適当にやってたオブジェクトの移動シーケンスが
物理現象に沿ったものにすげ変わるだけでしょ

**名前は開発中のものです。** · 2007/10/22(月) 23:14:13

いや、今まで出来なかった表現が出来たり
新たなゲーム性が生まれ

**名前は開発中のものです。** · 2007/10/23(火) 01:31:38

>>12
ん？PhysX対応の市販ゲー見れば
大抵は物量で押しまくるような使い方になっちゃうって分かるでしょ。
「相互作用を伴う多量の破片エフェクト」みたいなベタな使い方のことね。
安易だけど、PhysX-PPUの効果を分かりやすい形で（視覚的に）体感
させようとすると、あれが一番簡単。

あの手の破片エフェクトをバカ正直にやる場合、大量の変位・回転情報が
出力となってメモリに書き戻される。これをインスタンスモデル生成用データ
（テクスチャ等）としてCPU処理でセットアップし、ビデオカードに転送する。

提灯記事がいくら問題ない問題ないって擁護したって、物量で押しまくる
使い方が喜ばれる以上、あの冗長なデータパスは致命的なのはバカでも分かる。

**名前は開発中のものです。** · 2007/10/23(火) 01:58:23

レスアンカーを微妙に間違えた
>>12と>>13宛てかな

**名前は開発中のものです。** · 2007/10/24(水) 21:31:51

>バス速度が問題となるのは、物理シミュレーションの結果をCPU(ゲームエンジン側)に戻す時と、
ゲームエンジン側から次のフレーム分のシーンのアップデートをPhysXに行なうときだ。
これらのデータ量は物理シミュレーションのシーンセットアップと比較すると大部少ないために
PCIバスで全くまかなえる範囲であるとHedge氏は語っていた。

>ただし、大量の結果戻しや大量のアップデートが頻発する、
たとえば数千に及ぶパーティクルを物理制御するような場合にはここがボトルネックになることがあるかもしれない。
その場合は、PhysXサブシステムとの入出力同期サイクルを毎フレームではなく、
複数フレームごとに行なったりといった対応が必要になることだろう。

だって

**名前は開発中のものです。** · 2007/10/24(水) 21:35:07

PS3やXbox 360上での活躍に期待

**名前は開発中のものです。** · 2007/10/30(火) 00:54:53

ゲ製的には演算ボードの成功云々よりも無料のSDKが使えるのがポイントでしょ。
ソフトウェア処理については、ODEと比べてもなかなか良いライブラリらしいし。

物理エンジン AGEIA PhysX

物理エンジン　AGEIA PhysX