- Face au besoin croissant de contrôler directement des simulations physiques 3D à grande échelle sur des serveurs de jeu, Box3D est publié comme moteur physique 3D open source dans la lignée de Box2D
- Sa structure est proche de celle de Box2D et inclut une API C, du code source en C17, un solveur à sous-pas, les collisions continues, la coloration de graphe, un solveur de contacts wide SIMD et des hooks de multithreading
- Les difficultés rencontrées avec Chaos d’Unreal Engine pour répondre aux besoins de couple gyroscopique, de chute d’arbres et de broad-phase à grande échelle ont directement motivé son développement
- Les maillages triangulaires, les champs de hauteur, les baked compound collision, les grands mondes basés sur double, le déterminisme multiplateforme et l’enregistrement/relecture font partie des fonctionnalités destinées aux jeux 3D
- Il est déjà utilisé dans plusieurs jeux et moteurs, mais reste un logiciel alpha ; après le tag v0.1, il faudra renforcer les tests et la documentation jusqu’à la v1.0
Nature et fonctionnalités clés de Box3D
- Box3D est un moteur physique 3D open source publié sur GitHub, et s’apparente à un projet qui étend la conception de Box2D aux besoins des jeux 3D
- Son architecture centrale est presque identique à celle de Box2D, et l’ensemble du code source de la bibliothèque est écrit en C17
- Les principales fonctionnalités du moteur sont les suivantes
-
API C
- Solveur à sous-pas
- Collisions continues
- Coloration de graphe pour les grands îlots
- Solveur de contacts wide SIMD
- Hooks de multithreading
- Planificateur interne optionnel
- Prise en charge des grands mondes utilisant double pour les positions
- Déterminisme multiplateforme
- Enregistrement et relecture
- Des fonctionnalités de collision ajoutées pour les jeux 3D sont également incluses
- Collision de maillages triangulaires
- Collision de champs de hauteur
- baked compound collision
-
Le besoin né avec The Legend of California
- La première motivation du développement de Box3D a été The Legend of California, en cours de développement chez Kintsugiyama
- Ce jeu est réalisé avec Unreal Engine, et le projet a démarré sur Unreal 5.0
- Les expérimentations avec Chaos, le moteur physique par défaut d’Unreal, ont révélé plusieurs limites
- Il ne prenait pas en charge la simulation du couple gyroscopique, ce qui rendait difficile le traitement du comportement d’objets fins tournant longtemps tout en conservant leur vitesse angulaire
- Le développeur avait présenté à la GDC 2015 un algorithme prêt à intégrer d’environ 10 lignes pour ajouter le couple gyroscopique à un moteur physique
- Epic a ajouté cette fonctionnalité à Unreal Engine fin 2024
- Un problème plus important est apparu avec l’abattage d’arbres, une fonctionnalité clé d’un jeu de survie
- Les arbres qui tombaient se déplaçaient de manière irrégulière et se téléportaient à l’écran
- La situation correspondait à la simulation d’une grande capsule tombant sur un maillage triangulaire lisse, un cas qui aurait dû être facile à gérer
- Comme le serveur contient des centaines de milliers d’entités, un broad-phase rapide était également nécessaire
- Cet élément étant central pour le jeu, il a été jugé risqué de le confier à un middleware
- Le développeur possède une grande expérience des structures de données de broad-phase et a déjà donné des présentations GDC sur le sujet
De Rubikon-Lite à Box3D
- L’utilisation de Jolt, un moteur physique open source existant, a aussi été envisagée, mais Dirk Gregorius a proposé de forker Rubikon-Lite et de l’adapter aux besoins
- Dirk Gregorius est le programmeur physique qui a créé Rubikon, le moteur physique personnalisé intégré à Half-Life: Alyx, et il maintient une version loisir/domestique de Rubikon
- En connectant directement Rubikon-Lite à Unreal, le couple gyroscopique fonctionnait, et les arbres tombaient correctement
- Quelques raccourcis ont pu être utilisés pour remplacer le moteur physique d’Unreal
- Utilisation d’un système de scripting maison plutôt que Blueprint
- Portage et utilisation dans Unreal de l’Esoterica animation system
- Utilisation d’un ECS personnalisé connecté directement à Box3D
- En voulant intégrer les optimisations de Box2D v3.0 dans le fork de Rubikon-Lite, il est devenu nécessaire de garder les travaux 2D et 3D aussi similaires que possible
- Presque toutes les API, structures de données et algorithmes de Rubikon-Lite ont été remplacés par du code Box2D
- Les structures de données 2D et 3D étaient en grande partie indépendantes de la dimension spatiale
- Avec le temps, le fork de Rubikon-Lite est devenu Box3D
- Aujourd’hui, Box3D conserve du code Rubikon-Lite pour la génération de convex hulls et certains algorithmes de collision
- Le reste est constitué de code Box2D et de nouveau code destiné à Box3D
- Côté Valve, Rubikon continue d’évoluer, et Dirk a développé des optimisations similaires à Box3D dans le nouveau moteur Ragnarok
Des besoins de jeu adaptés avec un moteur physique personnalisé
- The Legend of California est un projet doté d’un grand open world et d’une architecture à autorité serveur
- Les arbres qui tombent, les ragdolls, les voxels, les portes de saloon et les virevoltants sont tous simulés sur le serveur
- Utiliser un moteur physique personnalisé permet d’ajuster directement les fonctionnalités et les performances aux besoins du jeu
- Le travail de performance s’est particulièrement concentré sur les arbres qui tombent
- D’immenses redwoods tombent rapidement sur un terrain voxel
- Le travail visant à faire fonctionner de manière stable les collisions de maillage et le CCD est important
- Les maillages de collision pour le système de voxels doivent aussi être générés rapidement à l’exécution
- Les voxels étant en grille, ils se structurent bien avec un median split
- Le streaming était également une exigence importante
- Les strongholds sont composés par kitbashing
- Un grand stronghold peut contenir environ 50 000 maillages de collision distincts
- Les charger un par un dans le moteur physique serait inefficace et consommerait beaucoup de mémoire
- Un système de compound collision a été créé pour cuire les formes de collision distinctes dans une structure de données optimisée et les charger comme une uber shape unique
- Cette approche élimine le surcoût lié à la création de milliers de bodies et de shapes
Pourquoi l’open source, et pour qui
- Le développeur crée des moteurs physiques pour jeux depuis 2004, et devait laisser ce travail derrière lui à chaque changement d’emploi
- Box2D a notamment été créé pour accumuler connaissances et efforts dans un projet open source et s’en servir comme base pour les travaux ultérieurs
- Côté 3D, il fallait sans cesse refaire un travail similaire
- Kintsugiyama a autorisé la publication de Box3D en open source et son développement dans le cadre du travail
- Box3D n’est pas un projet destiné à concurrencer d’autres moteurs physiques ; si la conception de Box2D vous plaît, Box3D a de bonnes chances de vous convenir aussi
Démarrage et documentation
- Pour commencer avec Box3D, il suffit d’installer les outils de base git et CMake, puis de cloner le dépôt Box3D
- Les instructions de build se trouvent dans le README
- Après le build, vous pouvez exécuter les exemples pour vérifier les fonctionnalités et commencer à coder à partir du code d’exemple
- Les en-têtes du moteur comportent des commentaires Doxygen complets, et le manuel rédigé est en cours d’élaboration
- Une documentation hébergée est disponible
- Un exemple minimal de code est visible dans le test HelloWorld
Usages actuels et prochaines étapes
- Box3D est déjà utilisé ailleurs que dans The Legend of California
- s&box : plateforme de jeu de Facepunch Studios
- Esoterica : moteur de jeu open source dirigé par Bobby Anguelov
- A 1000-player space game : jeu multijoueur de Glenn Fiedler
- Bien qu’il soit utilisé dans plusieurs jeux, Box3D est encore considéré comme un logiciel alpha
- Il est prévu de créer bientôt un tag v0.1, puis de le faire évoluer jusqu’à une version v1.0
- Il faut davantage de tests et une documentation plus aboutie, mais l’ensemble de fonctionnalités est déjà bien positionné
- Les travaux à l’étude sont les suivants
- Renforcement des fonctionnalités de déplacement des personnages
- Amélioration de l’atténuation des ghost collisions
- Optimisation
- Amélioration du joint solver
- Box3D devrait être pris en charge indéfiniment aux côtés de Box2D
- Une fois le stade de maturité atteint, les travaux sur les fonctionnalités pourront marquer une pause
- Contrairement à Box2D, Box3D devrait accepter les pull requests, avec la possibilité d’utiliser un CLA
- Aucun site web ou serveur Discord séparé ne sera créé pour Box3D
- Les mises à jour seront fournies sur le site de Box2D
- Les échanges se dérouleront sur le serveur Discord Box2D
- Pour voir Box3D fonctionner dans The Legend of California, vous pouvez suivre le projet via sa page d’accueil et Steam
1 commentaires
Avis de Hacker News
Chaque fois que Box2D est mentionné, je repense à cette vieille histoire, avec le lien évident avec la bibliothèque Box3D du même auteur
https://kotaku.com/this-guy-created-angry-birds-physics-and-...
Vesterbacka a répondu : « Venez me voir à la fin de l’événement », et c’est peut-être à ce moment-là qu’Erin a reçu un hoodie. Son nom aurait été ajouté aux crédits peu après
Ce qui avait surpris tout le monde, c’était que le responsable marketing sache quel moteur physique était utilisé
Box2D a été, à une époque, la base de nombreux jeux indépendants fondés sur la physique
Je me demande si le paysage actuel est suffisamment vide pour laisser place à une renaissance
L’ajout d’une nouvelle entrée à une liste aussi petite et fermée est toujours une bonne nouvelle
Les API C de Box2D, et maintenant de Box3D, sont vraiment agréables à utiliser
C’est vraiment une excellente nouvelle. Erin Catto est un hacker impressionnant, et merci à lui de partager son code avec la communauté open source
L’annonce ne parlait pas de déterminisme, mais j’aimerais aussi en voir davantage là-dessus. Quand on essaie de faire un jeu de billard en réseau avec la physique intégrée de Unity, c’est assez pénible, car les clients n’arrivent pas à se mettre d’accord sur ce qui s’est passé
D’après la documentation,
-ffast-mathn’est pas pris en charge ; il est donc possible que le déterminisme multiplateforme soit visé : https://box2d.org/documentation3d/recording.htmlÉdit : clarification de ce que je voulais dire à propos de
ffast-mathEn tant que chercheur en machine learning, Box2D m’est familier grâce aux environnements d’apprentissage par renforcement. C’est la base qui soutient des environnements de benchmark standards comme Lunar Lander ou Car Racing dans OpenAI Gym
https://gymnasium.farama.org/environments/box2d/car_racing/
La simulation physique est un dangereux terrier de lapin. Même en se concentrant uniquement sur les corps rigides et des comportements physiquement plausibles, il reste beaucoup de problèmes ouverts en détection et résolution de collisions
Pour la géométrie, on utilise généralement des approximations ou décompositions convexes, les solveurs se règlent à la main, et il faut constamment arbitrer entre robustesse, précision et vitesse
Je l’attendais vraiment. J’ai eu pas mal de succès avec Box2D par le passé, et c’est clairement l’un des meilleurs résultats du F/OSS
Spectre VR basé sur Box3D ? Ça me paraît inévitable. Il y a aussi un parfum de Tanarus
Édit : dans la démo Legend of California (basée sur Unreal Engine), le passage entre enregistrement et lecture ressemble à un bond assez brutal. Même si ça paraît un peu basique au début, il faut absolument regarder au moins jusqu’à la 18e minute de la vidéo de démo. Ça devient assez brutalement intéressant, et les fonctions d’enregistrement et de lecture sont superbes
Je connais un peu Rapier, et avant ça Cannon et Ammo ; je me demande comment ils se comparent à Box3D
Au passage, il y a quelques semaines, j’ai créé moi-même un moteur physique pour l’espace 3D et je l’ai partagé ici aussi. En réalité, c’est juste une ligne qui déplace les objets vers le bas à intervalles réguliers, mais ça fonctionne déjà étonnamment bien. Du point de vue de l’apprentissage, c’est vraiment amusant, je recommande d’essayer
Il y a quelques jours, j’ai commencé à utiliser Jolt pour créer un jeu 3D façon Tron dans le navigateur, donc c’est amusant de tomber là-dessus maintenant. Jusqu’ici, Jolt fonctionne plutôt bien, mais je compte aussi regarder celui-ci de près
1 - Je possède ce domaine depuis des années : https://lightcycles.io
Je me demande comment il se comparera à Jolt. Les deux semblent avoir un bon pedigree : d’un côté Valve et Erin Catto, de l’autre un moteur utilisé dans les jeux Horizon
« Côté Valve, Rubikon continue d’évoluer, et Dirk a développé dans leur nouveau moteur Ragnarok des optimisations similaires à celles de Box3D. Vous les verrez dans de futurs jeux Valve. »
Attends une seconde…
Box3D
3D
3
Espoir !