Bulut render için Houdini'yi yapılandırın

Farm'ımızdaki Houdini, modern USD öncelikli iş akışı üzerine kurulu çok renderer'lı bir ortamdır. Karma XPU, Houdini 20.5'teki yeni projeler için SideFX tarafından önerilen yoldur ve açılış sayfamızdaki birincil tercihedir. Karma CPU ve Mantra, eski çalışmalar için kullanılabilir olmayı sürdürür; üçüncü taraf renderer'lar — Redshift, Arnold, Houdini için V-Ray, Octane — köklü iş akışlarına sahip stüdyolar için desteklenmektedir. Bu sayfa; proje paketleme (Houdini'de bu yalnızca dokular değil HDA'lar ve simülasyon önbellekleri anlamına gelir), Solaris/USD varlık iş akışı, renderer başına notlar, gönderim akışı ve destek taleplerinde en sık gördüğümüz Houdini'ye özgü sorun giderme konularını kapsar.

Başlamadan önce lisanslama hakkında bir not: Houdini kurulumlarını farm'da yalnızca render kullanımı kapsamında işletiyoruz; bu, müşteri projelerinin çevrimdışı rendering için render worker'larında Houdini çalıştırılmasına izin verir. Super Renders Farm, SideFX iş ortağı değildir — yalnızca render kullanımı, stüdyonuzun lisans havuzundan SideFX lisans hakkı kullanmadan Houdini sahnelerinin farm rendering'ini mümkün kılan yasal çerçevedir. Houdini lisansınızı bize aktarmazsınız; sanatçı tarafındaki proje katmanı meta verisi (Indie, Core, FX), worker'ın lisans düzenlemesini belirlemez. Worker, kendi tarafında farm'ın lisansından yararlanır.

Genel konumlandırma için — desteklenen Houdini sürümleri, donanım uygunluğu, fiyatlandırma örnekleri — adresindeki özel açılış sayfası yetkili referanstır. Okuduğunuz bu sayfa iş akışı belgesidir: Gönder'e tıklamadan önce Houdini'de yapılması gerekenler.

Desteklenen sürümler

Farm'daki her worker'a Houdini 19.5, 20.0 ve 20.5 önceden kurulmuştur. SideFX yayın takvimine göre ilerler ve yeni büyük derlemeleri kamuya duyurulmasından dört hafta içinde temin ederiz. Nokta sürümleri (ör. Houdini 20.5.410 ile 20.5.487) sürekli olarak takip edilir; projeniz bir düğüm uyumluluk sorunu nedeniyle belirli bir derleme numarasına kilitliyse, gönderimde iş notlarında derlemeyi belirtin; worker'ı bununla eşleştiririz.

Hem Houdini FX (üretim katmanı) hem de Houdini Indie sahne dosyaları (.hip ve .hipnc), farm'ın yalnızca render kullanımı düzenlemesi kapsamında worker'a yüklenir ve render edilir. Sanatçı tarafındaki katman (Indie veya Core/FX), worker'ın lisans hakkına yansımaz — worker, rendering için farm'ın sağladığı katmanı kullanır. Houdini Apprentice dosyaları render edilir; ancak SideFX'in ticari olmayan lisans koşulları uyarınca filigran içeren çıktı üretir — ücretli üretim çalışmaları için göndermeden önce ticari olmayan Apprentice dışı bir lisansla sahneyi kaydedin. Eğitim lisansları da aynı kurala tabidir.

Houdini yayın döngüsü hakkında bir not: SideFX, 12–18 ayda bir büyük sürüm ve daha sık nokta güncellemeleri yayımlar. Karma XPU özellikle 19.5, 20.0 ve 20.5 arasında önemli ölçüde iyileşti — 19.5'te CPU'ya geri düşülen bazı özellikler (ağır hacimler, belirli shader ağları) 20.5'te XPU yerel desteğine kavuştu. Projeniz belirli bir derlemede yayımlanan Karma XPU özelliğine bağlıysa, worker'ın mevcut en son sürümü almasına izin vermek yerine derlemeyi iş notlarında kilitleyin.

Houdini projenizi paketleme

Bir Houdini projesi, .hip (veya .hipnc) sahne dosyasından daha fazlasını içerir. Genellikle şunları da kapsar: HDA'lar (Houdini Digital Assets — .hda veya daha eski .otl biçimi), simülasyon önbellek dosyaları (.bgeo, .bgeo.sc, .vdb, .abc), USD varlık katmanları ve referansları (.usd, .usda, .usdc), doku haritaları ve File veya Alembic SOP'larından içe aktarılan herhangi bir harici geometri. Bulut rendering, sahnenin başvurduğu her bağımlılık worker'da mevcut olduğunda başarılı olur; yalnızca iş istasyonuna özgü bir yol üzerinden yerel olarak çözülen bir şey farm'da çözüleceği bir yol bulamadığında başarısız olur.

Houdini'nin yol kuralları ortam değişkenleri üzerine inşaşmıştır — en yaygın olarak $HIP (.hip dosyasını içeren dizini çözer), $HIPNAME (sahne dosyası temel adı) ve $JOB (ortam değişkeni aracılığıyla ayarlanan proje kökü). Bulut rendering için güvenilir kural, her yerde $HIP'e göreli yollar kullanmaktır. Aşağıdaki paketleme adımları bu kuralı baştan sona uygular:

