1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • A medida que crece la necesidad de controlar directamente simulaciones físicas 3D a gran escala en servidores de juegos, Box3D se presenta como un motor de física 3D de código abierto de la familia Box2D
  • Su estructura es cercana a Box2D e incluye API en C, código fuente en C17, solucionador con substepping, colisión continua, graph coloring, solucionador de contactos wide SIMD y hooks de multithreading
  • La experiencia de no poder satisfacer en Chaos de Unreal Engine requisitos como torque giroscópico, caída de árboles y broad-phase a gran escala fue el motivo directo del desarrollo
  • Para juegos 3D incorpora funciones como mallas triangulares, height fields, baked compound collision, mundos grandes basados en double, determinismo multiplataforma y grabación/reproducción
  • Ya se usa en varios juegos y motores, pero sigue siendo software alfa y necesita más pruebas y mejor documentación antes de llegar de la etiqueta v0.1 a v1.0

Naturaleza de Box3D y funciones clave

  • Box3D es un motor de física 3D de código abierto publicado en GitHub, y se parece más a un proyecto que extiende el diseño de Box2D para adaptarlo a las necesidades de los juegos 3D
  • La arquitectura central es casi igual a la de Box2D, y todo el código fuente de la librería está escrito en C17
  • Las funciones principales del motor son las siguientes
    • API en C

      • solucionador con substepping
      • colisión continua
      • graph coloring para islas grandes
      • solucionador de contactos wide SIMD
      • hooks de multithreading
      • scheduler interno opcional
      • soporte para mundos grandes usando double en las posiciones
      • determinismo multiplataforma
      • grabación y reproducción
      • también incluye funciones de colisión agregadas para juegos 3D
      • colisión con mallas triangulares
      • colisión con height fields
      • baked compound collision

La necesidad que surgió en The Legend of California

  • El primer impulso para desarrollar Box3D fue The Legend of California, en desarrollo en Kintsugiyama
  • Este juego está hecho con Unreal Engine, y el proyecto comenzó en Unreal 5.0
  • En las pruebas con Chaos, el motor de física predeterminado de Unreal, quedaron expuestas varias limitaciones
    • No soportaba simulación de torque giroscópico, por lo que era difícil manejar el comportamiento de objetos delgados que conservan velocidad angular y giran durante mucho tiempo
    • El desarrollador ya había presentado en GDC 2015 un algoritmo drop-in de unas 10 líneas para agregar torque giroscópico a un motor de física
    • Epic añadió esta función a Unreal Engine a finales de 2024
  • Un problema todavía mayor apareció en una función central del juego de supervivencia: talado de árboles
    • Los árboles al caer se movían de forma irregular y se teletransportaban en pantalla
    • La situación era una simulación en la que una cápsula grande caía sobre una malla triangular suave, un caso que debería ser fácil de resolver
  • También se necesitaba un broad-phase rápido porque hay cientos de miles de entidades en el servidor
    • Como este elemento está en el centro del juego, se consideró arriesgado dejarlo en manos de middleware
    • El desarrollador tiene mucha experiencia con estructuras de datos de broad-phase y también ha dado charlas relacionadas en GDC

De Rubikon-Lite a Box3D

  • También se evaluó usar Jolt, un motor de física de código abierto ya existente, pero Dirk Gregorius propuso bifurcar Rubikon-Lite y modificarlo según las necesidades
  • Dirk Gregorius es el programador de física que creó Rubikon, el motor de física personalizado usado en Half-Life: Alyx, y mantiene una versión hobby/home de Rubikon
  • Al conectar Rubikon-Lite directamente con Unreal, el torque giroscópico funcionó y los árboles también cayeron correctamente
  • En el reemplazo del motor de física de Unreal se pudieron aprovechar algunos atajos
    • Se usa un sistema propio de scripting en lugar de Blueprint
    • Se usa Esoterica animation system, porteado a Unreal
    • Se usa un ECS personalizado conectado directamente a Box3D
  • Al intentar llevar las optimizaciones de Box2D v3.0 al fork de Rubikon-Lite, surgió la necesidad de mantener el trabajo 2D y 3D lo más parecido posible
    • Casi todas las API, estructuras de datos y algoritmos de Rubikon-Lite fueron reemplazados por código de Box2D
    • En gran parte, las estructuras de datos de 2D y 3D eran independientes de la dimensión espacial
  • Con el tiempo, el fork de Rubikon-Lite se transformó en Box3D
    • Actualmente, en Box3D queda código de Rubikon-Lite en la generación de convex hulls y en algunos algoritmos de colisión
    • El resto es código de Box2D y código nuevo para Box3D
  • Del lado de Valve, Rubikon sigue evolucionando, y Dirk desarrolló optimizaciones similares a las de Box3D en el nuevo motor Ragnarok

