- Rive เปิดซอร์ส Rive Renderer ที่พัฒนาขึ้นเอง ทำให้สามารถใช้ฐานการเรนเดอร์เดียวที่ออกแบบมาสำหรับคอนเทนต์ แอนิเมชัน และรันไทม์ของ Rive ได้บนทุกแพลตฟอร์ม
- เป้าหมายของเรนเดอร์เรอร์คือการวาดกราฟิกเวกเตอร์และข้อความคมชัดจำนวนมาก ขณะยังคงรักษา แอนิเมชัน 120fps และคุณภาพ anti-aliasing ระดับสูง
- ก่อนหน้านี้ต้องพึ่งพาเรนเดอร์เรอร์หลายตัว เช่น Skia และ HTML Canvas API ทำให้ฟีเจอร์ที่ไม่มีในแบ็กเอนด์ใดแบ็กเอนด์หนึ่งเปิดตัวบนทุกแพลตฟอร์มได้ยาก
- ด้วยเรนเดอร์เรอร์เดียว จึงสามารถเพิ่มเอฟเฟกต์อย่าง blur, drop shadow, glow, tapered stroke ให้กับหลายรันไทม์ได้สอดคล้องกันมากขึ้น
- การใช้งานลดเส้นทางเวกเตอร์ที่ทำ anti-aliasing แล้วให้เป็น แพตช์สามเหลี่ยม และใช้ประโยชน์จากไปป์ไลน์การแรสเตอร์ไรซ์สามเหลี่ยมแบบขนานของ GPU โดยเปิดใช้งานได้บน iOS, Android และ Web และถูกรวมเข้ากับรันไทม์ Unity และ Unreal แล้ว
การเปิดตัว Rive Renderer และเบื้องหลังการพัฒนา
- Rive Renderer คือเรนเดอร์เรอร์ที่พัฒนาขึ้นเองสำหรับคอนเทนต์ แอนิเมชัน และรันไทม์ของ Rive
- มีเป้าหมายเพื่อให้ได้แอนิเมชัน 120fps และคุณภาพ anti-aliasing ที่สะอาด แม้ในสถานการณ์ที่ต้องวาดกราฟิกเวกเตอร์และข้อความจำนวนมากบนหน้าจอ
- การพัฒนาภายในใช้เวลา 2 ปี และทำให้ควบคุมประสบการณ์ทั้งหมดได้โดยตรงมากขึ้น ตั้งแต่ช่วงที่ดีไซเนอร์สร้างใน Rive Editor ไปจนถึงตอนที่ผู้ใช้เห็นและโต้ตอบในรันไทม์
- ปรับให้สร้างเฉพาะคอนเทนต์ที่ตั้งใจให้ทำงานได้รวดเร็วในรันไทม์ ช่วยให้ดีไซเนอร์กังวลเรื่องวิธีทำให้ประสิทธิภาพดีน้อยลง และโฟกัสกับการสร้างสรรค์ได้มากขึ้น
ข้อจำกัดของโครงสร้างเรนเดอร์เรอร์หลายตัว และผลของเรนเดอร์เรอร์เดียว
- Rive ในช่วงแรกใช้โซลูชันเรนเดอร์โอเพนซอร์สที่มีอยู่ เช่น Skia และ HTML Canvas API
- ยังคงรองรับโครงสร้าง bring-your-own-renderer ที่ให้ผู้ใช้เชื่อมต่อเรนเดอร์เรอร์ที่ต้องการได้ง่าย
- แต่หากไม่มีเรนเดอร์เรอร์ของตัวเองที่สอดคล้องและปรับให้เหมาะสม โรดแมปผลิตภัณฑ์และการพัฒนาฟีเจอร์ใหม่ย่อมถูกผูกไว้กับข้อจำกัดของแต่ละแพลตฟอร์ม
- ในโครงสร้างที่ใช้เรนเดอร์เรอร์หลายตัว เมื่อฟีเจอร์บางอย่างไม่มีในเรนเดอร์เรอร์ตัวใดตัวหนึ่ง ฟีเจอร์นั้นก็จะไม่ทำงานบนทุกแบ็กเอนด์ที่ Rive รันอยู่ ทำให้เปิดตัวฟีเจอร์ดังกล่าวได้ยาก
- เอฟเฟกต์ที่เพิ่มได้ง่ายขึ้นด้วยเรนเดอร์เรอร์เดียว ได้แก่ blurs, drop shadows, glows, tapered strokes เป็นต้น
วิธีการทำงานและการรองรับแพลตฟอร์ม
- Rive Renderer อิงวิธีเชิงเรขาคณิตที่ลดเส้นทางเวกเตอร์ที่ทำ anti-aliasing แล้วให้เป็น แพตช์สามเหลี่ยม เฉพาะตัว
- ใช้ประโยชน์จากไปป์ไลน์การแรสเตอร์ไรซ์สามเหลี่ยมแบบขนานขนาดใหญ่ที่มีมาใน GPU สำหรับเดสก์ท็อปและมือถือ
- ใช้ฮาร์ดแวร์ 3D ผ่านวิธีแบ่งสามเหลี่ยมแบบเฉพาะเพื่อวาด เส้นโค้ง Bézier
- ยังสามารถใช้เรนเดอร์เรอร์จากภายนอกต่อไปได้ แต่สำหรับฟีเจอร์เฉพาะของ Rive และประสบการณ์โดยรวม แนะนำให้ใช้ Rive Renderer
- บน iOS, Android และ Web สามารถเปิดใช้งาน Rive Renderer ได้ตาม คู่มืออย่างเป็นทางการ
- โค้ดเผยแพร่บน GitHub และถูกรวมเข้ากับรันไทม์ Unity และ Unreal แล้ว โดยมีแผนจะรวมเพิ่มเติมในอนาคต
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เพิ่งไปอยู่ที่ บูธ GDC มา ดูเป็นโปรแกรมที่ดีมากสำหรับให้ดีไซเนอร์ UI/UX ทำงานในเกมได้เองมากขึ้น
ปกติแล้วดีไซเนอร์จะทำงานใน Figma อยู่หลายวันแล้วส่งต่อให้โปรแกรมเมอร์ จากนั้นโปรแกรมเมอร์ก็ตอบกลับมาว่าทำไม่ได้ด้วยเหตุผลต่าง ๆ แล้วก็ต้องวนไปวนมาแบบนี้
ใน Unreal Engine ยิ่งหนักขึ้นไปอีก เพราะขาดเฟรมเวิร์ก UI ดี ๆ ที่เหมาะกับเกมระดับ AAA แต่เวิร์กโฟลว์ของเครื่องมือนี้ดีที่สุดเท่าที่เคยเห็นมา และดูเหมือนจะผสานเข้ากับ Unreal Engine และ Blueprints ได้อย่างเป็นธรรมชาติ
ส่วนตัวแล้วค่อนข้างคาดหวัง เพราะดูเหมือนดีไซเนอร์ UI/UX จะทำงานได้โดยไม่ต้องพึ่งโปรแกรมเมอร์ อีกอย่างโปรแกรมเมอร์เกมโดยทั่วไปก็มักไม่ชอบงาน UI ด้วย
น่าจะอธิบายได้ด้วยความแตกต่างของ mindset ระหว่างตอนนั่งลงเพื่อทำงานกับตอนนั่งลงเพื่อเล่นเกม
แทบจะเป็นครั้งแรก ๆ ที่รู้สึกเหมือนคนแก่ที่ตะโกนว่าภาคสมัยใหม่นั้นห่วยแตกเกินไป
มีงานวิจัยเกี่ยวกับการเรนเดอร์ กราฟิกเวกเตอร์ 2D ด้วย GPU tessellation กันอย่างคึกคัก และการนำเทคโนโลยีในสายเดียวกับงานของ Raph Levien ออกมาเป็นผลิตภัณฑ์จริงก็ดูเจ๋งทีเดียว
ยังไม่เคยใช้ Rive เลยสงสัยว่ามันทำมาเพื่อสร้างแอนิเมชันสวย ๆ โดยเฉพาะ หรือสามารถสร้าง UI แบบไดนามิก แบบที่น่าจะทำด้วยไลบรารี GUI แบบ immediate mode ได้ด้วยหรือไม่
https://rive.app/game-ui
https://rive.app/blog/how-age-of-learning-uses-rive-to-a-b-t...
เคยทำ UI ที่ค่อนข้างซับซ้อนด้วย Rive มาแล้ว แต่ยังไม่ได้สำรวจส่วนที่เพิ่มองค์ประกอบด้วยโปรแกรมตามอีเวนต์ภายนอก หรือเปลี่ยนข้อความ UI
รู้สึกว่าการทดลองนี้เราเคยทำกันไปแล้วด้วย Flash ไม่ใช่หรือ Macromedia/Adobe ปล่อย player ให้ใช้ฟรีแล้วคิดเงินกับเครื่องมือ ส่วน Rive ก็ดูเหมือนจะเปิดซอร์ส player แล้วคิดเงินกับ editor
Rive ต่างออกไปเล็กน้อยตรงที่ดูเหมือนจะเล็งไปที่นักพัฒนาเกมที่ใช้แพลตฟอร์มอื่นอย่าง Unity หรือ Unreal เช่น กลุ่มที่ต้องการฝังสิ่งอย่าง cinematic
ถึงอย่างนั้น การมี player แบบโอเพนซอร์สก็หมายความว่า Rive อยากควบคุมประสบการณ์ทั้งหมด จึงทำให้นึกถึง Flash
รอมาตลอดตั้งแต่ตอนประกาศ ก่อนหน้านี้ใช้ Skia และทั้งแอปกับผลลัพธ์การเรนเดอร์ก็ทำด้วย Flutter ตอนนี้ Flutter มีเอนจินเรนเดอร์ใหม่ชื่อ Impeller ซึ่งปรับให้เหมาะกับปัญหาเฉพาะของ Flutter มากกว่า Skia
เคยถามทีม Impeller ว่ามอง renderer ของ Rive อย่างไร พวกเขาบอกว่าสำหรับกราฟิกเวกเตอร์นั้นยอดเยี่ยม แต่ Impeller ต้องจัดการปัญหาการเรนเดอร์ที่เกี่ยวกับ UI ด้วย เช่น การแสดงข้อความให้ถูกต้อง จึงไม่ใช่สิ่งที่เทียบกันแบบหนึ่งต่อหนึ่ง
ตอนนี้ renderer นี้กลายเป็นโอเพนซอร์สแล้ว ก็หวังว่าทั้งสองทีมจะได้เรียนรู้จากกัน
ชอบทั้งผลิตภัณฑ์และบริษัท Rive และก็ชอบโอเพนซอร์สด้วย แต่สิ่งนี้คือการเปิดเผย เลเยอร์ abstraction สำหรับการเรนเดอร์ ซึ่งเป็นส่วนหนึ่งของ Rive runtime ที่ต้องสร้างคอนเทนต์ด้วย Rive Editor ภายใต้ไลเซนส์ MIT
อยากรู้ว่าเป้าหมายของการทำให้เป็นโอเพนซอร์สคืออะไร และอยากสร้างคอมมูนิตี้ที่ใหญ่ขึ้นแบบไหนรอบ ๆ สิ่งนี้
รวมถึงอยากรู้ว่ามีโปรเจกต์อื่นใดบ้างที่นึกออกว่าจะได้ประโยชน์จากการนำเฉพาะ renderer ไปใช้
ส่วนตัวก็สนใจเหมือนกัน ตอนนี้ใช้ canvasAPI กับ pixi อยู่ และมักชนเพดานของการวาด 2D ภายในงบเวลาเฟรม 16ms
[0] https://github.com/rive-app/rive-renderer
ดูเจ๋งมากจนอยากเอาไปลองใช้กับโปรเจกต์งานอดิเรกส่วนตัว
ดูเหมือนจะมี Cairo/Skia/canvas/NanoVG API ที่ค่อนข้างเป็นมาตรฐาน เช่น moveTo, lineTo ให้ใช้ เลยหวังว่าจะไม่ต้องใช้ความพยายามมากนักในการเรียนรู้
อย่างน้อยก็เห็น lineTo อยู่ตรงนี้: https://github.com/rive-app/rive-renderer/blob/main/renderer...
สงสัยว่าประสิทธิภาพการเรนเดอร์นี้เมื่อเทียบกับ Skia หรือ Pathfinder เป็นอย่างไร Pathfinder ถ้าฮาร์ดแวร์รองรับ ก็สามารถให้ GPU compute จัดการขั้นตอนแปลง path เป็นสามเหลี่ยมได้
แนวทางการเรนเดอร์ 2D แบบอิง compute ที่ครอบคลุมกว่านี้ก็มี Vello ด้วย
จากการประเมินเบื้องต้น ประสิทธิภาพน่าจะขึ้นอยู่กับฮาร์ดแวร์อย่างมาก โดยเฉพาะการรองรับ pixel local storage เท่าที่เห็นตอนนี้ Apple Silicon น่าจะเป็นจุดที่เหมาะที่สุด เพราะฮาร์ดแวร์รองรับการทำ binning และ sorting ระดับไทล์ และยังทำงานได้ดีแม้ serialize การรัน fragment shader ภายในไทล์
คาดว่าบนฮาร์ดแวร์อื่น ต้นทุนของการ serialize การเรียกแบบนั้นจะสูงกว่ามาก
หนึ่งในเหตุผลที่ฝั่ง Vello ยังไม่ได้ทำ benchmarking เชิงลึก คือเรื่องประสิทธิภาพยังไม่ลงตัว ตอนนี้มีปัญหาการรวบรวม bounding box ด้วย device atomic operations และ implementation ต้นแบบที่ใช้ monoid สำหรับการลดรูปเซกเมนต์[2] ก็แสดงผลลัพธ์ที่ดีขึ้นพอสมควร
นอกจากนี้ยังมีแผนจะใช้การคำนวณแบบ f16 ซึ่งอาจให้ประโยชน์มากโดยเฉพาะบนมือถือ หลายขั้นตอนของ prefix sum มีแผนจะใช้ subgroups ซึ่งกำลังถูกเพิ่มเข้าไปใน WebGPU[3]
โดยรวมแล้วดีใจที่เรนเดอร์เรอร์นี้ถูกเปิดเป็นโอเพนซอร์ส และก็ดีใจที่วงการเรนเดอร์เวกเตอร์กราฟิกบน GPU ให้เร็วเริ่มคึกคักขึ้น อยากเห็นอนาคตที่สักวันหนึ่งการเรนเดอร์ path บน 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 ก่อนแบบนี้มีแนวทางแตกต่างกันเล็กน้อย และมีความเป็นไปได้สูงว่าแต่ละตัวจะมีพื้นที่ที่ดีที่สุดของตัวเองในมิติหลายด้าน เช่น คุณภาพ ประสิทธิภาพ การรองรับฮาร์ดแวร์/ไดรเวอร์ และความยากในการผสานรวม ถ้าไม่ชอบหนึ่งในสี่ตัวนี้ ก็คุ้มที่จะลองดูตัวที่เหลือด้วย
โดยส่วนตัวดีใจมาก
ตลอดประมาณ 6 เดือนที่ผ่านมา ผมผลักดันให้ลูกค้าหลายราย ตั้งแต่บริษัทเฮลท์แคร์ที่มีแอปมือถือแบบ native ไปจนถึงบริษัทเกมและผลิตภัณฑ์เชิงลึก หันมา ใช้ Rive แทน Lottie และโซลูชันรุ่นเก่า ๆ ตอนนี้ในที่สุดก็ดูเหมือนจะเข้าที่และอยู่ในสถานะ “พร้อมนำไปใช้” แล้ว
ในการพูดคุยเหล่านั้น ประเด็นสุดท้ายที่ยังเป็นความกังวลที่อาจเกิดขึ้นได้ คือเรนเดอร์เรอร์รุ่นใหม่ยังเป็นแบบปิดและยังไม่ใช่รูปแบบสุดท้าย
ด้วยการตัดสินใจครั้งนี้และงานโดยรวมของทีม Rive เลยคาดหวังว่าพื้นที่ปัญหานี้จะพัฒนาต่อไปเรื่อย ๆ ฟีเจอร์อย่างเงาและเบลอก็น่าจะน่าสนใจมากเมื่อเปิดตัว
Lottie กำลังค่อนข้างลงหลักปักฐานในฐานะฟอร์แมตไฟล์ เวิร์กโฟลว์ก็จัดตั้งไว้ดีแล้ว และค่อนข้างเรียบง่าย
อยากรู้ว่า Rive ทำอะไรได้ดีกว่ามากจนถึงขั้นควรผลักดันขนาดนั้น
รีโพซิทอรี: https://github.com/rive-app/rive-renderer
เกี่ยวข้อง: https://news.ycombinator.com/item?id=39754770 (Build System Schism: The Curse of Meta Build Systems)
ปัญหานี้ดูเหมือนจะไม่มีวิธีแก้ที่ชัดเจนตายตัว และยังคงมีการสร้างซอฟต์แวร์เพื่อพยายามแก้มันต่อไป
เหตุผลที่ดูแปลกอยู่บ้างคือ หากมีฟังก์ชัน sampling พิกเซลและเมตริกของ color space ให้แล้ว สำหรับฉากเวกเตอร์กราฟิกใด ๆ ก็ควรมีการเรนเดอร์ที่ถูกต้องอย่างเป็นวัตถุวิสัยอยู่หนึ่งแบบ ค่าแต่ละพิกเซลเอาต์พุตควรเป็นสีที่สามารถแทนค่าได้ซึ่งใกล้เคียงที่สุดกับ convolution ของฟังก์ชันนั้นกับฉาก และฉากสามารถแทนเป็นฟังก์ชันจาก R^2 ไปยัง R ส่วนสีก็แทนได้ด้วยระบบสีเชิงเส้น
ดูเหมือนจะทำได้ หากจัดการ GPU compute และขอบเขตความคลาดเคลื่อนเมื่อทำ curve tessellation หรือคำนวณ numerical exact symbolic integration ของเส้นโค้งได้ดี
อีกทั้งวิธีแก้แบบนี้ยังดูน่าจะทำให้ปรับระดับการประมาณค่าเพื่อการเรนเดอร์ที่เร็วขึ้นได้ง่ายด้วย
ถ้าแค่มีคอมพิวเตอร์ขนานที่ดีพอ เรื่องนี้คงไม่ยากนัก แต่ในความเป็นจริงต้องปรับตรรกะการเรนเดอร์ให้เข้ากับชุดของ hack ต่าง ๆ ที่โครงสร้างพื้นฐาน GPU รองรับ ซึ่งแต่ละอย่างก็มีข้อจำกัดและ trade-off ที่เฉพาะตัวมาก
คุณน่าจะชอบ paper เรื่องการขยาย stroke ที่เป็นมิตรกับ GPU ซึ่งกำลังจะออกมาเร็ว ๆ นี้ แก่นของมันคือการจัดการ exact symbolic integration สำหรับเมตริกความโค้งเฉพาะบางแบบของเส้นโค้ง ด้วยวิธีเชิงตัวเลขที่มีขอบเขตความคลาดเคลื่อน
ถ้าสนใจ ตอนนี้ก็ดูได้ในโค้ด
shader/flatten.wgslบน main ของ Vello