Oyun Sinematikleri ve Fragmanları İçin Render Farm 2026

Giriş: Oyun Sinematikleri Neden Farklı Bir Rendering Problemidir

Bir oyunun motoru içindeki performansı ile oyunun fragmanı birbirinden tamamen farklı iki rendering problemidir. İlki, oyuncunun GPU'sunda saniyede 60 kare olarak çalışır. İkincisi ise kare kare, 4K çözünürlükte ve hiçbir piyasaya sürülen oyunun interaktif hızlarda kaldıramayacağı gölgeleme karmaşıklığıyla çevrimdışı olarak işlenir. Bu ikisini birbirine karıştıran stüdyolar ya oyun ekran görüntüsü gibi görünen sinematiklerle ya da fragmanın talep ettiği çözünürlüğü sağlayamayan motorlar nedeniyle bütçeyi aşan programlarla karşı karşıya kalır.

Oyunlar için sinematik rendering her zaman hibrit bir çalışma olmuştur. Bazı stüdyolar, oyun asset'lerini tamamen çevrimdışı bir pipeline için referans olarak kullanarak, amiral gemisi fragmanlarını hâlâ Maya veya Cinema 4D'de pişirmektedir. Diğerleri ise Unreal Engine'in Movie Render Queue'sunu Sequencer ayarlı yüksek örneklemeli path-traced çıktıyla çalıştırır; 30 dakika/kare bütçesini kabul ederek gönderilen oyunla asset paritesini korur. Bazıları ise ikisini birleştirir: Unreal'den export edilen oyun düzeni, Maya'da yeniden tasarlanan kahraman çekimleri, Houdini'de oluşturulan parçacık katmanları ve After Effects ya da Nuke'ta yapılan nihai kompozisyon.

Super Renders Farm'da tam yönetimli bir render farm işletiyoruz ve yaklaşık on yıldır oyun sinematik çalışmalarının, birkaç fragman evinin sahip olduğu niş bir pipeline'dan orta ölçekli oyun stüdyolarının artık dahili olarak yönettiği bir iş yüküne dönüştüğünü gözlemliyoruz. Ancak bu dönüşüm çoğunlukla render tarafında destek olmadan gerçekleşmiyor. Bu makale, oyun sinematik renderinginin ne açıdan farklı olduğunu, bulut renderinginin bunu iyi desteklemek için ne yapması gerektiğini ve fragmanın nihai teslimat olduğu durumlarda prodüksiyon yöneticilerinin maliyet, güvenlik ve zamanlama konusunda nasıl düşünmesi gerektiğini ele almaktadır.

2026'da "Oyun Sinematikleri" Kavramı Neleri Kapsar

Bu ifade, sadece çıkış fragmanlarından çok daha fazlasını kapsamaktadır. 2026 prodüksiyon takvimine göre tek bir AAA oyun aşağıdakileri planlayabilir:

• Motoriçi sinematikler — oyun motoru içinden pişirilmiş, oyun bölümleri arasında kullanılan önceden işlenmiş ara sahneler. Genellikle çalışma zamanından daha yüksek örneklemelerle path-traced olarak işlenir ancak oyunla tutarlı bir ton korunur.
• Tanıtım ve duyuru fragmanları — halkın oyunu ilk gördüğü an. Genellikle stüdyonun karşılayabileceği en yüksek örnek bütçeyle çevrimdışı olarak işlenir; 4K veya daha yüksek, zaman zaman film renk derinliğinde.
• Oynanış fragmanları — motoriçi görüntülere daha yakın, ancak yayıncının belirli çekimler elde etmesi ve bunları bitmiş bir reklam olarak renk gradelayabilmesi için çevrimdışı işlenir.
• Hikaye fragmanları ve anlatı sinematikleri — ruh açısından oynanıştan çok kısa animasyona daha yakın. Genellikle harici fragman evleri tarafından yapılır, bazen kalite güvencesi için stüdyoya iade edilir.
• Pazarlama görselleri ve anahtar sanat — tek kare renderlar; ancak gönderilen oynanışta yer almayan çok yüksek çözünürlükte ve yüzey altı saçılma (subsurface scattering), deplasmanı ve ray-traced hacim bilişimi gibi gölgeleme detaylarıyla.
• Oyun içi önceden işlenmiş arka planlar — sabit kamera segmentleri, geçiş kartları veya stilize sekanslar için. Bugün nadir görülse de bazı anlatı oyunlarında hâlâ mevcuttur.

