1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Com a crescente necessidade de controlar diretamente simulações físicas 3D em larga escala em servidores de jogos, Box3D foi lançado como um engine de física 3D open source da família Box2D
  • Sua estrutura é próxima à do Box2D e inclui C API, código-fonte em C17, solver com substepping, colisão contínua, graph coloring, solver de contato wide SIMD e hooks para multithreading
  • A experiência de dificuldade em atender, no Chaos do Unreal Engine, a requisitos como torque giroscópico, queda de árvores e broad-phase em larga escala foi o pano de fundo direto do desenvolvimento
  • Recursos para jogos 3D incluem malhas triangulares, height fields, baked compound collision, mundos grandes baseados em double, determinismo cross-platform e gravação/reprodução
  • Ele já é usado em vários jogos e engines, mas ainda é software alfa; após a tag v0.1, serão necessários mais testes e documentação até a v1.0

Natureza e principais recursos do Box3D

  • Box3D é um engine de física 3D open source publicado no GitHub, mais próximo de um projeto que expande o design do Box2D para atender às necessidades de jogos 3D
  • A arquitetura central é quase idêntica à do Box2D, e todo o código-fonte da biblioteca é escrito em C17
  • Os principais recursos do engine são os seguintes
    • C API

      • Solver com substepping
      • Colisão contínua
      • Graph coloring para ilhas grandes
      • Solver de contato wide SIMD
      • Hooks para multithreading
      • Scheduler interno opcional
      • Suporte a mundos grandes usando double para posições
      • Determinismo cross-platform
      • Gravação e reprodução
      • Também inclui recursos de colisão adicionados para jogos 3D
      • Colisão com malhas triangulares
      • Colisão com height fields
      • baked compound collision

A necessidade surgida em The Legend of California

  • A primeira motivação para o desenvolvimento do Box3D foi The Legend of California, em desenvolvimento na Kintsugiyama
  • O jogo é produzido com Unreal Engine, e o projeto começou no Unreal 5.0
  • Experimentos com Chaos, o engine de física padrão do Unreal, revelaram várias limitações
    • Como não havia suporte à simulação de torque giroscópico, era difícil lidar com o movimento de objetos finos girando por muito tempo enquanto preservavam a velocidade angular
    • O desenvolvedor já havia apresentado na GDC de 2015 um algoritmo drop-in de cerca de 10 linhas para adicionar torque giroscópico a um engine de física
    • A Epic adicionou esse recurso ao Unreal Engine no fim de 2024
  • Um problema maior surgiu no corte de árvores, um recurso central do jogo de sobrevivência
    • As árvores caindo se moviam de forma irregular e se teletransportavam na tela
    • A situação era uma simulação de uma cápsula grande caindo sobre uma malha triangular suave, um caso que deveria ser tratado facilmente
  • Como há centenas de milhares de entidades no servidor, também era necessário um broad-phase rápido
    • Por esse elemento ser central para o jogo, considerou-se arriscado deixá-lo a cargo de um middleware
    • O desenvolvedor tem bastante experiência com estruturas de dados de broad-phase e já fez palestras relacionadas na GDC

De Rubikon-Lite a Box3D

  • O uso do Jolt, um engine de física open source existente, também foi considerado, mas Dirk Gregorius sugeriu fazer um fork do Rubikon-Lite e modificá-lo conforme as necessidades
  • Dirk Gregorius é o programador de física que criou o engine de física customizado Rubikon, usado em Half-Life: Alyx, e mantém uma versão hobby/doméstica do Rubikon
  • Ao conectar diretamente o Rubikon-Lite ao Unreal, o torque giroscópico funcionou, e as árvores também passaram a cair corretamente
  • Na substituição do engine de física do Unreal, foi possível aproveitar alguns atalhos
    • Foi usado um sistema próprio de scripting, não Blueprint
    • O sistema de animação Esoterica foi portado para o Unreal e usado
    • Foi usado um ECS customizado conectado diretamente ao Box3D
  • Ao tentar trazer as otimizações do Box2D v3.0 para o fork do Rubikon-Lite, surgiu a necessidade de manter os trabalhos 2D e 3D tão parecidos quanto possível
    • Quase todas as APIs, estruturas de dados e algoritmos do Rubikon-Lite foram substituídos por código do Box2D
    • As estruturas de dados em 2D e 3D eram, em grande parte, independentes da dimensão espacial
  • Com o tempo, o fork do Rubikon-Lite se transformou no Box3D
    • Atualmente, ainda há código do Rubikon-Lite no Box3D para geração de convex hull e alguns algoritmos de colisão
    • O restante é código do Box2D e código novo para o Box3D
  • Do lado da Valve, o Rubikon continua evoluindo, e Dirk desenvolveu otimizações semelhantes às do Box3D no novo engine Ragnarok

