anasayfa / blog / grafik
Yayın: 5 Şubat 2026 9 dk okuma grafik
URP mi HDRP mi? Unity'de doğru render pipeline seçimi

URP mi HDRP mi? Unity'de doğru render pipeline seçimi

Hedef platform listeniz kararı zaten vermiş olabilir; HDRP'nin volumetric ve SSR faturasını, URP'nin mobildeki avantajını ve geç geçişin gerçek maliyetini ölçtüm.

Demo güzeldi, Switch derlemesi patladı

Kasım 2024'te üç kişilik bir ekiple dikey dilim çıkarıyorduk. Unity render pipeline seçimini beş dakikada yaptık: Scene view'da volumetric sis güzel göründüğü için HDRP. Hedef platform listesi o gün kimsenin açmadığı bir tablodaydı — Steam, Nintendo Switch ve olası bir Quest portu. Ekipte daha önce HDRP ile ürün çıkarmış kimse yoktu; karar tamamen bir ekran görüntüsüne dayanıyordu.

Beşinci hafta Switch derlemesini denedik. HDRP o platformda hiç build almıyor; HDRenderPipelineAsset compute shader ve DX11/Vulkan/Metal sınıfı bir API bekliyor. Quest tarafı da aynı duvara çarpıyordu. Yani sorun bir ayar değil, en baştaki seçimdi.

Geri dönüş 11 iş gününü aldı: 190 materyal, 60 ışık, iki VolumeProfile ve dört özel shader. URP mi HDRP mi sorusunun cevabı ilk gün beş dakikalık bir platform tablosuyla verilebilirdi. Ben o beş dakikayı 11 güne çevirdim, o yüzden bu yazıyı yazıyorum. O günden beri her yeni projenin ilk commit'ine bir platform tablosu koyuyorum ve pipeline satırını oraya yazıyorum.

Hedef platform listesi kararı çoktan vermiş

Artık pipeline seçimini sanat yönüyle değil, hedef cihaz tablosuyla başlatıyorum. HDRP; OpenGL ES, Nintendo Switch, Quest ve WebGL için desteklenmiyor. Bu dört satırdan biri projede varsa tartışma orada biter. Bu bir zevk meselesi değil, Unity'nin resmi destek matrisi; sürüm notlarında da aynı şekilde duruyor.

Universal Render Pipeline tarafında böyle bir kesme yok. GLES3.0 çalıştıran orta segment bir telefondan Xbox Series X'e kadar aynı UniversalRenderPipelineAsset yapısıyla çıkıyorsunuz; cihaz sınıfı başına ayrı asset tanımlayıp QualitySettings üzerinden bağlıyorsunuz. Renderer varlıklarını cihaz sınıfına göre ayırmak, tek projede hem düşük hem yüksek profili taşımayı kolaylaştırıyor. Aynı ayrımı HDRP'de de yapabilirsiniz ama alt sınır yine HDRP'nin alt sınırı olarak kalıyor.

Taban maliyeti ölçmek için basit bir test yaptım: RTX 3060, 1080p, tek yön ışığı olan boş bir sahne. URP 0.9 ms GPU, HDRP 4.3 ms. Bu 3.4 ms'yi henüz hiçbir model, hiçbir materyal koymadan ödüyorsunuz; depth prepass, motion vector, GBuffer ve hazırda bekleyen volumetric froxel ızgarası bedava değil. Ölçümü FrameTimingManager yerine RenderDoc ile aldım, çünkü editör içi rakamlar HDRP lehine yanıltıcı çıkıyordu.

Bellek tarafı da benzer. Aynı sahnede 1440p'de HDRP'nin RTHandle havuzları yaklaşık 640 MB tutuyordu, URP'de 180 MB. 8 GB'lık bir kartta bu fark doğrudan doku bütçenizden çıkıyor ve Unity grafik ayarlarını kısarak geri kazanamıyorsunuz. Aynı testte HDRP'nin shader varyant önbelleği ilk açılışta 40 saniyelik bir derleme duraklaması da getirdi.