Bu iş yüklerinin her birinin farklı bir örnek bütçesi, farklı bir teslim süresi ve farklı bir risk profili vardır. İki hafta geç gelen bir tanıtım fragmanı çıkış tarihini öteleyebilir. Yeniden işlenen bir motoriçi ara sahne ise rutin bir asset yamasıdır. Bulut rendering kararları proje genelinde değil, çekim bazında verilmelidir.

Stüdyoların Gerçekte Kullandığı Pipeline'lar

Oyun sinematikleri için tek bir kanonik pipeline yoktur. Render farm'ımızdan geçen prodüksiyon çalışmalarında dört model görmekteyiz.

Model A — Unreal Engine Sequencer ve Movie Render Queue. Bu, gönderilen oyunla asset paritesi isteyen stüdyolar için 2026'daki en yaygın modeldir. Sequencer, çekim düzenini, animasyonu ve kamerayı barındırır. Movie Render Queue (MRQ), seçilen kalitede, çekim başına yapılandırılabilir anti-aliasing örnekleri ve ısınma kareleriyle kareleri dışarı aktarır. Unreal içindeki path tracing, kahraman çekimlerin artık motordan çıkmadan fotorealistik görünebileceği noktaya olgunlaşmıştır. Tam ayrıntılı ağır MetaHuman kalabalıkları, Nanite ortamları ve Lumen veya donanım ray tracing global illumination, artık çevrimdışı bütçelerde gerçekçi seçeneklerdir.

Model B — Maya ve V-Ray ya da Arnold. Derin Maya pipeline'larına sahip stüdyolar veya gerçek zamanlı motorların uygulanabilir olmadığı dönemden bu yana sinematik teslim eden fragman evleri, kahraman çekimlerini hâlâ çevrimdışı bir DCC'de pişirmektedir. Oyun asset'leri (genellikle Universal Scene Description aracılığıyla) Maya'ya export edilir, sinematik oyunculuk için riglenir ve film kalitesinde malzemelerle gölgelendirilir. V-Ray ve Arnold her ikisi de yaygındır; Arnold Maya'ya daha nativedir; V-Ray ise paralel mimari görselleştirme veya ürün çalışması olan stüdyolarda daha yaygındır.

Model C — Cinema 4D ve Redshift, stilize AAA için. Güçlü bir sanat yönetimli görünüme sahip stilize oyunlar (toon shading, empresyonist NPR, el çizimi kare mantığı) genellikle Cinema 4D ve Redshift'te yaşar. C4D'nin MoGraph araç seti, fragmanların başında veya sonunda sık sık karşılaşılan soyut hareket tasarımı segmentlerini işler. Redshift'in GPU hızı, kare başına iterasyonu hızlandırır.

Model D — Houdini efektler için, ardından birincil DCC'ye geri dönüş. Yıkım, sıvı, duman, büyük ölçekli kalabalık simülasyonu — bu iş yükleri ana pipeline'dan bağımsız olarak Houdini'de çözülme eğilimindedir. Çıktı genellikle nihai aydınlatma ve render için Maya, Unreal veya Cinema 4D'ye bırakılan bir önbellek (VDB, Alembic, USD) olur. Bazı stüdyolar Houdini'yi doğal olarak Karma ile işler; özellikle efekt yoğun tanıtım fragmanlarında.

Pratikte tek bir fragman nadiren tek bir pipeline'da yaşar. Bir tanıtım fragmanı Unreal'de düzenlenebilir, kahraman yakın çekimler Maya'da işlenebilir, yıkım simülasyonları Houdini'de yapılabilir ve bileşim Nuke'ta yapılabilir. Render farm tümünü yönetebilmelidir ve katmanlar arasındaki geçiş prodüksiyon ekibi için görünmez olmalıdır.

Bulut Renderinginin Oyun Sinematik Çalışmalarında İyi Yapması Gerekenler

Genel bulut rendering — bir mimari görselleştirme çekimi veya ürün görselleştirmesi için işe yarayan türden — otomatik olarak oyun sinematikleri için çalışmaz. İş yükünün şekli farklıdır.

