Nuke Cloud Render Farm: Render Comp Quy Mô Lớn Năm 2026

Render comp Nuke trên cloud render farm

Compositing là công đoạn cuối cùng của một shot hiệu ứng hình ảnh. Đến khi một chuỗi cảnh đến tay Nuke, các render 3D đã hoàn thành, plate đã được grade, và artist đang ghép ảnh cuối cùng — merge, key, deep holdout, lens work, grain. Vấn đề là "ảnh cuối cùng" này hiếm khi xuất ra được với chi phí thấp. Một chuỗi 200 frame 4K với stack các input EXR đa kênh và một vài node tăng tốc GPU có thể giữ nguyên một máy trạm trong nhiều giờ, và artist không thể tiếp tục làm việc trong khi render đang chạy. Đó chính xác là loại công việc mà một cloud render farm tồn tại để xử lý.

Chúng tôi vận hành NukeX trên toàn bộ fleet render tại Super Renders Farm, và qua nhiều năm, chúng tôi đã quan sát thấy cùng một vài chi tiết quyết định liệu comp Nuke có render sạch trên farm hay bị kẹt giữa chừng. Hầu như không bao giờ là do bản thân các phép toán compositing. Đó là một gizmo thiếu, OCIO config không khớp, đường dẫn Windows tuyệt đối không có nghĩa gì trên worker Linux, hoặc hiểu lầm về phiên bản Nuke nào có thể render ngoài máy. Hướng dẫn này đi qua cách render comp Nuke phân phối trên farm, bức tranh về phiên bản và cấp phép bạn cần hiểu trước khi submit, những trường hợp GPU acceleration thực sự có ích (và khi nào không), cùng cách đóng gói comp để không có gì bị thiếu. Tư duy vận hành tương tự áp dụng cho các workflow VFX và product-visualization rộng hơn, nhưng Nuke có những điểm đặc thù riêng, và đó là những gì chúng tôi sẽ tập trung ở đây.

Tại sao comp Nuke song song theo frame, không phải theo tile

Để hiểu Nuke phân phối trên farm như thế nào, sẽ hữu ích khi so sánh với renderer 3D. Một path tracer như V-Ray hoặc Arnold có thể chia một frame đơn thành các bucket hoặc tile và giao mỗi vùng cho một luồng khác nhau — hoặc với distributed rendering, một máy khác. Các pixel ở góc trên bên trái không phụ thuộc vào pixel ở góc dưới bên phải, vì vậy frame có thể được phân chia theo không gian.

Comp 2D hoạt động khác. Giá trị của bất kỳ pixel nào tại frame N chỉ phụ thuộc vào các input của frame đó chạy qua node tree. Mỗi frame hoàn toàn độc lập, khiến comp Nuke song song một cách tự nhiên theo frame: bạn có thể render frame 1 trên một máy và frame 200 trên máy khác mà không cần phối hợp giữa chúng. Điều Nuke không làm là chia một frame thành các tile không gian để farm ra các máy riêng biệt — một Write node render một frame hoàn chỉnh trong một process duy nhất. Trong một máy, Nuke song song hóa qua các CPU thread và sử dụng engine scanline/region, nhưng trên các máy khác nhau, đơn vị phân phối là frame.

Một thực tế đó định hình tất cả mọi thứ về farm rendering cho Nuke. Render manager không chia nhỏ hình ảnh; nó chia nhỏ frame range. Chuỗi 1.000 frame trở thành một tập các "chunk" frame range nhỏ hơn, mỗi chunk được giao cho một worker, và mỗi worker khởi chạy render Nuke headless riêng cho phần của nó. Sơ đồ bên dưới thể hiện hình dạng của nó.

Vì các frame độc lập, throughput tăng gần tuyến tính với số worker bạn có thể đưa vào công việc — đây chính là lý do tại sao render một chuỗi comp dài trên đám mây đáng làm.

