Reddit

Bevy 0.20

Bevy 0.20 출시 — 렌더링·씬 시스템·ECS 개선

Rust 게임 엔진 Bevy 0.20이 실시간 경로 추적 렌더러 Solari와 DLSS를 개선하고, 새 씬 시스템 BSN의 문법을 다듬었습니다. WESL 셰이더, 약한 시스템 순서 지정, 스케줄 무작위화, 텍스처 압축 등 렌더링과 개발 도구 전반의 변경 사항도 담았습니다.

AI 요약

Bevy 0.20은 227명의 기여자가 참여한 릴리스로, 렌더링 성능과 씬 구성, ECS 스케줄링, UI 기능을 폭넓게 개선했습니다. 새 기능을 추가하는 데 그치지 않고 기존 프로젝트의 마이그레이션에 영향을 주는 BSN 문법과 셰이더 언어도 정리했습니다.

렌더러와 셰이더

실시간 경로 추적 렌더러 Solari는 ReSTIR 구현을 개선해 조명 정확도를 높였고, 움직이는 물체의 그림자 지연과 반사의 떨림을 줄였습니다. ReSTIR는 기본 설정에서 꺼졌습니다. 성능 부담에 비해 화질 개선이 크지 않은 장면이 있기 때문입니다. 그림자 품질이나 움직이는 장면의 그림자가 중요하다면 SolariLighting::restir를 다시 켜야 합니다. 장면 관리 코드도 유지형(retained) 방식으로 바꾸고 최적화해 CPU 비용을 줄였습니다. 조명 캐시 크기, 픽셀별 광원 샘플 수, 시간 누적, 경로 추적 반사 횟수 등을 조정하는 설정도 추가했습니다.

Solari는 이제 macOS의 Metal에서도 실행되지만, macOS용 내장 디노이저는 없습니다. 조명 입력으로 Atmosphere와 카메라의 EnvironmentMapLights를 지원하며, PointLight·SpotLight·RectLight 지원은 향후 과제로 남았습니다. dlss_wgpu 업데이트로 DLSS-RR 4.5도 지원합니다. Bevy 0.19에서 DLSS를 사용했다면 새 DLSS SDK를 설치해야 합니다.

Bevy 셰이더는 WGSL 확장 문법 대신 WESL을 사용합니다. WESL은 모듈, import, 조건부 컴파일 등을 제공하는 WGSL 확장 표준입니다. Bevy는 자체 WGSL 방언을 유지하는 대신 공통 표준과 도구 생태계에 합류했습니다. wgsl-analyzer를 설치하면 구문 강조, 정의로 이동, 인레이 힌트, 코드 접기, 포맷팅을 사용할 수 있습니다. 기존 Bevy 확장 WGSL 파일은 WESL로 옮기고 확장자를 .wesl로 바꿔야 합니다. 일반 WGSL 파일은 전처리 지시문이 없다면 계속 사용할 수 있습니다.

BSN과 씬 준비 이벤트

새 씬 시스템 BSN은 문법을 정리해 씬 참조에 @ 접두사를 붙이고, 컴포넌트 값에서 template_value 래퍼를 제거했습니다. 메서드 체인과 clone()도 래퍼 없이 작성합니다. enum은 Default와 Clone을 구현하면 VariantDefaults나 FromTemplate 없이 쓸 수 있지만, 각 variant의 필드를 모두 적어야 합니다. 리스트 안의 엔티티 구분자는 쉼표 대신 --를 씁니다. 기존 BSN 선언을 수정해야 하는 변경 사항입니다.

씬이 하위 엔티티까지 모두 생성된 뒤 실행되는 Ready 이벤트도 추가했습니다. 기존 Add 이벤트는 하향식으로 실행돼 자식 엔티티를 사용할 수 없었지만, Ready는 해당 엔티티와 자손의 생성 및 초기 컴포넌트 삽입이 끝난 뒤 발생합니다. 덕분에 완전히 준비된 씬을 전제로 하는 로직을 구성할 수 있고, glTF 같은 다른 씬 표현 위에 Bevy 로직을 얹기도 쉬워집니다.

ECS 스케줄링과 오류 처리

