godot-box3d

godot-box3d est une GDExtension qui intègre Box3D, le moteur physique 3D d'Erin Catto, dans Godot 4 en remplacement direct du PhysicsServer3D intégré. Les nœuds physiques Godot standard continuent de fonctionner : vous modifiez un paramètre de projet plutôt que vos scènes. Le projet est décrit comme précoce et expérimental, et Box3D lui-même est un moteur jeune. Motivation : l'auteur construit SurfsUp, une recréation du « SkillSurf » du moteur Source dans Godot. Les cartes de surf sollicitent la physique avec de longues rampes trimesh concaves, des virages à grande vitesse et le head surf sous la géométrie. La physique intégrée de Godot et godot-jolt auraient du mal avec certaines de ces situations. Box3D provient du Rubikon-lite de Valve, le moteur physique de Source 2, donc un solveur de la lignée Rubikon semblait valoir la peine d'être essayé. Le pont entre le PhysicsServer3D de Godot et Box3D suit l'architecture de godot-jolt. Comparé à box3d-godot, une autre liaison Box3D pour Godot : box3d-godot expose Box3D sous forme de 14 nœuds personnalisés fonctionnant aux côtés de la physique de Godot, tandis que ce projet remplace la physique de Godot. Cela signifie que les nœuds standard et les addons existants continuent de fonctionner, mais les fonctionnalités propres à Box3D telles que les explosions, le couple gyroscopique, le profilage du solveur et le pas asynchrone ne sont pas accessibles via l'interface PhysicsServer3D. box3d-godot offre plus de types de joints (8 contre 3), une vraie contrainte de roue et plus de plateformes (Android, web), tandis que ce projet prend en charge les heightfields et VehicleBody3D via raycast. Le README indique que ce projet est actuellement en retard sur box3d-godot concernant les types de joints, ConeTwist et 6DOF, les indices par forme dans les résultats de requête, le profilage et les plateformes. Aucun des deux n'est décrit comme prêt pour la production. Ce qui fonctionne : corps rigides, statiques et cinématiques ; formes incluant boîte, sphère, capsule, cylindre, polygone convexe, polygone concave (trimesh), heightmap et limite du monde ; zones avec événements de chevauchement, remplacements de gravité/amortissement, ordre de priorité et gravité ponctuelle ; requêtes d'espace d'état direct (ray casts, intersection de points et de formes, shape casts, collide_shape, rest_info) ; body_test_motion pour que CharacterBody3D et move_and_slide() fonctionnent ; surveillance des contacts avec points de contact réels, normales et impulsions ; exceptions de collision par paire ; joints pin, hinge et slider ; un solveur multithread avec détection automatique des cœurs physiques et un remplacement worker_count, déterministe quel que soit le nombre de workers ; et un projet de test avec un hub de démonstration, un benchmark déterministe et 19 tests de régression headless. Le travail restant comprend les formes de rayons de séparation, les joints ConeTwist, Generic6DOFJoint3D (Box3D n'a pas de contrainte de verrouillage/limite/moteur par axe, donc aucune correspondance fidèle n'existe), SoftBody3D, les indices par forme dans les résultats de requête et de contact, le profilage du solveur, les binaires universels macOS et la notarisation, davantage de plateformes et d'architectures, ainsi que l'analyse comparative et l'optimisation des performances. Les différences de comportement sont documentées : Area3D ne détecte pas les corps trimesh ou heightmap, car les formes concaves de Box3D ne peuvent pas agir comme visiteurs de capteur par conception ; collide_shape() rapporte les points de contact sans profondeur de pénétration car Box3D expose GJK ; les requêtes de forme nécessitent une forme de requête convexe ; et la friction et la restitution se combinent différemment (sqrt(a*b) pour la friction, max(a,b) pour la restitution, contre min(a,b) et somme bornée pour Godot), donc les matériaux peuvent nécessiter un réajustement. Le README inclut une scène de benchmark qui fait tomber des boîtes sur un treillis fixe à partir d'une graine fixe jusqu'à ce que 4096 corps existent, exécutée sous Linux avec Godot 4.7.2.rc. Les résultats rapportés placent Box3D Physics devant Jolt Physics, Godot Physics et Rapier3D sur les corps à 16,66 ms, le pas médian, le pas p95, le pas maximal et la mémoire dans cette charge de travail spécifique de boîtes denses. Le README avertit explicitement que les quatre backends dépassent le budget bien avant 4096 corps, que cela mesure la dégradation en surcharge, et qu'un tas dense de boîtes ne dit rien des raycasts, des contrôleurs de personnage ou des joints, donc cela doit être pris comme un point de départ plutôt qu'un classement. Prérequis : Godot 4.3 ou plus récent (le projet de test cible 4.7). L'installation se fait via le zip de l'addon depuis les Releases, en copiant addons/godot-box3d/ dans le projet, puis en définissant Paramètres du projet → Physique → 3D → Moteur physique sur Box3D Physics et en redémarrant. Le solveur utilise un worker par cœur physique par défaut, remplaçable via physics/box3d/worker_count. macOS est décrit comme un travail en cours : Apple Silicon uniquement, non notarisé, non testé au-delà de la compilation. Linux et Windows sont les plateformes testées. La compilation utilise CMake, avec un fichier de chaîne d'outils MinGW-w64 pour la compilation croisée d'une DLL Windows depuis Linux. Les tests s'exécutent via un script headless qui compile l'extension, l'enregistre, vérifie que le backend est chargé et exécute 19 tests de régression, sortant avec un code non nul en cas d'échec ou de fuite de RID Box3D. Les contributions sont les bienvenues. Sous licence MIT ; Box3D est sous licence MIT, et le projet s'inspire structurellement de godot-jolt, également sous licence MIT.