
VFX Compositing và Cloud Rendering: Vì sao Comp Render là một khối lượng công việc khác 3D
Tổng quan
Giới thiệu
Phần lớn nội dung về cloud rendering được viết cho một loại khối lượng công việc duy nhất: một scene 3D đi qua path tracer, từng bucket một, cho tới khi nhiễu (noise) giảm hết và frame hoàn thành. Cách khung hình đó chính xác với một job Redshift hay V-Ray, nhưng gần như vô nghĩa với một comp render. Comp không sample các đường truyền ánh sáng (light path). Nó đang đánh giá một node graph dựa trên footage và các pass đã có sẵn, và yếu tố quyết định thời gian và chi phí gần như không bao giờ là số lượng sample GPU.
Sự khác biệt đó quan trọng hơn vẻ ngoài của nó, vì hai loại khối lượng công việc này thường xuyên bị gộp chung trong các lời khuyên "cloud rendering" chung chung. Một compositor lần đầu đưa một Nuke script hoặc một project After Effects lên farm, kỳ vọng hành vi GPU-bound giống 3D render, thường bối rối vì sao một comp không có simulation, không ray tracing mà vẫn chậm, hoặc vì sao nó nhanh theo cách chẳng liên quan gì đến tier GPU đã chọn. Bài viết này nói về khoảng cách đó: một comp render thực sự làm gì trên farm, nó khác 3D render ra sao về mặt cơ chế, và khi nào chuyển compositing lên cloud là đáng làm thay vì để workstation chạy qua đêm.
Chúng tôi làm việc với cả hai phía của pipeline này hằng ngày trên farm của mình tại Super Renders Farm, từ 3D render tạo ra beauty pass và AOV, đến compositing render lắp ghép chúng thành shot cuối. Hai bên dùng chung phần cứng nhưng gần như không có gì chung về hành vi render, và hiểu rõ khác biệt đó là điều biến một job comp render từ bí ẩn thành dự đoán được.