Büyük asset yüzeyi. Tek bir çekim 200 GB MegaScans ortamı, gigabaytlarca MetaHuman geometrisi, 8K karakter texture'ları ve sabit bir import yerine akış kaynağı olarak ele alınan bir Nanite mesh kütüphanesi içerebilir. Upload ve senkronizasyon bu ölçekte sağlam olmalıdır. Çoğu iş için web upload desteklenmekle birlikte, paket başına yaklaşık 300 GB'ın üzerindeki transferler için SFTP veya Client App kullanılması önerilir; sürdürülebilir, paralel transfer yolu mutlak üst sınırdan daha önemlidir. Sıkıştırılmış arşivler tar, tar.gz ve 7z formatlarıyla sınırlıdır; ZIP platformumuzda desteklenmez; bu durum ilk defa karşılaşan stüdyoları zaman zaman şaşırtır.

Kaynak kontrol farkındalığı. Oyun stüdyoları mimari görselleştirme stüdyoları gibi çalışmaz. Kaynak kontrol sistemi (Perforce, Plastic, zaman zaman Git LFS) her asset'in kanonik durumudur. Render paketlerinin belirli bir değişiklik listesinde export edilmesi gerekir, "en son sürümü al" yaklaşımı geçerli değildir. Ciddi sinematik çalışmalar yapan stüdyolar genellikle yükleme öncesinde değişiklik listesini kilitlemek için paket hazırlığını sürüm kontrol sistemlerine karşı betikler. Bulut render farm'larının Perforce'u doğrudan anlaması gerekmez; ancak kaynak kontrol güdümlü iş akışlarının gerektirdiği uzun yükleme sürelerine ve katı tekrarlanabilirliğe toleranslı olmaları gerekir.

NDA ve fikri mülkiyet disiplini. Yayınlanmamış oyun görüntüleri, herhangi bir bulut pipeline'ındaki en hassas içerik kategorilerinden biridir. Fragman asset'leri, stüdyo hazır olmadan önce düzenli olarak basına sızar ve bir render farm sızıntısı, tedarikçiyi seçen prodüksiyon yöneticisi için kariyer sona erdiren bir olaydır. NDA koşulları, şifreli depolama, erişim kaydı ve net veri silme politikaları isteğe bağlı değildir. Stüdyolar herhangi bir potansiyel tedarikçiden ayrıntı istemelidir: kimin erişimi var, içerik ne kadar süre saklanıyor, erişim nasıl kaydediliyor, teslimattan sonra render çıktısı ve kaynak asset'lere ne oluyor. Varsayılan render çıktısı saklama süremiz iş tamamlanmasından itibaren 45 gündür; sonrasında çıktı otomatik olarak silinir; kaynak yüklemeler de benzer bir yaşam döngüsü izler. Belirli NDA gereksinimleri olan stüdyolar, ilk yüklemeden önce ekibimizle iletişime geçmelidir; proje gerektirdiğinde daha kısa saklama süreleri ve daha sıkı erişim kontrolleriyle çalışıyoruz ve render farm NDA sayfası bu konudaki ilk başvuru noktasıdır.

Çıktı yönetimi ve inceleme döngüleri. Sinematikler çoğu rendering çalışmasından daha fazla inceleme iterasyonundan geçer. Tek bir çekim, nihai onaydan önce yönetmen notu, müzik değişikliği veya yayıncı talebi nedeniyle beş ya da altı kez yeniden işlenebilir. Bulut render çıktısının tüm inceleme döngüsü boyunca alınabilir, çekim ve sürüme göre düzenlenmiş ve tercihen prodüksiyon ekibinin yeniden indirme yapmadan sürümleri karşılaştırabileceği şekilde erişilebilir olması gerekir.

Çoklu DCC ve çoklu motor desteği. Yalnızca bir motoru destekleyen bir render farm'a bağlanan stüdyo, Houdini simülasyonunun Karma'da işlenmesi gereken ilk anda ya da sanat yönetmeninin bir kahraman çekimin Redshift toon-shaded sürümünü istediği anda bu kararın bedelini öder. Aynı filoda V-Ray, Corona, Arnold, Redshift, Octane ve Cycles'ı; 3ds Max, Maya, Cinema 4D, Blender, Houdini, After Effects ve NukeX'i kapsayan çoklu DCC desteğiyle yönetiriz. Hangi motoru kullanacağınıza dair karar sanatsal olmalıdır; render farm'ın kurulu yazılım listesiyle kısıtlanmamalıdır.

Super Renders Farm'ın Oyun Sinematik İş Yüklerini Nasıl Desteklediği

Bir oyun stüdyosu render farm'ımızı sinematik çalışma için değerlendirirken birkaç şey önemlidir.