Headless render: Nuke chạy như thế nào trên worker

Trên farm không có GUI. Mỗi worker chạy Nuke ở chế độ terminal (batch), render tất cả các Write node đang hoạt động cho một frame range nhất định rồi thoát. Lệnh cơ bản trông như thế này:

nuke -x -F 1-50 comp.nk

-x đặt Nuke vào execute mode. -F thiết lập frame range, và nó chấp nhận frame đơn (-F 7), range có giới hạn (-F 1-50), và range có bước nhảy (-F 1-100x2 render mỗi frame thứ hai). Bạn có thể truyền nhiều đối số -F trong một lệnh cho các range không liên tục. Thêm một vài flag quan trọng khi bạn chuyển từ comp đơn sang chuỗi sản xuất:

Flag	Chức năng	Tại sao quan trọng trên farm
-x	Execute (render) tất cả Write node đang hoạt động	Switch batch-render tiêu chuẩn
-F a-bxc	Frame range với bước nhảy tùy chọn	Render manager điền vào cho mỗi chunk
-X node	Chỉ render Write node được đặt tên	Render một output khi comp có nhiều Write
--sro	Tuân theo thứ tự render của Write node	Cần khi Read downstream phụ thuộc vào output của Write trước đó
--cont	Tiếp tục sau lỗi frame	Một frame bị lỗi không hủy cả chunk
-m N	Đặt số luồng render	Điều chỉnh concurrency per-worker theo số core của máy

Một render khởi động theo cách này sẽ yêu cầu render license theo mặc định thay vì interactive seat — thêm về điều đó trong phần tiếp theo. Nuke cũng trả về các exit code hữu ích mà render manager đọc để đánh dấu task thành công, thất bại, hoặc cần retry: 0 là thành công, 1 là lỗi render, và 100 báo hiệu lỗi cấp phép. Trên farm được quản lý, bạn hiếm khi tự gõ các lệnh này; công cụ submission sẽ xây dựng chúng. Nhưng biết những gì chạy phía sau giải thích hầu hết các hành vi bạn sẽ thấy trong render log.

Còn một cơ chế phân phối nữa đáng nhắc đến để không bị nhầm lẫn với farm rendering: Frame Server nội bộ của Nuke. Frame Server khởi chạy nhiều tiến trình render nền để tăng tốc một render đơn — hữu ích trên một máy trạm bận hoặc một nhóm nhỏ máy hỗ trợ. Đây là công cụ khác với phân phối frame range theo quy mô farm, thứ bạn cần khi toàn bộ chuỗi cần trả về qua đêm thay vì sau một cuối tuần dài.

Các phiên bản Nuke và cấp phép cho farm rendering

Đây là phần mà nhiều người vấp ngã nhất, vì "Nuke" là một dòng sản phẩm, không phải sản phẩm đơn lẻ, và các phiên bản không hoạt động theo cùng một cách trên farm.

Phiên bản	Mô tả	Có thể render trên farm không?
Nuke (Commercial)	Compositor node-based cơ bản	Có — với render license
NukeX	Nuke cộng thêm các node nâng cao (CameraTracker, denoise, deblur, lens distortion, PointCloudGenerator, ParticleSystem)	Có — với render license
Nuke Studio	Bộ công cụ NukeX cộng thêm timeline editorial/conform	Có — với render license
Nuke Indie	Phiên bản chi phí thấp cho solo artist	Không — farm render bên ngoài và cloud không được hỗ trợ
Nuke Assist	Tập hợp node hạn chế cho paint, roto và tracking	Không — đây là interactive assist seat, không phải render license

Bảng đó mô tả dòng Nuke nói chung theo yêu cầu của bất kỳ render farm nào — không riêng fleet của chúng tôi; trên farm của chúng tôi, ứng dụng phía render là NukeX, như phần còn lại của hướng dẫn này mô tả. Có hai điều đáng rút ra từ bảng.

