ttp://www.ageia.com/
建てちゃった・・
物理エンジン AGEIA PhysX
■ このスレッドは過去ログ倉庫に格納されています
2007/10/17(水) 23:41:16ID:JMcE+2Z1
2007/10/18(木) 00:31:44ID:JRQK2+I6
そういえばこんなんあったなー（遠い目）
2007/10/18(木) 00:58:06ID:9YZpwpOS
マルチコアCPUとか普及してるしPhysXチップ意味なしじゃん
ってことで自作PC板では脂肪判定。とっくの昔にスレ消滅
破片とか煙が増えるだけだろ？マルチで不利じゃん
ってことでPCアクション板でも脂肪判定。スレも立たない
PhysX-APIって標準的な地位を築けずにこのまま滅びそうだけど大丈夫？
てことでゲームプログラマにもいまいち受けが良くない
AGEIAは果たしてこの先生きのこれるのか
ってことで自作PC板では脂肪判定。とっくの昔にスレ消滅
破片とか煙が増えるだけだろ？マルチで不利じゃん
ってことでPCアクション板でも脂肪判定。スレも立たない
PhysX-APIって標準的な地位を築けずにこのまま滅びそうだけど大丈夫？
てことでゲームプログラマにもいまいち受けが良くない
AGEIAは果たしてこの先生きのこれるのか
2007/10/18(木) 18:01:28ID:gQs1p2KQ
板チガイ
2007/10/18(木) 20:03:52ID:IVbUtLuv
板違いじゃないがPhysX(NovodeX)限定でお先真っ暗なスレだね
6名前は開発中のものです。
2007/10/20(土) 06:17:23ID:WQsXUYmi ３Dゲーにおける物理計算のスレとしては再利用できない？
2007/10/20(土) 21:47:13ID:dDzVJ6tc
2007/10/21(日) 17:59:46ID:yLVui26L
俺もこういう自作魂が疼くパーツは期待大なのだが
記事の日付を見る限り古いし、自分の記憶でも初出は相当前だしな。
いまとなってはGPGPUなんて言葉が出てきたように
2枚目のGPUに任せる方向性で物理エンジン専門は消えていくんじゃないだろうか。
非常に残念ではあるけどな。
記事の日付を見る限り古いし、自分の記憶でも初出は相当前だしな。
いまとなってはGPGPUなんて言葉が出てきたように
2枚目のGPUに任せる方向性で物理エンジン専門は消えていくんじゃないだろうか。
非常に残念ではあるけどな。
2007/10/21(日) 20:34:16ID:GopKEX1o
SDKに認証が必要ってだけで
失敗確定だっつーの
失敗確定だっつーの
2007/10/21(日) 20:48:41ID:0m1QuAYb
メール送るだけだろ？
2007/10/22(月) 01:48:00ID:LJMiMWVi
メインメモリ→PhysXカード→メインメモリ→ビデオカード
っていう冗長な形でデータ転送をしなきゃならん時点で
あの専用カードは死相が出てた
最低でもPhysXカード(PCI-E)⇔ビデオカード(PCI-E)で
直接データ転送できるような仕組みを作るべきだったね
っていう冗長な形でデータ転送をしなきゃならん時点で
あの専用カードは死相が出てた
最低でもPhysXカード(PCI-E)⇔ビデオカード(PCI-E)で
直接データ転送できるような仕組みを作るべきだったね
2007/10/22(月) 21:10:13ID:bCtKZdb4
でも、データ転送速度は問題にならないとか>> 7に書いてあるけど
2007/10/22(月) 23:08:01ID:MBdJQA8i
っていうか、物理エンジン->描画エンジンへのデータの流れは特にないよな
今まで、適当にやってたオブジェクトの移動シーケンスが
物理現象に沿ったものにすげ変わるだけでしょ
今まで、適当にやってたオブジェクトの移動シーケンスが
物理現象に沿ったものにすげ変わるだけでしょ
2007/10/22(月) 23:14:13ID:bCtKZdb4
いや、今まで出来なかった表現が出来たり
新たなゲーム性が生まれ
新たなゲーム性が生まれ
15名前は開発中のものです。
2007/10/23(火) 01:31:38ID:Q4vQSgmG >>12
ん？PhysX対応の市販ゲー見れば
大抵は物量で押しまくるような使い方になっちゃうって分かるでしょ。
「相互作用を伴う多量の破片エフェクト」みたいなベタな使い方のことね。
安易だけど、PhysX-PPUの効果を分かりやすい形で（視覚的に）体感
させようとすると、あれが一番簡単。
あの手の破片エフェクトをバカ正直にやる場合、大量の変位・回転情報が
出力となってメモリに書き戻される。これをインスタンスモデル生成用データ
（テクスチャ等）としてCPU処理でセットアップし、ビデオカードに転送する。
提灯記事がいくら問題ない問題ないって擁護したって、物量で押しまくる
使い方が喜ばれる以上、あの冗長なデータパスは致命的なのはバカでも分かる。
ん？PhysX対応の市販ゲー見れば
大抵は物量で押しまくるような使い方になっちゃうって分かるでしょ。
「相互作用を伴う多量の破片エフェクト」みたいなベタな使い方のことね。
安易だけど、PhysX-PPUの効果を分かりやすい形で（視覚的に）体感
させようとすると、あれが一番簡単。
あの手の破片エフェクトをバカ正直にやる場合、大量の変位・回転情報が
出力となってメモリに書き戻される。これをインスタンスモデル生成用データ
（テクスチャ等）としてCPU処理でセットアップし、ビデオカードに転送する。
提灯記事がいくら問題ない問題ないって擁護したって、物量で押しまくる
使い方が喜ばれる以上、あの冗長なデータパスは致命的なのはバカでも分かる。
2007/10/23(火) 01:58:23ID:Q4vQSgmG
2007/10/24(水) 21:31:51ID:iFWfGhlk
>バス速度が問題となるのは、物理シミュレーションの結果をCPU(ゲームエンジン側)に戻す時と、
ゲームエンジン側から次のフレーム分のシーンのアップデートをPhysXに行なうときだ。
これらのデータ量は物理シミュレーションのシーンセットアップと比較すると大部少ないために
PCIバスで全くまかなえる範囲であるとHedge氏は語っていた。
>ただし、大量の結果戻しや大量のアップデートが頻発する、
たとえば数千に及ぶパーティクルを物理制御するような場合にはここがボトルネックになることがあるかもしれない。
その場合は、PhysXサブシステムとの入出力同期サイクルを毎フレームではなく、
複数フレームごとに行なったりといった対応が必要になることだろう。
だって
ゲームエンジン側から次のフレーム分のシーンのアップデートをPhysXに行なうときだ。
これらのデータ量は物理シミュレーションのシーンセットアップと比較すると大部少ないために
PCIバスで全くまかなえる範囲であるとHedge氏は語っていた。
>ただし、大量の結果戻しや大量のアップデートが頻発する、
たとえば数千に及ぶパーティクルを物理制御するような場合にはここがボトルネックになることがあるかもしれない。
その場合は、PhysXサブシステムとの入出力同期サイクルを毎フレームではなく、
複数フレームごとに行なったりといった対応が必要になることだろう。
だって
2007/10/24(水) 21:35:07ID:iFWfGhlk
PS3やXbox 360上での活躍に期待
2007/10/30(火) 00:54:53ID:G0mWsV9X
ゲ製的には演算ボードの成功云々よりも無料のSDKが使えるのがポイントでしょ。
ソフトウェア処理については、ODEと比べてもなかなか良いライブラリらしいし。
ソフトウェア処理については、ODEと比べてもなかなか良いライブラリらしいし。
2007/10/30(火) 01:06:50ID:LnLCjAx5
>ODEと比べても
ぉぃぉぃ
土俵が違いすぎる
ぉぃぉぃ
土俵が違いすぎる
2007/10/30(火) 01:26:03ID:G0mWsV9X
何の土俵だよ
無料で使える物理エンジン仲間だろが
無料で使える物理エンジン仲間だろが
■ このスレッドは過去ログ倉庫に格納されています