Requisitos de jogo atendidos por um engine de física customizado

  • The Legend of California é um projeto com um grande mundo aberto e uma arquitetura server-authoritative
  • Árvores caindo, ragdolls, voxels, portas de saloon e tumbleweeds são todos simulados no servidor
  • Usar um engine de física customizado permite ajustar diretamente recursos e desempenho de acordo com as necessidades do jogo
  • O trabalho de desempenho se concentrou especialmente nas árvores caindo
    • Árvores redwood gigantes caem rapidamente sobre terreno voxel
    • Foi grande o trabalho para fazer colisão de malha e CCD funcionarem de forma estável
  • Malhas de colisão para o sistema de voxels também precisam ser criadas rapidamente em runtime
    • Como os voxels são em grade, eles se organizam bem com median split
  • Streaming também era um requisito importante
    • Strongholds são montadas por kitbashing
    • Uma stronghold grande pode ter cerca de 50.000 malhas de colisão separadas
    • Carregá-las uma a uma no engine de física seria ineficiente e consumiria muita memória
    • Foi criado um sistema de compound collision que cozinha formas de colisão separadas em uma estrutura de dados otimizada e as carrega como uma única uber shape
    • Essa abordagem elimina o overhead de criar milhares de bodies e shapes

Motivos para virar open source e público-alvo

  • O desenvolvedor cria engines de física para jogos desde 2004 e, a cada mudança de emprego, precisava deixar esse trabalho para trás
  • O Box2D foi criado, em parte, para acumular conhecimento e esforço em um projeto open source e usá-lo como base para trabalhos futuros
  • No lado 3D, havia o peso de recriar trabalhos semelhantes repetidamente
  • A Kintsugiyama permitiu publicar o Box3D como open source e trabalhar nele como parte das atividades profissionais
  • O Box3D não é um projeto que pretende competir com outros engines de física; se o usuário gosta do design do Box2D, há boa chance de o Box3D também se encaixar bem

Como começar e documentação

  • Para começar com o Box3D, basta instalar o git e o CMake básicos e clonar o repositório do Box3D
  • As instruções de build estão no README
  • Após o build, é possível executar os exemplos para verificar os recursos e começar a programar a partir do código de exemplo
  • Os headers do engine têm comentários Doxygen completos, e o manual escrito está em andamento
  • documentação hospedada disponível
  • O código de exemplo mínimo pode ser visto no teste HelloWorld

Uso atual e próximos planos

  • Além de The Legend of California, o Box3D já está em uso em vários lugares
  • Embora já esteja em uso em vários jogos, o Box3D ainda é considerado software alfa
  • O plano é criar em breve a tag v0.1 e evoluir até o lançamento v1.0
  • São necessários mais testes e documentação de alta qualidade, mas o conjunto de recursos já está em uma boa posição
  • Os trabalhos em avaliação são os seguintes
    • Reforçar recursos de movimentação de personagens
    • Melhorar a mitigação de ghost collision
    • Otimização
    • Melhorias no joint solver
  • A expectativa é dar suporte ao Box3D por tempo indeterminado, junto com o Box2D
  • Ao atingir um estágio de maturidade, o trabalho em recursos poderá pausar por um tempo
  • Diferentemente do Box2D, espera-se que o Box3D aceite pull requests, possivelmente com uso de CLA
  • Não será criado um site separado nem um servidor Discord separado para o Box3D
  • Para ver o Box3D funcionando em The Legend of California, é possível acompanhar pela home page e pela Steam

