OpenGL vs physique?

Je suis très nouveau dans la programmation de jeux et je suis dans mon premier projet. Je suis arrivé à un point où j'ai besoin de conseils d'experts:

Maintenant, pour que la physique du jeu puisse travailler sur des objets, elle doit connaître la position de chaque objet et son orientation dans l'espace 3D. Dans le cadre de la simulation et en raison des mouvements d'objets (changement de position) et des changements d'orientation (rotation).

Est-ce à dire que les calculs de rotation et de translation se font deux fois? L'un en physique et l'autre se fait en utilisant glTranslate et glRotate avant de dessiner l'objet?

OMI, cela ne devrait pas se produire. Le calcul de la translation et de la rotation dans la partie physique les amènera également à utiliser le CPU au lieu du GPU, ce qui affectera les performances.

Comment les experts procèdent-ils et quels conseils donnez-vous sur une architecture de jeu efficace pour gérer de telles situations?

Il y a un certain nombre de raisons pour lesquelles les pipelines de rendu et de physique ont toujours été discrets. Gardez à l'esprit lorsque je les énumère, qu'il ne s'agit pas uniquement de jeux. Votre question concerne toute application qui utilise une technologie de rendu 3D comme OpenGL, ses concurrents ou ses précurseurs.

• Toutes les applications qui utilisent la 3D n'ont pas besoin de physique. N'oubliez pas qu'OpenGL n'a pas été conçu uniquement pour les jeux, son utilisation couvre tout, des simulations médicales à la modélisation des statistiques de vente, des simulations de trafic aérien aux réactions chimiques complexes, etc.

• Tout système qui sert à trop d'objectifs se dilue en termes d'efficacité. Un pipeline graphique doit être incroyablement rapide. Au moment où vous commencez à introduire des points où ce pipeline doit s'interfacer avec d'autres sous-systèmes tels que la mémoire système principale (où réside votre code), vous allez constater des réductions de l'ordre de grandeur de l'efficacité. Le matériel de votre carte graphique est très spécifiquement rétréci et ultra-optimisé pour pousser les pixels , à un coût élevé et de nombreuses années de recherche hautement compétitive.

• La nature des mathématiques et des structures de données entourant les opérations physiques (en particulier la détection et la résolution des collisions, sans lesquelles il n'y a vraiment pas de physique ) est très différente des mathématiques requises pour le rendu.

• Il existe des solutions qui traitent de la physique dans le matériel. Mais contrairement à la façon dont nous rendons, la façon dont nous effectuons la physique dans une situation donnée diffère considérablement. L'indication la plus fondamentale de cela est que la physique newtonienne n'est pas universelle; il existe d'autres méthodes de modélisation mathématique de la physique qui sont plus appropriées dans d'autres situations, comme la mécanique hamiltonienne. Et dans les jeux en particulier, chaque jeu individuel peut choisir de modéliser sa physique différemment, que ce soit en 2D ou en 3D. Ceux-ci n'ont même pas besoin de refléter la physique du monde réel! - parce qu'un jeu est un produit de l'imagination. En d'autres termes, la physique fait finalement partie de la dynamique de votre jeu, et cela peut changer d'un jeu à l'autre - sans parler de toutes les autres solutions auxquelles des technologies comme OpenGL sont appliquées.

• Simuler avec précision la physique au niveau sommet par sommet n'est, pour la plupart, pas actuellement une option viable. Étant donné le nombre élevé de poly des modèles dans la plupart des jeux et la difficulté inhérente à la détection des collisions impliquant des polyèdres concaves, ce n'est pas aussi simple que de simplement calculer la physique à partir du modèle fourni. Pour de nombreux jeux 3D, sinon la plupart, des volumes englobants sous forme de cylindres ou de boîtes sont utilisés pour simplifier la détection de collision, où ce type de niveau de détection de collision est même requis. Compte tenu de la technologie actuelle, le niveau de traitement impliqué ne laisserait pas beaucoup de place pour le reste de votre logique de jeu. Même PhysX de Nvidia nécessite des polyèdres concaves complexes à décomposer en polyèdres convexes plus simples, pour la simulation physique.

• Votre carte graphique produit de la perspective avec les transformations qu'elle effectue. C'est différent des transformations effectuées en physique, qui n'ont rien à voir avec la perspective en tant que telle - il s'agit simplement de calculer les positions et orientations de base dans votre monde. Si vous connaissez MVC, vous comprendrez qu'il existe une différence nette entre les données que vous détenez dans votre application et la façon dont vous présentez ces données.

L'industrie de la technologie informatique est motivée par le besoin, et bien que la visualisation soit un besoin presque universel, les simulations physiques ne sont en aucun cas universelles, ni en tant qu'exigence ni en termes de leurs implémentations respectives.

Donc, mon conseil est, arrêtez de vous inquiéter d'aller à contre-courant et commencez à vous concentrer sur la façon de faire les deux choses que vous devez faire: le rendu et la physique. Vous n'allez pas accéder aux données dans le pipeline de traitement de votre carte graphique (CUDA / OpenCl sont des exceptions): vous insérez des triangles et des données matérielles, cela pompe votre monde 3D en tant qu'image en mouvement.

Enfin, votre question n'est pas dénuée de sens. Le désir d'une base combinée pour la physique et le rendu, et le fait que les mathématiques en virgule flottante peuvent être beaucoup plus lentes que les virgules fixes, nous montre pourquoi les technologies de voxel connaissent un énorme regain d'intérêt: elles simplifient le monde entier jusqu'à une position sur la grille , polyèdres convexes à axe aligné. Cela améliore considérablement les performances, en réduisant la quantité de mathématiques vectorielles à virgule flottante nécessaires pour les opérations physiques, car vous travaillez maintenant principalement dans une grille spatialement subdivisable, instanciable et indexée sur des nombres entiers. Cette même grille peut être utilisée à la fois pour le rendu et la physique, d'autant plus que vous pouvez utiliser des résolutions de grille différentes pour ces deux sous-systèmes distincts (lors de l'utilisation d'une solution basée sur octree telle que les SVO).