- Rive đã công khai mã nguồn Rive Renderer do hãng tự phát triển, cho phép sử dụng một nền tảng kết xuất duy nhất trên mọi nền tảng, được tối ưu cho nội dung, hoạt ảnh và runtime của Rive
- Mục tiêu của renderer là duy trì hoạt ảnh 120fps và chất lượng khử răng cưa cao, ngay cả khi phải vẽ nhiều đồ họa vector và văn bản sắc nét
- Trước đây, Rive phụ thuộc vào nhiều renderer như Skia và HTML Canvas API, nên nếu một backend thiếu tính năng nào đó thì rất khó phát hành tính năng đó trên toàn bộ nền tảng
- Nhờ renderer duy nhất, có thể bổ sung nhất quán hơn trên nhiều runtime các hiệu ứng như blur, drop shadow, glow, tapered stroke
- Cách triển khai là rút gọn các đường vector đã khử răng cưa thành mảng tam giác và tận dụng pipeline raster hóa tam giác song song của GPU; có thể kích hoạt trên iOS, Android, Web, và đã được tích hợp sẵn vào runtime Unity và Unreal
Công bố Rive Renderer và bối cảnh phát triển
- Rive Renderer là renderer do Rive tự xây dựng cho nội dung, hoạt ảnh và runtime của mình
- Renderer này hướng tới hoạt ảnh 120fps và chất lượng khử răng cưa sạch đẹp ngay cả trong các tình huống phải vẽ nhiều đồ họa vector và văn bản trên màn hình
- Quá trình phát triển nội bộ mất 2 năm, giúp Rive kiểm soát trực tiếp hơn toàn bộ trải nghiệm, từ lúc nhà thiết kế tạo nội dung trong Rive Editor đến khi người dùng xem và tương tác trong runtime
- Hệ thống được tối ưu để chỉ chủ động tạo ra những nội dung có thể chạy nhanh trong runtime, nhờ đó nhà thiết kế bớt phải lo cách hiện thực hiệu năng và có thể tập trung hơn vào việc thiết kế
Giới hạn của cấu trúc nhiều renderer và hiệu quả của renderer đơn nhất
- Ở giai đoạn đầu, Rive sử dụng các giải pháp kết xuất mã nguồn mở sẵn có như Skia và HTML Canvas API
- Cấu trúc bring-your-own-renderer cho phép người dùng dễ dàng gắn renderer họ muốn vẫn sẽ tiếp tục được hỗ trợ
- Tuy nhiên, nếu không có renderer riêng nhất quán và được tối ưu, lộ trình sản phẩm và việc phát triển tính năng mới gần như buộc phải phụ thuộc vào các ràng buộc riêng của từng nền tảng
- Trong cấu trúc dùng nhiều renderer, nếu một tính năng nào đó không có ở một renderer cụ thể thì nó sẽ không hoạt động trên mọi backend nơi Rive chạy, khiến việc phát hành tính năng đó trở nên khó khăn
- Các hiệu ứng sẽ dễ bổ sung hơn với renderer đơn nhất bao gồm blurs, drop shadows, glows, tapered strokes
Cách triển khai và hỗ trợ nền tảng
- Rive Renderer dựa trên một phương pháp hình học, trong đó các đường vector đã khử răng cưa được rút gọn thành các mảng tam giác riêng biệt
- Hệ thống tận dụng pipeline raster hóa tam giác song song quy mô lớn vốn có sẵn trên GPU desktop và di động
- Sử dụng phần cứng 3D để vẽ đường cong Bézier bằng một kỹ thuật chia tam giác cụ thể
- Việc dùng renderer bên thứ ba vẫn tiếp tục khả dụng, nhưng để có các tính năng đặc trưng của Rive và trải nghiệm tổng thể tốt hơn thì Rive khuyến nghị dùng Rive Renderer
- Trên iOS, Android và Web, có thể bật Rive Renderer theo hướng dẫn chính thức
- Mã nguồn đã được công khai trên GitHub; renderer này đã được tích hợp vào runtime Unity và Unreal, và sẽ còn có thêm các tích hợp khác trong thời gian tới
1 bình luận
Ý kiến trên Hacker News
Tôi vừa ghé gian hàng GDC, và công cụ này trông thật sự rất tuyệt nếu xét như một chương trình giúp nhà thiết kế UI/UX trực tiếp làm được nhiều việc hơn trong game
Thông thường, nhà thiết kế làm vài ngày trong Figma rồi chuyển cho lập trình viên, sau đó lập trình viên trả lời rằng vì đủ thứ lý do nên không thể triển khai được, và quá trình qua lại cứ tiếp diễn
Vấn đề còn tệ hơn vì Unreal Engine thiếu một UI framework tốt phù hợp với game AAA, nhưng workflow của công cụ này là tốt nhất trong những gì tôi từng thấy, và có vẻ tích hợp rất tự nhiên với Unreal Engine và Blueprints
Cá nhân tôi rất kỳ vọng vì có vẻ nhà thiết kế UI/UX có thể làm việc mà không cần lập trình viên hỗ trợ. Các lập trình viên game nhìn chung cũng ghét làm UI
Có thể giải thích bằng sự khác biệt trong tâm thế khi ngồi xuống để làm việc và khi ngồi xuống để chơi game
Đó gần như là một trong những khoảnh khắc đầu tiên khiến tôi cảm thấy mình như một ông già đang la lên rằng phiên bản hiện đại quá tệ
Hiện có khá nhiều nghiên cứu về việc render đồ họa vector 2D bằng GPU tessellation, và việc đưa một công nghệ cùng dòng với các công trình của Raph Levien thành sản phẩm thực tế là khá ấn tượng
Tôi chưa từng dùng Rive nên đang thắc mắc liệu nó chỉ dành riêng để tạo animation đẹp mắt, hay cũng có thể tạo UI động kiểu có thể làm bằng thư viện GUI immediate mode
https://rive.app/game-ui
https://rive.app/blog/how-age-of-learning-uses-rive-to-a-b-t...
Tôi từng tạo UI khá phức tạp bằng Rive, nhưng vẫn chưa khám phá phần thêm element bằng lập trình hoặc thay đổi text UI theo sự kiện bên ngoài
Tôi có cảm giác thí nghiệm này chẳng phải đã từng được làm bằng Flash rồi sao. Macromedia/Adobe phát player miễn phí và thu tiền từ công cụ, còn Rive cũng có vẻ đang định mở mã nguồn player và thu tiền từ editor
Rive hơi khác ở chỗ dường như nhắm đến các nhà phát triển game dùng nền tảng khác như Unity hay Unreal, chẳng hạn những người muốn nhúng cinematic
Dù vậy, việc có một player nguồn mở cho thấy Rive muốn kiểm soát toàn bộ trải nghiệm, nên làm tôi nhớ đến Flash
Tôi đã chờ nó từ lúc được công bố. Trước đây họ dùng Skia, và toàn bộ ứng dụng cùng output render được làm bằng Flutter. Giờ Flutter có engine render mới là Impeller, được tối ưu hơn Skia cho các vấn đề đặc thù của Flutter
Trước đây khi tôi hỏi nhóm Impeller họ nhìn nhận renderer của Rive thế nào, họ nói rằng nó rất tuyệt cho đồ họa vector, nhưng Impeller còn phải xử lý cả các vấn đề render liên quan đến UI như hiển thị văn bản đúng cách, nên không phải là đối tượng so sánh một-một
Giờ renderer này đã được mở mã nguồn, hy vọng hai nhóm có thể học hỏi lẫn nhau
Tôi thích sản phẩm và công ty Rive, cũng thích mã nguồn mở, nhưng đây là việc phát hành theo giấy phép MIT một lớp trừu tượng render thuộc runtime Rive, vốn cần tạo nội dung bằng Rive Editor
Tôi tò mò mục tiêu của việc mở mã nguồn là gì, và họ muốn xây dựng một cộng đồng lớn hơn nào xung quanh nó
Tôi cũng tò mò liệu có dự án nào khác có thể hưởng lợi chỉ bằng cách đưa renderer này vào hay không
Cá nhân tôi cũng quan tâm. Hiện tôi dùng canvasAPI và pixi, và thường xuyên chạm tới giới hạn của vẽ 2D trong ngân sách khung hình 16ms
[0] https://github.com/rive-app/rive-renderer
Trông thật sự rất tuyệt, đến mức tôi muốn dùng thử cho một dự án sở thích cá nhân
Có vẻ như nó cung cấp một API Cairo/Skia/canvas/NanoVG đã được chuẩn hóa ở mức nào đó, kiểu như moveTo, lineTo, nên tôi hy vọng sẽ không tốn quá nhiều công học
Ít nhất ở đây có thấy lineTo: https://github.com/rive-app/rive-renderer/blob/main/renderer...
Tôi tò mò hiệu năng render này so với Skia hay Pathfinder như thế nào. Pathfinder, nếu phần cứng hỗ trợ, cũng có thể xử lý bước chuyển path thành tam giác bằng GPU compute
Một hướng tiếp cận render 2D dựa trên compute toàn diện hơn nữa là Vello
Đánh giá ban đầu của tôi là hiệu năng có vẻ phụ thuộc rất lớn vào phần cứng, đặc biệt là hỗ trợ pixel local storage. Theo những gì tôi thấy đến giờ, Apple Silicon là điểm lý tưởng. Phần cứng hỗ trợ binning và sắp xếp theo tile, và vẫn hoạt động tốt ngay cả khi tuần tự hóa việc thực thi fragment shader bên trong tile
Trên các phần cứng khác, tôi dự đoán chi phí tuần tự hóa các lời gọi như vậy sẽ lớn hơn nhiều
Một trong những lý do phía Vello chưa benchmark sâu là câu chuyện hiệu năng vẫn chưa hoàn chỉnh. Hiện có vấn đề khi gom bounding box bằng phép toán nguyên tử trên thiết bị, và một prototype dùng monoid cho việc rút gọn segment[2] cho thấy kết quả cải thiện khá tốt
Ngoài ra còn có kế hoạch dùng phép toán f16, điều này có thể mang lại lợi ích lớn, đặc biệt trên di động. Với nhiều bước prefix sum, dự kiến sẽ dùng subgroups; subgroups đang được đưa vào WebGPU[3]
Nhìn chung tôi vui vì renderer này được mở mã nguồn, và cũng mừng khi thấy có nhiều hoạt động hơn trong lĩnh vực render đồ họa vector GPU tốc độ cao. Tôi muốn một ngày nào đó thấy tương lai mà render path bằng CPU bị xem là lỗi thời, và lần công bố này đưa chúng ta tiến gần hơn theo hướng đó
[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
Đây có vẻ là những lựa chọn công nghệ vững chắc từ những người biết mình đang làm gì, và rất đáng để tự kiểm chứng hiệu năng cũng như chất lượng
Các renderer ưu tiên GPU kiểu này có cách tiếp cận hơi khác nhau, và nhiều khả năng mỗi cái sẽ có vùng mạnh riêng trong không gian đa chiều gồm chất lượng, hiệu năng, hỗ trợ phần cứng/driver và độ khó tích hợp. Nếu không thích một trong bốn điểm đó ở một lựa chọn, cũng đáng để xem các lựa chọn còn lại
Cá nhân tôi thật sự rất vui
Trong khoảng 6 tháng qua, tôi đã thúc đẩy nhiều khách hàng, từ các công ty chăm sóc sức khỏe có ứng dụng di động native cho đến các công ty và sản phẩm game chuyên sâu, chọn Rive thay vì Lottie và các giải pháp cũ. Giờ cuối cùng tôi xem nó đã đi vào quỹ đạo và ở trạng thái “sẵn sàng áp dụng”
Trong các cuộc thảo luận đó, điểm cuối cùng còn là lo ngại tiềm tàng là renderer mới nhất vẫn đóng và chưa ở hình thái cuối cùng
Nhờ quyết định này và công việc chung của đội ngũ Rive, tôi kỳ vọng mảng vấn đề này sẽ tiếp tục tốt lên. Các tính năng như shadow, blur khi được phát hành cũng sẽ rất thú vị
Lottie đang khá ổn định với tư cách là một định dạng tệp, workflow cũng đã được thiết lập tốt và tương đối đơn giản
Tôi tò mò Rive làm tốt hơn điều gì nhiều đến mức đáng phải thúc đẩy như vậy
Repository: https://github.com/rive-app/rive-renderer
Có liên quan: https://news.ycombinator.com/item?id=39754770 (Build System Schism: The Curse of Meta Build Systems)
Vấn đề này dường như cứ tiếp tục tạo ra các phần mềm cố gắng giải quyết nó, mà không có một lời giải dứt khoát
Lý do hơi lạ là vì, nếu có một hàm lấy mẫu pixel và thước đo không gian màu, thì với bất kỳ cảnh đồ họa vector nào cũng có một kết quả render đúng một cách khách quan. Mỗi giá trị pixel đầu ra phải là màu có thể biểu diễn gần nhất với tích chập của hàm đó và cảnh; còn cảnh có thể được biểu diễn như một hàm từ R^2 sang R, và màu sắc bằng một hệ màu tuyến tính
Điều này có vẻ khả thi nếu xử lý tốt GPU compute, cùng các giới hạn sai số khi tessellate đường cong hoặc tính số học phép tích phân ký hiệu chính xác của đường cong
Ngoài ra, một lời giải như vậy cũng có vẻ dễ cho phép điều chỉnh mức xấp xỉ để render nhanh hơn
Nếu chỉ có một máy tính song song đủ tốt thì có lẽ đã không khó đến vậy, nhưng thực tế là phải điều chỉnh logic render cho phù hợp với một tổ hợp cụ thể của đống “hack” mà hạ tầng GPU hỗ trợ, và mỗi thứ lại có những ràng buộc cùng đánh đổi rất riêng
Có lẽ bạn sẽ thích bài báo sắp ra về mở rộng nét vẽ thân thiện với GPU. Trọng tâm chính là xử lý phép tích phân ký hiệu chính xác đối với một thước đo độ cong cụ thể của đường cong bằng các phương pháp số có giới hạn sai số
Nếu tò mò thì hiện có thể xem trong mã shader/flatten.wgsl trên nhánh main của Vello