URP mobil ve orta segment PC'de neyi kazanıyor

Aynı sahneyi iki pipeline'da kurup ölçtüm: 420 bin üçgen, 38 ışık, SSAO açık. GTX 1650'de 1080p'de URP 7.1 ms, HDRP 15.6 ms sürdü. Orta segment bir kart hedefliyorsanız bu fark 60 fps ile 45 fps arasındaki fark demek. İki ölçümde de aynı asset'leri, aynı gölge çözünürlüğünü ve aynı gölge mesafesini kullandım; aradaki fark bir ayar farkı değil.

URP 14 ile gelen Forward+ yolu, nesne başına 8 ışık sınırını kaldırdı. Artık 200'ün üzerinde nokta ışığını tek geçişte işleyebiliyorum; bunun için deferred'a geçmem veya ışık gruplarını elle bölmem gerekmiyor. Eskiden HDRP'yi haklı çıkaran gerekçelerden biri buydu, artık değil. Maliyet ışık sayısıyla değil ekrandaki kaplama alanıyla büyüdüğü için, dar açılı spot'lar neredeyse bedavaya geliyor.

Mobilde asıl kazanç bant genişliğinde. Adreno 730 üzerinde 60 fps için 16.6 ms bütçem vardı; URP'nin tek geçişli forward yolu MSAA 4x'i tile belleğinde tutuyor ve post-process'i UberPost içinde tek geçişte topluyor. Bloom ile tonemap'i ayrı geçişlere böldüğüm bir denemede sadece bant genişliğinden 2.4 ms geri geldi. Telefonda kazanılan her milisaniye aynı zamanda ısınma bütçesi; on dakikalık bir oturumda kare süresi %15 daha az kaydı.

Eksik kalan şeyleri ScriptableRendererFeature ile ekliyorum: planar yansıma, outline geçişi, özel decal. HDRP'nin hazır verdiği birkaç şeyi böyle geri kazanmak 2-3 günlük iş. HDRP'nin taban maliyetini geri kazanmanın ise bir yolu yok. Bu feature'ları ayrı bir assembly'de tutuyorum, böylece düşük profilli cihaz asset'inde hiç yüklenmiyorlar.

HDRP'de volumetric, SSR ve path tracing faturası

HDRP'yi savunan özellikler gerçek, sadece ücretli. Volumetric sis froxel tabanlı çalışıyor ve ışık başına doğru saçılma veriyor; Fog override'ında kalite Medium iken 1.3 ms, High iken 3.6 ms ölçtüm (3060, 1440p). Bu tek bir efekt için ciddi bir dilim. Sisin görünür katkısı ise sahnenin yarısı kapalı mekan olduğunda dramatik biçimde düşüyor; ödeme her karede sürüyor.

ScreenSpaceReflection 1440p'de 1.8-2.4 ms arasında geziyordu ve ekranda olmayan hiçbir şeyi yansıtamıyor. Ray tracing'li varyantı DXR donanımı istiyor; aynı sahnede 3060'ta 5.9 ms'ye çıktı. HDRP performans tartışması genelde burada, tek tek efektlerin fiyat etiketinde düğümleniyor. Kapalı mekanda aynı sonucun yüzde 60'ını planar reflection probe'larla 0.4 ms'ye almak mümkündü.

Path tracing ise gerçek zamanlı değil. Örnekleri kare üstünde biriktiriyor; 512 örneklik temiz bir kare için 20-40 saniye bekliyorum. Sinematik, kapak görseli ve pazarlama render'ı için mükemmel bir araç, oynanış için bir seçenek değil. Bu yüzden path tracing'i pipeline kararına hiç katmıyorum; onu ayrı bir render sahnesinde çalıştırmak daha mantıklı.

Bu üçü kapalı mekan, kontrollü kamera ve PC/konsol hedefli görsel odaklı bir proje için doğru cevap. Ama HDRP'yi en düşük ayarlara çekip geniş bir donanım yelpazesine yaymaya çalıştığınızda elinizde URP'ye çok benzeyen bir görüntü kalıyor. O noktada taban maliyeti niye ödediğinizi cevaplayamıyorsanız, seçim yanlış. Ekipte HDRP'nin volume katmanlarını ve exposure zincirini bilen biri yoksa fatura bir kat daha artıyor.

