VFX Compositing ve Bulut Rendering: Comp Render'lar Neden 3D'den Farklı Bir İş Yüküdür

Giriş

Çoğu bulut rendering içeriği tek bir iş yükü için yazılır: bir 3D sahnenin, gürültü temizlenip bir kare tamamlanana kadar bucket'lar hâlinde bir path tracer'dan geçmesi. Bu çerçeveleme bir Redshift veya V-Ray işi için doğrudur, ancak bir compositing render için neredeyse işe yaramaz. Bir comp, ışık yollarını örneklemez; zaten var olan görüntü (footage) ve pass'lere karşı bir node graph'ı değerlendirir. Ne kadar sürdüğünü ve ne kadara mal olduğunu belirleyen şey neredeyse hiçbir zaman GPU örnek sayısı değildir.

Bu ayrım göründüğünden daha önemlidir, çünkü bu iki iş yükü genel "bulut rendering" tavsiyelerinde sürekli birbirine karıştırılır. Bir Nuke script'ini veya bir After Effects projesini ilk kez bir farm'a taşıyan ve 3D render ile aynı GPU'ya bağlı davranışı bekleyen bir compositor, ne simülasyon ne de ray tracing içeren bir comp'ın neden hâlâ yavaş olduğu, ya da seçtiği GPU katmanıyla hiçbir ilgisi olmayan bir şekilde neden hızlı olduğu konusunda kafası karışmış hâlde kalır. Bu rehber tam olarak bu boşlukla ilgilidir: bir comp render'ın bir farm'da gerçekte ne yaptığı, bir 3D render'dan mekanik olarak nasıl farklılaştığı ve compositing işini buluta taşımanın, gece boyunca çalışan bir iş istasyonuna kıyasla ne zaman değdiği.

Super Renders Farm'daki farmımızda bu pipeline'ın her iki tarafıyla da günlük olarak çalışıyoruz: beauty pass ve AOV'leri üreten 3D render'dan, bunları nihai bir shot'a birleştiren compositing render'a kadar. İkisi donanımı paylaşır, ancak render davranışı açısından paylaştıkları başka pek bir şey yoktur; bu farkı anlamak, bir comp render işini bir gizeme dönüşmek yerine öngörülebilir kılan şeydir.

Çok pass'li EXR compositing akışını gösteren pipeline diyagramı: 3D render pass'leri çok katmanlı bir EXR dosyasında birleşir, ardından compositing uygulamasına ve nihai grade'e geçer

Compositing, 3D Rendering'den Farklı Bir Render İş Yüküdür

V-Ray, Redshift veya Arnold gibi bir 3D render motoru ışık taşınımı (light transport) yapar: ışınları izler, malzemeleri örnekler ve bir görüntü yakınsayana kadar zamanla gürültü azaltmayı biriktirir. Bu iş piksel başına gerçekten hesaplama yoğun bir iştir; bu yüzden 3D rendering, motora bağlı olarak CPU ağırlıklı veya GPU ağırlıklı olur ve GPU hızlandırma 3D render sürelerinde bu kadar büyük bir etkiye sahip olur.

Bir compositing render bunların hiçbirini yapmaz. Nuke, After Effects, Fusion ve benzeri araçlar bir node graph'ı değerlendirir: bir görüntü okur, bir renk düzeltmesi uygular, iki katmanı birleştirir, bir dönüşüm uygular, sonucu yazar. Örnekleme ve yakınsama yoktur. Her işlem, piksel verisi üzerinde belirlenimci (deterministic) ve çoğunlukla doğrusal cebir tabanlı bir geçiştir; bu işlemlerin büyük çoğunluğu (merge'ler, grade'ler, keyer'lar, transform'lar, çoğu filtre) GPU yerine CPU üzerinde çalışır. Bir avuç belirli node türü (ağır retime'lar, bazı denoise işlemleri, belirli makine öğrenmesi araçları) GPU hızlandırmalıdır, ancak bunlar tipik bir comp'ta kural değil, istisnadır.

Bir comp render'ın ne kadar sürdüğünü gerçekte belirleyen şey, bir hesaplama probleminden çok bir veri taşıma problemine yakındır:

• Okuma verimi (read throughput). Bir comp script'i her kare için footage ve render pass'lerini okur; genellikle aynı anda birkaç çok katmanlı EXR sekansını birden.
• CPU threading. Compositing işlemleri tek bir kare içinde CPU çekirdekleri arasında paralelleşir; render manager ise kare aralığının parçalarını farklı worker'lara dağıtarak kareler arasında paralelleşir.
• Bellek. Aynı anda birkaç tam çözünürlüklü, çok kanallı kareyi bellekte tutmak (bir beauty pass, bir avuç AOV, bir cryptomatte matte'i, belki bir deep pass) göründüğünden çok daha fazla bellek talep eder; bir karenin ortasında RAM'in tükenmesi, başarısız bir comp render'ın ham CPU hızından daha yaygın bir nedenidir.
• Yazma verimi (write throughput). Nihai composite edilmiş kare veya ara bir precomp geri yazılmalıdır; VFX pipeline teslimatları için bu çıktı genellikle tek bir video dosyası değil, başka bir EXR sekansıdır.

Bunların hiçbiri compositing yazılımına yönelik bir eleştiri değildir. Bu, sıfırdan görüntü verisi üretmek yerine mevcut görüntü verisini taşımak ve birleştirmek üzerine kurulu farklı bir iş yükü türüdür. Bir comp işini bir 3D render gibi ele alan, ağır GPU kapasitesi sağlayıp RAM ve depolama veriminden kısan bir render farm, işi iyi karşılaması gereken tam da o makinelerde beklenenin altında performans gösterir.

Bir Comp Render Gerçekte Ne Okur ve Ne Yazar

Bir compositing işinin girdi ve çıktı şekli, 3D rendering'den farkın en somut şekilde ortaya çıktığı yerdir.

Girişte çok katmanlı, çok pass'li EXR. Bir comp, tipik olarak her kare için zaten birçok kanal taşıyan bir veya daha fazla OpenEXR dosyası açar: bir beauty render, ayrı diffuse ve specular pass'ler, lighting AOV'leri, bir Z-depth pass'i, motion vector'lar ve nesne, malzeme ve asset ID izolasyonu için cryptomatte matte'leri; hepsi tek bir Read node üzerinden okunan tek bir dosyada bulunur ve pass başına çalışma için Shuffle node'larıyla ayrılır. Bu dosyayı okumak küçük bir dosya erişimi değildir; belirli bir comp bunların yalnızca birkaçına dokunsa bile, bir karenin taşıdığı her kanalı çekmektir. Bu nedenle depolama okuma bant genişliği, comp ağırlıklı farm node'larında gerçek bir darboğazdır; bu durum, EXR verisinin çoğunu okumak yerine yazan bir 3D render için nadiren geçerlidir.

Bir çıktı değil, bir girdi olarak cryptomatte. Cryptomatte verisi (bir compositor'ün yeniden render almadan, sonradan tekil nesneleri, malzemeleri veya asset örneklerini izole etmesini sağlayan prosedürel olarak üretilmiş ID matte'leri) 3D render tarafından yazılır ve comp tarafından tüketilir. Bu, bir compositing farm işinin, yukarı akıştaki 3D render'ın ürettiği her ne cryptomatte kanalını devraldığı ve cryptomatte izolasyonuna dayanan bir comp'ın, dayanmayan bir comp'a göre kare başına daha fazla kanal okuduğu anlamına gelir. EXR-IO ve cryptomatte rehberimiz, bu verinin nasıl yapılandırıldığını ve verimli şekilde nasıl çalışılacağını ele almaktadır; cryptomatte ağırlıklı bir comp'ı herhangi bir farm'a göndermeden önce okumaya değer.

Yüksek bit derinliğinde az sayıda çıktı. Bir 3D render genellikle kare başına birkaç pass yazarken, bir comp render tipik olarak bu pass'leri bire veya birkaç nihai composite edilmiş çıktıya indirger; genellikle VFX pipeline'ında daha ileriye giden HDR lineer teslimatlar için 16-bit half-float EXR, tam hassasiyet gerektiren veri pass'leri için ara sıra 32-bit. Yazma, kanal sayısı bakımından okumadan daha küçüktür, ancak yine de tam çözünürlüklü bir karedir; deep-compositing işleri için (3D sahneyi yeniden render almadan holdout'ları çözmek amacıyla piksel başına birden fazla derinlik örneği tutmak) hem okuma hem de yazma önemli ölçüde ağırlaşır.

