タグ付けされた質問 「physics」

2D宇宙ゲームを作成していますが、宇宙船が惑星を妨害する必要があります。直線切片の作業コードはありますが、円軌道での惑星の位置の計算方法がわかりません。 ゲームは科学的に正確ではないので、慣性、重力、楕円軌道などについて心配していません。 宇宙船の位置と速度、そして惑星の軌道（半径）と速度も知っています。

23 2d  mathematics  physics 

私はCoronaを使用して2D iPhoneゲームに取り組んでいます（試用版なので、フォーラムを使用できません）。このゲームでは、キャラクターが空を落ちていくので、私はキャラクターに「ダブルジャンプ」を実装しようとしています。私はコロナの物理ライブラリを使用してキャラクターを倒しましたが、これまでのところ、彼にジャンプさせる最良の方法は垂直インパルス法を使用することです object:applyLinearImpulse(0, -0.4, object.x, object.y) 私が直面している問題は、キャラクターが始まったばかりのとき（垂直速度が遅い）、彼は本当に高くジャンプし、しばらく落ちているとき（垂直速度が高い）、ジャンプは無視できることです。速度に関係なくジャンプを同じにするために、入力として速度を使用したある種の方程式を使用することが最善の解決策であると推測していますが、その方程式がどうなるかはわかりません。 さて、それで私の考えはすべてです。最後の質問は、物理学で二重ジャンプをどのように正確に実装するのですか？私の問題に適切な方程式はありますか？別のアプローチを取るべきですか？スマッシュブラザーズなどのゲームで以前に行われたことがありますので、再現可能なソリューションがありますよね？

23 2d  physics 

互いに引き寄せられるサイズと速度がさまざまなオブジェクトがたくさんあります。更新するたびに、すべてのオブジェクトを調べて、他のすべてのオブジェクトの重力による力を加算する必要があります。それはあまりうまくスケールせず、ゲームで見つけた2つの大きなボトルネックの1つであり、パフォーマンスを改善するために何をすべきかわかりません。 パフォーマンスを改善できるはずだと感じています。常に、システム内のオブジェクトの99％がオブジェクトに与える影響はごくわずかです。もちろん、オブジェクトを質量でソートすることはできず、力は質量よりも距離によって大きく変化するため、上位10個の最大オブジェクトまたは何かのみを考慮することができます（方程式はに沿っていますforce = mass1 * mass2 / distance^2）。何かに影響を与えないかもしれない世界の反対側にある何百もの小さな岩の断片を無視して、最大のオブジェクトと最も近いオブジェクトを考慮することは良い近似だと思いますが、どのオブジェクトが最も近い私はすべてのオブジェクトを反復処理する必要があり、それらの位置は絶えず変化しています、それで私が一度だけできるのではない。 現在、私はこのようなことをしています： private void UpdateBodies(List<GravitatingObject> bodies, GameTime gameTime) { for (int i = 0; i < bodies.Count; i++) { bodies[i].Update(i); } } //... public virtual void Update(int systemIndex) { for (int i = systemIndex + 1; i < system.MassiveBodies.Count; i++) { GravitatingObject body …

23 xna  algorithm  physics  optimization 

トップダウンの2D XNAゲームを書いています。最初の頃から、物理学と衝突に関するものを自分で書いて、それを学習しようとしています。 プレーヤーのスプライトキャラクターが境界が壁の端と交差する位置に移動しようとするたびに、跳ね返り角度（入射角=反射の角度）を計算し、プレーヤーを壁から跳ね返して衝突を回避します。 角に当たったとしても、スプライトが2つの壁のエッジと同時に交差する状況をどのように処理するかを考えるのに苦労しています。 私のコードでは現在、2つの壁のエッジが交差しているが、どちらのエッジが最初にヒットしたか、したがってどのエッジが跳ね返ったかはわかりません。 どのエッジを跳ね返すかを選択する数学的テストは何ですか？見てみるとわかりやすいですが、数学テストを理解するのに苦労しています。

22 xna  2d  collision-detection  physics  collision-resolution 

