실시간 벡터 그래픽용 Rive Renderer, 오픈 소스로 전환

 (rive.app)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Rive가 자체 제작한 Rive Renderer를 오픈 소스로 공개해, Rive 콘텐츠·애니메이션·런타임에 맞춘 단일 렌더링 기반을 모든 플랫폼에서 사용할 수 있게 함
  • 렌더러의 목표는 벡터 그래픽과 선명한 텍스트를 많이 그리면서도 120fps 애니메이션과 높은 안티앨리어싱 품질을 유지하는 것임
  • 기존에는 Skia와 HTML Canvas API 등 여러 렌더러에 의존해, 한 백엔드에 없는 기능은 전체 플랫폼에 출시하기 어려웠음
  • 단일 렌더러 덕분에 blur, drop shadow, glow, tapered stroke 같은 효과를 여러 런타임에 더 일관되게 추가할 수 있음
  • 구현은 안티앨리어싱된 벡터 경로를 삼각형 패치로 줄이고 GPU의 병렬 삼각형 래스터화 파이프라인을 활용하며, iOS·Android·Web에서 활성화 가능하고 Unity·Unreal 런타임에는 이미 통합됨

Rive Renderer 공개와 제작 배경

  • Rive Renderer는 Rive 콘텐츠, 애니메이션, 런타임을 위해 자체 제작된 렌더러임
  • 벡터 그래픽과 텍스트를 화면에 많이 그리는 상황에서도 120fps 애니메이션과 깨끗한 안티앨리어싱 품질을 목표로 함
  • 내부 제작에는 2년이 걸렸고, Rive Editor에서 디자이너가 만드는 시점부터 런타임에서 사용자가 보고 상호작용하는 시점까지 전체 경험을 더 직접 제어할 수 있게 됨
  • 런타임에서 빠르게 동작할 콘텐츠만 의도적으로 생성하도록 최적화해, 디자이너가 성능 구현 방식을 덜 신경 쓰고 제작에 집중할 수 있음

여러 렌더러 구조의 한계와 단일 렌더러의 효과

  • 초기 Rive는 Skia와 HTML Canvas API 같은 기존 오픈 소스 렌더링 솔루션을 사용함
  • 사용자가 원하는 렌더러를 쉽게 연결할 수 있는 bring-your-own-renderer 구조는 계속 지원함
  • 하지만 일관되고 최적화된 자체 렌더러가 없으면, 제품 로드맵과 새 기능 개발이 플랫폼별 제약에 묶일 수밖에 없었음
  • 여러 렌더러를 쓰는 구조에서는 특정 기능이 한 렌더러에 없을 때 Rive가 실행되는 모든 백엔드에서 동작하지 않아, 해당 기능을 출시하기 어려웠음
  • 단일 렌더러로 추가하기 쉬워지는 효과에는 blurs, drop shadows, glows, tapered strokes 등이 포함됨

