Connecter des simulations physiques à différents systèmes de coordonnées

Je veux que les objets se déplacent entre deux simulations physiques à travers une "fenêtre" et entrent en collision avec ceux des deux simulations au cas où ils coupent le plan de la fenêtre.

Les systèmes de coordonnées des simulations n'ont pas la même origine et peuvent avoir une orientation différente. Envelopper une simulation en soi n'est pas nécessaire, mais serait un plus.

Comment connecter efficacement les systèmes sans cloner les objets individuels?

Éditer:

Les calculs doivent être aussi précis que possible, afin que les objets ne restent pas coincés s'ils traversent la fenêtre en même temps de côtés opposés.

physics collision-detection

— Tamschi
source

La première question serait: la simulation physique doit-elle être précise à travers la fenêtre? Parce que les changements d'orientation rendent un balayage correct assez impossible. C'est un peu comme des portails à changement d'échelle - un monde de douleur possible. Deuxième question: orientation différente, comme dans des angles arbitraires, ou au moins à 90 degrés, juste un échange d'axe?

— Kaj

Maintenant, cela ressemble à un problème qu'ils devaient résoudre dans Portal. Si je me souviens bien, ils mentionnent ces problèmes et comment ils les ont résolus dans certains commentaires en jeu. Vous pouvez probablement les trouver en ligne quelque part.

— Nailer

@Kaj Je pense qu'il serait préférable de diviser le chemin de calcul pour les transitions arbitraires et à angle droit. De cette façon, les angles droits pourraient avoir une précision et une vitesse plus élevées tandis que d'autres angles seraient également possibles.

— Tamschi du

@Nailer Si je me souviens bien, ils ont créé un nouvel environnement physique pendant l'ouverture du portail, puis cloné tous les objets physiques qui se sont approchés de cette simulation supplémentaire. Ils ont dit qu'ils avaient en quelque sorte contraint les objets, mais il est très probable qu'ils transforment simplement les forces et les positions à chaque étape de la physique. <br> Je suis sûr qu'ils créent un troisième clone à destination en raison de la façon dont le mouvement du joueur est simulé dans Source.

— Tamschi

Réponses:

Il y a ce projet sympa appelé Pseudoform, anciennement connu sous le nom de `` Portalized '', qui gère les simulations physiques en utilisant des portails de manière groovie:

Pseudoforme

Vérifiez-le!

Surtout les vidéos - c'est incroyablement cool.

C'est open source, donc vous pouvez voir comment ils le font.

Je parie que c'est ce que tu veux. :)

— jacmoe
source

Je viens de lire le code: La façon dont ils le font est presque comme la solution de Valve, mais sans l'environnement physique supplémentaire. Les portails du moteur Portalized créent un doublon d'un objet une fois qu'il touche la surface du portail, puis le supprime une fois qu'il a quitté le portail pendant un certain temps. Cette réponse est encore quelque peu utile: le joint utilisé pour contraindre les doublons montre comment l'objet est transformé dans le portail.

— Tamschi

D'accord - je ne sais pas si cela fonctionnerait.
Sur la base des informations ci-dessus, je mettrais des déclencheurs sur les «fenêtres» afin de pouvoir détecter quand un objet sort d'un monde. Saisissez le vecteur de vitesse actuel au moment de la collision. Calculez le pas de temps restant en fonction de l'endroit où il a frappé la gâchette et de l'endroit où il a terminé cette image (en dehors du monde, votre monde aurait besoin d'une bordure virtuelle pour permettre cela). À ce stade, vous connaissez la vitesse et le pas de temps restant, vous pouvez donc le repositionner à la frontière du monde dans lequel il est sur le point d'entrer, et reprojeter la vitesse. Cela nécessiterait cependant deux mises à jour physiques dans une trame, et il y aurait la casse d'un objet allant de a à b tandis qu'un autre passe de b à a à la même position - il n'y aurait aucune collision détectée du tout.
Un peu sommaire,