Thứ nhất, Nuke Indie không thể render trên farm. Phiên bản Indie của Foundry được xây dựng cho solo artist dưới mức doanh thu nhất định, và điều khoản của nó rõ ràng loại trừ farm render bên thứ ba bên ngoài, dịch vụ cloud rendering, và remote Frame Server rendering. Indie cũng lưu theo định dạng script được mã hóa riêng mà parser commercial không thể đọc. Vì vậy nếu bạn đang dùng Indie và thắc mắc tại sao farm submission không hoạt động, đó không phải vấn đề cấu hình — mà là giới hạn cấp phép. Farm rendering cần phiên bản Commercial Nuke, NukeX, hoặc Nuke Studio.

Thứ hai, trên farm bạn render bằng render license, không phải interactive seat. Render license là Nuke headless, không có GUI, tồn tại chuyên để render — khi bạn khởi chạy terminal render, Nuke yêu cầu một cái theo mặc định. Render license độc lập với các interactive seat mà artist của bạn sử dụng, đó là lý do tại sao một studio có thể đặt comp trên năm mươi máy mà không cần mua năm mươi Nuke interactive seat đầy đủ. Một chi tiết hữu ích cho các pipeline hỗn hợp: render license có thể render bất kỳ node nào được tạo trong phiên bản NukeX trở xuống, vì vậy render node được trang bị NukeX sẽ vui vẻ render script mà artist xây dựng trong Nuke cơ bản. NukeX là superset của Nuke — nó bổ sung thêm node, không loại bỏ khả năng đọc các node tiêu chuẩn. Giới hạn duy nhất thực sự là ngược lại: Nuke cơ bản không thể đánh giá các node chỉ có trong NukeX.

Về mô hình cấp phép, Foundry đã chuyển dòng Nuke sang đăng ký hàng năm vào đầu năm 2023, với cấp phép dựa trên đăng nhập có thể chạy online hoặc offline; tùy chọn vĩnh viễn và cho thuê cũng tồn tại. Cơ chế khác nhau tùy theo từng studio, đó là nội dung của phần tiếp theo.

Cấp phép hoạt động như thế nào trên farm của chúng tôi

Super Renders Farm không phải là đối tác của Foundry, và chúng tôi không tuyên bố như vậy — các đối tác nhà cung cấp đã được xác minh của chúng tôi là với các nhà sản xuất render engine, không phải với nhà cung cấp phần mềm compositing. Điều farm của chúng tôi vận hành là mô hình sử dụng render-only, cùng cách tiếp cận chúng tôi dùng cho các ứng dụng khác trên fleet không gắn với đối tác.

Trong thực tế, điều đó có nghĩa là bạn không tự cấp phép hoặc quản lý render license seat cho mỗi worker. Fleet worker chạy NukeX, được gim phiên bản vào một bản build được hỗ trợ, và compositor khởi chạy headless để render script của bạn. Vì SuperRenders là farm quản lý toàn diện, bạn không remote-desktop vào máy, cài đặt Nuke, hoặc cấu hình license server thủ công — môi trường phía render đã có sẵn khi job của bạn đến. Đó là sự khác biệt vận hành giữa farm được quản lý và thiết lập IaaS tự làm, nơi việc đưa Nuke và cấp phép của nó vào hoạt động là vấn đề của bạn cần giải quyết trên mỗi instance.

Về chi phí, render comp được tính phí theo cách tương tự như phần còn lại của công việc CPU của chúng tôi — theo GHz-giờ tính toán đã sử dụng, không có mức tối thiểu thuê máy và render credit không hết hạn. Tài khoản mới bắt đầu với credit $25, đủ để render một chuỗi test ngắn đầu đến cuối và xác nhận comp của bạn hoạt động giống nhau trên farm như trên máy trạm của bạn trước khi cam kết job đầy đủ. Mức giá hiện tại và Cost Calculator có trên trang pricing.