Dual Xeon E5-2699 V4 filomuzda 20.000'den fazla CPU çekirdeği işletiyoruz; ayrıca kart başına 32 GB VRAM'e sahip NVIDIA RTX 5090 kartlarıyla donatılmış özel GPU makinelerimiz mevcuttur. CPU tarafı V-Ray, Corona ve Arnold iş yüklerini yönetir; GPU tarafı ise Redshift, Octane, V-Ray GPU ve Cycles'ı işler. Unreal Engine Movie Render Queue çalışmaları için GPU kaynakları önem taşır — Unreal'in path tracer'ı VRAM kapasitesinden ve modern RT çekirdeklerinden yararlanır. Chaos Group (V-Ray ve Corona) ve Maxon (Cinema 4D, Redshift) ile resmi ortaklıklarımız mevcuttur; bu sayede lisanslamamız doğrulanmış olup ekibimiz render davranışını değiştiren motor güncellemelerini erken görmektedir.

Modelimiz tam yönetimli kiralama tabanlı bir render farm'dır: stüdyolar sahne paketlerini yükler, pipeline'ımız bağımlılıkları analiz eder, render node'larımız işi çalıştırır ve tamamlanan çıktı iade edilir. Uzak masaüstü adımı yoktur. Stüdyonun donanımımızda rendering yazılımı yüklemesi veya lisanslaması gerekmez. Plugin kütüphaneleri — 3ds Max tarafında Forest Pack, Phoenix FD, Tyflow; Maya'da Yeti, MASH, Bifrost; C4D'de X-Particles, Octane, Redshift — lisanslama izin verdiğinde önceden yüklüdür. Unreal Engine iş akışları için projeyi doğru şekilde paketleme ve uzun render'lara başlamadan önce Movie Render Queue ayarlarını doğrulamak üzere stüdyolarla birlikte çalışıyoruz.

Tam yönetimli model, sinematikler için rutin rendering'den daha önemlidir. 24 fps, 60 saniyeye karşılık gelen 4K kahraman çekimi 1.440 karedir. Kare başına 30 dakikada bu, geçiş başına 720 GPU-saat anlamına gelir. Yalnızca 800. karede tespit edilen hatalı yapılandırılmış bir AOV veya eksik texture gerçek bir prodüksiyon maliyetidir. Pipeline'ımız yaygın başarısızlık modlarını — eksik referanslar, uyumsuz plugin sürümleri, bozuk UDIM yolları — kuyruk GPU zamanı harcamaya başlamadan önce tespit eder.

Güvenlik duruşunun satın alma kararının bir parçası olduğu stüdyolar için politikalarımızı render farm NDA sayfasında yayımlıyor ve herhangi bir asset yüklemesi öncesinde projeye özgü NDA koşullarını kabul ediyoruz. Varsayılan render çıktısı saklama süresi 45 gündür; hassas projeler için talep üzerine daha kısa saklama süreleriyle çalışıyoruz.

Maliyet: Sinematik Render Bütçesini Nasıl Düşünmeli

Oyun sinematikleri stüdyoları maliyet açısından şaşırtma eğilimindedir çünkü kare başına maliyet, mimari görselleştirme baskısından daha yüksektir ve kare sayısı kısa film animasyonundan fazladır. 24 fps'de 90 saniyelik bir tanıtım fragmanı 2.160 karedir; tam path tracing ile 4K'da bireysel kareler, gölgeleme karmaşıklığına, örnek sayısına ve AOV yüküne bağlı olarak tek bir yüksek kaliteli GPU'da 20 ila 60 dakika sürebilir. Bu, geçiş başına 720 ila 2.160 GPU-saat aralığına karşılık gelir ve fragmanlar genellikle nihai teslimattan önce üç ila dört tam kaliteli geçişten geçer.

Birkaç kullanışlı çerçeveleme kuralı:

İşlem süresi, duvar süresini değil, maliyeti belirler. İster küçük bir filoda üç günde ister büyük bir filoda sekiz saatte tamamlansın, GPU-saat maliyeti benzerdir. Bulut rendering, duvar süresi önemli olduğunda — fragmanın salı günü teslim edilmesi gerektiğinde ve yayıncının kesimi cuma günü onayladığında — değerini ortaya koyar. (Kare başına matematiği daha ayrıntılı incelediğimiz kare başına maliyet rehberimizi inceleyebilirsiniz.)