chain_weak(), before_weak(), after_weak()는 시스템 데이터 접근이 충돌하는 경우에만 순서를 강제합니다. 일반적인 chain()처럼 묶인 모든 시스템을 차례로 기다리지 않아도 되므로, 충돌하지 않는 시스템은 병렬로 실행할 수 있습니다. 다만 Commands 같은 지연 효과를 내는 시스템과 exclusive 시스템은 순서를 유지합니다. 스케줄러가 추적하지 못하는 내부 가변성이나 전역 상태에 의존한다면 약한 순서 지정을 피해야 합니다.

디버그 기능으로 스케줄 실행 순서를 무작위화하는 설정도 들어갔습니다. 명시적으로 지정한 순서는 유지하면서 충돌하는 시스템의 순서를 섞어, 시스템이 우연한 실행 순서에 기대는 문제를 테스트할 수 있습니다. 시드를 기록하면 실패를 재현할 수 있습니다. 다만 지연 명령의 동기화 지점과 멀티스레드 실행기의 탐욕적 실행 때문에 실제 실행 순서는 셔플 순서와 다를 수 있습니다.

시스템·명령·옵저버에서 발생한 패닉은 이제 오류 처리기로 전달됩니다. 기본 동작은 다시 패닉을 일으키지만, 오류를 기록하고 앱을 계속 실행하는 방식도 선택할 수 있습니다. 컴포넌트에 summary_tick을 설정하면 변경 질의에서 엔티티마다 확인하는 대신 컬럼 전체를 건너뛸 수 있습니다. 변경이 드물고 질의가 잦은 경우에 유리하며, 변경 시 컬럼 틱도 기록하므로 쓰기 비용은 늘어납니다. GPU 메시 추출 코드에서는 변경 틱으로 최대 132배 빨라졌다고 보고했습니다.

UI와 자산 처리

Feathers에는 색상 선택기, 스크롤 가능한 목록, 드롭다운, 지연 생성 메뉴가 추가됐습니다. 숫자 입력 위젯은 드래그 조정과 최소·최대값 설정을 지원하며, 시각 요소를 직접 제공하는 탭 동작도 들어갔습니다. UI 크기 단위로 em과 rem을 지원하고 기본 글꼴 크기를 rem(1)로 바꿨습니다. FixedNode는 부모의 레이아웃·클리핑·변환을 따르지 않고 카메라 뷰포트 기준으로 배치됩니다.

2D 렌더링에서는 스프라이트용 사용자 셰이더 재료와 3D ExtendedMaterial에 대응하는 2D 재료 확장을 지원합니다. 스프라이트 렌더 백엔드도 3D 렌더링 기반 시설을 재사용하도록 바꿔 성능과 유지보수성을 개선했습니다. 새 메시 셰이더 파이프라인은 GPU에서 직접 기하를 생성하는 저수준 기능입니다. 메시렛, 절차적 잔디, 복셀, 파티클 등에 활용할 수 있지만 웹 플랫폼은 지원하지 않으며, 고수준 API와 StandardMaterial 연동은 향후 작업입니다.

텍스처 압축 백엔드는 ctt를 사용하도록 바뀌었습니다. 데스크톱에는 BCn, 모바일에는 ASTC 형식을 사용하며 채널 수와 텍스처 유형에 따라 출력 형식을 고릅니다. 예를 들어 단일 채널은 BC4, HDR은 BC6H, 일반 RGBA는 BC7로 압축합니다. 압축 과정에서 전체 밉맵 체인도 생성합니다. 기존 Basis Universal 방식은 compressed_image_saver_universal 기능으로 남아 있으며, WebGPU를 포함한 크로스 플랫폼 배포에 적합합니다.

