Sobre el proyecto

godot-box3d es una extensión GDExtension que integra Box3D, el motor de física 3D de Erin Catto, en Godot 4 como reemplazo directo del PhysicsServer3D integrado. Los nodos de física estándar de Godot siguen funcionando: cambias un ajuste del proyecto en lugar de tus escenas. El proyecto se describe como temprano y experimental, y Box3D en sí es un motor joven. Motivación: el autor está construyendo SurfsUp, una recreación del "SkillSurf" del motor Source en Godot. Los mapas de surf ponen a prueba la física con largas rampas de trimesh cóncavo, curvas de alta velocidad y surf de cabeza bajo geometría. Se informa que la física integrada de Godot y godot-jolt tienen dificultades con partes de eso. Box3D se originó del Rubikon-lite de Valve, el motor de física de Source 2, por lo que valía la pena probar un solucionador de linaje Rubikon. El puente entre el PhysicsServer3D de Godot y Box3D sigue la arquitectura de godot-jolt. En comparación con box3d-godot, otra unión de Box3D para Godot: box3d-godot expone Box3D como 14 nodos personalizados que funcionan junto con la física de Godot, mientras que este proyecto reemplaza la física de Godot en su lugar. Esto significa que los nodos estándar y los complementos existentes siguen funcionando, pero las características exclusivas de Box3D como explosiones, torque giroscópico, perfilado del solucionador y pasos asíncronos no son accesibles a través de la interfaz PhysicsServer3D. box3d-godot ofrece más tipos de articulaciones (8 vs 3), una restricción de rueda real y más plataformas (Android, web), mientras que este proyecto admite heightfields y VehicleBody3D mediante raycast. El README indica que este proyecto está actualmente detrás de box3d-godot en tipos de articulaciones, ConeTwist y 6DOF, índices por forma en resultados de consultas, perfilado y plataformas. Ninguno se describe como listo para producción. Lo que funciona: cuerpos rígidos, estáticos y cinemáticos; formas que incluyen caja, esfera, cápsula, cilindro, polígono convexo, polígono cóncavo (trimesh), mapa de altura y límite mundial; áreas con eventos de superposición, anulaciones de gravedad/amortiguación, orden de prioridad y gravedad puntual; consultas directas de estado espacial (raycasts, intersección de puntos y formas, casts de formas, collide_shape, rest_info); body_test_motion para que CharacterBody3D y move_and_slide() funcionen; monitoreo de contacto con puntos de contacto reales, normales e impulsos; excepciones de colisión por par; articulaciones de pasador, bisagra y deslizante; un solucionador multihilo con núcleos físicos auto-detectados y una anulación de worker_count, determinista entre recuentos de workers; y un proyecto de prueba con un centro de demostración, benchmark determinista y 19 pruebas de regresión sin cabeza. El trabajo restante incluye formas de rayos de separación, articulaciones ConeTwist, Generic6DOFJoint3D (Box3D no tiene una restricción de bloqueo/límite/motor por eje, por lo que no existe un mapeo fiel), SoftBody3D, índices por forma en resultados de consultas y contactos, perfilado del solucionador, binarios universales de macOS y notarización, más plataformas y arquitecturas, y benchmarking y ajuste de rendimiento. Las diferencias de comportamiento están documentadas: Area3D no detecta cuerpos trimesh o heightmap, ya que las formas cóncavas de Box3D no pueden actuar como visitantes de sensores por diseño; collide_shape() informa puntos de contacto sin profundidad de penetración porque Box3D expone GJK; las consultas de forma necesitan una forma de consulta convexa; y la fricción y restitución se combinan de manera diferente (sqrt(a*b) para fricción, max(a,b) para restitución, versus min(a,b) y suma limitada de Godot), por lo que los materiales pueden necesitar reajuste. El README incluye una escena de benchmark que deja caer cajas sobre una celosía fija desde una semilla fija hasta que existen 4096 cuerpos, ejecutada en Linux con Godot 4.7.2.rc. Los resultados informados colocan a Box3D Physics por delante de Jolt Physics, Godot Physics y Rapier3D en cuerpos a 16.66 ms, paso mediano, paso p95, paso máximo y memoria en esa carga de trabajo específica de cajas densas. El README advierte explícitamente que los cuatro backends superan el presupuesto mucho antes de 4096 cuerpos, que esto mide la degradación bajo sobrecarga, y que una pila densa de cajas no dice nada sobre raycasts, controladores de personajes o articulaciones, por lo que debe tomarse como un punto de partida en lugar de una clasificación. Requisitos: Godot 4.3 o más nuevo (el proyecto de prueba apunta a 4.7). La instalación es a través del zip del complemento desde Releases, copiando addons/godot-box3d/ en el proyecto, luego configurando Project Settings → Physics → 3D → Physics Engine a Box3D Physics y reiniciando. El solucionador usa un worker por núcleo físico por defecto, anulable mediante physics/box3d/worker_count. macOS se describe como trabajo en progreso: solo Apple Silicon, no notarizado, no probado más allá de compilar. Linux y Windows son las plataformas probadas. La compilación usa CMake, con un archivo de toolchain MinGW-w64 para compilar una DLL de Windows desde Linux. Las pruebas se ejecutan a través de un script sin cabeza que compila la extensión, la registra, verifica que el backend se cargó y ejecuta 19 pruebas de regresión, saliendo con código distinto de cero en caso de fallo o RID de Box3D filtrado. Se agradecen contribuciones. Licencia MIT; Box3D es MIT, y el proyecto se inspira estructuralmente en godot-jolt, también MIT.