— Kaj
source

Cela semble être le moyen le plus rapide possible, mais il y a un problème si deux objets traversent la fenêtre du même côté: si le premier objet se coince à mi-chemin de la frontière, le second ne se heurterait pas jusqu'à ce qu'il atteigne la frontière, aussi, et apparaissent à l'intérieur du premier à la destination.

— Tamschi

Modifié légèrement pendant que vous tapiez cela, et c'était effectivement le problème que j'ai ajouté: o \

— Kaj

Je dois apprendre à lire. Mon ajout était un autre cas frontalier. Va réfléchir.

— Kaj

Non, la frontière est en dehors du monde. Ainsi, l'objet un serait tiré dans le monde 2 (à partir de la frontière du monde 2 - pas à la position de la fenêtre) avec sa propre vitesse, comme le serait l'objet b. Ils entreraient en collision dans le monde 2 à la frontière correctement ... Je pense: o? Cependant mon propre cas de frontière tient toujours.

— Kaj

On dirait que j'ai mal lu la partie sur la bordure virtuelle. Quoi qu'il en soit, il y a un autre problème si un objet se coince. La partie située à l'arrière de la fenêtre de destination sera toujours rendue à sa position d'origine, mais les objets qui ne touchent pas la bordure n'entreront pas en collision avec elle. Une façon de résoudre ces problèmes serait d'unifier les simulations, mais je ne sais pas comment cela peut être fait efficacement.

— Tamschi

J'ai lu quelques informations sur les simulations physiques et trouvé une solution possible. Il fonctionne en divisant chaque étape physique en trois phases:

1. Pré-étape:

À chaque étape de la physique, une fenêtre crée quatre transformations, deux de chaque côté de la connexion:

une transformation d'entrée qui transforme la position, la vitesse (et éventuellement la taille et le poids) d'un objet dans le système de coordonnées de destination et
une transformation de sortie qui transforme les forces dans le système d'origine de l'objet.

(Les fenêtres statiques ne doivent le faire qu'une seule fois.)

De plus, les objets de chaque système de coordonnées sont divisés en trois groupes:

Groupement de physique http://content.wuala.com/contents/Tamschi/Stack%20Exchange/WindowGrouping.png

Objets devant la fenêtre (vert).
Un objet est également compté dans ce groupe s'il coupe le plan de la fenêtre ou est susceptible de le traverser par derrière la fenêtre (non illustré).
Objets coupant la fenêtre ou susceptibles de la croiser dans cette étape physique (orange).
Objets derrière la fenêtre (bleu). Si un objet vole vers l'arrière de la fenêtre, il est toujours marqué comme membre du groupe trois.

Le regroupement peut être simplifié si la fenêtre est au bord de la simulation.

2. Étape principale:

La physique est calculée principalement comme d'habitude, à quelques exceptions près:

Les objets du deuxième groupe n'entrent jamais en collision avec ceux du troisième et vice-versa.
La transformation d'entrée de la fenêtre est utilisée sur les objets du deuxième groupe et les résultats sont évalués par rapport aux objets avant et entrecroisés du système de destination. La force résultante est transformée à l'aide de la transformation de sortie et appliquée à l'objet d'origine.

(Si un objet est touché pendant le calcul, il doit être regroupé!)

3. Après l'étape:

Si un objet du deuxième groupe a traversé la fenêtre, il est déplacé dans le système de destination à l'aide de la transformation d'entrée.

Réflexions supplémentaires:

Si les transformations sont conservées après le calcul de la physique, elles peuvent être utilisées pour accélérer le rendu et pour des calculs d'IA plus faciles. Le regroupement pourrait être utilisé pour supprimer les plans de clips du processus de rendu.

L'inconvénient de cette solution est que les fenêtres doivent être ajoutées directement dans le moteur physique.

— Tamschi
source