Reddit 반응

  • @ _cart — Bevy 창시자이자 프로젝트 리드입니다. 편하게 무엇이든 물어보세요!
  • @-Teapot — Skate 3를 역공학해 Bevy로 만든 일에 대해 어떻게 생각하시나요? Bevy를 만든 팀의 노고에 감사드립니다.
    • @ _cart — 동시에 아주 멋지고 우울한 일이라고 생각합니다. Bevy가 이런 작업을 하는 사람들에게 매력적인 플랫폼이라는 점은 기쁘고, 오래된 게임을 새 플랫폼으로 옮겨 되살리거나 모드 제작을 쉽게 하는 일도 좋습니다. 하지만 요즘의 ‘AI 역공학’은 원작자의 저작권과 비전을 지워버리기도 합니다. 이런 일이 창작자에게 사회적 인정, 관심, 감사, 수익을 빼앗을 수도 있다고 봅니다. Skate 3 사례가 그렇다는 뜻은 아닙니다. 이미 충분히 사랑받은 게임이니까요. 다만 이런 범주의 프로젝트를 접할 때마다 그 점을 생각해볼 만합니다.
    • @Yorunokage — Bevy가 AI가 만든 저품질 게임 엔진이라는 평판을 얻지 않았으면 합니다. Unity도 많은 사람이 저렴한 에셋 재활용 게임을 만든 탓에 그런 평판을 얻었잖아요.
  • @Lacosst0 — Bevy에 로드맵이 생길까요? 특히 UI 반응성 기능을 기다리고 있습니다.
    • @ _cart — Bevy Project Goals Board가 가장 가까운 대안입니다. 일정을 기준으로 계획하지는 않지만, 현재와 가까운 시기의 초점을 보여줍니다.
  • @ksoops — 6주년 게시물에서 3개월 안팎의 출시 주기 대신 더 자주 작은 릴리스를 내는 방안을 논의한 적이 있습니다. 그 뒤로 진전이 있었나요?
    • @ _cart — 지금도 대체로 3개월 주기를 유지하기로 한 상태입니다.
  • @xxDJBxx — Bevy를 프로덕션에 쓸 준비가 됐다고 보시나요? 추천할 만한 튜토리얼도 있나요?
    • @ _cart — Bevy를 프로덕션에서 잘 쓰는 사람도 있지만, 씬과 에디터를 비롯한 기반 기능은 아직 다듬는 중입니다. 현재 상태를 살펴보고 프로젝트에 맞는지 판단하는 편이 좋습니다. Tainted Coders에 괜찮은 튜토리얼이 있습니다.
  • @chris-drm — 0.19의 ‘다음 계획’에 있던 Entity Inspector와 Bevy Book은 이번 릴리스에도 없고 0.20의 계획에도 언급되지 않았습니다. 진행 상황이 궁금합니다.
    • @alice_i_cecile — Inspector는 현재 main에서 기능의 약 90%까지 왔습니다. 최근 진척이 좋았지만, 프로토타입과 다듬기에 시간이 오래 걸렸습니다. Bevy에 통합하려면 reflection, BRP, UI 전반에서 약 40개의 OR이 필요합니다. 0.20에도 일부 기능이 들어갔지만 GUI는 없습니다. Book도 느리지만 꾸준히 진행 중이며, 편집에 한두 주 더 필요합니다. 늘 하고 싶은 작업은 아니지만 중단하지 않았습니다.
  • @Flaky_Response1881 — 정말 멋집니다! Bevy UI는 언제쯤 나올까요?
    • @ _cart — Bevy Editor를 말하는 거라면 씬 자산, 엔티티로서의 자산, 컴포넌트 검사기, 에디터 UI 위젯 같은 기반을 만들고 있습니다. 아직 날짜를 약속할 수는 없지만, 가까워지고 있습니다.
  • @atlasgorn — 공유 컴포넌트 계획이 있나요? 조만간 도입될까요?
    • @ _cart — 당장 계획은 없습니다. 씬 자산, 엔티티로서의 자산, 기본 에디터 작업 흐름이 들어간 뒤 중기적으로 검토하고 싶습니다. 구현하면 구조가 복잡해지지만 씬 생성 속도와 공유 변경 같은 장점도 있습니다.
  • @alice_i_cecile — Inspector는 0.21에 들어갈 예정입니다. 현재 main에서는 거의 완전히 작동합니다.
  • @atlasgorn — 게임 모드가 여러 개거나 시작 메뉴에서 싱글플레이와 멀티플레이를 고르는 게임을 위해 동적 플러그인을 지원할 계획이 있나요?
    • @alice_i_cecile — 왜 동적 플러그인이 해결책인가요? 보통은 실행 조건과 상태를 쓰면 됩니다. 일을 복잡하게 만들 필요가 없습니다.

원문: Bevy / 번역·요약: Trawling