1 comentários

 
GN⁺ 4 시간 전
Opiniões no Hacker News
  • Sempre que Box2D é mencionado, lembro de uma história antiga junto com a conexão óbvia de que é uma biblioteca do mesmo autor do Box3D
    https://kotaku.com/this-guy-created-angry-birds-physics-and-...

    • Ouvi essa história quando trabalhava na Rovio (criadora de Angry Birds): durante uma palestra, o responsável por marketing Peter Vesterbacka estava respondendo a perguntas quando alguém na plateia perguntou qual engine de física o jogo usava. Vesterbacka respondeu corretamente que era Box2D, e a pessoa disse: “Por que ela não aparece nos créditos? Aliás, eu sou Erin Catto, o criador do Box2D”
      Vesterbacka respondeu: “Venha falar comigo depois do evento”, e talvez tenha sido nessa ocasião que Erin ganhou um moletom. Dizem que, pouco depois, o nome dele foi adicionado aos créditos
      O que surpreendeu todo mundo foi o fato de o pessoal de marketing saber qual engine de física era usada
  • Box2D já foi a base de muitos jogos indie baseados em física
    Fico curioso se o cenário atual está suficientemente vazio para permitir um renascimento

    • Para começo de conversa, nunca houve muitas engines de física 3D gratuitas e open source. Entre os ancestrais mais antigos estão ODE, Bullet e Newton Dynamics, todos surgidos no começo dos anos 2000; depois disso parece ter havido um vazio de quase 20 anos, até Jolt em 2021 e agora Box3D
      É sempre bem-vinda a adição de um novo item a uma lista tão pequena e fechada
    • Lembro da época em que eu era viciado em Incredibots. Foi ali que conheci Box2D pela primeira vez
    • Box2D ainda é muito bom. Para um projeto de jogo com física 2D, eu certamente recomendaria
      A API em C do Box2D e agora do Box3D é realmente ótima de usar
    • Usei um pouco o Chipmunk2D no passado, e ele era mais fácil de usar para o trabalho esquisito que eu estava fazendo
  • Isso é realmente muito bem-vindo. Erin Catto é um hacker excelente, e agradeço por compartilhar o código com a comunidade open source
    O anúncio não falou sobre determinismo (determinism), mas eu gostaria de ver mais sobre isso também. Ao tentar criar um jogo de bilhar em rede com a física embutida do Unity, vira uma dor de cabeça considerável porque os clientes não conseguem concordar entre si sobre o que aconteceu

    • Eu estava procurando a mesma coisa. Como há um mecanismo de replay, parece ser determinístico. Mas, se for física de ponto flutuante, talvez não seja entre plataformas
      Segundo a documentação, -ffast-math não é compatível, então talvez a intenção seja determinismo entre plataformas: https://box2d.org/documentation3d/recording.html
      Edição: esclareci o significado de ffast-math
  • Como pesquisador de machine learning, Box2D me é familiar por causa dos ambientes de aprendizado por reforço. Ele sustenta ambientes de benchmark padrão como Lunar Lander e Car Racing no OpenAI Gym
    https://gymnasium.farama.org/environments/box2d/car_racing/

  • Simulação física é uma toca de coelho perigosa. Mesmo focando apenas em corpos rígidos e movimentos fisicamente plausíveis, há muitos problemas em aberto na detecção e na resolução de colisões
    Em geometria, é comum usar aproximação ou decomposição convexa, os solvers geralmente são ajustados manualmente, e é preciso trocar robustez e precisão por velocidade o tempo todo

  • Eu estava mesmo esperando por isso. Tive bastante sucesso com Box2D no passado, e ele está claramente entre os melhores resultados dentro de F/OSS
    Spectre VR baseado em Box3D? Isso com certeza deve aparecer. Também tem um clima de Tanarus
    Edição: a parte da demo Legend of California (baseada no Unreal Engine) em que há a transição para gravação e reprodução parece um salto bastante brusco. Mesmo que pareça meio básica no começo, vale assistir pelo menos até a marca de 18 minutos do vídeo de demonstração. Fica bem interessante de um jeito meio bruto, e os recursos de gravação e reprodução são legais

    • Sempre penso em Tanarus, mas quase nunca vejo alguém mencioná-lo
  • Conheço um pouco Rapier e, antes dele, Cannon e Ammo, e fico curioso para saber como eles se comparam ao Box3D
    Além disso, algumas semanas atrás eu mesmo fiz uma engine de física para espaço 3D e compartilhei aqui também. Na verdade, é uma linha de código que move os objetos para baixo em intervalos regulares, mas já funciona surpreendentemente bem. Do ponto de vista de aprendizado, é muito divertido, então recomendo tentar

  • Alguns dias atrás comecei a usar Jolt para fazer um jogo 3D estilo Tron para navegador, então é engraçado ver isso agora. Até aqui, Jolt tem funcionado bem, mas com certeza vou dar uma olhada neste também
    1 - Eu já tinha este domínio havia alguns anos: https://lightcycles.io

  • Fico curioso para saber como ele vai se comparar ao Jolt. Os dois parecem ter bons históricos: de um lado Valve e Erin Catto, do outro, uso nos jogos Horizon

  • “Do lado da Valve, Rubikon continua evoluindo, e Dirk desenvolveu no novo engine Ragnarok otimizações semelhantes às do Box3D. Vocês verão isso em futuros jogos da Valve.”
    Espera aí…

    • Melhor não criar muita expectativa. Provavelmente será usado no modo de vôlei de Deadlock
    • Sabe-se que a Valve está fazendo um jogo de codinome HLX, e que ele usa muitos recursos de física. Mas não faço a menor ideia do que “HLX” significa
    • Valve
      Box3D
      3D
      3
      esperança!
    • Half-Life 2D confirmado?
    • Day of Defeat Source 2.1 está a exatamente uma semana de distância!