Sơ đồ pipeline minh họa luồng compositing EXR multi-pass: các pass render 3D hội tụ vào một file EXR multi-layer, sau đó chuyển sang phần mềm compositing và grade cuối cùng
Compositing Là Một Khối Lượng Công Việc Render Khác 3D Rendering
Một render engine 3D như V-Ray, Redshift, hay Arnold thực hiện light transport: nó bắn tia (trace ray), sample vật liệu, và tích lũy giảm nhiễu theo thời gian cho tới khi ảnh hội tụ. Đó là công việc thực sự nặng tính toán trên từng pixel, đó là lý do vì sao 3D rendering nặng CPU hoặc nặng GPU tùy engine, và vì sao tăng tốc GPU có tác động lớn tới thời gian render 3D.
Một compositing render không làm bất kỳ điều nào trong số đó. Nuke, After Effects, Fusion và các công cụ tương tự đánh giá một node graph: đọc một ảnh, áp một color correction, gộp hai layer, áp một transform, ghi kết quả. Không có sampling, không có hội tụ. Mỗi thao tác là một bước xử lý tuyến tính, xác định, chủ yếu là đại số tuyến tính trên dữ liệu pixel, và phần lớn các thao tác đó (merge, grade, keyer, transform, hầu hết filter) chạy trên CPU chứ không phải GPU. Một số ít loại node cụ thể (retime nặng, một vài phép denoise, một số công cụ machine-learning) được tăng tốc GPU, nhưng đó là ngoại lệ trong một comp thông thường, không phải quy tắc.
Yếu tố thực sự quyết định thời gian một comp render gần với một bài toán di chuyển dữ liệu (data movement) hơn là một bài toán tính toán:
- Thông lượng đọc (read throughput). Một comp script đọc footage và các render pass, thường là nhiều chuỗi multi-layer EXR cùng lúc, cho mỗi frame.
- CPU threading. Các thao tác compositing chạy song song trên các nhân CPU trong một frame, và render manager chạy song song giữa các frame bằng cách chia các đoạn của dải frame cho các worker khác nhau.
- Bộ nhớ (memory). Giữ nhiều frame độ phân giải đầy đủ, đa kênh (multi-channel) trong bộ nhớ cùng lúc (một beauty pass, vài AOV, một cryptomatte matte, có thể một deep pass) tốn bộ nhớ hơn nhiều so với vẻ ngoài, và hết RAM giữa chừng một frame là nguyên nhân phổ biến hơn khiến comp render thất bại so với tốc độ CPU thuần túy.
- Thông lượng ghi (write throughput). Frame composite cuối cùng, hoặc một precomp trung gian, phải được ghi lại, và với deliverable pipeline VFX, output đó thường là một chuỗi EXR khác chứ không phải một file video đơn.
Điều đó không phải là chỉ trích phần mềm compositing. Đây là một loại khối lượng công việc khác, xây dựng quanh việc di chuyển và kết hợp dữ liệu ảnh sẵn có thay vì tạo ra nó từ đầu, và một render farm xử lý một job comp như một 3D render, cấp nhiều năng lực GPU nhưng tiết kiệm RAM và thông lượng lưu trữ, sẽ hoạt động kém hiệu quả chính trên những máy đáng lẽ nên xử lý job đó tốt.
Một Comp Render Thực Sự Đọc Và Ghi Gì
Hình dạng input và output của một job compositing là nơi khác biệt so với 3D rendering thể hiện rõ nhất.
Multi-layer, multi-pass EXR đầu vào. Một comp thường mở một hoặc nhiều file OpenEXR mỗi frame vốn đã mang nhiều kênh: một beauty render, các pass diffuse và specular riêng, các lighting AOV, một Z-depth pass, motion vector, và các cryptomatte matte để tách riêng object, material, và asset ID, tất cả trong một file được đọc qua một Read node và tách ra bằng các Shuffle node để xử lý theo từng pass. Đọc file đó không phải là một lần truy cập file nhỏ; đó là kéo mọi kênh mà frame mang theo, ngay cả khi một comp cụ thể chỉ chạm vào vài kênh trong số đó, đây là lý do vì sao băng thông đọc lưu trữ là một nghẽn cổ chai thực sự trên các node farm nặng comp theo cách hiếm khi xảy ra với một 3D render đang ghi, chứ không phải đọc, phần lớn dữ liệu EXR của nó.
Cryptomatte là đầu vào, không phải đầu ra. Dữ liệu cryptomatte (các matte ID được tạo tự động cho phép compositor tách riêng từng object, material, hoặc asset instance sau đó, mà không cần render lại) được ghi bởi 3D render và được comp tiêu thụ. Điều đó nghĩa là một job compositing trên farm kế thừa bất kỳ kênh cryptomatte nào mà 3D render phía trước tạo ra, và một comp dựa vào việc tách cryptomatte đang đọc nhiều kênh hơn mỗi frame so với một comp không dùng. Bài viết hướng dẫn EXR-IO và cryptomatte của chúng tôi nói rõ dữ liệu đó được cấu trúc thế nào và cách làm việc với nó hiệu quả, đáng đọc trước khi gửi một comp nặng cryptomatte lên bất kỳ farm nào.
Một số lượng nhỏ output, ở bit depth cao. Trong khi một 3D render thường ghi nhiều pass mỗi frame, một comp render thường gộp các pass đó lại thành một, hoặc một số ít, output composite cuối cùng, thường là EXR 16-bit half-float cho các deliverable HDR linear đi tiếp xuống pipeline VFX, đôi khi 32-bit cho các data pass cần độ chính xác đầy đủ. Việc ghi nhỏ hơn về số kênh so với việc đọc, nhưng vẫn là một frame độ phân giải đầy đủ, và với một job deep-compositing (giữ nhiều depth sample trên mỗi pixel để giải quyết holdout mà không cần render lại scene 3D) cả đọc lẫn ghi đều nặng hơn đáng kể.
Encode video là một bước riêng, không phải bản thân render. Khi deliverable cuối cùng là H.264 hoặc HEVC thay vì một chuỗi ảnh, việc encode đó nói chung diễn ra như một pass riêng biệt sau comp render theo từng frame, không phải là một phần của nó, vì codec video không thể chia nhỏ gọn gàng giữa các worker theo cách một chuỗi ảnh độc lập có thể. Bài viết hướng dẫn encode H.264 vs H.265 của chúng tôi nói sâu hơn về sự đánh đổi ở bước cuối cùng đó.

