CityGaussian: การเรนเดอร์ฉากขนาดใหญ่คุณภาพสูงแบบเรียลไทม์ด้วย Gaussian
(dekuliutesla.github.io)- CityGaussian(CityGS) เป็นวิธีจาก ECCV 2024 ที่ขยาย 3D Gaussian Splatting(3DGS) ไปสู่ฉากระดับเมือง โดยมุ่งทั้งประสิทธิภาพการฝึกและคุณภาพการสำรวจแบบเรียลไทม์
- แก้ข้อจำกัดที่การจัดการฉากขนาดใหญ่ทั้งหมดในครั้งเดียวทำได้ยาก ด้วยการแบ่งปัญหาออกเป็น การฝึกแบบแบ่งแยกแล้วพิชิต และกลยุทธ์ ระดับรายละเอียด(LoD)
- ใช้ข้อมูล prior ของฉากโดยรวมและการเลือกข้อมูลฝึกแบบปรับตัวได้ เพื่อจัดแนวผลลัพธ์การฝึกแต่ละบล็อกให้มีประสิทธิภาพยิ่งขึ้นและหลอมรวมอย่างราบรื่น
- บีบอัด Gaussian primitive ที่หลอมรวมแล้วเพื่อสร้างรายละเอียดหลายระดับ และในขั้นตอนเรนเดอร์จะเลือกและรวมระดับรายละเอียดที่เหมาะสมเป็นรายบล็อก
- หากแสดง MatrixCity โดยไม่ใช้ LoD ด้วย Gaussian 25 ล้านตัว จะได้เพียง 18 FPS บน A100 แต่ CityGS ที่ใช้ LoD ทำการเรนเดอร์แบบเรียลไทม์ได้ที่เฉลี่ย 36 FPS
โครงสร้างการฝึกและเรนเดอร์สำหรับ 3DGS ขนาดใหญ่
- 3D Gaussian Splatting(3DGS) แสดงจุดแข็งในการสร้างฉาก 3D แบบเรียลไทม์และการสังเคราะห์มุมมองใหม่ แต่ การฝึกฉากขนาดใหญ่ และการเรนเดอร์แบบเรียลไทม์ในสเกลที่หลากหลายยังคงเป็นภาระหนัก
- CityGaussian แบ่งปัญหานี้ออกเป็นสองขั้นตอน
- การฝึกแบบแบ่งแยกแล้วพิชิต: แบ่งฉากขนาดใหญ่ออกเป็นบล็อกเพื่อฝึกอย่างมีประสิทธิภาพ
- กลยุทธ์ LoD: เพิ่มความเร็วการเรนเดอร์โดยใช้เฉพาะระดับรายละเอียดที่จำเป็นให้สอดคล้องกับสเกลการสังเกต
- ข้อมูล prior ของฉากโดยรวมและการเลือกข้อมูลฝึกแบบปรับตัวได้ช่วยเพิ่มประสิทธิภาพการฝึก และช่วยให้ชิ้นส่วนฉากที่แยกกันหลอมรวมได้เป็นธรรมชาติมากขึ้น
- Gaussian primitive ที่หลอมรวมแล้วจะผ่านกระบวนการบีบอัดและถูกจัดเป็น ระดับรายละเอียด หลายระดับ
- ในขั้นตอนเรนเดอร์ จะใช้กลยุทธ์การเลือกและรวมระดับรายละเอียดตามแต่ละบล็อก ทำให้สร้างภาพได้รวดเร็วแม้ในหลายสเกล
ประสิทธิภาพและทรัพยากรที่เปิดเผย
- หากไม่ใช้ LoD ฉาก MatrixCity จะถูกแสดงด้วย Gaussian 25 ล้านตัว และวัดได้ 18 FPS บน A100
- ความเร็วระดับนี้ถูกประเมินว่ายังยากที่จะมอบประสบการณ์การโรมมิ่งที่ลื่นไหล
- CityGS ที่ใช้ LoD สามารถเรนเดอร์แบบเรียลไทม์ได้แม้ในสเกลที่แตกต่างกันมาก และวัดได้เฉลี่ย 36 FPS บน A100
- ในการทดลองฉากขนาดใหญ่ CityGS แสดงคุณภาพการเรนเดอร์ระดับแนวหน้า และรองรับการเรนเดอร์แบบเรียลไทม์ที่สม่ำเสมอสำหรับฉากขนาดใหญ่ในหลายสเกล
- ทรัพยากรที่เปิดเผย
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
จากชื่อชุดข้อมูลของวิดีโอที่ชื่อว่า Matrix city ก็ดูมีแนวโน้มสูงว่าน่าจะดึงมาจากเดโม Matrix ของ Unreal Engine 5 ที่ปล่อยเมื่อหลายปีก่อน
มุมมองต่าง ๆ คล้ายกันมาก เลยให้ความสมจริงเหมือนภาพถ่าย แต่ก็ดูไม่น่าได้มาจากภาพถ่ายจริง
ลองค้นเพิ่มแล้วก็ใช่จริง: https://city-super.github.io/matrixcity/
พอมองแบบนี้ก็น่าสนใจ เพราะเท่ากับว่าบทความต้นฉบับกำลังสร้างสิ่งที่สร้างใหม่จากวัตถุจริงขึ้นมาอีกที
แผนที่ MatrixCity ไม่เหมือนกันเสียทีเดียว แต่ก็คล้ายกับแผนที่ของ Matrix Awakens อยู่พอสมควร เรื่องนี้ดูได้จากการวิเคราะห์การออกแบบในหน้านี้ [3] ที่เขียนโดยหัวหน้าฝ่ายเทคนิคของโปรเจกต์ Matrix Awakens
ถ้าดูต่อไปอีก ในส่วน MatrixPlugin ของโค้ดเบส GitHub [4] ก็มีการระบุไว้ชัดเจนว่าใช้ โปรเจกต์ city-sample
[1] https://www.unrealengine.com/marketplace/en-US/product/city-...
[2] https://www.unrealengine.com/marketplace/en-US/learn/city-sa...
[3] https://quentinmarmier.artstation.com/projects/xYeKNO
[4] https://github.com/city-super/MatrixCity
เลยทำให้การฝึก NeRF หรือ Gaussian Splatting ง่ายขึ้นเล็กน้อย เพราะไม่มีความคลาดเคลื่อนจากการปรับท่ากล้องให้เหมาะที่สุด
นี่ก็เป็นเหตุผลเดียวกับที่งานวิจัย NeRF ยุคแรก ๆ ใช้รถขุด Lego สีเหลืองชื่อดังที่เรนเดอร์จาก Blender
สำหรับฉากอย่าง Matrix city ก็ดูเหมือนไม่จำเป็นต้องเสียเวลาเทรนนาน ๆ เพื่อสร้างข้อมูลเดิมขึ้นมาใหม่
สุดสัปดาห์ที่ผ่านมา ผมลองเอา 3D tile mesh ของ Google Maps มาประกบกับ Gaussian splat ดู แม้จะไม่เหมือนกันทั้งหมด แต่เอฟเฟกต์ที่ได้คล้ายกันพอสมควรและใช้งานได้จริง
ตัวอย่าง 1 ที่มีโค้ดแนบลิงก์ไว้: https://twitter.com/kfarr/status/1773934700878561396
ตัวอย่าง 2: https://twitter.com/3dstreetapp/status/1775203540442697782
ในลิงก์แรกมี error ขึ้นในเครื่องมือนักพัฒนา
Uncaught (in promise) Error: Failed to fetch resource [https://tile.googleapis.com/v1/3dti](<https://tile.googleapis.com/v1/3dti>;)...ตั้งใจว่าจะไปดู aframe-loader-3dtiles-component
ที่บอกว่า “ความเร็วเฉลี่ย 36 FPS (ทดสอบบน A100)” ฟังดูเหมือนหมายถึงว่าเรียลไทม์ถ้าคุณมี GPU ราคา $8k
เวลาอ่านงานกราฟิกส์ที่บอกว่าทำความเร็วระดับเรียลไทม์ได้ ต้องเช็กเสมอว่าหมายถึงเรียลไทม์จริง ๆ หรือหมายถึง “640x480 ที่ 20fps บนฮาร์ดแวร์ที่แพงที่สุดเท่าที่เงินซื้อได้”
ถ้าลดมาตรฐานลงพอ อะไรก็เรียลไทม์ได้ทั้งนั้น
สำหรับงานอย่าง virtual production มันอาจมีประโยชน์ แต่คงยังไม่ใช่สำหรับมือถือ
https://www.techpowerup.com/forums/attachments/all-cards-png...
ถ้าคุณอยากได้อะไรที่รันได้บนโน้ตบุ๊กอายุ 10 ปี หรือแม้แต่ไม่มี GPU ก็ยังรันได้ ลองดู https://github.com/pierotofy/OpenSplat ได้เลย ผมเป็นคนทำเอง
ดังนั้นมันเลยยังดูไม่ใช่ปัญหาที่ข้ามไม่ได้
มีใครช่วยอธิบายให้เชื่อได้ไหมว่า 3D Gaussian splatting ไม่ใช่ ทางตัน
การเรนเดอร์ช้าเกินไปในระดับเลขหลักเดียว และข้อมูลก็ใหญ่เกินไปในระดับเลขหลักเดียวเหมือนกัน ให้ความรู้สึกเหมือนกำลังกลับไปดูความขัดแย้งระหว่าง rasterization กับ ray tracing อีกครั้ง
rasterization จะเร็วกว่า ray tracing เสมอ และถ้า ray tracing เร็วขึ้น 10 เท่า rasterization ก็จะเร็วขึ้น 10 เท่าเช่นกัน
การสร้าง geometry และ material แบบดั้งเดิมจาก Gaussian point cloud อาจน่าสนใจได้ แต่ photogrammetry ก็มีมานานพอสมควรแล้ว
การพยายามเรนเดอร์เมืองขนาดใหญ่แบบ splat แบบเรียลไทม์ไม่ได้ให้ความรู้สึกว่าเป็น “ทิศทางที่ถูกต้อง”
มันดูเท่ สนุก และน่าสนใจ แต่ไม่แน่ใจว่าจะมีประโยชน์จริงไหม ถามจริงจังเพราะไม่ใช่ผู้เชี่ยวชาญ
งานวิจัยส่วนใหญ่ตอนนี้ยังไม่ได้โฟกัสเรื่องประสิทธิภาพ และแม้แต่ข้อตกลงเรื่อง ฟอร์แมตรวมศูนย์ ที่รวมการบีบอัดก็ยังไม่มีเลย
ศักยภาพในการปรับแต่งให้ดีขึ้นนั้นชัดเจนมาก และก็ปรับให้เหมาะกับอุปกรณ์หลายแบบได้ง่าย คล้ายกับ point cloud LOD หรือ mesh culling
ประสิทธิภาพของ splat อาจเป็นความได้เปรียบชั่วคราวของ viewer แต่เหมือนกับการถอดรหัสวิดีโอหรือมาตรฐาน 3D อื่น ๆ ที่แพร่หลายเป็นโอเพนซอร์ส ภายในไม่กี่ปีความสามารถในการดู splat คุณภาพสูงเฟรมสูงบนอุปกรณ์ส่วนใหญ่อาจกลายเป็นคุณสมบัติพื้นฐาน
คำถามถัดไปก็คือจะเอาสิ่งนี้ไปใช้ที่ไหน
ในเบราว์เซอร์เกิน 100fps: https://current-exhibition.com/laboratorio31/
900fps: https://m-niemeyer.github.io/radsplat/
เอนจินแบบดั้งเดิมมีงานวิจัยและพัฒนาสะสมมา 30 ปีแล้ว ดังนั้นคงต้องใช้เวลาที่เครื่องมือและการปรับแต่งจะตามทัน
แต่ถ้าดูว่าบทความวิจัยออกมาจากไหน ก็จะเห็น Apple กับ Meta เยอะมาก และมันดูเหมือนเป็นเทคโนโลยีที่จะขับเคลื่อนยุค metaverse/spatial computing ที่สองบริษัทนี้กำลังผลักดัน
ความสามารถในการย้ายคอนเทนต์ต้นทุนการผลิตต่ำมากอย่างวิดีโอจาก iPhone ไปสู่สภาพแวดล้อม 3D จะเข้ามาแทนที่งานวิจัยและพัฒนาแบบดั้งเดิมจำนวนมาก
และยังจับ รายละเอียดระดับละเอียดมาก อย่างโครงสร้างบาง ๆ หรือเส้นผมได้ยากมากด้วย 3DGS แข็งแกร่งในจุดนั้น
ตอนนี้ก็มีงานวิจัยเพื่อปรับปรุงจุดอ่อนในปัจจุบันอยู่ รวมถึงวิธีแยก mesh ที่สามารถนำไปใช้ใน graphics pipeline แบบดั้งเดิมได้
photogrammetry ทำงานได้ดีเฉพาะตอนที่ข้อมูลพื้นผิวสะอาด แต่ Gaussian splat แข็งแกร่งกับข้อมูลกึ่งปริมาตร เช่น ขน พืชพรรณ อนุภาค และพื้นผิวหยาบ
ยังเหมาะกับวัสดุที่เงา/สะท้อนแสง ปริมาตรที่มีคุณสมบัติพื้นผิวแบบแบ่งย่อยเด่นชัด และวัสดุที่ขึ้นกับมุมมองอย่างมากด้วย
ถ้าเป็นงานประเภทภาพถ่าย 3D แบบสมบูรณ์ มันก็ค่อนข้างเจ๋งและเป็นกรณีใช้งานที่สมเหตุสมผลมากพอ
แต่ถ้าเป็นสำหรับเอนจินเกม 3D ผมคิดว่ามันยากที่จะจัดการ primitive พื้นฐานแบบไดนามิกในแบบที่เอนจินเกมต้องการ คงยังมีการลองกันต่อไป แต่จากมุมนี้ Gaussian ดูใกล้เคียง ฟอร์แมตเรนเดอร์ขั้นสุดท้าย มากกว่าจะเป็นตัวแทนกลางที่มีประโยชน์
ถ้าจะให้ใช้ได้จริงในเอนจิน ก็ต้องมีอะไรบางอย่างถูกคิดค้นขึ้นมาเพื่อเชื่อมช่องว่างนั้น และตอนนี้ยังมีคำถามอีกมาก
ไม่รู้ว่ายังใช้กับอะไรได้อีก แต่โลกไม่ได้มีแค่เกม 3D และงานวิชวลเอฟเฟกต์เท่านั้น
มีของหลายอย่างมากที่ใช้ชื่อ Gauss และพอเห็นชื่อใหม่อย่าง Gaussian splatting โผล่มาเรื่อย ๆ ก็ยิ่งรู้สึกสนุกดีว่า Gauss ส่งอิทธิพลไว้ในหลายสาขาแค่ไหน
แม้จะไม่ได้เป็นคนคิดค้นโดยตรง แต่ก็ถือว่ามีส่วนสำคัญกับคณิตศาสตร์นั้นมาก
https://en.wikipedia.org/wiki/Monte_Carlo_(disambiguation)
แค่หัวข้อ “Science and Technology” อย่างเดียวก็มี 8 รายการแล้ว
อยากรู้ว่าจะปล่อยออกมาภายใต้ ไลเซนส์ แบบไหน
อยากเห็นเกมโอเพนซอร์สที่ใช้สิ่งนี้
ในประวัติศาสตร์มีหลายกรณีที่ดูเหมือนจะเป็นตัวเลือกทดแทน triangle mesh ที่มีอนาคต แต่สุดท้ายก็หายไปเพราะพบว่าไม่มีวิธีทำแอนิเมชันอย่างมีประสิทธิภาพ
วัตถุใน point cloud ไม่มีเมทาดาทาภายในตัวอย่าง “เก้าอี้ โต๊ะ คน” เลย ทำให้การโต้ตอบทุกอย่างยากมาก
ไม่ใช่ว่าจะเป็นไปไม่ได้ แต่ตอนนี้ยังไม่ใช่สิ่งที่ใช้งานได้จริง
แถมก็ไม่ได้ถูกปรับให้เหมาะกับการเรนเดอร์แบบเรียลไทม์มากนักด้วย ถึงจะตัดจุดออกไปเยอะแล้ว การใช้ mesh ความละเอียดต่ำก็ยังมีประสิทธิภาพกว่ามาก
มันดูไม่ได้ดีกว่าอะไรอย่าง Cities: Skylines มากนัก
ไม่มีทั้งการซูมเข้าและซูมออก และแสดงเฟรมที่จำกัดมากตลอดเวลา หรือว่าผมกำลังพลาดอะไรบางอย่าง?
ตัวงานวิจัยอ้างถึง MatrixCity ซ้ำ ๆ และ https://city-super.github.io/matrixcity/ ที่อีกคนหามาให้ด้านบนก็ระบุชัดว่าเป็น ข้อมูลสังเคราะห์ทั้งหมด
เท่าที่ผมเข้าใจ มันถูกดึงออกมาจาก Unreal Engine
กำลังเรียนด้วย pygame อยู่ เลยสงสัยว่าจะใส่ motion blur ในเกมอย่างไร
ตัวอย่างเช่น ถ้าสร้าง Mario ด้วย pygame ตอนที่ Mario กระโดดก็อยากให้ดูเบลอนิด ๆ
จะทำ Mario เวอร์ชันเบลอด้วยการเฉลี่ย 9 พิกเซลก็ได้ แต่ไม่แน่ใจว่าเกมอื่น ๆ ปกติก็ทำแบบนั้นหรือเปล่า
หลายเกมก็คมชัดมากโดยไม่มี motion blur เลย เลยสงสัยว่าในทางปฏิบัติใช้กันจริงไหม
มันเป็นองค์ประกอบที่ค่อนข้างสำคัญในภาพยนตร์ และยังทำให้นึกถึงเรื่องที่ว่าถ้าอยากได้ motion blur แบบภาพยนตร์ก็ต้องถ่ายที่ 25fps
กล่าวคือคำนวณความเร็วของวัตถุแต่ละชิ้นแล้วเรนเดอร์ออกมาเป็นสี จากนั้นใช้ในขั้นตอน post-processing เพื่อกำหนดความแรงและทิศทางของเอฟเฟกต์เบลอ
อาจต้องใช้การเคลื่อนที่ในมุมมองของกล้องด้วย สำหรับ Mario อาจไม่จำเป็น แต่ในเกม FPS เวลากล้องเคลื่อนไปข้างหน้า คุณก็น่าจะอยากให้ขอบหน้าจอดูเบลอ
แหล่งข้อมูลที่เกี่ยวข้อง: https://city-super.github.io/octree-gs/
นี่เป็นแนวทางที่ค่อนข้างล้ำในการเรนเดอร์ฉากขนาดใหญ่ขึ้นด้วย 3D Gaussians ถ้ามีโค้ดออกมาเมื่อไรอยากรีบทดลองเลย