Phân phối frame range trong thực tế

Biết rằng farm chia nhỏ frame range là một điều; nhưng để có được render sạch sẽ và có thể dự đoán là việc khác. Một vài thực hành xuất hiện lặp đi lặp lại trong bộ phận hỗ trợ của chúng tôi.

Kích thước chunk là sự đánh đổi. Chunk nhỏ (vài frame mỗi chunk) phân bổ công việc trên nhiều máy hơn và phục hồi nhanh hơn khi task thất bại, nhưng phải trả chi phí khởi động của Nuke — tải script, checkout license, khởi tạo plugin — thường xuyên hơn. Chunk lớn phân bổ thời gian khởi động nhưng để lại straggler khi một máy chậm giữ phần đuôi của chuỗi. Đối với hầu hết comp, một chunk vừa phải giữ mỗi worker bận trong vài phút là mặc định hợp lý; comp rất nặng per-frame (deep, 4K+, nhiều node GPU) nghiêng về chunk nhỏ hơn.

Chú ý đến phụ thuộc Write node. Nếu script của bạn có Read downstream phụ thuộc vào file mà Write trước đó tạo ra — ví dụ precomp được bake ra đĩa — những Write đó phải thực thi theo thứ tự. Đó là lý do tồn tại của --sro. Không có nó, worker có thể thử Write phụ thuộc trước khi input của nó tồn tại, và bạn nhận được lỗi frame thiếu ngẫu nhiên vì chúng phụ thuộc vào timing của máy.

Lên kế hoạch cho frame xấu không tránh khỏi. Một input không đọc được hay hiccup lưu trữ thoáng qua không nên giết cả một chunk. --cont cho phép render tiếp tục qua frame thất bại để bạn có thể re-queue chỉ những khoảng trống sau đó thay vì render lại tất cả. Kết hợp với tính năng tự động retry task của render manager giúp các chuỗi dài tiếp tục chạy mà không cần giám sát.

Kết quả khi làm đúng là đơn giản: một chuỗi sẽ chiếm máy của artist cả ngày trả về trong thời gian chunk đơn chậm nhất hoàn thành, vì mọi chunk khác render cùng lúc với nó.

GPU vs CPU cho Nuke trên farm

Đây là điểm khiến nhiều người ngạc nhiên khi đến từ 3D rendering ưu tiên GPU: Nuke về cơ bản là ứng dụng CPU. Tuyệt đại đa số các hoạt động compositing — merge, color correction, transform, key, hầu hết các bộ lọc — chạy trên CPU. GPU acceleration trong Nuke là tùy chọn trên một tập hợp con cụ thể của các node, được hiển thị qua điều khiển "use GPU if available"; các node không có điều khiển đó chỉ chạy trên CPU.

Workload	Nơi chạy	Ví dụ
Compositing tổng quát	CPU	Merge, Grade, ColorCorrect, Transform, Keyer, hầu hết bộ lọc
Node tăng tốc GPU	GPU (tùy chọn, có CPU fallback)	Kronos và MotionBlur retimes, Denoise, VectorGenerator, Convolve, ZDefocus
BlinkScript / machine learning	GPU	BlinkScript kernels, CopyCat training (cần NVIDIA GPU)

Điều này có nghĩa là về phần cứng: comp chủ yếu là grade, merge và transform thấy ít lợi ích từ GPU — nó cần CPU core và bộ nhớ. Comp nghiêng về Kronos retime nặng, ZDefocus lớn, Denoise, hoặc công việc BlinkScript tùy chỉnh có thể tăng tốc đáng kể với GPU. Hầu hết comp sản xuất nằm ở đâu đó giữa, đó là lý do tại sao chúng tôi dẫn đầu với CPU capacity và xem GPU như accelerator cho các node thực sự sử dụng nó.

