Le fait de montrer une collision au ralenti est-il relaxant sur le plan informatique?

Dans de nombreux jeux de course ( Burnout Paradise , par exemple) lorsqu'une collision est sur le point de se produire, le jeu passe automatiquement au ralenti et se poursuit lentement jusqu'à la fin de la collision.

J'ai toujours pensé que c'était pour les effets. Vous ne voulez manquer aucune partie de la collision! Mais un de mes amis a récemment suggéré que cela soit fait pour s'assurer qu'il n'y a pas un taux écrasant de traitement requis en cas de collision.

Maintenant, je pense que c'est en fait l'inverse. Lorsqu'une collision se produit, tant de détails sont affichés au ralenti, je suis sûr qu'il y a un surcoût sur le pipeline de calcul et de rendu.

Qu'est-ce qui est correct?

Une scène au ralenti augmente-t-elle l'utilisation du processeur / GPU ou la diminue-t-elle?

Si vous exécutez votre simulation physique avec un pas de temps fixe (comme vous le devriez), alors un ralenti mettra moins de charge sur la simulation physique, car moins de calculs devront être effectués par image.

Supposons que vous exécutez votre physique avec 200 mises à jour par seconde. Par exemple. une mise à jour toutes les 0.005secondes de temps de simulation. Lors de l'exécution du jeu avec 50 mises à jour par seconde, cela entraînerait 4 mises à jour physiques par mise à jour de rendu. Maintenant, vous exécutez le jeu au ralenti, ce qui signifie que vous ralentissez le temps de simulation. Donc, si le jeu fonctionne toujours à 50 mises à jour par seconde ( 0.02secondes de temps de simulation), mais que vous montrez le monde au ralenti (disons la moitié de la vitesse), alors une image équivaudrait à des 0.01secondes de temps de simulation. Donc, seulement 2 mises à jour physiques par image rendue. Cela signifie moins de calculs physiques par image rendue.

Donc, si vous le regardez du point de vue de l'utilisation du processeur par image rendue, le ralenti est moins lourd (à moins que vous ne choisissiez d'augmenter votre taux de simulation physique pendant le ralenti). La charge GPU par image est bien sûr à peu près constante.

Si vous posez des questions sur la charge cumulée CPU / GPU pendant la durée d'une collision , alors évidemment la simulation physique est la même, que ce soit au ralenti ou à vitesse normale. La charge du GPU sera plus élevée, car vous restituez plus d'images.

Il est possible que ce soit le cas. À moins que vous ne fassiez de la physique pour la collision sur le GPU, cela signifie s'accroupir pour cela. Mais en termes de physique elle-même ... c'est possible.

Si vous simulez le mouvement d'un certain nombre de corps, ils ont tendance à se déplacer de manière très prévisible. Les forces et les champs de force (par exemple: la gravité) sont facilement prévisibles. L'endroit où les choses bougent est rapidement calculé.

Jusqu'à ce qu'une chose en frappe une autre. Vous voyez, en physique, vous avez ce qu'on appelle une tranche de temps; c'est le temps que couvre l'exécution du système de physique. Si votre tranche de temps couvre 1 / 30e de seconde (30 images par seconde pour la mise à jour physique), chaque mise à jour physique déplace les objets de 33,3 millisecondes dans le futur.

Lorsque les objets ne se heurtent pas, vous pouvez simplement les déplacer du début de ces 33,3 ms à la fin. La physique pour ce faire est simple et est bien connue depuis des siècles. Vous déterminez simplement l'accélération à partir des forces nettes, appliquez cette accélération pour la tranche de temps à l'objet et déplacez-la à sa nouvelle vitesse (remarque: cela peut être plus complexe si vous voulez une plus grande précision).

Le problème est lorsque des objets entrent en collision. Soudain, vous devez maintenant traiter les forces physiques dans une tranche de temps, plutôt qu'une seule fois au début. Si un objet entre en collision deux ou trois fois dans un cadre physique, c'est plus de calculs physiques que vous devez refaire.

