Moteur physique capable de gérer plusieurs attracteurs?

Je prépare un jeu qui se jouera principalement avec une gravité en trois dimensions.

J'entends par là plusieurs planètes / étoiles / lunes se comportant de manière réaliste, et le tracé de trajectoire et la prévision de trajectoire dans le champ de gravité.

J'ai examiné une variété de moteurs physiques, tels que Bullet , tokamak ou Newton , mais aucun ne semble convenir, car je devrais essentiellement réécrire le moteur de gravité dans leur cadre.

Connaissez-vous un moteur physique capable de gérer plusieurs corps tous attirés les uns par les autres?

Je n'ai pas besoin de gestion de scénario ou de rendu, juste de la physique de base. (La détection de collision serait un bonus, tout comme la dynamique du corps rigide).

Mon expérience est en physique, je serais donc en mesure d'écrire un moteur qui utilise l'intégration Verlet ou RK4 (ou même l'intégration Euler, si je devais le faire), mais je préférerais de loin adapter une solution standard.

[edit]: Il existe d'excellentes ressources pour la simulation physique des problèmes à n corps en ligne et sur stackoverflow

physics algorithm physics-engine brice
la source

Ne pouvez-vous pas simplement utiliser Bullet et désactiver sa force de gravité standard d'une manière ou d'une autre? (par exemple, évitez d'appeler applyGravity, appelez setGravity avec un vecteur zéro, utilisez BT_DISABLE_WORLD_GRAVITY ...) Ce n'est pas parce que l'effet souhaité est une forme de gravité que vous devez être en mesure de l'atteindre via les API "gravité" de le moteur physique sous-jacent.

Neverender

Vous pouvez utiliser une sorte de ressorts inverses

Roy T.

@RoyT. Un ressort en soi a une force proportionnelle à d alors que la gravité est d ^ (- 2) (pas même d ^ (- 1)). Vous pouvez obtenir des orbites des deux, mais avec des caractéristiques très différentes. Si vous voulez simplement dire «utilisez une contrainte basée sur la distance fournie par le moteur», alors oui - si elle a une carré inverse.

Kevin Reid

@KevinReid vous avez probablement raison, mais je ne suis pas sûr d'avoir votre explication. Voulez-vous dire que les forces du ressort dépendent de la distance et que la gravité dépend du carré inverse?

Roy T.

Osmos est un super petit jeu. le meilleur que j'ai pu trouver était cette interview

brice

Réponses:

Je ne pense pas que vous allez pouvoir utiliser un moteur physique classique à tranches de temps car le problème des trois corps ne permettra pas des orbites stables.

Vous pourrez peut-être extraire le moteur physique de Stellarium ou d'un autre package d'astronomie.

Cependant, je pense que la meilleure solution consiste à simplement cuire sur les chemins de votre planète et à les retirer d'une table. À moins que votre joueur ne puisse réellement affecter la trajectoire des planètes par ses actions, il est inutile de faire une simulation complète.

servetus
la source

En fait, par rapport au problème du N-corps, vous pouvez obtenir des orbites stables. Cela dépend de votre méthode d'intégration. J'ai réussi des orbites stables avec Verlet et RK4.

brice

C'est une bonne suggestion de pré-calculer les chemins, mais j'aimerais générer dynamiquement les systèmes à la volée, et aussi, les planètes ne sont pas vraiment ce qui m'inquiète. En fait, je veux que les navires soient affectés par la gravité, et puisque ceux-ci seront sous le contrôle des joueurs, je ne peux pas pré-calculer les chemins.

brice

La façon d'obtenir des orbites stables, pour mémoire, est de créer des systèmes symétriques. De plus, les délais d'instabilité sont beaucoup plus longs que la durée d'un jeu moyen. (instable sur 100s à 1000s d'orbites planétaires, alors que le jeu ne durerait pas plus de 4/5)

brice

Pour des exemples d'orbites stables, jetez un œil à ceci (utilise Verlet)

brice

Y a-t-il une limitation de plate-forme? Parce que PhysX , de nVidia, a exactement ce que vous recherchez, et plus encore .

YuriAlbuquerque
la source

Cheers @YuriAlbuquerque, c'est une piste assez intéressante. Je prévois de faire de la physique côté serveur et du rendu côté client, donc je vais devoir vérifier si ça convient, mais ça sonne bien.

brice