Thần tượng: Từ một hình ảnh đến Gaussian Splat 3D
Idol của Speridlabs chuyển đổi các hình ảnh đơn lẻ thành các Gaussian splat 3D có thể xoay, dự đoán các mặt chưa thấy và xuất các tệp PLY tiêu chuẩn với mật độ có thể điều chỉnh.
Điểm nổi bật và Kết quả
Idol, từ Speridlabs, biến một bức ảnh, bản kết xuất hoặc hình ảnh được tạo của một vật thể thành một Gaussian splat 3D có thể xoay. Nó dự đoán các mặt chưa thấy của vật thể và xuất ra tệp PLY 3DGS tiêu chuẩn chứa từ 32.768 đến 1.048.576 Gaussian. Điểm hấp dẫn thực tế của nó là SDK suy luận công khai với mật độ đầu ra và yêu cầu bộ nhớ GPU tiêu dùng có thể kiểm soát, thay vì bắt buộc phải thực hiện một phiên chụp đa góc. Trang nghiên cứu chính thức.
So sánh của các tác giả sử dụng một H100 cho mỗi mô hình. Ở 50 bước lấy mẫu và 262.144 Gaussian, Idol báo cáo 6,8 giây cho mỗi yêu cầu, SSIM của góc nhìn đầu vào là 0,726 và độ tương đồng DINOv2 của bảy góc nhìn mới là 0,781, so với các mức 0,716 và 0,754 của TRELLIS trong thiết lập 50 + 50 bước được liệt kê. LGM nhanh hơn với 1,1 giây, vì vậy Idol không dẫn đầu ở mọi chỉ số. Đây là các kết quả do tác giả báo cáo; phần so sánh được hiển thị không xác định bộ dữ liệu benchmark có tên hoặc số lượng mẫu cụ thể. Benchmark.
Một bảng thời gian riêng báo cáo 19,1 giây trên RTX 4090 ở cùng thiết lập 50 bước, 262.144 Gaussian, lấy trung vị trên tám hình ảnh. Thẻ mô hình báo cáo bộ nhớ đỉnh 7,2 GB. Do đó, tiêu đề “dưới hai giây” không nên được hiểu là thời gian chạy được đo của cấu hình 4090 tiêu chuẩn này. Thẻ mô hình và thiết lập phần cứng.