Shader Graph mı, elle HLSL mi?

Shader Graph pipeline'lar arasında taşınabilir görünüyor ama bu yalnızca master stack seviyesinde doğru. Grafiğe bir Custom Function düğümü koyup URP'nin Lighting.hlsl dosyasını include ettiğiniz anda o graph HDRP'de derlenmiyor. Taşınabilirlik, özel bir şey yapmadığınız sürece geçerli. Ürettiği kod da okunabilir değil; bir sorunu ayıklarken Show Generated Code çıktısında 900 satır arasında geziniyorsunuz.

Elle HLSL yazmak ise doğrudan pipeline'a bağlanmak demek. URP'de Packages/com.unity.render-pipelines.universal/ShaderLibrary/ altındaki fonksiyonlara, HDRP'de ise SurfaceData ve BSDFData etrafında kurulmuş bambaşka bir aydınlatma API'sine yaslanıyorsunuz. Toon shader'ımı HDRP'ye taşırken satırların yaklaşık %70'ini yeniden yazdım. Bu yüzden aydınlatma hesabını ayrı bir .hlsl dosyasına çıkarıp iki taraftan da include ediyorum; taşıma yine bedava olmuyor, sadece ucuzluyor.

Varyant sayısı da karara giriyor. Shader Graph multi_compile üretmekte cömert; dört graph'lı bir sette shader derleme süresi 11 dakikaydı. Gereksizleri shader_feature'a çevirip ShaderVariantCollection ile ayıklayınca 3 dakikaya indi. Kuralım basit: sanat ekibinin dokunacağı materyaller Shader Graph, sıcak yoldaki ve platforma özel shader'lar elle HLSL.

Proje ortasında geçiş ve net öneri

Geçişin faturasını bir kez tuttum, sayılar şöyle. 640 materyalin Render Pipeline Converter ile %68'i otomatik dönüştü; kalan 205'i elle düzelttim. Bunların çoğu özel shader kullanan veya detail map'i olan materyallerdi ve converter onlara sessizce boş bir Lit atıyor. Converter'ın raporunu okumadan devam etmeyin; hangi materyalin sessizce düştüğünü sadece orada görüyorsunuz.

En sinsi kısım ışıklar. HDRP fiziksel birim kullanıyor — güneş 100.000 lux civarında — URP'de aynı ışık keyfi bir yoğunluk değeri. Converter yaklaşık bir çarpan uyguluyor, ama 60 ışıklık sahnede 20 tanesini gözle yeniden dengelemek zorunda kaldım. Ardından tüm lightmap ve reflection probe'ları baştan bake ettim: 6 saat makine zamanı.

Post-process tarafında iki pipeline da Volume sistemini kullanıyor ama override setleri örtüşmüyor. Exposure, Fog ve ScreenSpaceReflection URP'de yok; yerlerini ColorAdjustments ve elle yazılmış renderer feature'lar alıyor. Bir de üçüncü parti asset'ler var: store'dan aldığınız her shader paketinin hedef pipeline sürümü ayrı bir sorun. Toplam maliyet iki kişi × üç hafta oldu ve bu süre boyunca oyuna tek bir yeni özellik eklenmedi.

Karar tablom şu: hedefinizde mobil, Quest, Switch, WebGL varsa ya da yayın donanımını bilmiyorsanız URP, tartışma yok. Yalnızca PC ve konsol hedefliyor, taban donanımı GTX 1660 üstü tutabiliyor, kapalı mekan ağırlıklı görsel bir oyun yapıyor ve ekipte tam zamanlı bir grafik programcınız varsa HDRP. İkisinin arasında kaldıysanız URP seçip eksiğini ScriptableRendererFeature ile kapatın — ve bu kararı prototipin ilk gününde verin, beşinci haftasında değil.

← Tüm yazılar