Requisitos del juego ajustados con un motor de física personalizado

  • The Legend of California es un proyecto con un gran mundo abierto y una arquitectura autoritativa de servidor
  • Los árboles que caen, ragdolls, vóxeles, puertas de salón y tumbleweeds se simulan todos en el servidor
  • Usar un motor de física personalizado permite ajustar directamente funciones y rendimiento a las necesidades del juego
  • El trabajo de rendimiento se concentró especialmente en los árboles que caen
    • Árboles redwood gigantes caen rápidamente sobre terreno voxelizado
    • Hubo mucho trabajo para hacer que la colisión de mallas y el CCD funcionaran de forma estable
  • Las mallas de colisión para el sistema de vóxeles también debían generarse rápido en tiempo de ejecución
    • Como los vóxeles tienen estructura de cuadrícula, se organizan bien con median split
  • El streaming también era un requisito importante
    • Los strongholds están compuestos con kitbashing
    • Un stronghold grande puede tener unas 50,000 mallas de colisión separadas
    • Cargarlas una por una en el motor de física es ineficiente y consume mucha memoria
    • Se creó un sistema de compound collision que cocina las formas de colisión separadas en una estructura de datos optimizada y las carga como una sola uber shape
    • Este enfoque elimina el overhead de crear miles de bodies y shapes

Por qué se liberó como código abierto y a quién va dirigido

  • El desarrollador lleva creando motores de física para juegos desde 2004, y cada vez que cambiaba de trabajo tenía que dejar atrás ese trabajo
  • Box2D también se creó en parte para acumular conocimiento y esfuerzo en un proyecto de código abierto que pudiera servir de base para trabajos posteriores
  • En 3D existía la misma carga de tener que rehacer trabajo similar una y otra vez
  • Kintsugiyama permitió publicar Box3D como código abierto y trabajar en él como parte del trabajo
  • Box3D no es un proyecto que busque competir con otros motores de física; si a alguien le gusta el diseño de Box2D, es muy probable que Box3D también le encaje bien

Cómo empezar y documentación

  • Para empezar con Box3D, basta con instalar git y CMake, y luego clonar el repositorio de Box3D
  • El método de compilación está en el README
  • Después de compilar, se pueden ejecutar los ejemplos para revisar las funciones y empezar a programar usando el código de ejemplo
  • Los headers del motor incluyen comentarios completos de Doxygen, y el manual aún está en progreso
  • También hay documentación alojada
  • El código del ejemplo mínimo puede verse en la prueba HelloWorld test

Uso actual y planes a futuro

  • Además de The Legend of California, Box3D ya se usa en varios lugares
  • Aunque ya se usa en varios juegos, Box3D todavía se considera software alfa
  • El plan es crear pronto la etiqueta v0.1 y avanzar hasta una versión v1.0
  • Hace falta más testing y documentación más completa, pero el conjunto de funciones ya está en una buena posición
  • Entre los trabajos en evaluación están los siguientes
    • reforzar el movimiento de personajes
    • mejorar la mitigación de ghost collision
    • optimización
    • mejorar el joint solver
  • Se espera dar soporte a Box3D indefinidamente junto con Box2D
  • Cuando llegue a una etapa madura, podrá tomarse un descanso del trabajo de nuevas funciones
  • A diferencia de Box2D, se espera que Box3D sí reciba pull requests, y es posible que use CLA
  • No se creará un sitio web ni un servidor de Discord separados para Box3D
  • Para ver Box3D funcionando en The Legend of California, se puede seguir el proyecto en su home page y en Steam