Si vous avez beaucoup de collisions dans une tranche de temps, vous pouvez vraiment tuer votre framerate. Cependant, le risque de collisions multiples au sein d'une tranche de temps diminue à mesure que la taille de la tranche de temps diminue. Les sims de course haut de gamme comme Forza et Gran Turismo exécutent leurs systèmes physiques à des fréquences d'images incroyables. Je pense que l'un d'eux obtient jusqu'à 300 + fps sur sa mise à jour physique.

Le ralenti est l'équivalent efficace de cela. En diminuant la tranche de temps de la physique sans augmenter également le framerate de rendu pour compenser, le monde apparaît plus lentement. Et par conséquent, vous réduisez considérablement la probabilité d'obtenir plusieurs collisions dans une tranche de temps.

Cela étant dit, je doute que c'est pourquoi des jeux comme celui-ci se mettent au ralenti. En général, c'est plus pour le flair visuel et la présentation dramatique. Ces systèmes physiques peuvent généralement le gérer, en termes de performances.

Tout d'abord, cela se fait pour l'effet visuel, pas pour des raisons de performances.

La manière standard de gérer les performances dans les jeux lourds en physique est de mettre à l'échelle le nombre d'objets, de mettre à l'échelle la complexité des objets et de jouer avec les paramètres du moteur pour passer de la précision de la simulation à la performance. S'il y a des problèmes, vous supprimez ce que vous percevez comme les fonctionnalités les moins importantes.

N'oubliez pas cependant que l'industrie a créé des jeux de voiture assez réalistes au cours des 15 dernières années, avec les ordinateurs modernes, ce n'est pas comme s'ils devaient passer à 3 roues pour faire fonctionner les choses.

Le problème:
Il est vrai qu'une collision peut entraîner un travail supplémentaire, combien dépend beaucoup des spécificités du jeu, un moteur physique plus détaillé aura beaucoup de petites collisions entre différentes parties qui peuvent constituer une augmentation significative du calcul requis . Mais cela devrait être pris en compte lorsque la physique est mise à l'échelle, ce n'est pas un problème pour obtenir une bonne physique qui peut encore gérer certaines collisions.

Si vous exécutez simplement la simulation physique plus lentement pour obtenir un ralenti, la charge diminuera proportionnellement. Cependant, il convient de noter que les exigences en matière de ralenti et de physique en temps réel sont différentes, vous pouvez vous permettre d'avoir une précision inférieure lorsque les choses se produisent à la vitesse de course. Tant que le joueur ne remarque pas que le moteur physique est mauvais, ce n'est pas un gros problème, le ralenti rend les glissements beaucoup plus faciles à attraper, donc le ralenti a une exigence de précision plus élevée.

On peut choisir d'utiliser la même physique, mise à l'échelle pour répondre aux deux ensembles d'exigences. Cette solution nécessitera une puissance de traitement supplémentaire, mais elle est facile à mettre en œuvre et compte tenu des ordinateurs modernes parfaitement viables.

Changer les paramètres physiques est plus compliqué, mais peut potentiellement entraîner de magnifiques collisions, non seulement on peut augmenter la précision, mais il est également possible de changer les modèles physiques des voitures pour des modèles plus détaillés qui se cassent de manière plus réaliste. Ce mode devrait finir par utiliser approximativement la même quantité de temps CPU pour la physique que le mode normal, tout simplement parce qu'ils sont tous deux mis à l'échelle pour fonctionner avec la même configuration minspec.

Une solution intermédiaire consiste à utiliser un moteur de physique à pas variable, ceux-ci augmenteront généralement la précision lorsque vous ralentirez la simulation, résolvant ainsi au moins une partie du problème. Il existe d'autres raisons de ne pas utiliser la physique à pas variable, mais le pas variable est encore assez courant dans l'industrie.