Video encode'ları render'ın kendisi değil, ayrı bir adımdır. Nihai teslimat bir görüntü sekansı yerine H.264 veya HEVC olduğunda, bu encode genellikle karesel comp render'ın bir parçası olarak değil, ondan sonra ayrı bir pass olarak gerçekleşir; çünkü video codec'leri, bağımsız bir görüntü sekansı gibi worker'lar arasında temiz bir şekilde bölünemez. H.264 ve H.265 encoding rehberimiz, bu son adımdaki ödünleşimleri (tradeoffs) daha ayrıntılı ele almaktadır.

Altı render pass'i (beauty, diffuse, specular, cryptomatte, depth, ambient occlusion) tek bir çok katmanlı EXR dosyasında birleşiyor

Comp Render'lar Bir Bulut Farm Genelinde Nasıl Dağıtılır

Compositing işi için dağıtım modeli, bir 3D render motorununkinden çok Nuke'unkine yakındır; nedenini net bir şekilde açıklamakta fayda vardır.

Bir 3D render motoru tek bir kareyi mekânsal olarak bölebilir: bucket'lar veya tile'lar farklı thread'lere veya makinelere dağıtılır; çünkü bir bölgedeki pikseller gerçekten başka bir bölgedeki piksellere bağımlı değildir. Bir comp genellikle bu şekilde bölünemez. N karesindeki bir pikselin değeri, o karenin girdilerinin tüm node ağacından geçmesine bağlıdır; bu da compositing işinin çoğunu görüntü bölgesine göre değil, kareye göre son derece paralelleştirilebilir (embarrassingly parallel) hâle getirir. Bir render manager bir comp karesini alt bölümlere ayırmaz; kare aralığını alt bölümlere ayırır ve kare parçalarını farklı worker'lara dağıtır; her biri kendi parçası için compositing uygulamasının headless (GUI'siz) bir örneğini çalıştırır.

Bu, Nuke cloud render farm rehberimizin özellikle Nuke için tam komut satırı bayrakları ve lisanslama mekaniği dahil olmak üzere ayrıntılı olarak ele aldığı modeldir. After Effects, çoğu prodüksiyon comp'ı için (title sequence'ler, motion graphics, archviz reveal'lar) benzer şekilde davranır, ancak burada belirtilmeye değer bir istisna vardır: kareler arasında zamansal duruma bağlı AE composition'ları (kareler arası örneklemeli motion blur, birikimli particle simülasyonları, bazı tracking işlemleri) temiz bir şekilde kareye göre paralel değildir ve bunları naif bir şekilde worker'lar arasında bölmek, parça sınırlarında görünür dikişlere (seam) yol açabilir. After Effects bulut rendering kurulum rehberimiz, hangi AE iş akışlarının temiz bir şekilde paralelleştiğini ve hangilerinin bunun yerine tek worker'lı bir pass gerektirdiğini ele almaktadır.

Bir farm üzerinde bir comp render işinin pratik şekli şöyledir: script veya proje, referans verdiği her şeyle birlikte kendi kendine yeterli (self-contained) bir paket olarak yüklenir; render manager toplam kare aralığını parçalara böler; her worker kendi parçasını çeker, sanatçının makinesindeki aynı footage yollarını, renk konfigürasyonunu, fontları ve plugin bağımlılıklarını çözer ve headless olarak render alır; her parça tamamlandıkça tamamlanmış kareler paylaşımlı veya bulut depolamaya iner; böylece uzun bir sekans, son worker bitmeden çok önce kullanılabilir çıktı döndürmeye başlayabilir.

Bulut Compositing'inde Yaygın Sorunlar

Bir farm'da başarısız olan veya yanlış dönen comp render'ların ezici çoğunluğu compositing matematiği sorunu değildir. Bunlar, yerel bir iş istasyonunun sessizce gizlediği bağımlılık ve ortam sorunlarıdır.

Bunların hiçbiri tek bir uygulamaya özgü değildir. Bu, bir compositing script'i yazıldığı makineden ayrıldığında neyin bozulacağının genel şeklidir; "tam sekansı göndermeden önce küçük ölçekte test edin" (önce birkaç kareyi render alın, yerel sonuçla karşılaştırın) yaklaşımının, herhangi bir comp render için, herhangi bir farm'da almaya değer düşük maliyetli bir güvence adımı olmasının nedeni de budur.

Bulut Rendering Bir Compositing Pipeline'ına Gerçekte Ne Zaman Yardımcı Olur

Her comp bir farm'a ihtiyaç duymaz. Yerel olarak birkaç dakikada render alınan kısa bir sekans, buluta taşınmanın yükleme ve kuyruk ek yükünden çok az fayda sağlar. Bulut compositing, belirli bir dizi durumda değerini kanıtlar:

Son tarihe dayalı yoğun yükler. Günler değil saatler içinde teslim edilmesi gereken; kare sayısının ve karmaşıklığın bir iş istasyonunu son tarihin izin verdiğinden daha uzun süre meşgul edeceği bir teslimat. 1.000 karelik bir sekansı düzinelerce worker'a dağıtmak, gece boyu süren bir render'ı bir veya iki saatte geri dönebilen bir şeye dönüştürür; çünkü verim, kullanılabilir worker sayısıyla neredeyse doğrusal olarak ölçeklenir.

Aksi hâlde bir sanatçıyı bloke edecek gece boyu toplu işler. Sert bir son tarih baskısı olmasa bile, bir sanatçının kendi makinesini birkaç saat boyunca meşgul edecek bir comp, o sanatçının iterasyon yapamadığı, inceleme yapamadığı veya bir sonraki shot üzerinde çalışamadığı süredir. İşi bir farm'a göndermek, yerel bir render'ın temizlenmesini beklemek yerine iş istasyonunu hemen serbest bırakır.

Kare başına ağır veriye sahip büyük sekanslar. Deep compositing, 4K ve üzeri çok kanallı EXR ve cryptomatte ağırlıklı comp'lar, kare başına render süresinin en çok biriktiği ve birçok CPU ağırlıklı worker'a dağıtımın, hafif, düşük kanal sayılı bir comp'a kıyasla en çok karşılığını verdiği tam da o iş yükleridir.

Zaten bir farm kullanan karma 3D ve comp pipeline'ları. Bir shot için 3D render zaten bir bulut farm üzerinde çalışıyorsa, compositing aşamasını aynı altyapıda tutmak, iki aşama arasında yerel bir makineye gidiş dönüşü önler ve pass'leri (beauty, AOV, cryptomatte) comp'ın onları okuyacağı yere yakın tutar.

Bulut compositing'in en az değer kattığı durum: son tarih baskısı olmayan, yerel render süresinin zaten kendi kendine yeterli bir proje paketini hazırlayıp yüklemek için gereken süreden çok daha az olduğu bir avuç kısa, basit comp. Yükleme ve bağımlılık denetimi ek yükü gerçektir ve küçük bir iş için kazanılan zamanı aşabilir.

Maliyet: Bir Comp Render İşi Gerçekte Ne Kadara Mal Olur

Compositing, tipik bir comp'taki node'ların büyük çoğunluğu için CPU ve belleğe bağlı bir iş yükü olduğundan, maliyeti genellikle belirleyen CPU oranıdır; GPU oranı yalnızca gerçekten GPU hızlandırma kullanan belirli node'lara (ağır retime'lar, bazı denoise'lar, makine öğrenmesi araçları) uygulanır.

Farmımızda CPU hesaplaması GHz-saat başına faturalandırılır; baz oran GHz-saat başına 0,004 dolardır (öncelik katmanları kuyruk önceliğine bağlı olarak GHz-saat başına 0,004 ila 0,016 dolar arasında değişir), GPU hesaplaması ise OctaneBench-saat (OBh) başına faturalandırılır; baz oran OBh başına 0,003 dolardır ve tam kullanımda bir RTX 5090 (32 GB VRAM) kart yaklaşık kart-saat başına 5,2 dolara mal olur. Render kredileri sona ermez ve bir makine kiralama minimumu yoktur; dolayısıyla bir comp işi, ayrılmış bir zaman bloğu yerine gerçekte tükettiği hesaplama için faturalandırılır.

Bunu açıklayıcı bir işlenmiş örnekle somutlaştırmak gerekirse (bir benchmark rakamı değil; çünkü kare başına gerçek render süresi çözünürlük, kanal sayısı ve node karmaşıklığına göre büyük ölçüde değişir): toplamda 5.000 GHz-saat toplam CPU hesaplaması tüketen bir compositing batch'i, gece boyunca düzinelerce worker'a dağıtılan birkaç bin karelik bir 4K sekans için makul bir büyüklük mertebesidir ve herhangi bir öncelik katmanı çarpanı olmadan baz oranda yaklaşık 20 dolarlık hesaplamaya mal olur. Aynı işin bir kısmı GPU hızlandırmalı node'lara dayanıyorsa, bu dilim GHz-saat oranı yerine ayrıca OBh oranından faturalandırılır. Bütçeleme için önemli olan mekanik, tam rakamlar işten işe değişse bile basittir: maliyet, gerçek saatlik render süresini değil, tüketilen toplam hesaplamayı izler; dolayısıyla bir işi daha hızlı bitirmek için daha fazla worker'a dağıtmak, tek başına maliyeti değiştirmez.

Comp Rendering ve 3D Rendering: Yan Yana Karşılaştırma

Compositing, Daha Geniş Bir Bulut Rendering Pipeline'ına Nasıl Uyar

Compositing genellikle bir 3D render ile başlayan zincirin son aşamasıdır; bu iki aşamayı donanım ve darboğazlar konusunda aynı varsayımlarla ele almak, bulut compositing'e yeni başlayan ekiplerin destek taleplerinde gördüğümüz en yaygın hatadır. Pipeline'ınız tamamen 3D tarafındaysa ve daha geniş servis modelini henüz çözmediyseniz, bir cloud render farm'ın ne olduğuna dair rehberimiz ve VFX ve ürün görselleştirme bulut rendering rehberimiz bu zemini kapsamaktadır. Özellikle compositing aşaması için Nuke bulut rendering rehberimiz ve After Effects bulut rendering kurulum rehberimiz, bu makalenin bilinçli olarak genel bıraktığı uygulamaya özgü mekanikleri (lisanslama, gönderim bayrakları, plugin matrisleri) ele almaktadır. After Effects tarafında, After Effects cloud render farm sayfamız desteklenen iş akışını ve fiyatlandırmayı doğrudan ele almaktadır.

Çoğu VFX compositing pipeline'ının temelini oluşturan dosya formatı için kanonik bir referans olarak, OpenEXR projesi çoğu comp render'ın okuduğu ve yazdığı çok kanallı, çok parçalı formatı belgelemektedir ve Cryptomatte spesifikasyonu ID-matte verisinin bu dosyalara nasıl kodlandığını belgelemektedir.

SSS

Q: Bir bulut farm'da compositing rendering, 3D rendering ile aynı şey midir? A: Hayır. Bir 3D render, bir görüntü yakınsayana kadar ışık taşınımı yapar, örnekleme ve ışın izleme gerçekleştirir ve bu iş piksel başına gerçekten hesaplama yoğundur. Bir compositing render, zaten var olan görüntü verisi (footage, render pass'leri) üzerinde bir node graph'ı değerlendirir ve örneklemeden çok CPU threading, bellek kapasitesi ve depolama I/O tarafından domine edilir. İki iş yükü farm donanımını paylaşır, ancak farklı darboğazlara ve farklı hata modlarına sahiptir.