Fleet của chúng tôi phản ánh điều đó. Phần lớn công việc compositing chạy trên máy CPU được xây dựng trên bộ vi xử lý Intel Xeon E5-2699 V4 kép với 96–256 GB RAM mỗi máy — cộng lại hơn 20.000 CPU core — và headroom bộ nhớ đó là phần mà mọi người thường đánh giá thấp. Deep compositing và multi-channel EXR plate độ phân giải cao rất ngốn bộ nhớ; một frame deep duy nhất ở 4K có thể chứa nhiều mẫu mỗi pixel, và hết RAM giữa frame là nguyên nhân phổ biến hơn nhiều gây ra lỗi farm render so với tốc độ CPU thuần túy. Đối với các comp thực sự được hưởng lợi từ các node GPU, chúng tôi cũng vận hành một GPU cloud render farm chuyên dụng trên card NVIDIA RTX 5090 với 32 GB VRAM mỗi card. Nếu bạn muốn xem GPU tier đó hoạt động như thế nào với workload nặng hơn, benchmark RTX 5090 cloud rendering của chúng tôi trình bày chi tiết. Tuy nhiên, hướng dẫn trung thực dành riêng cho Nuke là hãy chọn đúng kích thước cho comp: đừng trả tiền cho thời gian GPU mà script nặng merge sẽ không bao giờ đụng đến.

Xử lý file và asset: phần thực sự hay bị lỗi

Nếu Nuke render thất bại trên farm, xác suất áp đảo là do vấn đề dependency, không phải vấn đề compositing. Comp script chủ yếu là một tập các tham chiếu — đến footage, gizmo, config màu — và mỗi tham chiếu đó phải resolve giống hệt nhau trên worker không phải máy của artist.

Dependency	Kiểu lỗi	Cần kiểm tra gì
Footage / Read node	Frame thiếu, "file not found"	Đường dẫn có thể truy cập qua mạng, không phụ thuộc OS — không phải ký tự ổ đĩa Z:\ local chỉ tồn tại trên PC của artist
Gizmo / OFX plugin	Script không tải được, node không biết	Được cài trên mọi render node, hoặc được nhóm/bake vào script trước khi submit
OCIO color config	Màu sắc sai, grade không khớp	Config giống nhau được triển khai và chọn trên farm như artist đã sử dụng
Font	Glyph bị thay thế hoặc sai trong Text node	Font được sử dụng có mặt trên render node
LUT / file .cube	Color transform thất bại	File LUT độc lập được tham chiếu bởi comp được gửi kèm
Phiên bản Nuke	Node không tương thích	Bản render khớp (hoặc mới hơn) bản mà artist sử dụng

Một vài trong số này xứng đáng xem xét kỹ hơn. Đường dẫn là vấn đề cổ điển: artist trên Windows tham chiếu Z:\project\plates\ sẽ tạo ra script không có nghĩa gì với worker Linux. Đường dẫn project nhất quán, có thể truy cập qua mạng — hoặc render manager viết lại đường dẫn trên đường đến farm — giải quyết vấn đề này. Gizmo và OFX tùy chỉnh phải tồn tại trên render node; thói quen an toàn nhất trước khi submit là chuyển đổi gizmo tùy chỉnh thành Group để chúng được bake vào script và không có dependency bên ngoài.

OCIO config drift là vấn đề tinh tế nhất và đáng chú ý, vì nó tạo ra render thành công nhưng trông sai. Quản lý màu của Nuke được điều khiển bởi config OpenColorIO; nếu farm resolve config khác với config artist đã sử dụng — đường dẫn file khác, config tùy chỉnh chưa được triển khai, hoặc biến môi trường trỏ đến nơi khác — các color transform phân kỳ và farm render sẽ không khớp với viewer mà artist đã approve. Cách khắc phục là kỷ luật: gim project vào một config cụ thể đã được triển khai và đảm bảo môi trường render sử dụng đúng config đó. Farm được quản lý giữ các OCIO config tiêu chuẩn, đi kèm của Nuke mặc định, nhưng OCIO config tùy chỉnh của studio vẫn phải đi cùng job.