1 comentarios

 
GN⁺ 4 시간 전
Comentarios de Hacker News
  • Cada vez que se menciona Box2D, me acuerdo de esta vieja historia, junto con la conexión obvia de que Box3D es una biblioteca del mismo autor
    https://kotaku.com/this-guy-created-angry-birds-physics-and-...

    • La escuché cuando trabajaba en Rovio (la empresa creadora de Angry Birds): durante una charla, al jefe de marketing Peter Vesterbacka le hicieron una pregunta y alguien del público preguntó qué motor de física usaban en el juego. Vesterbacka respondió correctamente que era Box2D, y entonces esa persona dijo: “¿Y por qué no aparece en los créditos? Por cierto, soy Erin Catto, creador de Box2D”
      Vesterbacka respondió “ven a verme después del evento”, y tal vez fue en ese momento cuando Erin recibió una sudadera. Luego, poco después, agregaron su nombre a los créditos
      Lo que sorprendió a todos fue que la persona de marketing supiera qué motor de física usaban
  • Box2D en su momento fue la base de los juegos indie basados en física
    Me pregunto si el panorama actual está lo bastante vacío como para que pueda tener un nuevo auge

    • Para empezar, nunca hubo tantos motores de física 3D gratuitos y de código abierto. Entre los ancestros viejos están ODE, Bullet y Newton Dynamics; todos aparecieron por primera vez a inicios de los 2000, y después parece que hubo un vacío de casi 20 años hasta Jolt en 2021, y ahora Box3D
      Siempre da gusto ver que se agregue una entrada nueva a una lista tan pequeña y cerrada
    • Me acuerdo de cuando estaba obsesionado con Incredibots. Ahí fue donde conocí Box2D por primera vez
    • Box2D sigue siendo bastante bueno. Definitivamente lo recomendaría para proyectos de juegos 2D con física
      La API en C de Box2D, y ahora también la de Box3D, es realmente muy agradable para trabajar
    • Hace tiempo usé un poco Chipmunk2D, y para el trabajo raro que estaba haciendo me resultó más fácil de usar
  • Esto de verdad me da gusto. Erin Catto es un hacker genial, y gracias por compartir su código con la comunidad open source
    En la presentación no se habló de determinismo, pero también me gustaría ver más sobre ese tema. Si intentas hacer un juego de billar en red con la física integrada de Unity, es bastante doloroso porque los clientes no logran ponerse de acuerdo sobre lo que pasó

    • Yo estaba buscando justo eso. Como tiene un mecanismo de replay, da la impresión de que es determinista. Aunque si usa física de punto flotante, puede que no lo sea entre plataformas
      Según la documentación, -ffast-math no está soportado, así que quizá sí apuntan a determinismo entre plataformas: https://box2d.org/documentation3d/recording.html
      Edit: aclaré lo que quería decir con ffast-math
  • Como investigador de machine learning, conozco Box2D gracias a los entornos de aprendizaje por refuerzo. Es la base que sostiene entornos benchmark estándar de OpenAI Gym como Lunar Lander y Car Racing
    https://gymnasium.farama.org/environments/box2d/car_racing/

  • La simulación física es una madriguera de conejo peligrosa. Incluso si solo te concentras en cuerpos rígidos y comportamiento físicamente plausible, todavía hay muchos problemas abiertos en detección y resolución de colisiones
    En geometría se suelen usar aproximaciones o descomposiciones convexas, y los solucionadores normalmente se ajustan a mano; siempre estás intercambiando robustez y precisión por velocidad

  • De verdad estaba esperando esto. Me fue bastante bien con Box2D en el pasado, y definitivamente es de lo mejor dentro de F/OSS
    ¿Spectre VR basado en Box3D? Siento que eso tiene que pasar. También me da vibra de Tanarus
    Edit: en el demo de Legend of California (basado en Unreal Engine), la parte donde cambia a grabación y reproducción se siente como un salto bastante abrupto. Aunque al principio parezca algo básico, de verdad hay que ver por lo menos hasta el minuto 18 del video del demo. Se pone bastante salvajemente interesante, y la función de grabación y reproducción está genial

    • Siempre pienso en Tanarus, pero casi nunca veo que alguien lo mencione
  • Conozco un poco Rapier, y antes de ese Cannon y Ammo, pero me pregunto cómo se compara Box3D con ellos
    Como extra, hace unas semanas hice mi propio motor de física para espacio 3D y también lo compartí aquí. En realidad es una sola línea que baja objetos a intervalos regulares, pero sorprendentemente ya funciona bastante bien. Como experiencia de aprendizaje, la verdad es muy divertido, así que lo recomiendo

  • Hace unos días empecé a usar Jolt para hacer un juego 3D estilo Tron para navegador, así que justo me da curiosidad ver esto. Hasta ahora Jolt ha funcionado bastante bien, pero definitivamente también voy a revisar esto
    1 - Llevo años teniendo este dominio: https://lightcycles.io

  • Me pregunto cómo se comparará con Jolt. Ambos parecen tener muy buen historial: por un lado Valve y Erin Catto, y por el otro el uso en los juegos Horizon

  • “En Valve, Rubikon sigue evolucionando, y Dirk desarrolló optimizaciones similares a Box3D para el nuevo motor Ragnarok. Lo veremos en futuros juegos de Valve.”
    Espera…

    • Mejor no emocionarse demasiado. Seguro lo usarán en el modo de voleibol de Deadlock
    • Se sabe que Valve está haciendo un juego con nombre clave HLX y que usa muchísimas funciones de física. Pero no tengo idea de qué significa “HLX”
    • Valve
      Box3D
      3D
      3
      ¡Esperanza!
    • ¿Confirmado Half-Life 2D?
    • ¡Falta exactamente una semana para Day of Defeat Source 2.1!