Cách thức hoạt động
Quy trình suy luận là chuẩn bị hình ảnh → mã hóa hình ảnh kép → lấy mẫu luồng vật thể và camera kết hợp → đặt neo octree → giải mã Gaussian → xuất PLY và camera. BiRefNet loại bỏ nền, và vật thể được đặt khung ở 1024 × 1024 pixel. Chế độ ảnh chụp và tổng hợp sử dụng các lề cắt khác nhau, lần lượt là 1,7 và 1,2. Quy trình.
DINOv3 cung cấp các token đặc trưng hình ảnh, trong khi VAE FLUX.2 cung cấp thông tin hình ảnh đã nén. Sau khi được chiếu vào chiều làm việc của transformer, các embedding của chúng được cộng lại để tạo thành điều kiện hình ảnh. Quá trình tạo bắt đầu từ hai tensor ngẫu nhiên: một latent vật thể gồm 8.192 token với 16 kênh và một token camera năm kênh. Các luồng được tinh chỉnh riêng trước khi cơ chế chú ý kết hợp xử lý đồng thời các token latent, hình ảnh và camera. Mô hình dự đoán vận tốc cho cả vật thể và camera, khiến góc nhìn trở thành một phần của quá trình tạo thay vì một đầu vào được giả định độc lập. Triển khai Transformer.
Bộ lấy mẫu tích hợp rectified flow từ nhiễu tại t = 1 đến dữ liệu tại t = 0 bằng các bước Euler. Mặc định là 50 bước, tham số hướng dẫn w = 3 và độ dịch thời gian 3. Phương trình hướng dẫn thực tế là v = (1 + w)v_cond − wv_uncond; lưới thời gian đã dịch phân bổ nhiều bước hơn ở vùng nhiễu cao. Các phép toán này thay đổi latent nhỏ gọn và trạng thái camera, chứ không phải hàng triệu Gaussian tường minh ở mỗi lần lặp. Bộ lấy mẫu flow.
Giải mã mở rộng kết quả nhỏ gọn đó theo không gian. Bộ giải mã octree lấy điều kiện từ latent vật thể và phân bổ số lượng neo được yêu cầu vào tám ô con ở mỗi cấp. Bộ giải mã Gaussian đọc cùng latent thông qua cơ chế chú ý chéo và phát ra 32 Gaussian cho mỗi neo, dự đoán độ lệch vị trí, màu sắc, tỷ lệ, phép quay và độ mờ. Do đó, 262.144 Gaussian cần 8.192 neo. Mật độ đầu ra được kiểm soát trong quá trình giải mã; nó không phải là số lượng token latent hay cấp độ phân chia lưới. Các bộ giải mã.
Bộ khử nhiễu chứa 370,6M tham số và hai bộ giải mã chứa khoảng 288,1M, tổng cộng khoảng 0,66B cho các thành phần cốt lõi đó. Tính cả các bộ mã hóa hình ảnh và việc loại bỏ nền, toàn bộ yêu cầu có khoảng 1,80B tham số. SDK trả về splat, hình ảnh đầu vào đã xử lý và các tham số camera được dự đoán. Các tối ưu hóa GPU biên dịch bộ khử nhiễu và gom các lượt chạy có điều kiện/không điều kiện theo batch, với chi phí khởi động bổ sung trong lần tạo đầu tiên. Tính toán thành phần và thời gian chạy.
Ứng dụng, Khả năng cung cấp và Định hướng tương lai
Đầu ra phù hợp với bản xem trước vật thể dựa trên splat, bản trình bày tương tác và các thử nghiệm tạo 3D từ hình ảnh. PLY Gaussian không phải là lưới đa giác kín nước, khối rắn CAD hay nhân vật được gắn rig tự động. Các bề mặt bị che khuất được suy luận thay vì đo đạc. SDK và các trọng số được công bố theo giấy phép Apache-2.0, trong khi các thành phần bộ mã hóa DINOv3 và FLUX.2 bắt buộc cần quyền truy cập có kiểm soát riêng và các điều khoản áp dụng tương ứng. Yêu cầu phát hành và truy cập.
Bài đánh giá này sử dụng trang nghiên cứu chính thức, thẻ mô hình và commit SDK 4702a7f, được kiểm tra vào ngày 6 tháng 11 năm 2026. Không tìm thấy bài báo kỹ thuật độc lập hoặc lộ trình công việc tương lai cụ thể cho Idol trong các tài liệu đó. Kho lưu trữ được kiểm tra cung cấp suy luận và bản demo, vì vậy nội bộ của nó không xác lập một công thức huấn luyện chưa được công bố. Không có phép suy luận mô hình hoặc benchmark nào được chạy lại cho bài viết này.
Câu hỏi thường gặp
PLY có thể được gửi trực tiếp đến máy in 3D không?
Không. Nó lưu trữ các primitive Gaussian để kết xuất, không phải một bề mặt kín có thể in. Việc tái tạo bề mặt và chuẩn bị để in sẽ là các quy trình riêng biệt nằm ngoài đầu ra được ghi chép trong tài liệu của SDK này.
Việc tăng số lượng Gaussian có đảm bảo mặt ẩn chính xác hơn không?
Không. Nó làm tăng mật độ giải mã. Phần không nhìn thấy vẫn đến từ mô hình sinh có điều kiện theo hình ảnh, vì vậy nhiều phần tử nguyên thủy hơn không cung cấp các phép đo còn thiếu.
Tôi nên mong đợi điều gì khi chạy cục bộ?
Thiết lập theo tài liệu sử dụng Python 3.10+, PyTorch 2.5+ và GPU NVIDIA CUDA, với quyền truy cập vào cả hai bộ mã hóa hình ảnh. So sánh thời gian ở các thiết lập lấy mẫu tương đương và tính đến thời gian tải xuống cũng như biên dịch trong lần chạy đầu tiên.