1. Proje klasörünü ayarlayın. Yeni bir proje kaydettiğinizde Houdini, $HIP'i .hip dosyasını içeren dizine ayarlar. Python kabuğunda hou.text.expandString('$HIP') ile doğrulayın — yol, sahne dosyanızın bulunduğu yerle eşleşmelidir.
2. Standart alt klasör yapısını kullanın. Simülasyonlar için $HIP/cache/, Alembic ve harici geometri için $HIP/geo/, dokular için $HIP/tex/, dijital varlıklar için $HIP/hda/, USD katmanları ve referansları için $HIP/usd/, çıktı için $HIP/render/. Sahnenizdeki File SOP'larındaki, File COP'larındaki, ROP çıktılarındaki ve doku referanslarındaki tüm yollar, mutlak sürücü harfi yolları yerine $HIP/... kullanmalıdır.
3. Yolların çözüldüğünü doğrulayın. File → Refresh All. Houdini, Konsolda çözümsüz dosya referanslarını raporlar. Python kabuğundan hou.fileReferences(), harici referansların tam listesini döndürür — D:\, Y:\, \\server\ gibi UNC paylaşımı veya worker'ın ulaşamayacağı herhangi bir yolla başlayan referanslar için tarama yapın.
4. Simülasyonları diske pişirin. Farm, render işinin bir parçası olarak simülasyon çalıştırmaz — simülasyonlar iş istasyonu işidir ve farm önceden pişirilmiş önbellek dosyalarına göre render eder. Tüm DOP ağlarını (FLIP sıvıları, Pyro, Vellum kumaş, RBD Bullet, granüller), parçacık çözücüleri ve diğer simülasyon çıktılarını göndermeden önce $HIP/cache/ içinde .bgeo.sc veya .vdb dosyalarına pişirin. "Save to Disk" ile File Cache SOP standart iş akışıdır.
5. HDA'ları gömün veya ekleyin. Sahneniz bir stüdyo kitaplığından özel HDA'lar kullanıyorsa, bunları ya .hip'e gömün (Varlık menüsü → Save Operator Type → "Embedded") ya da worker'ın bunları proje klasöründen yükleyebilmesi için .hda/.otl dosyalarını $HIP/hda/ içine ekleyin. Ağ sürücülerindeki stüdyo paylaşımlı HDA kitaplıkları worker'dan erişilemez.
6. USD katmanlarını düzeltin veya paketleyin. Sahneniz Solaris/LOP'lar kullanıyorsa, ya göndermeden önce USD aşamasını USD ROP aracılığıyla tek bir birleştirilmiş USD dosyasına pişirin, ya da $HIP/usd/ dizin ağacını tam olarak ekleyin; böylece her katman worker'da çözülür. USD varlık çözümleme kuralları sonraki bölümde ayrıntılı ele alınmaktadır.
7. Tüm $HIP klasörünü arşivleyin. .tar, .tar.gz veya .7z kullanın. Houdini projeleri için .zip yüklemelerini kabul etmiyoruz (Houdini'nin dosya adı kuralları zaman zaman Linux worker'larındaki Windows .zip arşivlerini bozan karakterler içerebilir).

Yaygın bir Houdini'ye özgü tuzak: ROP düğümlerindeki "Pre-Render Script" ve "Post-Render Script" alanları zaman zaman iş istasyonuna özgü Python scriptlerine başvurur — stüdyonuzun iş akışı araçları, yerel Houdini yapılandırma yolu, worker'ın görüntülenecek ekranının olmadığı bir iletişim kutusu açan hou.ui.displayMessage çağrısı. Bulut render ya sessizce başarısız olur ya da hiç gelmeyecek bir girdi bekleyerek takılır. Göndermeden önce render öncesi Python veya HScript geri çağrımlarını denetleyin; yerel yollara, kullanıcı arayüzü çağrılarına veya iş istasyonu ikili programlarına hou.system() ile çıkış yapan kodları devre dışı bırakın veya yol taşınabilir hale getirin. Etkileşimli geri çağrımlar yerine print() günlüğünü tercih edin.

Solaris, USD katmanları ve varlık çözümleme

Sahneniz Solaris'te oluşturulmuşsa (/stage LOP'lar ağı), USD varlık çözümleme katmanı bulut gönderimize yalnızca OBJ/SOP'lara özgü sahnelerde bulunmayan ek bir boyut katar. Houdini'nin USD çözücüsü standart USD varlık çözümleme kurallarına uyar: bir katmandaki referanslar, katmanın tanımlayıcı yoluna, houdini.env veya varlık çözücü eklentisi aracılığıyla yapılandırılan arama yollarına ve aşamanın kullandığı herhangi bir birleşim ark'ına (referanslar, alt katmanlar, yükler) göre çözülür.

Bulut gönderimi için iki kalıp güvenilir biçimde çalışır:

• Aşamayı düzeltin. "Flatten Stage" seçeneği etkinleştirilmiş USD ROP düğümünü "Save to Disk" ile kullanın. Sonuç, tüm referansları çözülmüş, tüm aşamayı içeren tek bir birleştirilmiş .usd (veya ikili için .usdc) dosyasıdır. Bu en basit kalıptır — worker tek bir dosya okur, çözümleyici yönlendirmesi yoktur — ancak USD'yi işbirliği için değerli kılan katmanlı yapıyı kaybedersiniz.
• Tam varlık ağacını paketleyin. Tüm USD katmanlarını $HIP/usd/ altına yerleştirin ve alt katmanlarınızda, referanslarınızda ve yüklerinizde $HIP'e göreli referanslar kullanın. Worker, $HIP'i yükleme köküne çözer; böylece aynı göreli konumdaki katman dosyaları doğru yüklenir.