Q: Compositing neden 3D rendering'den daha fazla I/O'ya bağımlıdır? A: Bir comp, tipik olarak kare başına bir veya daha fazla çok katmanlı, çok pass'li EXR dosyası okur ve bir dosyanın taşıdığı her kanalı (beauty, AOV, cryptomatte matte'leri, depth) çeker; node graph'ı değerlendirirken bu tam çözünürlüklü karelerin birkaçını aynı anda bellekte tutar. Bu okuma hacmi, composite edilmiş karenin geri yazılmasıyla birleştiğinde, tipik bir comp'taki node'ların büyük çoğunluğu için depolama verimini ve RAM kapasitesini, ham hesaplama hızından daha büyük bir faktör hâline getirir.

Q: Bir compositing render farm'ın GPU node'larına ihtiyacı var mıdır? A: Çoğu comp için hayır. Compositing işlemlerinin büyük çoğunluğu (merge'ler, grade'ler, keyer'lar, transform'lar, çoğu filtre) CPU üzerinde çalışır. Belirli, daha küçük bir node türü grubu (ağır retime'lar, bazı denoise işlemleri, makine öğrenmesi araçları) GPU hızlandırmalıdır ve bu node'lara ağırlıklı olarak dayanan comp'lar GPU kapasitesinden faydalanır. Tipik olarak merge ve grade ağırlıklı bir comp için CPU çekirdekleri ve RAM, GPU katmanından daha önemlidir.

Q: Cryptomatte nedir ve bulut compositing için neden önemlidir? A: Cryptomatte, bir 3D render tarafından yazılan ve bir compositor'ün 3D sahneyi yeniden render almadan, sonradan tekil nesneleri, malzemeleri veya asset örneklerini izole etmesini sağlayan, prosedürel olarak üretilmiş ID-matte verisidir. Bir bulut compositing işi için cryptomatte verisi, comp render'ın ürettiği bir şey değil, comp'ın okuduğu bir girdidir; cryptomatte ağırlıklı comp'lar kare başına daha fazla kanal okur, bu da render node'undaki I/O ve bellek yükünü artırır.

Q: Nuke ve After Effects comp'ları aynı bulut farm'da render alabilir mi? A: Evet, her iki uygulamayı da destekleyen bir farm'da; ancak dağıtım modeli biraz farklıdır. Nuke comp'ları tasarım gereği neredeyse her zaman kareye göre paraleldir (her kare tamamen kendi kendine yeterlidir). After Effects comp'ları çoğu prodüksiyon durumunda kareye göre paraleldir, ancak belirli motion blur veya particle-simülasyon kurulumları gibi kareler arasında zamansal duruma bağlı composition'lar, dikişleri önlemek için kare aralığı dağıtımı yerine tek worker'lı render'a ihtiyaç duyar. Nuke ve After Effects rehberlerimiz uygulamaya özgü mekanikleri ele almaktadır.

Q: Bir compositing işini yerel olarak render almak yerine bir bulut farm'a göndermek ne zaman mantıklıdır? A: Bulut compositing en çok son tarihe dayalı yoğun yüklerde, aksi hâlde bir sanatçının iş istasyonunu meşgul edecek gece boyu toplu işlerde ve büyük veya kare başına ağır sekanslarda (deep compositing, 4K ve üzeri çok kanallı EXR, cryptomatte ağırlıklı comp'lar) değer kazandırır. Son tarih baskısı olmayan, yerel render süresinin zaten kendi kendine yeterli bir proje paketini yükleme için hazırlamaktan daha kısa olduğu bir avuç kısa, basit comp'ta ise en az değer kazandırır.

