DevDiary : La physique
Samedi 2 août 2008 à 20 h 35
J'avais 2 choix pour la physique:
- utiliser ODE (ou un autre moteur physique)
- coder mon intégrateur
Je n'ai pas pris ODE pour diverses raisons dont celles-ci:
- Il est plus difficil de tweaker (faire des hack/arriver exactement au modèle physique qu'on veut)
- Les performances peuvent rapidement tomber.
J'ai vu une charge CPU anormale dans certains cas. Ces cas sont difficils a éliminer et/ou demande plus de travail
J'ai fait mon "moteur" physique pour ces raisons:
- apprendre à coder un moteur minimaliste
- beaucoup de cas particuliers (intégrateur qui tourne a 1Khz)
- performances: la physique prends 1% du CPU avec les collisions sur 1 athlong 64 3700+
- Le code de la détection de collision est ce qui demande le plus de travail/code et devait de toute facon etre fait meme avec ODE
Alors, comment marche la physique dans le jeu?
Il y a 2 parties +/- distinctes:
- La détection de collisions avec la piste, et les collisions entre vaisseau/missiles/mines
- la physique du vaisseau
Les collisions entre les vaisseaux, et entre tout ce qui n'est pas piste en générale, est super simple.
C'est du sphere-sphere. On détermine la distance au carrée entre les 2 objets. Si elle est inférieure aux carrés des rayons respectifs, il y a collision. Simple.
Pour les balles du machine gun, et les missiles, je fais un raycasting avec les mesh de la piste.
Il y a en plus 1 time to live par entité (sauf les mines). Le raycasting se fait pour les mesh dont la bounding sphere à une collision avec le ray de la velocité de l'objet mobil.
C'est ce qui prends le plus de temps cpu. En utilisant Opcode ou une autre lib du genre, ca diminuerais l'utilisation CPU.
MAIS, vu le faible nombre de missiles/balles/... et leur distribution tout au long du jeu, il y a globalement peu de raycasts dans une session de jeu.
La collision entre les vaisseaux et la route est une grosse gruge.
Voici une image qui décrit super bien la facon dont je gere la chose:
J'une ligne composée d'une multitutide points (tous les 2m) composant le tracé du circuit. Pour chaque point, j'ai un vecteur UP. Le 1er point à (0,1,0) comme vecteur UP.
A cela, et toujours pour chaque point, j'ai un vecteur right. Ce vecteur right est le produit vectoriel entre le UP du point et le vecteur directeur (point courrant - point suivant).
Plus la position du point, j'ai donc un ensemble de matrices.
Sur cette ligne de matrices, j'empile un ensemble de mesh (qui seront deformés). Pour chaque mesh, le designer specifie par script une largeur.
Le vaisseau crée, je lui assigne la matrice dont la position est la plus proche comme matrice courrante.
Maintenant, pour synthétisé la détection de collision, il faut penser au passage sur l'étoile noire de Starwars. Dans la tranchée, le XWing peut se crasher sur le sol, et les cotés.
Il en est de même dans le jeu et dans le manège.
Au rythme de 1Khz, quelque soit le nombre de FPS, je projete la position du vaisseau avec la matrice courrante, ainsi que les 10suivantes et les 10précedentes.
Avec ca, j'ai un scalaire droite gauche, un scalaire haut/bas et 1 scalaire avant/arriere. respectivement sur les vecteur RIGHT, UP et DIRECTION de la matrice.
Rien de plus simple ensuite pour calculer la collision potentielle. Il y a collision droite/gauche si la valeur absolue du scalaire droite/gauche est supérieure a la moitiée de la largeur de la route.
Il y a collision en bas, si le scalaire UP est inférieur a 0. Il n'y a pas de limite en hauteur.
On court dans un couloir. La physique du vaisseau est super simple aussi. J'ai un effet de spring sur la hauteur du vaisseau par rapport a la route. Ce spring marche ainsi. Si le vaisseau est plus haut que
hauteur du sol + 5m, la gravité va vers le bas. Si le vaisseau est entre le sol et sol+5m, on a une gravité vers le haut. C'est ce qui permet d'avoir un effet a la wipeout et qui donne du rebond apres un
saut. Le reste de la physique doit tenir dans le programme de 1ere S (mobile en mouvement, moment d'inertie, toussa).
Tout ca marche plutot bien et est plutot fiable (bien plus que je ne l'aurais imaginé au début).
- utiliser ODE (ou un autre moteur physique)
- coder mon intégrateur
Je n'ai pas pris ODE pour diverses raisons dont celles-ci:
- Il est plus difficil de tweaker (faire des hack/arriver exactement au modèle physique qu'on veut)
- Les performances peuvent rapidement tomber.
J'ai vu une charge CPU anormale dans certains cas. Ces cas sont difficils a éliminer et/ou demande plus de travail
J'ai fait mon "moteur" physique pour ces raisons:
- apprendre à coder un moteur minimaliste
- beaucoup de cas particuliers (intégrateur qui tourne a 1Khz)
- performances: la physique prends 1% du CPU avec les collisions sur 1 athlong 64 3700+
- Le code de la détection de collision est ce qui demande le plus de travail/code et devait de toute facon etre fait meme avec ODE
Alors, comment marche la physique dans le jeu?
Il y a 2 parties +/- distinctes:
- La détection de collisions avec la piste, et les collisions entre vaisseau/missiles/mines
- la physique du vaisseau
Les collisions entre les vaisseaux, et entre tout ce qui n'est pas piste en générale, est super simple.
C'est du sphere-sphere. On détermine la distance au carrée entre les 2 objets. Si elle est inférieure aux carrés des rayons respectifs, il y a collision. Simple.
Pour les balles du machine gun, et les missiles, je fais un raycasting avec les mesh de la piste.
Il y a en plus 1 time to live par entité (sauf les mines). Le raycasting se fait pour les mesh dont la bounding sphere à une collision avec le ray de la velocité de l'objet mobil.
C'est ce qui prends le plus de temps cpu. En utilisant Opcode ou une autre lib du genre, ca diminuerais l'utilisation CPU.
MAIS, vu le faible nombre de missiles/balles/... et leur distribution tout au long du jeu, il y a globalement peu de raycasts dans une session de jeu.
La collision entre les vaisseaux et la route est une grosse gruge.
Voici une image qui décrit super bien la facon dont je gere la chose:
J'une ligne composée d'une multitutide points (tous les 2m) composant le tracé du circuit. Pour chaque point, j'ai un vecteur UP. Le 1er point à (0,1,0) comme vecteur UP.
A cela, et toujours pour chaque point, j'ai un vecteur right. Ce vecteur right est le produit vectoriel entre le UP du point et le vecteur directeur (point courrant - point suivant).
Plus la position du point, j'ai donc un ensemble de matrices.
Sur cette ligne de matrices, j'empile un ensemble de mesh (qui seront deformés). Pour chaque mesh, le designer specifie par script une largeur.
Le vaisseau crée, je lui assigne la matrice dont la position est la plus proche comme matrice courrante.
Maintenant, pour synthétisé la détection de collision, il faut penser au passage sur l'étoile noire de Starwars. Dans la tranchée, le XWing peut se crasher sur le sol, et les cotés.
Il en est de même dans le jeu et dans le manège.
Au rythme de 1Khz, quelque soit le nombre de FPS, je projete la position du vaisseau avec la matrice courrante, ainsi que les 10suivantes et les 10précedentes.
Avec ca, j'ai un scalaire droite gauche, un scalaire haut/bas et 1 scalaire avant/arriere. respectivement sur les vecteur RIGHT, UP et DIRECTION de la matrice.
Rien de plus simple ensuite pour calculer la collision potentielle. Il y a collision droite/gauche si la valeur absolue du scalaire droite/gauche est supérieure a la moitiée de la largeur de la route.
Il y a collision en bas, si le scalaire UP est inférieur a 0. Il n'y a pas de limite en hauteur.
On court dans un couloir. La physique du vaisseau est super simple aussi. J'ai un effet de spring sur la hauteur du vaisseau par rapport a la route. Ce spring marche ainsi. Si le vaisseau est plus haut que
hauteur du sol + 5m, la gravité va vers le bas. Si le vaisseau est entre le sol et sol+5m, on a une gravité vers le haut. C'est ce qui permet d'avoir un effet a la wipeout et qui donne du rebond apres un
saut. Le reste de la physique doit tenir dans le programme de 1ere S (mobile en mouvement, moment d'inertie, toussa).
Tout ca marche plutot bien et est plutot fiable (bien plus que je ne l'aurais imaginé au début).
Quelles sont les conséquences d'un nombre plus petit sur les collisions? Visuellement.
Mais, je pense que 100detections/s suffiraient.
non ?