Örnek bütçeleri birikimlidir. Piksel başına 256 örnekle çekilen bir sahne, 128 örnekli sahneden yaklaşık iki kat, 64 örnekli sahneden dört kat daha uzun sürer. Çoğu sinematik çekim, denoiser doğru yapılandırıldığında 256 örnekten çok önce yakınsama sağlar. Yakınsama testleri yapmadan maksimum kaliteyi varsayılan olarak kullanan stüdyolar, tüm fragman bütçelerinde bir çarpan ödüyor demektir.

Kahraman çekimleri ve geniş kapsama. 30 saniyelik bir sekans, maksimum kalite gerektiren üç veya dört kahraman çekime ve kameranın yeterince hızlı hareket ettiği için ayrıntıların önem taşımadığı on ya da on iki geniş kapsama çekimine sahip olabilir. Çekim başına örnek bütçeleme, kare başına fiyat müzakeresi yapmaktan daha hızlı bir maliyet azaltma kaldıracıdır.

Render geçişleri önemlidir. Güzellik, derinlik, hareket vektörü, cryptomatte, ID, ambient occlusion — her ek AOV bellek ve zaman ekler. Geçiş yoğun bir kahraman çekimi yalnızca güzellik geçişinden daha pahalıdır; ancak kompozisyon esnekliği çoğunlukla render maliyetinin kendisinden daha fazla post-prodüksiyon zamanı tasarrufu sağlar.

Fiyatlandırmamız CPU rendering için GHz-hr başına ve GPU rendering için OctaneBench eşdeğer birimi başına yapılandırılmıştır. Güncel tarifeleri fiyatlandırma sayfasında yayımlıyor ve maliyet hesaplamamız prodüksiyon yöneticilerinin gönderim öncesinde işi tahmin etmesine olanak tanıyor. Özellikle sinematik çalışmalar için, tam sekansa geçmeden önce hedeflenen nihai örnek sayısında tek bir test çekimi yapılmasını öneririz — 30 saniyelik bir test render'ının maliyeti, seçilen örnek sayısının bin kareden sonra yanlış olduğunu öğrenmenin maliyetinden çok daha düşüktür.

Zamanlama: Fragman Teslim Son Teslim Tarihinden Nasıl Kaçınılır

Tekrar tekrar gözlemlediğimiz birkaç model:

Kurgunun çok geç kilitlenmesi. Fragmanlar teslimat tarihine çok yakın zamana kadar kurgu revizyonlarından geçer. Kurgu kilitlenmeden render almaya çalışan stüdyolar, nihai kurgudan çıkarılan çekimler için ödeme yapar. Planlanan teslimattan en az yedi takvim günü önce kurgunun kilitlenmesini öneriyoruz — teslimatta uluslararası yerelleştirme varsa daha erken.

İnceleme döngülerinin küçümsenmesi. Dahili bir sinematik için üç inceleme turu makul bir varsayılandır. Yayıncıya bağlı bir fragman için beş tur normaldir. Her tur bir ila üç gün yer. Tek bir inceleme penceresi planlayan stüdyolar teslim tarihini yeniden müzakere etmeye hazırlanıyor demektir.

Güzelliği kompozisyondan ayırmamak. Render bütçesi, yalnızca güzellik geçişini değil, güzellik geçişini artı tüm AOV'ları hesaba katmalıdır. Kompozisyon notları neredeyse her zaman en az birkaç çekimin yalnızca AOV'lu yeniden işlenmesini tetikler; AOV-only yeniden render'lar da gerçek GPU-saatlerdir.

Kuyruk derinliği için tampon günler. Render farm paylaşılan bir kaynaktır. Kuyruk derinliği mevsimsel olarak değişir. Prodüksiyon yöneticileri, sinematik kalitedeki herhangi bir çalışma için "işi gönderiyorum" ile "ilk kareyi geri bekliyorum" arasında en az 24 saatlik tampon planlamalıdır. Çiftliğimizde kuyruk derinliği 2026 ilkbahar prodüksiyon döngüsü boyunca istikrarlı kalmıştır; ancak tam bir sekansa geçmeden önce teslim süresini doğrulamak için her zaman başlangıçta bir test çekimi gönderilmesini öneririz.

Bir Render Farm'a Bağlanmadan Önce Sormanız Gerekenler

Oyun stüdyosu prodüksiyon yöneticilerine iyi hizmet etmiş kısa bir satın alma kontrol listesi:

1. Unreal Engine Movie Render Queue / Maya / Cinema 4D / Houdini / Blender için hangi render motorlarını ve plugin sürümlerini destekliyorsunuz?
2. Varsayılan çıktı saklama politikanız nedir ve NDA hassasiyeti gerektiren çalışmalar için kısaltılabilir mi?
3. Yüklenen asset'lere kimin erişimi var ve bu erişim nasıl kaydediliyor?
4. Maksimum yükleme boyutunuz nedir ve hangi arşiv formatları destekleniyor?
5. Filomdaki yazılımın motor satıcılarıyla resmi ortaklığınız var mı?
6. Fiyatlandırma modeliniz nasıl işliyor — GHz-hr başına, node başına, kare başına, abonelik?
7. Bir çekimin iki veya daha fazla uygulamadan asset çektiği çoklu DCC paketlerini nasıl ele alıyorsunuz?
8. Sıkışan bir render için belgelenmiş yükseltme yolu nedir — sohbet, bilet, özel hesap?

Bu soruların yanıtları, oyun sinematik iş yükünü destekleyebilen tedarikçileri destekleyemeyenlerden ayırır. Doğru tedarikçi bu soruları hızlı ve kesin olarak yanıtlar. Bizi değerlendiren stüdyolar aktif NDA kapsamındaki projeler için render farm NDA sayfasından, genel bütçe planlaması için fiyatlandırma sayfasından ve maliyet hesaplayıcımızdan başlayabilir.

Nerede Uygunuz, Nerede Değiliz

Stüdyonun çoklu DCC desteğine ihtiyaç duyduğu, projenin büyük rendering ekosistemlerinde plugin kapsamı talep ettiği, prodüksiyon ekibinin uzak masaüstü yükü olmadan tam yönetimli bir pipeline istediği ve güvenlik duruşu ile NDA disiplininin satın alma kararının bir parçası olduğu durumlarda oyun sinematik renderingine iyi uyum sağlıyoruz. İlk çıkış fragmanlarını gönderen bağımsız stüdyolardan bir amiral oyununun pazarlama renderingini yöneten köklü ekiplere kadar iş yüklerini destekliyoruz.

Özel araçlar yüklemek için render node'larına doğrudan kabuk erişimine ihtiyaç duyan stüdyolar, pipeline'ının desteklemediğimiz rendering yazılımına bağlı olduğu stüdyolar veya tüm satın alma kararının yönetilen hizmet ek yükü gözetmeksizin kare başına fiyatı minimize etmeye dayandığı iş yükleri için doğru seçim değiliz. Bu kategorilerde iyi tedarikçiler mevcuttur — yalnızca biz onlar değiliz.

Oyun sinematikleri için doğru render farm, stüdyonun pipeline şekline, güvenlik duruşuna ve programına uyan render farm'dır. Bir prodüksiyon ekibinin altyapımızda çalışmanın nasıl görüneceğini anlatmaktan memnuniyet duyarız; ancak başka bir tedarikçinin daha uygun olduğu durumlarda bunu dürüstçe belirteceğiz.

SSS

Q: Bir bulut render farm, oyun sinematikleri için tam path-traced Unreal Engine Movie Render Queue çıktısını işleyebilir mi? A: Evet. Unreal'in path tracer'ı GPU üzerinde çalışır ve VRAM kapasitesinden, modern RT çekirdeklerinden ve yönetilen plugin kapsamından yararlanır. Kart başına 32 GB VRAM'e sahip RTX 5090 node'larında MRQ çıktısı işliyoruz ve uzun render'lara başlamadan önce Sequencer ve MRQ ayarlarını doğrulamak üzere stüdyolarla birlikte çalışıyoruz. Pipeline, diğer GPU rendering çalışmaları için kullandığımız tam yönetimli modeldir.

Q: Oyun stüdyoları bulut rendering için Perforce veya Plastic SCM'den asset'leri nasıl export eder? A: Stüdyolar genellikle yüklemeden önce belirli bir değişiklik listesini düz bir paket olarak export etmek için paket hazırlığını sürüm kontrol sistemlerine karşı betikler. Render farm'ın Perforce ile doğrudan entegrasyon sağlaması gerekmez. Önemli olan, upload pipeline'ının büyük paket boyutlarında sağlam olmasıdır — paket başına yaklaşık 300 GB üzerindeki transferler için SFTP veya Client App kullanılmasını, bu eşiğin altında web upload kullanılmasını öneriyoruz.