Về phía output, comp Nuke thường đọc và ghi multi-channel EXR. Một file OpenEXR đơn có thể chứa nhiều kênh — beauty pass cộng với diffuse, specular, AOV ánh sáng, Z-depth pass và cryptomatte matte — tất cả đọc qua một Read node và tách ra bằng Shuffle node cho công việc per-pass trong comp. Đối với deep compositing, Nuke đọc và ghi deep EXR qua DeepRead và DeepWrite, lưu nhiều mẫu độ sâu mỗi pixel để giải quyết vấn đề holdout và cạnh mà không cần render lại 3D. Hầu hết dữ liệu này được lưu ở dạng 16-bit half-float, tiêu chuẩn cho plate linear HDR, với 32-bit full float dành cho data pass như world position hoặc motion vector cần độ chính xác đầy đủ. Không có gì xa lạ ở đây — nhưng mỗi kênh đó là thêm dữ liệu để di chuyển và thêm bộ nhớ để giữ, điều này quay lại lý do tại sao RAM và throughput lưu trữ quan trọng không kém số lượng core cho comp rendering.

Checklist trước khi submit cho comp Nuke

Trước khi gửi comp đến bất kỳ farm nào — của chúng tôi hay hàng đợi nội bộ của bạn — một lượt kiểm tra nhanh các điểm này ngăn ngừa đại đa số render thất bại:

• Đường dẫn: tất cả Read và Write node sử dụng đường dẫn có thể truy cập qua mạng, không phụ thuộc OS, không phải ký tự ổ đĩa local.
• Gizmo: gizmo tùy chỉnh được chuyển thành Group (baked vào) hoặc xác nhận đã cài trên render node.
• Màu sắc: OCIO config là config mà farm sẽ resolve; bất kỳ config tùy chỉnh nào đều đi cùng job.
• Font và LUT: mọi font được dùng bởi Text node và mọi file .cube/LUT được tham chiếu đều có mặt.
• Phiên bản: bản render khớp với bản comp được tạo.
• Phiên bản Nuke: script là từ Commercial Nuke, NukeX, hoặc Nuke Studio — không phải Indie, vốn không thể farm-render.
• Thứ tự render: nếu Read downstream phụ thuộc vào Write trước đó, render với --sro.
• Test nhỏ trước: render vài frame đầu tiên và so sánh với output local của artist trước khi cam kết toàn bộ range.

Điểm cuối cùng là bảo hiểm rẻ. Một test render năm frame phát hiện đường dẫn, màu sắc, hoặc lỗi phiên bản với chi phí vài phút — tốt hơn nhiều so với phát hiện ra nó sau 800 frame của job qua đêm.

Nơi Nuke rendering phù hợp trong pipeline rộng hơn

Output EXR frame cuối cùng là endpoint phổ biến nhất cho comp Nuke, nhưng không phải duy nhất. Nếu shot của bạn đang hướng đến real-time engine thay vì chuỗi được render phẳng — virtual production hoặc review trong engine — các câu hỏi tích hợp sẽ khác, và chúng tôi đề cập đến con đường đó riêng biệt trong hướng dẫn pipeline Nuke to Unreal Engine. Hãy giữ rõ sự phân biệt: bài viết này về render frame comp ở quy mô lớn trên farm, trong khi con đường Unreal là về chuyển công việc Nuke vào ngữ cảnh real-time. Nếu bạn vẫn đang tìm hiểu cách distributed rendering hoạt động nói chung, hướng dẫn render farm là gì của chúng tôi là điểm khởi đầu tốt.

Để tham khảo tài liệu chính thức về các cơ chế được mô tả ở đây, tài liệu của Foundry về hoạt động dòng lệnh và render farm và FAQ cấp phép dòng Nuke là nguồn chính thức, và các trang web dự án OpenEXR và OpenColorIO tài liệu hóa các tiêu chuẩn file và màu mà comp phụ thuộc vào.