この質問は、衝突の検出と解決に関する以前の質問からの「フォローアップ」質問であり、こちらで見つけることができます。 前の質問を読みたくない場合は、私の物理エンジンがどのように機能するかについて簡単に説明します。 すべての物理エンティティは、SSSPBodyと呼ばれるクラスに格納されます。 AABBのみがサポートされています。 すべてのSSSPBodyは、すべてのボディを更新し、重力を処理するSSSPWorldと呼ばれるクラスに格納されます。 すべてのフレームで、SSSPWorldはすべてのボディを更新します。 更新されたすべてのボディは、空間ハッシュで近くのボディを探し、それらとの衝突を検出する必要があるかどうかをチェックします。「はい」の場合、「衝突」イベントを呼び出し、それらとの衝突を解決する必要があるかどうかを確認します。はいの場合、侵入ベクトルと方向の重なりを計算し、侵入を解決するために位置を変更します。 ボディが他のボディと衝突すると、ボディの速度をそれ自体に設定するだけで、ボディの速度が他のボディに転送されます。 ボディの速度は、最後のフレームから位置を変更していない場合、0に設定されます。また、移動する物体（リフトや移動するプラットフォームなど）と衝突する場合、リフトの移動差を計算して、物体が最後の位置から移動していないかどうかを確認します。 また、ボディは、AABBのすべての角がフレーム内の何かと重なったときに「クラッシュ」イベントを呼び出します。 これは私のゲームの完全なソースコードです。3つのプロジェクトに分かれています。SFMLStartは、エンティティの入力、描画、更新を処理するシンプルなライブラリです。SFMLStartPhysicsは、SSSPBodyクラスとSSSPWorldクラスがある最も重要なものです。PlatformerPhysicsTestは、すべてのゲームロジックを含むゲームプロジェクトです。 そしてこれは、SSSPBodyクラスの「更新」メソッドであり、コメント化および簡略化されています。SFMLStartSimplePhysicsプロジェクト全体を見たくない場合にのみ、これを見ることができます。（そして、たとえ行ったとしても、コメントされているので、これを見てください。） .gifは2つの問題を示しています。 ボディが異なる順序で配置されている場合、異なる結果が発生します。左側のクレートは右側のクレートと同じで、逆順でのみ配置されます（エディターで）。 両方のクレートを画面の上部に向けて推進する必要があります。左側の状況では、木枠は推進されません。右側では、そのうちの1つだけです。両方の状況は意図していません。 最初の問題：更新の順序 これはかなり簡単に理解できます。左側の状況では、最上位のクレートが他のクレートの前に更新されます。下部のクレートが速度を他のクレートに「転送」しても、次のフレームが移動するのを待つ必要があります。移動しなかったため、下枠の速度は0に設定されます。 これを修正する方法がわかりません。物理エンジンの設計全体で何か間違ったことをしていると感じているため、更新リストの「ソート」に依存しないソリューションを好むでしょう。 主要な物理エンジン（Box2D、Bullet、Chipmunk）は更新順序をどのように処理しますか？ 2番目の問題：1つのクレートのみが天井に向かって推進されます 私はまだこれが起こる理由を理解していません。「スプリング」エンティティが行うことは、ボディの速度を-4000に設定し、スプリング自体の上に再配置します。再配置コードを無効にしても、問題は引き続き発生します。 私の考えは、下のクレートが上のクレートと衝突すると、その速度は0に設定されるということです。これがなぜ起こるのかわかりません。 最初の問題をあきらめる誰かのように見える可能性にもかかわらず、私は上記のプロジェクトソースコード全体を投稿しました。私はそれを証明するものは何もありませんが、信じてください、私はこれを修正するために一生懸命努力しましたが、解決策を見つけることができず、物理学と衝突に関する以前の経験はありません。私はこれらの2つの問題を1週間以上解決しようとしてきましたが、今は必死です。 ゲームから多くの機能（速度転送やスプリングなど）を取り除くことなく、自分で解決策を見つけることはできないと思います。 この質問を読んでくれてありがとう。また、解決策や提案を考えてみてください。

22 c#  collision-detection  physics  .net  aabb 

リアルなピザを作成し、ユーザーがそれを操作できるようにします。 私が欲しいもの： 私が作成したもの： Blenderでピザのモデル（8個）を作成し、Unityにインポートしました。ピザのピースは非常に人工的に見えますが、その主な理由は「堅い三角形」です。 ユーザーがピースを動かしたときにチーズを伸ばしたり壊したりするにはどうすればよいですか？