Q: Yayınlanmamış oyun görüntülerini bulutta işlerken NDA ve fikri mülkiyet koruması ne olacak? A: Yayınlanmamış oyun içeriği yüksek hassasiyetli materyaldir ve bu şekilde değerlendirilmelidir. Stüdyolar herhangi bir tedarikçiden erişim kaydı, saklama politikaları, şifreleme duruşu ve veri işlemeyi yöneten sözleşme koşulları hakkında bilgi istemelidir. Varsayılan render çıktısı saklama süremiz iş tamamlanmasından itibaren 45 gündür. Projeye özgü NDA koşullarını kabul ediyor ve talep üzerine daha kısa saklama süreleriyle çalışıyoruz. Render farm NDA sayfası, belirli satın alma gereksinimleri olan stüdyolar için doğru ilk adımdır.

Q: Aynı farm, aynı projede hem Unreal Engine sinematiklerini hem de Maya kahraman çekimlerini işleyebilir mi? A: Evet. Çoklu DCC desteği tam da çoğu sinematik projenin birden fazla uygulama kapsaması nedeniyle önemlidir. 3ds Max, Maya, Cinema 4D, Blender, Houdini, After Effects ve NukeX genelinde V-Ray, Corona, Arnold, Redshift, Octane ve Cycles'ı yönetiyoruz. Tek bir proje, stüdyonun her biri için ayrı bir tedarikçiye ihtiyaç duymadan bunların birçoğundan geçebilir.

Q: 90 saniyelik 4K oyun fragmanını render etmenin maliyeti nedir? A: 24 fps'de 90 saniyelik bir fragman 2.160 karedir. Tam path tracing ile 4K'da bireysel kareler, gölgeleme karmaşıklığına, örnek sayısına ve AOV yüküne bağlı olarak tek bir yüksek kaliteli GPU'da genellikle 20 ila 60 dakika sürer. Bu, tek bir geçişi 720 ila 2.160 GPU-saat arasına yerleştirir ve çoğu fragman nihai teslimattan önce üç ila dört tam kaliteli geçişten geçer. Maliyet hesaplamamız prodüksiyon yöneticilerinin gönderim öncesinde tahmin yapmasına olanak tanır. Tam sekansa geçmeden önce hedeflenen nihai örnek sayısında tek bir test çekimi yapılmasını öneririz.

Q: Aynı çekim birden fazla kez yeniden işlendiğinde inceleme döngüleri nasıl yönetilir? A: Render çıktısı varsayılan olarak iş tamamlanmasından itibaren 45 gün boyunca, iş ve sürüme göre düzenlenmiş olarak saklanır. Aynı çekimin yeniden işlenmesi yeni bir iş olarak gönderilir; önceki sürüm saklama süresi içinde erişilebilir kalır. Gördüğümüz çoğu sinematik proje üç ila beş inceleme turundan geçer; saklama penceresi bu döngüyü artı teslim ve arşivi rahatça karşılayacak şekilde boyutlandırılmıştır.

Q: Aynı fragman için birincil DCC rendering'in yanı sıra Houdini efekt çalışmasını destekliyor musunuz? A: Evet. Houdini, Karma, Redshift, Mantra, Arnold, Houdini için V-Ray ve Octane ile tam olarak desteklenmektedir. Stüdyolar genellikle yıkım, sıvı ve kalabalık simülasyonlarını Houdini'de çözer, ardından önbelleği (VDB, Alembic, USD) nihai aydınlatma ve render için birincil DCC'ye bırakır. Bu iş akışının her iki yarısı da render farm'ımızda çalışabilir.

Q: Uzun bir sekans ortasında bir render işi başarısız olursa ne olur? A: Pipeline kare başına durumu izler ve tamamlanan kareleri yeniden işlemeden başarısız kareden devam edebilir. Hata sahne düzeyindeki bir sorundan kaynaklanıyorsa (eksik referans, bozuk UDIM yolu, plugin sürümü uyuşmazlığı), ekibimiz kuyruğun sekansın geri kalanında önemli miktarda GPU zamanı harcamadan önce bunu işaretler. Ön denetimler yaygın başarısızlık modlarını erken tespit eder; bu da tam yönetimli modelin rutin rendering'den çok sinematik çalışmalar için daha önemli olmasının nedenlerinden biridir.