FAQ

Q: Tôi có thể render Nuke trên cloud render farm với Nuke Indie license không? A: Không. Phiên bản Nuke Indie của Foundry rõ ràng không hỗ trợ farm render bên thứ ba bên ngoài, dịch vụ cloud rendering, hoặc remote Frame Server rendering, và nó lưu theo định dạng script mã hóa mà parser commercial không thể đọc. Farm rendering yêu cầu phiên bản Commercial Nuke, NukeX, hoặc Nuke Studio.

Q: Tôi có cần Nuke render license riêng để sử dụng cloud render farm không? A: Trên farm, các render chạy headless bằng render license thay vì interactive seat — đó là cách một studio có thể render trên nhiều máy mà không cần mua interactive seat đầy đủ cho mỗi máy. Trên farm của chúng tôi, bạn không tự cấp phép những cái này; fleet worker chạy NukeX theo mô hình sử dụng render-only, vì vậy cấp phép phía render được xử lý ở phía farm.

Q: Nuke render nhanh hơn trên GPU hay CPU? A: Đối với hầu hết comp, là CPU. Nuke về cơ bản là ứng dụng CPU; chỉ một tập hợp con cụ thể của các node — Kronos, Denoise, ZDefocus, Convolve, BlinkScript, và các công cụ machine learning như CopyCat — được tăng tốc GPU. Comp được xây dựng chủ yếu từ merge, grade và transform cần CPU core và RAM, trong khi comp nghiêng về các node nặng đó được hưởng lợi từ GPU.

Q: Farm render chia comp Nuke trên các máy như thế nào? A: Theo frame range, không phải theo vùng ảnh. Vì mỗi frame của comp là độc lập, render manager chia tổng frame range thành các chunk và giao mỗi chunk cho một worker, worker render phần của nó theo chế độ headless. Throughput tăng gần tuyến tính với số worker trên job.

Q: Tại sao comp Nuke của tôi render với màu sai trên farm? A: Nguyên nhân phổ biến nhất là OCIO config drift — farm đã resolve config OpenColorIO khác với config mà artist đã sử dụng, dù qua đường dẫn file khác, biến môi trường, hay config tùy chỉnh chưa được triển khai lên render node. Hãy gim project vào một config cụ thể và đảm bảo đúng config đó là những gì môi trường render sử dụng.

Q: Tôi cần gửi những file gì cùng script Nuke để render từ xa? A: Script cộng với tất cả những gì nó tham chiếu: footage và chuỗi ảnh, gizmo hoặc OFX plugin tùy chỉnh (hoặc bake chúng vào Group), OCIO color config, font được sử dụng bởi Text node, và bất kỳ file LUT độc lập nào. Bản render cũng phải khớp với phiên bản comp được tạo.

Q: NukeX có render comp Nuke tiêu chuẩn không? A: Có. NukeX là superset của Nuke cơ bản — nó bổ sung node thay vì loại bỏ khả năng đọc các node tiêu chuẩn — vì vậy render node NukeX render script được xây dựng trong Nuke cơ bản mà không có vấn đề. Render license có thể render bất kỳ node nào được tạo trong phiên bản NukeX trở xuống. Giới hạn duy nhất là ngược lại: Nuke cơ bản không thể đánh giá các node chỉ có trong NukeX.

Q: Chi phí render comp Nuke trên farm của bạn là bao nhiêu? A: Render comp được tính theo GHz-giờ tính toán CPU đã sử dụng, không có mức tối thiểu thuê máy và render credit không hết hạn. Tài khoản mới nhận credit $25, đủ để render một chuỗi test ngắn đầu đến cuối. Mức giá hiện tại và Cost Calculator có trên trang pricing của chúng tôi.