Küçük bir nüans: Solaris'in "Asset Reference" LOP'u ve /obj bağlamındaki Reference SOP, referans yolunu yazıldığı gibi seri hale getirir. Bir Reference LOP'una D:\studio_assets\char_robot.usd yazdıysanız, worker'ın D:\ yoktur ve referans başarısız olur. Referansı $HIP/usd/char_robot.usd olarak yeniden oluşturun (veya farm'ın onurlandırdığı belgelenmiş bir ortam değişkeni eşlemesiyle ${SRF_ASSETS}/char_robot.usd). Yol ne kadar basit olursa, o kadar güvenilir biçimde taşınır.

İkinci bir nüans: USD varlık kitaplıkları kendi sürüm yönlendirmelerini taşıyabilir. USD 23.x'e göre derlenmiş USD varlıklarına başvuran bir Solaris aşaması, eski bir Houdini derlemesine paketlenmiş USD 22.x çalıştıran bir worker'da düzgün yüklenmeyebilir. Houdini ve USD sürüm matrisi önemlidir — varlık kitaplığınız Houdini 20.5'in USD sürümü için oluşturulduysa Houdini 20.5 worker'larında render edin.

HDA yönetimi

Houdini Digital Assets (HDA'lar, zaman zaman eski .otl uzantısıyla da görülür), bağımsız varlık dosyaları olarak paketlenmiş yeniden kullanılabilir düğüm ağlarıdır. Üretim iş akışlarında, özellikle tek çekimlerden bağımsız olarak oluşturulan ve sahneler arasında paylaşılan prosedürel varlıklar için yaygındır — binalar, bitkiler, kalabalık sistemleri, özel çözücüler.

Farm'da HDA yönetimi için üç kalıp:

• HDA'yı .hip dosyasına gömün. Varlık menüsü → Operator Type Manager → HDA'ya sağ tıklayın → "Save to Embedded." HDA artık .hip içinde saklanır ve sahneyle birlikte taşınır. Bu, tek seferlik işler veya özellikle tek bir çekim için oluşturduğunuz HDA'lar için en güvenli kalıptır.
• HDA'ları $HIP/hda/ içinde paketleyin. Tüm .hda/.otl dosyalarını projenizin bir alt klasörüne yerleştirin, ardından Houdini → Edit → Preferences → File Locations'da $HIP/hda/'nın OTL arama yolunun bir parçası olduğundan emin olun (alternatif olarak, houdini.env dosyanızda HOUDINI_OTLSCAN_PATH'i $HIP/hda/'yı içerecek şekilde ayarlayın). Worker, sahneyi yüklerken HDA'ları bu konumdan okur.
• HDA'lara bir stüdyo paylaşımlı kitaplığından başvurun. Stüdyonuz ağ sürücüsünde paylaşımlı bir HDA kitaplığı kullanıyorsa (ör. \\studio-fs\houdini\hda\), bu kitaplık worker'dan erişilemez. Göndermeden önce ilgili HDA'ları $HIP/hda/ içine kopyalayın ya da .hip'e gömün.

Göndermeden önce sahnedeki yüklenmiş HDA'ları Python kabuğundan listeleyin:

for hda in hou.hda.loadedFiles():
    print(hda)

Çıktıdaki her yol ya $HIP altında çözülmeli ya da Houdini ile birlikte gelen standart SideFX HDA'sı olmalıdır (bunlar her worker'a önceden kurulmuştur). $HIP dışında bulunan üçüncü taraf HDA'lar bulunamaz.

Önbellek dosyası yönetimi

Önbellek dosyaları genellikle bir Houdini projesi yüklemesindeki en büyük tek kategoridir — FLIP simülasyonları, Pyro önbellekleri, Vellum kumaş pişirmeleri, Alembic dışa aktarımları ve VDB hacimleri her biri onlarca veya yüzlerce gigabayta ulaşabilir. İki kalıp, render'dan ödün vermeden yükleme süresini azaltır:

• Pişirme zamanında önbellekleri sıkıştırın. .bgeo.sc (sıkıştırılmış bgeo, blosc sıkıştırmalı), aynı geometri için .bgeo'dan önemli ölçüde daha küçüktür ve File Cache SOP'larının modern varsayılanıdır. VDB dosyaları için hacim zaten OpenVDB kapsayıcısının içinde sıkıştırılmıştır; ancak .tar.gz arşivleri çevredeki dizin meta verilerini iyi sıkıştırır.
• $HIP/cache/ kullanımını tutarlı tutun. Houdini'nin File Cache SOP'u varsayılan olarak $HIP/cache/{node_name}/$F4.bgeo.sc'ye ayarlanır; bu, farm taşınabilir sahneler için doğru kalıptır. D:\sim_cache\ gibi mutlak önbellek yollarından kaçının — worker'ın D:\ yoktur ve render başlar, "önbellek dosyası bulunamadı" uyarıları kaydeder ve simülasyonun olması gereken yerde boş geometri üretir.

Çok büyük simülasyonlar için — tarayıcı yüklemesini aşan çok terabaytlık FLIP veya Pyro önbellekleri — web yükleme formu yerine SFTP kullanın. belgesi, SFTP iş akışını, arşiv kesilebilirliğini ve web yüklemesinden SFTP'ye geçiş için pratik eşikleri kapsar.

Göndermeden önce neleri doğrulayacaksınız

Herhangi bir Houdini gönderimi için kısa bir ön kontrol listesi:

• Etkin ROP düğümü doğru ayarlanmış olmalıdır. Çıktı bağlamı → Render. Gönderim zamanında seçtiğiniz ROP, worker'ın hangi renderer'ı çağıracağını belirler. Eşleşmeyen ROP'lar (ör. aydınlatması Mantra için oluşturulmuş bir sahne için Karma ROP seçmek), "render tamamen farklı görünüyor" taleplerinin en yaygın nedenidir.
• Kare aralığı ROP ayarlarıyla eşleşmelidir. ROP'ta saklanan kare aralığı (f1, f2, f3 parametreleri), worker'ın kullandığı şeydir; zaman çizelgesinin oynatma aralığı veya görüntü alanının mevcut karesi değil. ROP'un kare aralığının render etmek istediğinizle eşleştiğini onaylayın.
• Çıktı yolu $HIP'e göreli belirteçler kullanmalıdır. $HIP/render/$F4.exr, dört haneli dolgu içeren çok katmanlı EXR için güvenli varsayılandır. ROP çıktı ifadesinde mutlak sürücü harfi yollarından kaçının.
• Tüm File SOP'lar ve doku referansları çözülmelidir. File → Refresh All. Göndermeden önce Konsolda "Unable to read" hatalarını düzeltin — worker da bunları bildirir; ancak israf edilen bir render karesi pahasına.
• HDA'lar ya gömülü ya da $HIP/hda/ içinde olmalıdır. Sahneyi tamamen kapatıp farklı bir Houdini oturumundan yeniden açarak doğrulayın; HDA'lar yerel olarak yüklenmezse worker da yükleyemez.
• Önbellekler pişirilmiş olmalıdır. Göndermeden önce her File Cache SOP'ta manuel önbellek pişirmesi çalıştırın: Render → Save to Disk. "Auto-Bake on Frame Change"e güvenmeyin — açıkça pişirin ve önbellek dosyalarının beklenen $HIP/cache/... yollarında mevcut olduğunu onaylayın.
• USD katmanları (Solaris ise) paketlenmiş veya düzeltilmiş olmalıdır. Ya tam $HIP/usd/ ağacını ekleyin ya da USD ROP aracılığıyla düzeltilmiş bir birleştirilmiş USD yazın.
• Etkileşimli render öncesi veya sonrası script yok. ROP Python geri çağrımlarını ve Pre-Frame Script'leri herhangi bir kullanıcı arayüzü çağrısı, dışa çıkış veya iş istasyonuna özgü yollar için denetleyin.

Renderer'a özgü notlar

Karma XPU (önerilen)

Karma XPU, SideFX'in hibrit CPU+GPU renderer'ıdır; Houdini 20.5'te üretime hazır statüsüne yükseltilmiş ve yeni Houdini projeleri için ileriye dönük varsayılan yoldur. Houdini açılış sayfamızdaki birincil renderer'dır ve farm'daki yeni müşterilerin büyük çoğunluğunun benimsediği yoldur.

Yapılandırma notları:

• Worker katmanı: Render'ın GPU kısmı için RTX 5090 GPU worker katmanımızda (kart başına 32 GB VRAM) çalışır; XPU kod yolunun henüz desteklemediği özellikler için CPU'ya geri dönüşle.
• VRAM kısıtlamaları: Worker başına 32 GB VRAM. Karma XPU, saf GPU renderer'larından daha VRAM verimlidir; render'ın bölümlerini (özellikle hacimsel) VRAM kısıtlı olduğunda CPU belleğine aktarabilir — ancak çok yoğun USD sahneleri ve yüksek çözünürlüklü hacimler 32 GB zarfında kalmaktan yine de yararlanır.
• USD iş akışı entegrasyonu. Karma, Solaris USD tabanlı iş akışı için tasarlanmış renderer'dır. Projeniz /stage (Solaris LOP'lar bağlamı) kullanıyorsa Karma doğal renderer tercihidir ve worker, USD varlık referanslarını File SOP referanslarıyla aynı şekilde çözer — $HIP'e göreli yollar kazanır.
• AOV'lar. USD aşamasındaki Render Settings prim'inde render ürünü başına yapılandırılır. Çok kanallı EXR, varsayılan çıktı biçimidir ve VFX iş akışları için önerdiğimiz biçimdir (kare başına tek dosyada tüm AOV'ları korur).
• Örnekleme. Karma'nın path-tracing örnekleri, Render Settings prim başına yapılandırılır. Sekans göndermeden önce tek karede yerel olarak kalibre edin — XPU örnek yakınsaması CPU'dan farklıdır ve kalibrasyon worker'a doğrudan yansır.
• Hareket bulanıklığı. Karma XPU, geometri hareket bulanıklığı ve perde penceresi bulanıklığını destekler. USD kamera prim'indeki hareket bulanıklığı perde ayarınızın Render Settings prim'inin beklediğiyle eşleştiğini onaylayın — Solaris perde yönetimi ve Karma hareket bulanıklığı örneklemesi her zaman ilk ilkelerde anlaşamayabilir ve belirti "render iyi görünüyor ancak hareket bulanıklığı eksik veya iki katına çıkmış."

Karma CPU

Karma CPU, Karma'nın saf CPU varyantıdır. Houdini 19'dan beri özellik açısından eksiksiz ve kararlıdır; GPU VRAM'ini aşan sahneler veya XPU kod yolunda henüz uygulanmayan özelliklere dayanan sahneler için doğal geri dönüştür.

Yapılandırma notları:

• Worker katmanı: CPU worker katmanı (Dual Intel Xeon E5-2699 V4 düğümleri, düğüm başına 96–256 GB RAM, filoda 20.000'den fazla toplam CPU çekirdeği).
• Karma XPU yerine ne zaman kullanılır: Çok ağır geometri (>50M poligon), 32 GB VRAM'i zorlayan yoğun hacimsel rendering, henüz XPU eşdeğeri olmayan OSL özel shader'lar veya aynı gönderimde CPU ağırlıklı simülasyon geçişlerini karıştıran projeler.
• Karma XPU ile aynı Solaris/USD entegrasyonu. Render ürünü ve AOV yapılandırması aynıdır; yalnızca hesaplama arka ucu farklıdır.

Mantra (eski)

Mantra, Houdini'nin Karma öncesi renderer'ıdır — USD öncelikli iş akışından önce gelen SideFX'in mikropoligon motorudur. SideFX, Mantra'nın ileriye dönük yol olmadığını; Karma'nın olduğunu belirtmiştir. Mantra, Karma geçerli olmadan önce oluşturulmuş projelerin geriye dönük uyumluluğu için Houdini derlemesinde kalmaya devam eder.

Yapılandırma notları:

• Worker katmanı: CPU worker katmanı.
• Performans. Mantra, eşdeğer sahneler için genellikle Karma CPU'dan kare başına daha yavaştır ve Karma XPU'nun sağladığı GPU hızlandırma yolundan yoksundur. Yeni projeler Karma kullanmalıdır.
• Ne zaman kullanılır. Proje dosyanız Mantra'ya kilitliyse (Karma geçerli olmadan önce başlayan uzun soluklu bir üretim veya taşınmamış shader kitaplığı) ya da Mantra'ya özgü bir özelliğe ihtiyaç duyduğunuzda (bazı Mantra mikropoligon kenar durumlarının henüz tam Karma eşdeğeri yoktur). 2026'daki yeni çalışmalar için Karma'yı varsayılan olarak alın.

Houdini için Redshift

Houdini için Redshift, RTX 5090 GPU worker katmanımızda çalışır. Redshift, köklü Redshift iş akışlarına sahip stüdyolar için tercih edilir — genellikle DCC'ler arasında shader kitaplıklarını paylaşmak isteyen, FX için Houdini'ye geçen Maya veya Cinema 4D stüdyoları.

Yapılandırma notları:

• Lisans çerçevesi. Farm'ımızdaki Redshift, lisansımız kapsamında çalışır. Redshift artık bir Maxon ürünüdür ve Maxon iş ortaklığımız desteklediğimiz tüm DCC'lerde Redshift'i kapsar (C4D, Houdini, Maya).
• Out-of-core bellek. Varsayılan olarak etkindir. Worker başına 32 GB VRAM tavanının ötesine geçen sahneler için etkin sahne belleğini genişletir; aksi hâlde GPU'da yetersiz bellek hatası verecek yoğun sahneler için önemlidir.
• Houdini'ye özgü özellikler. Redshift, Houdini'nin hacim primitive türleriyle (VDB, Pyro önbellekleri) doğrudan entegre olur — hacimsel rendering için özel dışa aktarma adımı gerekmez. Redshift ROP, ışın sapması, örnekleme ve AOV yapılandırması için Houdini yerel parametrelerini sunar.
• Sürüm sabitleme. Redshift, Houdini'nin yayın döngüsünden bağımsız kendi 3.x döngüsünde yayımlanır. Büyük Redshift sürümleri (3.0 → 3.5 → çıktığında 4.0) geriye dönük uyumlu olmayabilir — Redshift 3.5.18 ile kaydedilen bir sahne, Redshift 3.0.x çalıştıran bir worker'a düzgün yüklenmeyebilir. Sahne kayıt zamanında Redshift derlemesini not edin ve tam sekans göndermeden önce worker uyumluluğunu onaylayın.

Houdini için Arnold

Houdini için Arnold (bazen HtoA olarak da anılır, şu anda Arnold 7.x yayın döngüsündedir) CPU worker katmanımızda çalışır. Paylaşılan Maya/Houdini Arnold iş akışlarına sahip stüdyolar için tercih edilir; lookdev bir DCC'de, FX diğerinde oluşturulurken shader ve rendering katmanı birleştirilmiştir.

Yapılandırma notları:

• Lisans çerçevesi. Farm'ımızdaki Arnold, Autodesk render düğümü lisanslaması kapsamında çalışır.
• AOV'lar. Houdini'de Arnold'ın AOV sistemi, Maya'dakiyle aynı şekilde çalışır. ROP başına yapılandırın ve çok kanallı EXR'ye veya AOV başına dosyalara yazın; platformlar arası kalıp tutarlıdır.
• Sürüm sabitleme. HtoA sürümleri, Arnold'ın yayın döngüsünü izler (Houdini 19.5/20.0 için HtoA 6.x; çıktığında Houdini 20.5/21.0 için HtoA 7.x). Büyük HtoA sürüm atlamaları (6 → 7) uyumlu varsayılmamalıdır — worker'ın sahnenizin kaydedildiği minör sürüme en azından sahip olduğunu onaylayın.

Houdini için V-Ray

Houdini için V-Ray, CPU worker katmanımızda çalışır. Houdini'deki benimseme, 3ds Max veya Maya'ya kıyasla belirgin biçimde daha düşüktür; ancak entegrasyon, V-Ray merkezli iş akışlarına sahip stüdyolar için desteklenmektedir.

Yapılandırma notları:

• Lisans çerçevesi. Farm'ımızdaki V-Ray, lisansımız kapsamında çalışır.
• VRayProxy varlıkları. Desteklenmektedir. .vrmesh dosyalarını worker'ın çözebilmesi için $HIP/geo/ içine ekleyin.
• Houdini özellikleri. Houdini için V-Ray'ın ROP'u, 3ds Max'teki V-Ray ile aynı render ayarlarını sunar — örnekleyici türü, render elementleri (AOV'lar), çıktı biçimi. Platformlar arası parametre eşlemesi, Chaos'un Houdini için V-Ray referansında belgelenmiştir.

Houdini için Octane

Houdini için Octane, RTX 5090 GPU worker katmanımızda çalışır. Stilize çıktı için Houdini ve Cinema 4D arasında köprü kuran hareket tasarımı stüdyolarında kullanılır.

Yapılandırma notları:

• Lisans çerçevesi. Otoy render düğümü lisanslaması.
• VRAM kısıtlamaları. C4D için Octane ile aynı — worker başına 32 GB VRAM, out-of-core yol olmaksızın Redshift'ten daha agresif bellek profili. Redshift'in 24 GB'ına sığan sahneler, Octane'de 32 GB'a sığmak için doku alt örneklemesi veya geometri azaltımı gerektirebilir.

Gönderim akışı

Farm'da Houdini projeleri için üç gönderim kanalı işe yarar:

• Web yükleme ve pano üzerinden gönderim. $HIP klasörünü .tar.gz veya .7z olarak arşivleyin, web sitesi aracılığıyla yükleyin, ardından işi (renderer, ROP düğümü, kare aralığı, çıktı biçimi) yapılandırın ve gönderin. Bu, tek seferlik Houdini işleri ve toplam yükleme boyutu yaklaşık 50 GB altındaki projeler için en yaygın yoldur.
• Büyük projeler için SFTP. Çok terabaytlık simülasyon önbelleğe sahip Houdini projeleri, kesilebilir aktarımlar için SFTP üzerinden gönderilmelidir. belgesi, SFTP iş akışını, kimlik bilgilerini ve web yüklemesinden SFTP'ye geçiş eşiğini kapsar.
• Client App. Super Renders Farm Client App, yükleme, gönderim ve otomatik indirmeyi masaüstü uygulamasında bir araya getirir. Aynı proje yapısının parametre değişiklikleriyle yeniden render edildiği tekrarlayan gönderimleri olan stüdyolar için kullanışlıdır. adresine bakınız.

Houdini kullanıcı arayüzüyle doğrudan entegre olan bir Houdini gönderim eklentisi geliştirme aşamasındadır; ancak henüz tüm worker'lara önceden kurulmamıştır. Şimdilik web panosu gönderim akışı önerilen yoldur. Platformlar arası gönderim kılavuzu — neyi dolduracağınız, kare aralığını nasıl ayarlayacağınız, çıktı dosyalarını nerede bulacağınız — adresindedir.

Arka planda worker, Houdini'nin toplu rendering giriş noktalarını çağırır: OBJ/SOP bağlamı ROP'larına (Mantra, Karma CPU, Redshift, Arnold, V-Ray, Octane) HIP dosyası gönderimlerinde hbatch ve Karma'ya (CPU veya XPU) USD aşama gönderimlerinde husk. Temel çağrıyı genellikle bilmeniz gerekmez; ancak beklenmedik çıktı adlandırmasını veya kare aralığı davranışını hata ayıklıyorsanız, ROP düzeyindeki ayarlar worker'ın komut satırı bayrakları aracılığıyla hbatch/husk'a aktardığı şeylerdir.

Houdini'ye özgü sorunları giderme

Genel platformlar arası sorun giderme (eksik varlık, N. karede render başarısız, yaygın çıktı biçimi sorunları) için adresine bakınız. Destek taleplerinde en sık gördüğümüz Houdini'ye özgü hata kalıpları:

• "HDA bulunamadı" veya HDA eski düğüm yer tutucusuyla yüklenemiyor. Worker, sahnenin başvurduğu HDA dosyasını bulamaz. HDA'ların ya .hip'e gömülü (Varlık menüsü → Operator Type Manager → "Save to Embedded") ya da arama yolu yapılandırılmış şekilde $HIP/hda/ içinde mevcut olduğunu doğrulayın. Stüdyo paylaşımlı kitaplığından HDA'lara başvuruyorsanız, göndermeden önce bunları proje klasörüne kopyalayın.
• Render'da önbellek dosyası bulunamadı / boş simülasyon geometrisi. Göndermeden önce önbellek dosyalarının gerçekten diske pişirildiğini doğrulayın — her File Cache SOP'u açın ve "Output" sekmesinin görüntülenen yolda dosyaları gösterdiğini onaylayın. Yol mutlak sürücü harfi kullanıyorsa (D:\sim_cache\flip.0001.bgeo.sc), $HIP/cache/{node_name}/$F4.bgeo.sc olarak değiştirin ve yeniden pişirin. Yüklemeden önce 60 saniyelik kontrol — File → Refresh All, ayrıca File Cache SOP'larının manuel taraması — gördüğümüz Houdini render hatalarının en büyük tek kategorisini önler.
• Render çıktıları tamamen boş / siyah kareler. ROP'un "Render Settings" prim'ini (Solaris aşamasında Karma için) veya kamera referansını (OBJ bağlamı ROP'larında Mantra, Redshift, Arnold, V-Ray, Octane için) kontrol edin. En yaygın neden, görüntü alanında ayarlanmış ancak ROP'ta başvurulmayan bir kameradır — worker'ın görüntü alanı yoktur, bu nedenle ROP düzeyindeki kamera referansı yetkilidir.
• Karma XPU "OptiX kullanılamıyor" veya "GPU algılanamadı" hatası vererek hemen başarısız oluyor. GPU worker filosu doğrulanmış CUDA + OptiX sürücü kapsamına sahip olduğundan farm'ımızda nadirdir. Oluşursa, en yaygın neden güncelleme ortasındaki bir worker veya devam eden sürücü geri almasıdır; 5–10 dakika sonra yeniden gönderin veya sorun birden fazla gönderimde devam ederse destek ekibiyle iletişime geçin.
• Render öncesi Python script worker'da başarısız oluyor. Script'i devre dışı bırakın veya yol taşınabilir hale getirin. İş istasyonuna özgü modül yollarına başvuran (stüdyonuzun iş akışı araçları), kullanıcı arayüzü iletişim kutularını açan veya hou.system() aracılığıyla yerel ikili programlara çıkış yapan özel Python, başsız bir Linux worker'da çalışmaz.
• Solaris / USD varlık referansları bozuluyor. USD varlık çözücü yollarının $HIP'e göreli olması, worker'ın yükleyebileceği bir USD çözücü bağlamı kullanması veya göndermeden önce USD ROP aracılığıyla tek bir birleştirilmiş USD'ye düzeltilmesi gerekir. USD referans katmanlarındaki mutlak yollar buradaki en yaygın hata modudur.
• Eklenti sürümü uyuşmazlığı / sahne yüklenemiyor. Yerel eklenti sürümü worker'dan farklı — genellikle HtoA 6 → 7 veya Redshift 3.0 → 3.5 atlamaları. Sahne kayıt zamanında eklenti sürümünü kontrol edin (HIP dosyası başlık metni veya eklentinin ROP menüsü sürüm damgasıyla görünür) ve worker'ın en azından o minör sürüme sahip olduğunu onaylayın. Büyük sürüm atlamaları asla uyumlu varsayılmamalıdır.
• Houdini sürümü uyuşmazlığı (20.5 sahnesi, 20.0 worker'ında). HIP dosya biçimi sürüm meta verisi içerir; eski Houdini, daha yeni kaydedilmiş sahneleri açamaz. Worker'ın Houdini'sinin sahne kayıt sürümünden ≥ olduğunu onaylayın; kesinlikle gerekli değilse hedef sürümde sahneyi yeniden kaydedin.
• OpenCL simülasyonu render'da çalışmıyor. OpenCL simülasyonları pişirme zamanıdır, render zamanı değil. Göndermeden önce önbelleğe pişirin. Farm, rendering sırasında canlı OpenCL simülasyonları çalıştırmaz — bu tasarım gereğidir ve FLIP, Pyro, Vellum ve diğer tüm OpenCL hızlandırmalı çözücüler için geçerlidir.
• Gönderim ve worker arasında OCIO yapılandırması kayması. Yerel OCIO ortam değişkeniniz worker'da mevcut olmayan stüdyoya özgü bir yapılandırmaya işaret ediyorsa, renkler worker'ın varsayılan yapılandırması altında render edilir ve farklı görünür. OCIO yapılandırma dosyasını projeyle paketleyin, gönderim ortam geçersiz kılması aracılığıyla OCIO'yu ayarlayın veya worker'ın da gönderdiği Houdini'nin yerleşik ACES yapılandırmasını kullanın.
• Houdini sürümleri genelinde Pyro/FLIP önbelleği "eksik alan" uyarısı. Önbellek dosyası biçimi zaman zaman büyük Houdini sürümleri arasında değişir; daha eski bir önbellek daha yeni Houdini'ye yüklendiğinde bazen alanlar düşer. Simülasyonu hedef Houdini sürümünde yeniden önbelleğe alın veya worker'ın önbelleği yazan aynı Houdini derlemesini kullandığını onaylayın.

Çapraz referanslar

• — yükleme, gönderim, indirme iş akışı (platformlar arası)
• — Houdini iş maliyetlerinin nasıl hesaplandığı (GPU ile CPU katmanları)
• — SFTP kılavuzu, arşiv biçimleri, büyük proje aktarımları
• — platformlar arası sorun giderme
• — masaüstü gönderim sarmalayıcısı
• — açılış sayfası (renderer matrisi, donanım, fiyatlandırma örnekleri)

SSS

S: Farm hangi Houdini sürümlerini destekler? C: Her worker'a Houdini 19.5, 20.0 ve 20.5 önceden kurulmuştur. SideFX yayın takvimine göre ilerler ve yeni büyük derlemeleri kamuya duyurulmasından dört hafta içinde temin ederiz. Hem Houdini FX (.hip) hem de Houdini Indie (.hipnc) sahne dosyaları desteklenmektedir. Houdini Apprentice dosyaları render edilir; ancak SideFX'in ticari olmayan lisans koşulları uyarınca filigran içeren çıktı üretir — ücretli üretim çalışmaları için göndermeden önce Apprentice dışı bir lisansla kaydedin.

S: Farm'da render yapmak için Houdini lisansımı aktarmam gerekiyor mu? C: Hayır. Houdini'yi, stüdyonuzun lisans havuzundan SideFX lisans hakkı kullanmadan render worker'larında çevrimdışı rendering için çalıştırılmasına izin veren yalnızca render kullanımı kapsamında işletiyoruz. Yerel Houdini lisansınız sizde kalır. Super Renders Farm, SideFX iş ortağı değildir — yalnızca render kullanımı, Houdini sahnelerinin farm rendering'ini mümkün kılan yasal çerçevedir.

S: Yeni bir proje için Karma XPU, Karma CPU veya Mantra kullanmalı mıyım? C: Yeni projeler için Karma XPU — 2026'da SideFX'in önerilen ileriye dönük yoludur, RTX 5090 GPU katmanımızda çalışır ve çoğu sahne için Karma CPU veya Mantra'dan önemli ölçüde daha hızlıdır. 32 GB VRAM'i aşan, GPU'ya taşan ağır hacimsel sahneler veya XPU'da henüz desteklenmeyen OSL özel shader'lar kullanan sahneler için Karma CPU kullanın. Mantra'yı yalnızca projeniz Mantra'ya kilitliyse (Karma geçerli olmadan başlayan uzun soluklu bir üretim veya Karma eşdeğeri olmayan Mantra'ya özgü shader özelliği) kullanın. Yeni çalışmalar için Karma'yı varsayılan olarak alın.

S: Farm Houdini simülasyonları (Pyro, FLIP, Vellum, RBD) çalıştırabilir mi? C: Hayır — simülasyonlar iş istasyonu işidir. Tüm simülasyon önbelleklerini göndermeden önce yerel olarak .bgeo.sc veya .vdb dosyalarına pişirin. Farm, önceden pişirilmiş önbelleklere göre render eder; render işinin bir parçası olarak canlı simülasyon çalıştırmaz. Bu, çoğu yönetilen bulut farm'ında Blender veya Maya simülasyon iş akışlarıyla aynı kalıptır.

S: Projem Houdini'nin Solaris/USD iş akışını kullanıyor. Doğru render edilecek mi? C: Evet, Karma (CPU veya XPU) renderer olarak kullanıldığında. Solaris için tasarlanmış yol Karma'dır — her iki renderer de USD aşamasını yerel olarak tüketir ve Solaris/Karma entegrasyonu SideFX'in önerilen ileriye dönük iş akışıdır. Bulut gönderimi için ya USD aşamasını USD ROP aracılığıyla tek bir birleştirilmiş .usd dosyasına düzeltin, ya da tam $HIP/usd/ dizin ağacını paketleyin; böylece her katman worker'da çözülür. Üçüncü taraf renderer'lar (Redshift, Arnold), Houdini entegrasyonları destekliyorsa USD tabanlı sahneleri de render edebilir — tam sekans göndermeden önce yerel olarak tek bir karede doğrulayın.

S: Sahnem stüdyomuzun paylaşımlı kitaplığından özel HDA'lar kullanıyor. Farm onları bulabilecek mi? C: Farm, stüdyonuzun paylaşımlı ağ sürücüsündeki HDA'ları bulamaz (\\studio-fs\hda\... veya eşdeğeri). HDA'ları ya Varlık menüsü → Operator Type Manager → "Save to Embedded" aracılığıyla .hip'e gömün, ya da projeyi arşivlemeden önce .hda/.otl dosyalarını $HIP/hda/ içine kopyalayın. Python kabuğundan hou.hda.loadedFiles() ile her yüklenen HDA'nın $HIP altında çözüldüğünü veya standart bir SideFX varlığı olduğunu doğrulayın.

S: Simülasyon önbelleği kullanan bir Houdini projesini nasıl paketlerim? C: Her simülasyonu göndermeden önce yerel olarak $HIP/cache/{solver_name}/$F4.bgeo.sc (veya hacimler için .vdb) yoluna pişirin. Önbellek dosyalarının File → Refresh All aracılığıyla beklenen yollarda mevcut olduğunu doğrulayın. cache/ alt klasörü dahil tüm $HIP klasörünü .tar.gz veya .7z olarak arşivleyin. Birkaç yüz gigabaytın üzerindeki önbellekler için web formu yerine SFTP üzerinden yükleyin. Farm, pişirilmiş önbelleklere göre render eder; simülasyonun kendisi iş istasyonunuzda çalışır, worker düğümünde değil.

S: Houdini proje yüklemesi ne kadar büyük olabilir? C: Kesin bir yükleme boyutu sınırı yoktur; ancak tek tarayıcı yüklemesini yaklaşık 50 GB altında tutmanızı öneririz. Bunun üzerinde, kesilebilir aktarımlar için SFTP'ye geçin — bkz. . Farm, uygun dizin yapısı korunarak SFTP aracılığıyla yüklenen çok terabaytlık Houdini sim render'larını yönetmiştir.

S: Mantra render'ım farm'da yerel render'dan çok daha yavaş. Bu beklenen bir durum mu? C: CPU worker katmanımızdaki (Dual Xeon E5-2699 V4) Mantra kare başına hızı, üst düzey bir iş istasyonuyla karşılaştırılabilir. Yerel render'dan önemli ölçüde daha yavaş kare başına süreler görüyorsanız, en olası nedenler şunlardır: worker'da farklı bir örnekleme yapılandırması (Mantra örnekleri ROP'tan okur — ROP düzeyindeki ayarların eşleştiğini onaylayın) veya worker'ın yalnızca CPU katmanında etkin olmayan yerel OpenCL hızlandırması. Yapısal çözüm taşıma yapmaktır: GPU katmanımızdaki Karma XPU, çoğu sahne için Mantra'dan önemli ölçüde daha hızlıdır ve Karma, SideFX'in ileriye dönük önerdiği yoldur.

S: Farm dağıtık görev yönetimi için Houdini'nin PDG/TOPs'unu destekliyor mu? C: PDG, iş istasyonu tarafında düzenleme aracıdır; farm kendi kuyruk ve worker atama sistemini kullanır. PDG'yi yerel olarak varlıkları oluşturmak ve pişirmek için kullanabilir, ardından web panosu veya Client App aracılığıyla final ROP işlerini farm'a gönderebilirsiniz. Harici farm'lara PDG güdümlü gönderim yol haritamızdadır; ancak henüz birinci sınıf bir iş akışı değildir.

S: Houdini bulut rendering maliyeti nasıl hesaplanır? C: Farm'daki Houdini maliyeti, renderer'ın worker katmanını izler — Karma XPU, Redshift ve Octane için GPU oranları; Karma CPU, Mantra, Arnold ve Houdini için V-Ray için CPU oranları. Kare başına karmaşıklık (örnek sayısı, AOV sayısı, çıktı çözünürlüğü), kare başına maliyeti yönlendirir; renderer tercihi, düğüm saati başına oranı belirler. Simülasyonlar, yalnızca farm'da çalıştırırsanız ekstra maliyet yaratır (yerel önbelleğe alma ve önbelleği yüklemeyi öneririz). Fiyatlandırma ayrıntıları için adresine bakın veya tahmin yapın.

---