Q: Compositing rendering bir bulut farm'da nasıl faturalandırılır? A: Farmımızda CPU hesaplaması (çoğu compositing işi için maliyeti belirleyen unsur) GHz-saat başına, GHz-saat başına 0,004 dolarlık bir baz oranla faturalandırılır; öncelik katmanları GHz-saat başına 0,016 dolara kadar çıkar. GPU hızlandırmalı node'lar, OBh başına 0,003 dolarlık bir baz oranla ayrıca faturalandırılır. Maliyet, gerçek saatlik süreyi değil, tüketilen toplam hesaplamayı izler; dolayısıyla bir işi daha hızlı bitirmek için daha fazla worker'a dağıtmak, tek başına toplam maliyeti değiştirmez.

Q: Bir compositing render farm tipik olarak hangi dosya formatlarını işler? A: Çok katmanlı, çok parçalı OpenEXR, VFX pipeline girdi ve çıktısı için standarttır; beauty pass'lerini, AOV'leri, cryptomatte matte'lerini ve depth verisini 16-bit half-float'ta (tam hassasiyet gerektiren veri pass'leri için 32-bit) taşır. Nihai teslimat bir görüntü sekansı yerine bir video dosyası (H.264, HEVC, ProRes) olduğunda, bu encode tipik olarak karesel comp render'dan sonra ayrı bir pass olarak çalışır; çünkü video codec'leri genellikle bağımsız bir görüntü sekansı gibi worker'lar arasında bölünemez. H.264 ve H.265 rehberimiz bu son encode adımını ele almaktadır.