21 unity  3d  physics  blender  soft-body-dynamics 

アンチエイリアシングによるぼかし効果を避けるために、正確なピクセル座標でスプライトをレンダリングしています（スプライトはピクセルアートであり、フィルター処理するとひどく見えます）。ただし、オブジェクトの移動には可変速度、重力、物理的相互作用が含まれるため、軌跡はサブピクセル精度で計算されます。 スクリーンスペースの速度が十分に大きい場合（vΔtが2または3ピクセルより大きい場合）、これは非常にうまく機能します。ただし、速度が小さい場合、特に対角線に沿って顕著な階段効果が現れることがあります。これは、非常に遅い画面空間速度（v << 1ピクセル/秒）ではもはや問題ではないため、中間速度値のソリューションを探しています。 左側には、オブジェクト座標を単純に丸めることで得られる、大きな速度のプロットされた軌跡があります。中央では、速度が小さくなると何が起こるか、そして私が話している階段効果を見ることができます。右側に、取得したい軌跡の軌跡を示します。 大小の速度で元の動作を維持しながら、エイリアシングを最小限に抑えるために軌跡をフィルタリングするアルゴリズムのアイデアに興味があります。Δt、瞬時の位置と速度、および任意の数の以前の値にアクセスできますが、リアルタイムシミュレーションであるため、将来の値については知りません（必要な場合、特定の仮定の下で推定値を推定できます） 。物理シミュレーションのため、突然の方向変更も発生する可能性があることに注意してください。

21 physics  interpolation  trajectory  pixel 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Game Development Stack Exchangeで話題になるようにします。 8か月前に閉鎖されました。 これらの素晴らしいスライドの最後に、著者は提示されたすべての異なるインテグレーターを比較します。いずれにせよ、改善されたオイラー統合とルンゲ・クッタ4統合を除き、それらはすべて不足しています。どちらもすべてのテストに合格します。 物理学をあまり重視していない 2Dゲームに取り組んでいることに言及する必要があると思います。改善されたオイラー統合がどこで不足し、代わりにRK4を使用する必要があるかについて、私は興味があります。 私のゲームは、主に単純な重力（ジャンプと落下）、X軸とY軸に沿った動き、境界ボックスの衝突で構成されています。RK4を実装する価値はありますか、または改良型オイラーで十分ですか？Euler Integrationのユーザーが懲戒される多くの議論を見ますが、私が見ることができることから、改良されたEulerは単純な2Dの問題に相当します。それも速くなると思います。

20 physics  rk4  integration 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Game Development Stack Exchangeで話題になるようにします。 4年前に閉鎖されました。 この時点で、プラットフォームとプログラミング言語は関係ありません。このために何かが存在するかどうかを知りたいだけです。どんな助けも大歓迎です。

20 2d  physics 

ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 6年前に閉鎖されました。 私が作った最も高度なゲームは、物理エンジンBox2dFlashAS3で作られた8ボールプールゲームとレベルのあるプラットフォームゲームです。 プラットフォームゲームをするとき、エンジンを再利用できるように、エンジンの作り方を常に知りたいと思っていました。斜面、曲線の斜面、完全な重力、現実の物理学を備えたゲームを見たとき、エンジンのコーディング方法を知っていたらと思っていました。 関連する知識ベースが必要な場合は、テクニックや記事を提案してください。

20 architecture  physics  physics-engine 

私は最近、ゲームでフレームレートのジッターの問題に対処していますが、最適な解決策は、クラシックなFix Your Timestepで Glenn Fiedler（ゲームのGaffer）によって提案されたものだと思われます！記事。 今-私はすでに更新のために固定タイムステップを使用しています。問題は、レンダリングのために提案された補間を行っていないことです。その結果、レンダリングレートが更新レートと一致しない場合、フレームが2倍またはスキップされます。これらは視覚的に顕著です。 それで、ゲームに補間を追加したいと思います-そして、これをサポートするために他の人がどのようにデータとコードを構造化したか知りたいです。 明らかに、レンダラーに関連するゲーム状態情報の2つのコピーを（どこで/どのように）保存する必要があります。 さらに-これはスレッドを追加するのに適した場所のようです。更新スレッドはゲーム状態の3番目のコピーで動作し、他の2つのコピーをレンダリングスレッドの読み取り専用のままにしておくことができると思います。（これはいい考えですか？） -ゲームの状態の二、三のバージョンを持つことは、パフォーマンスを紹介してできているようですはるかにもっと重要なこと-信頼性と開発者の生産性の問題を、単に1つのバージョンを持つに比べて。ですから、私はこれらの問題を軽減する方法に特に興味があります。 特に注意すべきなのは、ゲームの状態に対するオブジェクトの追加と削除の処理方法の問題です。 最後に、いくつかの状態はレンダリングに直接必要ではないか、異なるバージョン（たとえば、単一の状態を保存するサードパーティの物理エンジン）を追跡するのが難しすぎるようです-そのため、どのように知りたい人々はそのようなシステム内でそのようなデータを処理しました。