Sáu pass render (beauty, diffuse, specular, cryptomatte, depth, ambient occlusion) hội tụ vào một file EXR multi-layer duy nhất
Comp Render Phân Phối Trên Cloud Farm Như Thế Nào
Mô hình phân phối cho công việc compositing gần với Nuke hơn là với một render engine 3D, và đáng để nói rõ vì sao.
Một render engine 3D có thể chia một frame theo không gian: bucket hoặc tile được giao cho các thread hoặc máy khác nhau, vì pixel ở một vùng thực sự không phụ thuộc vào pixel ở vùng khác. Một comp nói chung không thể chia theo cách đó. Giá trị của một pixel ở frame N phụ thuộc vào input của frame đó chạy qua toàn bộ node tree, điều này khiến phần lớn công việc compositing "song song hoàn hảo" theo frame, không phải theo vùng ảnh. Một render manager không chia nhỏ một comp frame; nó chia nhỏ dải frame, giao các đoạn frame cho các worker khác nhau, mỗi worker chạy một instance riêng của ứng dụng compositing ở chế độ headless (không giao diện) cho phần của mình.
Đó là mô hình mà bài hướng dẫn Nuke cloud render farm của chúng tôi trình bày chi tiết cho riêng Nuke, bao gồm các cờ dòng lệnh chính xác và cơ chế cấp phép (licensing). After Effects hoạt động tương tự với phần lớn comp production (title sequence, motion graphics, archviz reveal) nhưng có một lưu ý đáng nêu ở đây: các composition AE phụ thuộc vào trạng thái thời gian (temporal state) giữa các frame (motion blur với cross-frame sampling, particle simulation tích lũy, một số thao tác tracking) không song song hoàn toàn theo frame, và chia chúng một cách ngây thơ giữa các worker có thể tạo ra đường nối (seam) nhìn thấy được tại ranh giới đoạn. Bài hướng dẫn thiết lập cloud rendering cho After Effects của chúng tôi nói rõ workflow AE nào song song sạch và workflow nào cần render bằng một worker duy nhất.
Hình dạng thực tế của một job comp render trên farm trông như thế này: script hoặc project, cùng mọi thứ nó tham chiếu, được đưa lên như một gói tự chứa (self-contained bundle); render manager chia tổng dải frame thành các đoạn; mỗi worker lấy đoạn của mình, phân giải cùng các đường dẫn footage, color config, font, và các phụ thuộc plugin mà máy của artist đã có, và render ở chế độ headless; các frame hoàn thành được đưa vào shared hoặc cloud storage khi mỗi đoạn hoàn tất, nhờ đó một chuỗi dài có thể bắt đầu trả về output dùng được rất lâu trước khi worker cuối cùng xong.
Các Vấn Đề Thường Gặp Khi Compositing Trên Cloud
Đại đa số các comp render thất bại hoặc trả về sai trên farm không phải là vấn đề toán học compositing. Đó là các vấn đề về phụ thuộc (dependency) và môi trường mà một workstation cục bộ đã âm thầm che giấu.
| Vấn đề | Nguyên nhân | Cách khắc phục |
|---|---|---|
| Sai màu, render "thành công" nhưng trông lệch | Một OCIO/color config khác được phân giải trên farm so với config artist dùng cục bộ | Cố định project vào một color config đã triển khai; xác nhận môi trường render dùng đúng config đó, không phải một config mặc định |
| Thiếu footage hoặc khối placeholder | Đường dẫn tuyệt đối cục bộ (ổ đĩa Windows, network drive được map) không có ý nghĩa gì trên một worker từ xa | Gom mọi media được tham chiếu vào một gói tự chứa, có thể truy cập qua network trước khi gửi |
| Lỗi hết bộ nhớ giữa frame | Nhiều pass EXR độ phân giải đầy đủ, đa kênh và một cryptomatte matte được giữ trong bộ nhớ cùng lúc | Cấp cho node comp-render dư địa RAM, không chỉ số nhân CPU; đây là nguyên nhân thất bại phổ biến hơn tính toán thuần túy |
| Đường nối nhìn thấy tại ranh giới đoạn | Một thao tác phụ thuộc thời gian (motion blur, particle sim, một số tracking) bị chia giữa các worker như thể nó độc lập theo frame | Xác định các comp phụ thuộc thời gian và định tuyến chúng sang render bằng một worker duy nhất thay vì chia dải frame |
| Thiếu plugin, gizmo, hoặc font | Một gizmo tùy chỉnh, plugin bên thứ ba, hoặc font được cài cục bộ nhưng không có trên render worker | Nướng (bake) các node/gizmo tùy chỉnh vào script khi có thể; xác nhận ma trận plugin và font với farm trước khi gửi |
| Chậm hơn dự kiến trên node GPU-tier | Comp bị chi phối bởi merge, grade, và transform, vốn là các thao tác CPU, không thuộc tập node được tăng tốc GPU | Cấp đúng năng lực CPU cho job; dành node GPU cho các comp thực sự dựa vào retime, denoise, hoặc node ML được tăng tốc GPU |
Không điều gì trong số này là riêng của một ứng dụng cụ thể. Đây là hình dạng chung của những gì hỏng khi một script compositing rời khỏi máy nó được tạo ra, và đó là lý do vì sao "kiểm thử nhỏ trước khi giao toàn bộ dải frame" (render một số ít frame trước, so sánh với kết quả cục bộ) là một bước bảo hiểm chi phí thấp đáng làm với bất kỳ comp render nào, trên bất kỳ farm nào.
Khi Nào Cloud Rendering Thực Sự Giúp Ích Pipeline Compositing
Không phải mọi comp đều cần farm. Một chuỗi ngắn render cục bộ trong vài phút thu được rất ít lợi ích từ chi phí upload và hàng đợi khi chuyển lên cloud. Cloud compositing chứng tỏ giá trị trong một số tình huống cụ thể:
Các đợt gấp theo deadline. Một deliverable cần trong vài giờ, không phải vài ngày, nơi số lượng frame và độ phức tạp sẽ chiếm workstation lâu hơn thời gian deadline cho phép. Phân phối một chuỗi 1.000 frame trên hàng chục worker biến một render qua đêm thành thứ có thể trả về trong một hoặc hai giờ, vì thông lượng mở rộng gần như tuyến tính theo số worker khả dụng.
Công việc batch qua đêm mà nếu không sẽ chặn một artist. Ngay cả không có áp lực deadline khắt khe, một comp chiếm máy riêng của artist trong vài giờ là thời gian artist đó không thể lặp lại (iterate), xem lại, hoặc làm shot tiếp theo. Gửi nó lên farm giải phóng workstation ngay lập tức thay vì chờ render cục bộ hoàn tất.
Các chuỗi lớn với dữ liệu mỗi frame nặng. Deep compositing, EXR đa kênh 4K trở lên, và các comp nặng cryptomatte chính là những khối lượng công việc nơi thời gian render mỗi frame tích lũy nhiều nhất, và nơi phân phối trên nhiều worker nặng CPU đem lại lợi ích lớn hơn so với một comp nhẹ, ít kênh.
Các pipeline kết hợp 3D và comp đã dùng farm. Nếu 3D render cho một shot đã chạy trên cloud farm, giữ giai đoạn compositing trên cùng hạ tầng tránh một chuyến quay lại máy cục bộ giữa hai giai đoạn, và giữ các pass (beauty, AOV, cryptomatte) gần nơi comp sẽ đọc chúng.
Nơi cloud compositing đem lại ít giá trị nhất: một số ít comp ngắn, đơn giản, không có áp lực deadline, nơi thời gian render cục bộ đã ngắn hơn nhiều so với thời gian chuẩn bị và upload một gói project tự chứa. Chi phí upload và audit phụ thuộc là có thật, và với một job nhỏ nó có thể vượt quá thời gian tiết kiệm được.
Chi Phí: Một Job Comp Render Thực Sự Tốn Bao Nhiêu
Vì compositing là khối lượng công việc bị chi phối bởi CPU và bộ nhớ đối với đại đa số node trong một comp thông thường, tỷ giá CPU là yếu tố thường quyết định chi phí, còn tỷ giá GPU chỉ áp dụng cho các node cụ thể (retime nặng, một vài phép denoise, công cụ machine-learning) thực sự dùng tăng tốc GPU.
Trên farm của chúng tôi, compute CPU tính phí theo GHz-hr, với mức phí cơ bản $0,004/GHz-hr (các tier ưu tiên chạy từ $0,004 đến $0,016/GHz-hr tùy độ ưu tiên hàng đợi), và compute GPU tính phí theo OctaneBench-hour (OBh) ở mức cơ bản $0,003/OBh, với card RTX 5090 (32 GB VRAM) chạy khoảng $5,2/card-hour ở mức sử dụng tối đa. Render credit không hết hạn, và không có mức thuê máy tối thiểu, nên một job comp được tính phí theo compute thực sự tiêu thụ chứ không phải theo một khối thời gian đã đặt trước.
Để làm rõ điều này bằng một ví dụ minh họa (không phải một con số benchmark, vì thời gian render thực tế mỗi frame biến động rất lớn theo độ phân giải, số kênh, và độ phức tạp node): một batch compositing tiêu thụ 5.000 GHz-hour compute CPU tổng hợp, một mức độ hợp lý cho một chuỗi 4K nhiều nghìn frame phân phối trên hàng chục worker qua đêm, tốn khoảng $20 tiền compute ở mức phí cơ bản trước bất kỳ hệ số nhân tier ưu tiên nào. Nếu một phần của job đó dựa vào các node được tăng tốc GPU, phần đó được tính phí riêng theo tỷ giá OBh chứ không phải tỷ giá GHz-hr. Cơ chế quan trọng khi lập ngân sách rất đơn giản dù các con số chính xác thay đổi tùy job: chi phí theo tổng compute đã tiêu thụ, không phải thời gian đồng hồ (wall-clock), nên phân phối một job trên nhiều worker hơn để hoàn thành nhanh hơn tự nó không thay đổi chi phí.
Comp Rendering vs 3D Rendering: So Sánh Song Song
| Danh mục | 3D Rendering | Compositing Rendering |
|---|---|---|
| Thao tác cốt lõi | Light transport: sampling, ray tracing, hội tụ nhiễu | Đánh giá node graph: đọc, kết hợp, transform, ghi |
| Nghẽn cổ chai chính | Compute GPU hoặc CPU (tùy engine) | CPU threading, dung lượng bộ nhớ, I/O lưu trữ |
| Đơn vị song song | Thường theo không gian (tile/bucket) cộng với frame | Gần như luôn theo frame, không theo vùng ảnh |
| Mức độ liên quan GPU | Trung tâm của render với các engine dùng GPU (Redshift, Octane) | Tùy chọn cho một tập node cụ thể; phần lớn thao tác chỉ dùng CPU |
| Input điển hình | Hình học scene, vật liệu, texture | Chuỗi EXR multi-layer, multi-pass (beauty, AOV, cryptomatte) |
| Output điển hình | Beauty pass cộng AOV, thường nhiều file mỗi frame | Một số ít output composite, thường một chuỗi EXR cuối cùng |
| Kiểu thất bại | Hội tụ/nhiễu, bộ nhớ trên scene phức tạp, tranh chấp license | Phụ thuộc đường dẫn/asset, lệch color-config, hết bộ nhớ khi đọc đa kênh |
Compositing Phù Hợp Ở Đâu Trong Một Pipeline Cloud Rendering Rộng Hơn
Compositing thường là giai đoạn cuối cùng trong một chuỗi bắt đầu từ 3D render, và xử lý hai giai đoạn với cùng giả định về phần cứng và nghẽn cổ chai là sai lầm phổ biến nhất chúng tôi thấy trong các ticket hỗ trợ từ những nhóm mới với cloud compositing. Nếu pipeline của bạn hoàn toàn thuộc phía 3D và bạn chưa nắm rõ mô hình dịch vụ rộng hơn, bài hướng dẫn cloud render farm là gì và bài hướng dẫn cloud rendering VFX và product-visualization của chúng tôi nói rõ điều đó. Đối với riêng giai đoạn compositing, hướng dẫn cloud rendering Nuke và hướng dẫn thiết lập cloud rendering After Effects nói rõ cơ chế riêng của từng ứng dụng (licensing, cờ submission, ma trận plugin) mà bài viết này cố tình giữ ở mức tổng quát. Về phía After Effects, trang After Effects cloud render farm của chúng tôi nói trực tiếp về workflow được hỗ trợ và giá.
Để tham khảo chính thức về định dạng file làm nền tảng cho phần lớn các pipeline VFX compositing, dự án OpenEXR ghi lại định dạng multi-channel, multi-part mà hầu hết comp render đọc và ghi, và đặc tả Cryptomatte ghi lại cách dữ liệu ID-matte được mã hóa vào các file đó.
FAQ
Q: Compositing rendering có giống 3D rendering trên cloud farm không? A: Không. Một 3D render thực hiện light transport, sampling và bắn tia cho tới khi ảnh hội tụ, và công việc đó thực sự nặng tính toán trên từng pixel. Một compositing render đánh giá một node graph trên dữ liệu ảnh đã có sẵn (footage, render pass) và bị chi phối bởi CPU threading, dung lượng bộ nhớ, và I/O lưu trữ chứ không phải sampling. Hai khối lượng công việc dùng chung phần cứng farm nhưng có nghẽn cổ chai và kiểu thất bại khác nhau.
Q: Vì sao compositing bị ràng buộc bởi I/O nhiều hơn 3D rendering? A: Một comp thường đọc một hoặc nhiều file EXR multi-layer, multi-pass mỗi frame, kéo mọi kênh mà file mang theo (beauty, AOV, cryptomatte matte, depth), và giữ nhiều frame độ phân giải đầy đủ đó trong bộ nhớ cùng lúc khi đánh giá node graph. Khối lượng đọc đó, kết hợp với việc ghi lại frame composite, khiến thông lượng lưu trữ và dung lượng RAM là yếu tố lớn hơn trong thời gian render comp so với tốc độ tính toán thuần túy đối với phần lớn node trong một comp thông thường.
Q: Một render farm compositing có cần node GPU không? A: Với hầu hết comp, không. Phần lớn thao tác compositing (merge, grade, keyer, transform, hầu hết filter) chạy trên CPU. Một tập node nhỏ hơn, cụ thể (retime nặng, một vài phép denoise, công cụ machine-learning) được tăng tốc GPU, và các comp dựa nhiều vào các node đó hưởng lợi từ năng lực GPU. Với một comp điển hình nặng merge-và-grade, số nhân CPU và RAM quan trọng hơn tier GPU.
Q: Cryptomatte là gì và vì sao nó quan trọng với cloud compositing? A: Cryptomatte là dữ liệu ID-matte được tạo tự động, được ghi bởi một 3D render, cho phép compositor tách riêng từng object, material, hoặc asset instance sau đó mà không cần render lại scene 3D. Với một job cloud compositing, dữ liệu cryptomatte là một input mà comp đọc, không phải thứ mà comp render tạo ra, và các comp nặng cryptomatte đọc nhiều kênh hơn mỗi frame, làm tăng tải I/O và bộ nhớ trên render node.
Q: Nuke và After Effects có thể cùng render trên một cloud farm không? A: Có, trên một farm hỗ trợ cả hai ứng dụng, dù mô hình phân phối hơi khác nhau. Comp Nuke gần như luôn song song theo frame theo thiết kế (mỗi frame tự chứa hoàn toàn). Comp After Effects song song theo frame trong hầu hết trường hợp production, nhưng các composition phụ thuộc vào trạng thái thời gian giữa các frame, như một số thiết lập motion blur hoặc particle-simulation, cần render bằng một worker duy nhất thay vì chia dải frame để tránh đường nối. Bài Nuke và After Effects của chúng tôi nói rõ cơ chế riêng của từng ứng dụng.
Q: Khi nào hợp lý để gửi một job compositing lên cloud farm thay vì render cục bộ? A: Cloud compositing đem lại giá trị lớn nhất ở các đợt gấp theo deadline, công việc batch qua đêm mà nếu không sẽ chiếm workstation của một artist, và các chuỗi lớn hoặc nặng dữ liệu mỗi frame (deep compositing, EXR đa kênh 4K trở lên, comp nặng cryptomatte). Nó đem lại giá trị ít nhất với một số ít comp ngắn, đơn giản, không có áp lực deadline, nơi thời gian render cục bộ đã ngắn hơn thời gian chuẩn bị một gói project tự chứa để upload.
Q: Compositing rendering được tính phí thế nào trên cloud farm? A: Trên farm của chúng tôi, compute CPU (yếu tố quyết định chi phí với phần lớn công việc compositing) tính phí theo GHz-hr ở mức cơ bản $0,004/GHz-hr, với các tier ưu tiên lên tới $0,016/GHz-hr. Các node được tăng tốc GPU tính phí riêng theo OctaneBench-hour ở mức cơ bản $0,003/OBh. Chi phí theo tổng compute đã tiêu thụ chứ không phải thời gian đồng hồ, nên phân phối một job trên nhiều worker hơn để hoàn thành nhanh hơn tự nó không thay đổi tổng chi phí.
Q: Một render farm compositing thường xử lý định dạng file nào? A: OpenEXR multi-layer, multi-part là chuẩn cho input và output pipeline VFX, mang beauty pass, AOV, cryptomatte matte, và dữ liệu depth ở 16-bit half-float (hoặc 32-bit cho data pass cần độ chính xác đầy đủ). Khi deliverable cuối cùng là một file video (H.264, HEVC, ProRes) thay vì một chuỗi ảnh, việc encode đó thường chạy như một pass riêng sau comp render theo từng frame, vì codec video nói chung không thể chia nhỏ giữa các worker theo cách một chuỗi ảnh độc lập có thể. Bài hướng dẫn H.264 vs H.265 của chúng tôi nói rõ bước encode cuối cùng đó.
About Thierry Marc
3D Rendering Expert with over 10 years of experience in the industry. Specialized in Maya, Arnold, and high-end technical workflows for film and advertising.