구현 방식과 플랫폼 지원

  • Rive Renderer는 안티앨리어싱된 벡터 경로를 고유한 삼각형 패치로 줄이는 기하학적 방식에 기반함
    • 데스크톱과 모바일 GPU에 기본 제공되는 대규모 병렬 삼각형 래스터화 파이프라인을 활용함
    • 특정 삼각분할 방식으로 3D 하드웨어를 사용해 Bézier 곡선을 그림
  • 서드파티 렌더러 사용은 계속 가능하지만, Rive 고유 기능과 전반적 경험을 위해서는 Rive Renderer 사용이 권장됨
  • iOS, Android, Web에서는 공식 안내를 따라 Rive Renderer를 활성화할 수 있음
  • 코드는 GitHub에 공개되어 있으며, Unity와 Unreal 런타임에는 통합되어 있고 추가 통합도 예정되어 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 방금 GDC 부스에 있었는데, UI/UX 디자이너가 게임에서 더 많은 일을 직접 하게 해주는 프로그램으로는 정말 좋아 보였음
    보통은 디자이너가 Figma에서 며칠 작업한 뒤 프로그래머에게 넘기고, 프로그래머가 이런저런 이유로 구현 불가능하다고 답하면서 왕복이 이어짐
    Unreal Engine에는 AAA 게임에 맞는 좋은 UI 프레임워크가 부족해서 더 심해지는데, 이 도구의 작업 흐름은 지금까지 본 것 중 최고이고 Unreal Engine과 Blueprints에 자연스럽게 붙는 듯함
    개인적으로는 UI/UX 디자이너가 프로그래머 도움 없이 작업할 수 있어 보여 기대가 큼. 게임 프로그래머들은 대체로 UI 작업을 싫어하기도 함

    • UI/UX 디자이너라면 게임 쪽에서 일하고 싶었을 것 같음. 생산성 소프트웨어는 이미 깊게 자리 잡은 패러다임과 추상화가 많아서 바꾸려 하면 사용자가 투덜대지만, 게임에서는 새로운 UI/UX 결정이 짜증보다 호기심으로 받아들여지는 경우가 많음
      일을 하려고 앉았을 때와 게임을 하려고 앉았을 때의 마음가짐 차이로 설명될 수 있어 보임
    • 디자인과 프로그래밍 사이의 인수인계가 지루하다는 데는 동의하지만, UMG가 어디서 부족하다고 보는지 궁금함. 익숙해지고 나서는 UI 구현이 꽤 재미있었음
    • 요즘 Unreal Engine의 UI/UX가 이렇게 나빠진 건 아쉬움. 얼마 전 친구들과 UT99를 했는데, 게임 안 UI부터 설정, 서버 브라우저 메뉴까지 얼마나 강력하고 직관적이며 유연했는지 새삼 놀랐음
      현대판이 너무 형편없다고 소리치는 노인처럼 느껴진 거의 첫 순간이었음

  • GPU 테셀레이션으로 2D 벡터 그래픽을 렌더링하는 연구가 활발한데, Raph Levien 작업 같은 흐름의 기술을 실제 제품으로 내놓는 건 꽤 멋짐
    Rive를 써본 적은 없어서, 멋진 애니메이션 제작 전용인지 아니면 즉시 모드 GUI 라이브러리로 만들 법한 동적 UI도 만들 수 있는지 궁금함

  • 이 실험은 이미 Flash로 해본 것 아닌가 싶음. Macromedia/Adobe는 플레이어를 무료로 풀고 도구에 과금했는데, Rive도 플레이어를 오픈소스로 공개하고 편집기에 과금하려는 것처럼 보임
    Rive는 Unity나 Unreal 같은 다른 플랫폼을 쓰는 게임 개발자, 예컨대 시네마틱 같은 것을 임베드하려는 쪽을 겨냥하는 듯해 조금 다르긴 함
    그래도 오픈소스 플레이어가 있다는 건 Rive가 전체 경험을 장악하고 싶어 한다는 뜻이라 Flash가 떠오름

    • Flash는 훌륭했음. 더 나은 Flash를 만드는 일은 오래전부터 필요했고, Rive는 새로운 Flash를 향한 좋은 시도처럼 보임
    • 좋은 비교이고, 이게 렌더러일 뿐이라는 점도 중요함. MIT 라이선스로 공개된 건 반갑지만, 호환 콘텐츠를 만들 오픈소스 도구가 얼마나 있는지, 기존 도구의 다른 형식에서 내보내기를 만들기가 얼마나 쉬울지는 궁금함
    • 플레이어와 파일 형식이 열려 있고 서드파티 도구가 역공학을 하지 않아도 됐다면 Flash가 얼마나 더 나아질 수 있었을지 생각하게 됨
    • 예전에 Scaleform이 있었고, Flash와 함께 중단된 것처럼 보임: https://en.wikipedia.org/wiki/Scaleform_GFx

  • 발표 때부터 계속 기다려 왔음. 이전에는 Skia를 썼고, 앱 전체와 렌더링 출력이 Flutter로 만들어졌음. 이제 Flutter에는 Skia보다 Flutter 특화 문제에 더 최적화된 새 렌더링 엔진 Impeller가 있음
    예전에 Impeller 팀에 Rive 렌더러를 어떻게 보는지 물었을 때, 벡터 그래픽에는 훌륭하지만 Impeller는 텍스트를 제대로 표시하는 등 UI 관련 렌더링 문제까지 다뤄야 해서 일대일 비교 대상은 아니라고 했음
    이 렌더러가 오픈소스가 되었으니 두 팀이 서로 배울 수 있기를 바람

    • 틀렸다면 고쳐달라. 글꼴도 이미 벡터 그래픽으로 렌더링되는 것 아닌가? TTF와 OTF는 벡터 형식이 맞지 않나?

  • Rive 제품과 회사도 좋아하고 오픈소스도 좋아하지만, 이건 Rive Editor로 콘텐츠를 만들어야 하는 Rive 런타임의 일부인 렌더링 추상화 계층을 MIT 라이선스로 공개한 것임
    오픈소스화의 목표와, 그 주변에 어떤 더 큰 커뮤니티를 만들고 싶은지 궁금함
    렌더러만 도입해서 이득을 볼 다른 프로젝트가 떠오르는지도 궁금함

    • 독점 편집기로 계속 돈을 벌면서, 배포와 생태계 형성을 위해 오픈소스 렌더러를 제공하려는 것 같음. 다른 사람들이 이 렌더러를 대상으로 삼게 만들 수 있다면 렌더러가 우수할수록 유리함
      개인적으로도 관심이 있음. 현재 canvasAPI와 pixi를 쓰는데, 16ms 프레임 예산 안에서 2D 그리기의 한계에 자주 부딪힘
    • GitHub에 따르면 이 저장소에는 렌더러 코드와 직접 인터페이스하는 방법을 보여주는 예제가 들어 있음
      [0] https://github.com/rive-app/rive-renderer
    • 벡터 그래픽을 만들기 위해 꼭 특수 편집기가 필요한 것은 아님. 게임부터 UI 툴킷까지 많은 프로젝트가 벡터 그래픽 렌더러를 필요로 하고, 그래서 Skia, Cairo, 이제 Rive 같은 라이브러리가 존재함
    • “Macromedia Flash가 되지 않기”를 위한 영리한 전략처럼 보임

  • 개인 취미 프로젝트에 써보고 싶을 만큼 정말 멋져 보임
    moveTo, lineTo 같은 어느 정도 표준화된 Cairo/Skia/canvas/NanoVG API가 제공되는 것 같아서 배우는 데 큰 노력이 들지 않기를 기대함
    적어도 여기에는 lineTo가 보임: https://github.com/rive-app/rive-renderer/blob/main/renderer...

  • 이 렌더링 성능이 Skia나 Pathfinder와 비교해 어떤지 궁금함. Pathfinder는 하드웨어가 지원하면 경로를 삼각형으로 바꾸는 단계를 GPU 컴퓨트로 처리할 수도 있음
    더 포괄적인 컴퓨트 기반 2D 렌더링 접근으로는 Vello도 있음

    • 신중한 벤치마킹을 해보고 싶음. 이 렌더러는 충분히 경쟁력 있어 보이지만, 의미 있는 결과를 얻으려면 벤치마킹이 정말 어려움
      초기 판단으로는 성능이 하드웨어, 특히 pixel local storage 지원에 크게 좌우될 것 같음. 지금까지 본 바로는 Apple Silicon이 이상적인 지점임. 타일 단위 빈닝과 정렬을 하드웨어가 지원하고, 타일 안에서 프래그먼트 셰이더 실행을 직렬화해도 잘 작동함
      다른 하드웨어에서는 그런 호출 직렬화 비용이 훨씬 커질 것으로 예상함
      Vello 쪽에서 깊은 벤치마킹을 아직 하지 않은 이유 중 하나는 성능 이야기가 아직 완성되지 않았기 때문임. 현재 장치 원자 연산으로 경계 상자를 모으는 문제가 있고, 세그먼트 축소에 모노이드를 쓰는 프로토타입 구현[2]이 꽤 개선된 결과를 보여줌
      추가로 f16 연산을 할 계획이고, 특히 모바일에서 큰 이득이 될 수 있음. 여러 누적합 단계에는 부분 그룹을 사용할 계획인데, 부분 그룹은 WebGPU에 들어가는 중임[3]
      전반적으로 이 렌더러가 오픈소스로 공개되어 기쁘고, 빠른 GPU 벡터 그래픽 렌더링에서 활동이 많아진 것도 반가움. 언젠가 CPU 경로 렌더링이 시대에 뒤처진 것으로 여겨지는 미래를 보고 싶고, 이번 공개가 그 방향에 더 가까워지게 함
      [1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/da...
      [2]: https://github.com/linebender/vello/issues/259
      [3]: https://github.com/gpuweb/gpuweb/issues/4306
    • 사용한 GPU 기술과 저장소 커미터 이름들을 보면, 적어도 Skia와 Pathfinder 둘 다와 경쟁할 수 있다고 꽤 확신함. Vello는 잘 모름
      무엇을 하는지 아는 사람들이 고른 탄탄한 기술 선택으로 보이고, 성능과 품질을 직접 확인해볼 만한 가치가 충분함
      이런 GPU 우선 렌더러들은 접근이 조금씩 다르고, 품질·성능·하드웨어/드라이버 지원·통합 난이도라는 다차원 공간에서 각자 최고인 영역이 있을 가능성이 큼. 네 가지 중 하나가 마음에 들지 않으면 나머지도 확인해볼 만함
    • 새 벤치마킹을 해야 함. 초기 테스트 이후 Rive Renderer는 더 빨라졌음: https://twitter.com/guidorosso/status/1595187838454140928
    • 확인해본 런타임 구현 중 적어도 하나는 Skia 위에 구현되어 있었음. 여러 가능한 백엔드를 지원하는 것 같음

  • 개인적으로 정말 반가움
    지난 6개월가량 기본 모바일 앱을 가진 헬스케어 회사부터 깊은 게임 회사와 제품까지 여러 고객에게 Lottie와 예전 해결책들 대신 Rive 채택을 밀어왔음. 이제 드디어 궤도에 올라 “도입 준비 완료” 상태라고 봄
    그 논의들에서 마지막으로 잠재적 우려로 남았던 부분이 최신 렌더러가 닫혀 있고 아직 최종 형태가 아니라는 점이었음
    이번 결정과 Rive 팀의 전반적인 작업 덕분에 이 문제 영역이 계속 나아질 것 같아 기대됨. 그림자, 블러 같은 기능도 출시되면 아주 흥미로울 것임

    • 기본적인 질문일 수 있지만, 왜 Rive인가?
      Lottie는 파일 형식으로 꽤 자리 잡아가고 있고 작업 흐름도 잘 정립되어 있으며 비교적 단순함
      Rive가 무엇을 훨씬 더 잘해서 굳이 밀어야 할 정도인지 궁금함

  • 저장소: https://github.com/rive-app/rive-renderer

  • 이 문제는 확정적인 해법 없이, 이를 해결하려는 소프트웨어를 계속 만들어내는 듯함
    조금 이상한 이유는, 픽셀 샘플링 함수와 색공간 척도가 주어지면 어떤 벡터 그래픽 장면에도 객관적으로 올바른 렌더링이 하나 있기 때문임. 각 출력 픽셀 값은 그 함수와 장면의 합성곱에 가장 가까운 표현 가능한 색이어야 하고, 장면은 R^2에서 R로 가는 함수, 색은 선형 색 체계로 표현될 수 있음
    GPU 컴퓨트와, 곡선 테셀레이션 또는 곡선의 정확한 기호 적분을 수치적으로 계산할 때의 오차 한계를 잘 다루면 달성 가능해 보임
    또한 이런 해법은 더 빠른 렌더링을 위해 근사 수준을 조절할 수 있게 만들기도 쉬워 보임

    • 맞는 얘기라고 봄. 2D 렌더링은 꽤 잘 정의되어 있음. 문제는 GPU 생태계의 압도적인 복잡성임
      그저 괜찮은 병렬 컴퓨터만 있었다면 그리 어렵지 않았을 텐데, 실제로는 GPU 인프라가 지원하는 해킹 더미의 특정 조합에 맞춰 렌더링 논리를 적응시켜야 하고, 각각은 아주 독특한 제약과 절충을 가짐
      곧 나올 GPU 친화적 스트로크 확장 논문을 좋아할 것 같음. 핵심이 바로 곡선의 특정 곡률 척도에 대한 정확한 기호 적분을 오차 한계가 있는 수치 방법으로 다루는 것임
      궁금하면 지금도 Vello main의 shader/flatten.wgsl 코드에서 볼 수 있음
    • 그렇다면 직접 벡터 그래픽 라이브러리를 써야 할 듯함
답변달기