20 physics  multithreading  fixed-timestep  interpolation 

2D空間でフォローを実装する方法のアイデアを探しています。残念ながら、AI /パスの検索/自律制御についてはまだあまり知りません。 この船は自由に移動できるが、質量と勢いがあるとしましょう。また、外力がそれに影響を及ぼす可能性があります（爆発など）。プレイヤーはいつでも船の目標を設定でき、その場所に到達して停止するはずです。 物理学がなければ、これは簡単で、ただ方向を指して進むだけです。しかし、既存の勢いに対処し、その場で停止する方法は？船の配置を直接変更したくありません。 編集：明確にするために、船自体の物理学関連の数学は問題ではありません。

19 physics  ai  path-finding  movement 

私は最後の48時間をオブジェクトコンポーネントシステムに目を通し、それを実装する準備が十分に整ったと感じています。基本のObjectクラスとComponentクラスを作成しましたが、実際のコンポーネントの作成を開始する必要があるため、少し混乱しています。HealthComponentまたは基本的に単なるプロパティのようなものでそれらを考えるとき、それは完全に理にかなっています。物理/グラフィックコンポーネントとしてより一般的なものである場合、少し混乱します。 これまでのところ、私のオブジェクトクラスは次のようになっています（変更が必要な場合は、まだ新しいことをお知らせください）。 typedef unsigned int ID; class GameObject { public: GameObject(ID id, Ogre::String name = ""); ~GameObject(); ID &getID(); Ogre::String &getName(); virtual void update() = 0; // Component Functions void addComponent(Component *component); void removeComponent(Ogre::String familyName); template<typename T> T* getComponent(Ogre::String familyName) { return dynamic_cast<T*>(m_components[familyName]); } protected: // Properties ID m_ID; Ogre::String …

19 architecture  physics  graphics  component-based  game-component 

私のゲームでは、キャラクターが棚をつかんで保持できるようにし、そうする余裕があれば自分自身を引き上げることができるようにします。 棚があるかどうか、キャラクターが登るのに十分なスペースがあるかどうかを検出するにはどうすればよいですか？

18 physics 

2Dプラットフォームゲーム用の物理エンジンを開発しています。衝突検出に分離軸定理を使用しています。地面は、プレーヤーを軸に合わせた境界ボックスとして、方向付けられた境界ボックスから構築されます。（具体的には、SATを使用してOBBのスイープ衝突検出を実行する「Realtime Collision Detection」という本のアルゴリズムを使用しています）。動的オブジェクトが環境に侵入しないように、衝突応答でかなり小さな（ゼロに近い）復元係数を使用しています。 エンジンはほとんど正常に動作しますが、発生する可能性のあるいくつかのエッジケースについて心配しているだけです。たとえば、図では、A、B、Cが地面です。プレーヤーはBに沿ってAに向かって左に向かっています。不正確なため、プレーヤーボックスはボックスBのわずかに下にある可能性があります。したがって、Aに到達すると、プレーヤーの左下隅がAの右側と衝突する可能性がありますが、これは望ましくありません（プレーヤーがAの上部をスムーズに移動するためです）。プレイヤーがボックスCの上にいて、Bに向かって左に移動すると、同様の問題が発生するようです-プレイヤーの左下隅が上下にスライドする代わりに、Bの最も極端なポイントがプレイヤーの左側と衝突する可能性がありますBの上 Box2Dは、エッジ形状の接続情報を保存することでこの問題を処理しているように見えますが、この情報を使用して問題を解決する方法がよくわかりません。 どんな提案も大歓迎です。

18 2d  physics  platform