WebGPU'de UE5 Nanite Teknolojisi

 (github.com/Scthe)
1 puan yazan GN⁺ 2024-09-06 | 1 yorum | WhatsApp'ta paylaş
  • Nanite WebGPU, WebGPU ile tarayıcı içinde UE5 tarzı Nanite benzeri render etmeyi uygulayan bir projedir; meshlet LOD hiyerarşisi, yazılım rasterizer'ı, billboard impostor ve instance/meshlet düzeyinde culling içerir
  • Uygulama, OBJ girdisini tarayıcıda ön işleyebilmenin sadeliğini ve onay kutuları ile kaydırıcılar üzerinden ayarları değiştirerek performans değişimini denemeyi temel hedef olarak alır
  • Demoda Jinx sahnesinde 640M triangles, Lucy/Dragons gibi sahnelerde ise en fazla 1.7B triangles sunulur; Jinx'teki beyaz üçgenler, WebGPU kısıtları nedeniyle 32 bit'e sıkıştırılarak işlenen yazılım rasterization sonucudur
  • WebGPU'da atomic<u64> olmadığı için visibility buffer tabanlı verimli bir yazılım rasterizer'ını birebir uygulamak zordur; mevcut uygulama, depth u16 ve octahedron normal 2*u8 verisini 32 bit'e sığdırarak precision artifact'lerini göze alır
  • Gerçek bir Nanite tarzı uygulamada asıl zorluk, basitçe üçgen sayısı değil mesh simplification ve error metric'tir; yazar, kendi uygulamasının UE5'ten farklı olarak simplification, streaming, compression, visibility buffer ve 2-pass occlusion culling gibi özelliklere sahip olmadığını açıkça belirtir

Proje genel bakışı

  • Nanite WebGPU, WebGPU kullanarak web tarayıcısında Nanite tarzı render etmeyi uygulayan bir projedir
  • Dahil edilen başlıca bileşenler meshlet LOD hierarchy, yazılım rasterizer'ı, billboard impostor ve instance ile meshlet düzeyinde culling'dir
  • Texture'lı modelleri ve per-vertex normal'leri destekler; her ayar için kaydırıcı veya onay kutusu sunulur
  • WebGPU yalnızca Chrome'da kullanılabilir
  • Tüm uygulama Deno kullanılarak çevrimdışı da çalıştırılabilir; shader birim testleri de bu yöntemle yazılmıştır

Demo sahneleri ve ölçek

  • Jinx demosu, 120×120 instance ile 640M triangles ölçeğindedir
    • Tek bir Jinx modeli, 44k triangles'tan 3k triangles'a ve 59 root meshlet'e sadeleştirilir
    • Beyaz üçgenler, donanım rasterization bölgesi ile uzaktaki arka plan impostor'ları arasındaki yazılım rasterization üçgenleridir
  • Lucy and dragons, iki nesneyi de 70×70 instance olarak yerleştirip 1.7B triangles oluşturur
    • Örnek sahnede üçgenlerin neredeyse %98'i yazılım rasterization yoluyla işlenir ve bu yolun donanıma göre çok daha hızlı olduğu belirtilir
  • Lucy, 110×110 instance ve 1.2B triangles içeren bir sahnedir
    • Tek bir Lucy heykeli, 100k triangles'tan 86 triangles içeren tek bir root meshlet'e sadeleştirilir
  • Dragons, 70×70 instance ile 1.2B triangles'lık bir sahnedir
    • Tek bir dragon, 250k triangles'tan 102 triangles içeren tek bir root meshlet'e sadeleştirilir
  • Bunnies, 500×500 instance ile 1.2B triangles'lık bir sahnedir
    • Tek bir bunny, 5k triangles'tan 96 triangles içeren tek bir root meshlet'e sadeleştirilir
    • Bunny küçük olduğu için çoğunlukla frustum culling uygulanır

Uygulanan özellikler

  • Meshlet LOD hierarchy

    • Mesh preprocessing tarayıcıda çalışır
    • meshoptimizer ve METIS WebAssembly üzerinden kullanılır
    • Sayfa yenilemeleri arasında ön işlemeyi yeniden beklememek için bir dosya exporter'ı da sunulur

  • Software rasterizer

    • WebGPU'da verimli uygulama için gerekli atomic<u64> yoktur
    • Mevcut uygulama, depth u16 ile octahedron-encoded normal 2*u8 verisini 32 bit'e paketler
    • 32 bit sınırı nedeniyle precision ciddi biçimde feda edilir; amaç rasterizer'ın çalıştığını göstermektir
    • Bu kısıt, occlusion culling için kullanılan depth pyramid'i de etkiler

  • Billboard impostors

    • UP ekseni etrafında 12 görüntü kullanılır ve kamera konumuna göre dithering ile blend edilir
    • Yukarıdan/aşağıdan bakış açıları ele alınmaz
    • Hem diffuse hem normal içerir ve runtime shading yapılır
    • Impostors preview, impostor texture size'ın artırıldığı bir demodur

Culling ve render yolları

  • Culling birden çok aşamadan oluşur
    • Per-instance: frustum culling ve occlusion culling
    • Per-meshlet: frustum culling ve occlusion culling
    • Per-triangle: donanım backface culling ve z-buffer
  • WebGPU'da early-z yoktur
  • Occlusion culling yalnızca önceki karedeki depth buffer'dan oluşturulan depth pyramid kullanır
    • Reprojection ve two-pass yaklaşımı yoktur
    • Mevcut uygulamanın bile çok sayıda üçgeni cull ettiği ve performans kazanımını değerlendirmek için yeterli olduğu düşünülür
  • GPU-driven rendering ile basit bir CPU uygulaması arasında geçiş yapılabilir
    • CPU sürümü çok fazla optimize edilmemiştir, ancak debugger ile adım adım yürütülebilir
  • “Freeze culling” özelliği, kamerayı hareket ettirirken yalnızca son karede çizilenlerin incelenmesini sağlar

Kullanılabilirlik ve hata ayıklama

  • Hareket için [W, S, A, D], yükselme/alçalma için [Z, SPACEBAR], hızlı hareket için [Shift] kullanılır
  • Garip sonuçlar görülürse culling seçeneklerini açıp kapatarak kontrol edilebilir
    • Uygulamada bazı küçük bug'lar vardır
  • Beyaz üçgenler yazılım rasterization ile işlenen üçgenlerdir
    • WebGPU'daki atomic<u64> eksikliği nedeniyle depth ve normal 32 bit'e sıkıştırılır
    • 16-bit depth, z-fighting veya leak gibi çok sayıda artifact üretebilir
    • Yazılım rasterizer'ı kapatmak, ham Nanite meshlet'lerini görmeyi kolaylaştırır ancak büyük performans kaybına yol açabilir
  • FPS, tarayıcının zorunlu VSync'i nedeniyle dalgalanabilir; zamanlama kontrolü için “Profile” düğmesi kullanılır

Tasarım hedefleri

  • Projenin ilk hedefi sadelik
    • OBJ dosyasından başlayıp tüm işlemeyi uygulama içinde yapıyor
    • Blender export gibi ayrı bir ön işleme adımı gerektirmiyor
    • loadObjFile() içine breakpoint koyup ilk frame bitene kadar akışı takip edebileceğiniz bir yapı hedefleniyor
  • İkinci hedef deneysellik
    • Rust ve Vulkan yerine bir web sayfası olarak yapıldığı için bağlantıya tıklayıp onay kutuları veya kaydırıcıları değiştirerek performans farklarını görebilirsiniz
    • Tek bir ayarı değiştirdiğinizde FPS'nin ciddi biçimde düşmesi gibi durumlar üzerinden hangi seçeneklerin önemli olduğunu doğrudan görebilirsiniz
  • Kodun önemli bir kısmı optimize edilebilir, ancak simplification problemi çözülene kadar bu optimizasyonların önemli olmadığı düşünülüyor

UE5 Nanite'tan farkları

  • error metric olarak basit bir projected simplification error kullanılıyor
  • meshlet simplification basit bir yöntem kullanıyor
  • two-pass occlusion culling yok
    • Eklemek zor değil, ancak debug etmesi zahmetli ve GUI ayarlarıyla etkileşim doğuruyor
    • Kodun okunabilirliğini bozduğu için hedeflerle uyuşmuyor
  • visibility buffer yok
    • atomic<u64> kısıtı nedeniyle uygulanamıyor
  • built-in shadows ve multiview yok
  • shader içi work queue yok
    • meshlet culling ve LOD selection için meshlet başına thread dispatch ediliyor
  • Kullanılmayan LOD'lar için VRAM eviction ve streaming yok
  • compression yok
  • Çok sayıda farklı nesnede ölçeklenebilirlik düşük
    • Demo senaryosunda öngörülebilir bellek kullanımına odaklanılıyor
    • Stage'ler arasında veri taşıyan buffer'lar için çizilen meshlet sayısının üst sınırını önceden bilmek gerekiyor
  • Instance için BVH veya hiyerarşi uygulaması yok
    • Tüm instance'lar üzerinde frustum ve occlusion culling yapılıyor

Üçgen sayısının ne ifade ettiği

  • Yalnızca “milyarlarca triangle” sayısıyla performansı değerlendirmek zor; performans birçok etmene bağlı

  • Dense meshes

    • Yakında çok sayıda dense mesh olması performansı olumsuz etkileyebilir
    • Ancak ekranda büyük alan kaplayacak kadar yakınlarsa occlusion culling devreye girer
    • Dense geometry'de meshlet'ler küçüktür, ekranda kapladıkları alan azdır ve occlusion/cone culling'e daha yatkındırlar

  • Instance count

    • Her instance bir mat4x3 transform matrix taşıdığı için VRAM tüketir
    • Frame sırasında render edilecek öğelerin listesini de saklamak gerekir
    • En kötü durumda her instance en dense meshlet'leri render eder
    • Uygulama instanceCount * bottomLevelMeshletsCount * sizeof(vec2u) byte ayırır
    • Chrome'un WebGPU storage buffer için varsayılan sınırı 128MB'tır; demo sahne buna göre ayarlanmıştır

  • Scene arrangement

    • Uygulamadaki sahne nesneleri kare düzeninde yerleştirir
    • Uzaktaki nesnelerin yalnızca bir kısmı görünür, ancak coarse meshlet LOD daha geniş alanları kapsadığı için overdraw oluşur
    • Dense grid yerleşimi daha çok yakın üçgen render eder, ancak derinlik farkları küçük olduğundan occlusion culling açısından avantaj sağlar
    • Birbirinden uzak nesneler, rastgele uzak piksellerin depth pyramid'i kirletmesine neden olabilir

Jinx sahnesi neden zor

  • Jinx karakteri ince yapılı ve kollarıyla gövdesi arasında boşluklar olduğu için occlusion culling zorlaşıyor
  • Model iyi simplification olmadığı için en coarse LOD bile 3k triangles içeriyor
  • Çok sayıda 1 piksellik üçgenin birikmesi durumu ortaya çıkıyor
  • Software rasterizer büyük fayda sağlıyor, ancak sahne yerleşimi yüzünden instance'ların çoğu impostor olarak render ediliyor
  • Yakın bölgelerde işi hardware rasterizer üstleniyor; hardware rasterizer, software rasterizer ve impostor'ların her birinin farklı güçlü yönleri var

Nanite uygulamasında şaşırtıcı olanlar

  • DAG'nin amacı yalnızca uzaktaki nesnelerde daha az üçgen kullanmak değil, tüm ekranda 1 pixel == 1 triangle düzeyine yakın bir tutarlılık sağlamak
  • Discrete LOD mesh'lerde her LOD ayrı geometry olduğu için ara seviyeler gerektiğinde uyum sağlamak zor; continuous LOD gerekiyor
  • meshlet hierarchy, geometry'nin seçilen ayrıntı seviyesinde sampling yapılabilmesini sağlıyor
  • Nanite'ın kendisinden çok culling ve meshlet işlemleri zaman alıyor
  • meshlet LOD hierarchy'yi çalıştırmak kolay, ama verimli hâle getirmek zor
  • Mesh temiz biçimde simplification olmazsa, Jinx örneğinde olduğu gibi tek bir pikseli kaplayan yaklaşık 3.000 triangle gibi durumlar ortaya çıkabiliyor
  • Piksel boyutunda üçgenler istiyorsanız software rasterizer gerekiyor; billboard impostor da kararlılık odaklı bir fallback olarak yararlı

Mesh simplification problemi

  • Simplification, “bir mesh alıp üçgenleri %X azaltma” problemi değil; meshlet ve METIS bağlamında ele alınan bir problem
  • UE5, asset pipeline'ın ilk aşamasında kendi mesh simplification code'unu kullanıyor
    • Burada düşürülen maliyet, sonrasında tüm sistem boyunca zincirleme fayda sağlıyor
    • Brian Karis'in SIGGRAPH materyalinde LOD graph'ın tek bir root cluster ile bittiği ve her modelin 128 triangles'a simplification edilebildiği belirtiliyor
  • Jinx modelinde simplification'ın belirli bir noktada durması sorunu vardı
    • Girdi olarak X triangles verildiğinde yine aynı X triangles geri dönebiliyordu
    • Algoritma assertion ile çöküyordu
    • Sonrasında yeterince küçülmeyen mesh parçaları için DAG'de birden fazla root'a izin verilecek şekilde değiştirildi
  • Bunny modeli başlangıçta tek bir 128 tris meshlet'e simplification edilmişti, ancak koşullar değişince tek root'a gitmeme sorunu ortaya çıktı
    • Birçok meshlet üçgen sayısını yeterince azaltamadı ve 128 triangles'dan az olan çok sayıda “dolu olmayan” meshlet vardı
  • İlgili tartışmalar:

Hata metriği

  • 20.000.000 üçgenlik bir mesh, meshlet hiyerarşisiyle render edilirken hangi meshletin “doğru” meshlet olduğunun seçilmesi gerekir
  • Bu seçim problemi Nanite'ın özüdür; simplification, meshlet DAG ve software rasterizer ise bunu ele almak için daha çok ön koşul niteliğindedir
  • Uygulama, meshoptimizer'ın sunduğu projected simplification error metriğini kullanır
  • Yazar, bu metriğin Nanite için iyi bir metrik olmadığını ve diğer vertex attribute'larının da fonksiyona dahil edilmesi gerektiğini düşünüyor
    • attribute bazında weight verilebilmelidir
    • Jinx'in yüzündeki normal değerleri büyük bir problemdi
  • Başvurulan kaynaklar:

Software rasterizer neden texture çıktısı üretmiyor

  • Hardware rasterizer'da depth test sonucuna göre depth texture, color ve normal birlikte yazılabilir
  • Software rasterizer'da birden fazla thread aynı piksele yazarsa race condition oluşur
  • Yaygın çözüm visibility buffer'dır
    • Her pixel için en yakın triangle'ın sceneUniqueTriangleId değeri yazdırılır
    • Bu değer 32-bit depth ile birleştirilerek 64-bit bir değer haline getirilir ve 64-bit atomic operation kullanılır
    • Ayrı bir pass'te triangle yeniden rasterize edilir, barycentric coordinates hesaplanır ve shading uygulanır
  • WebGPU'da 64-bit atomics olmadığı için bu yöntem kullanılamaz
  • Bu projenin amacı software rasterize'ın çalıştığını göstermek olduğu için, arka plandaki software rasterize edilmiş model beyaz renktedir ve yalnızca makul düzeyde shading sunar

Kendi Nanite uygulamasına dair değerlendirme

  • En basit cevap UE5 kullanmaktır
  • Mevcut bir engine'e bu teknolojiyi eklemek için önce compute tabanlı bir graphics pipeline ve GPU-driven rendering pipeline uygulanmasının gerekli olduğu düşünülüyor
  • multi-step culling, scene/world chunk management, animated meshes gibi problemler önce ortaya çıkar
  • Bu aşamalar kararlı hale geldikten sonra software rasterizer denenmesi, ardından Nanite benzeri teknolojinin eklenmesi önerilir
  • toy renderer'da temel bir meshlet hiyerarşisi hafta sonu projesi olabilir, ancak gerçek uygulama simplification ve error metric sorunlarını ele almak zorundadır

Kullanılan araçlar ve kaynaklar

  • meshoptimizer, projenin uygulanmasındaki temel dayanak noktasıdır
    • Daha yeni meshoptimizer sürümlerinde Nanite klonu için meshopt_SimplifySparse bulunur
    • Proje, geliştirme sırasında test edilen durumu korumak için o sürüme güncellenmemiştir
  • METIS kullanılmıştır
  • Emscripten, meshoptimizer ve METIS'i tarayıcıda çalıştırmak için kullanılmıştır
  • Jinx modeli olarak Sketchfab'deki Arcane - Jinx kullanılmış; texture birleştirme, UV düzenleme ve silah kaldırma işlemleri yapılmıştır

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-06
Hacker News yorumları

  • Vay, güzel. Nanite oynatmanın üçüncü taraf bir uygulaması çıkmış oldu.
    Nanite, grafik mesh’lerini son derece akıllıca temsil ediyor. Bir ağaç değil, yönlendirilmiş döngüsüz grafik olduğu için tekrarlar kopya değil bağlantı hâline geliyor; bir mesh alt mesh’leri paylaşabiliyor, o alt mesh’ler de yeniden paylaşılabiliyor. Mesh içinde ayrıntı düzeyi (LOD) de destekleniyor; alt mesh yeterince küçüldüğünde devreden çıkarılıyor.
    Bu sayede sonlu miktarda veri ve hızlı render süreleriyle çok büyük miktarda tekrarlanan içerik işlenebiliyor. Ekranda sınırlı sayıda piksel olduğundan, gerçekten gereken render iş miktarının da bir üst sınırı olduğu içgörüsüne dayanıyor.
    Epic’ten birinin anlattığı SIGGRAPH videosu çok iyi. Mevcut GPU tasarımları Nanite ile pek uyumlu değil; daha fazla işlemi GPU’da yapmak için yeni donanım işlemleri gerekiyor. Nvidia’nın yapay zeka pazarına odaklandığı bir dönemde böyle bir değişimin olup olmayacağı şüpheli.
    Bu yöntemin etkili olabilmesi için sahnede çok fazla instancing olması gerekir. Unreal Engine demosundaki aynı heykellerle dolu salon gibi, sınırlı sayıda nesneyi yeniden kullanarak geniş içerikler oluşturan AAA oyunlara iyi uyuyor. Cyberpunk 2077 videolarına bakıp korkulukları ve çöp yığınlarını ararsanız, aynı şeylerin tamamen farklı bağlamlarda sürekli tekrarlandığını görebilirsiniz.
    Nanite mesh üretimi, çok sayıda iç bağlantı offset’i nedeniyle karmaşık ve şimdiye kadar bunu yalnızca Unreal Engine editörü hallediyordu. Oynatma tarafı açık kaynak olduğuna göre birilerinin üretim araçları da geliştirmesi büyük olasılık.
    Ancak formatın iç offset’leri bir saldırı yüzeyi olabilir ve kötü niyetle hazırlanmış Microsoft Word .doc dosyaları gibi manipüle edilmiş içeriklerle kötüye kullanılabilecek gibi görünüyor.

    • Grafik kesimi için yönlendirilmiş döngüsüz grafik oluşturuluyor olsa da, nihai disk verisi yalnızca içerme/dışlama ölçütlerine sahip kümelerin düz bir listesinden ibaret. DAG’ın nerede kullanıldığı ve nasıl oluşturulduğu konusunda epey büyük bir yanlış anlama var gibi görünüyor.
      DAG, tepe noktası verilerine dayanarak dinamik olarak oluşturulur; sanatçının alt mesh’leri nasıl yapılandırdığıyla ilgisi yoktur. “Tekrarlar bağlantıya dönüşür” gibi bir durum da değil.
      Ayrıca grafik kesiminin sonucu her nesne örneği için farklı olduğundan geleneksel instancing kullanılamıyor; bu yüzden sahnede çok fazla instancing olması gerektiğinde neden etkili olacağını düşündüğünüzü anlamıyorum.
    • 2000’lerin eski günlerinde PS3 geliştirmesi yaparken Cell’in bol hesaplama kaynağını düzgün kullanmanın ve RSX’in sınırlı bellek bant genişliğini aşmanın yollarını arıyorduk. Blu-ray depolama alanını da bolca kullanabiliyorduk.
      O dönemde Nanite’a benzeyen bir şeyi epey ilerletmiştim; buna sıkıştırılmış mesh diyordum. Tipik, hedefi ıskalayan mühendislik kibrinin bir örneğiydi.
      İlk çalışmalar umut verici görünüyordu ama sorunun içine girdikçe her şey giderek karmaşıklaştı. Tüm bir asset üretim pipeline’ı oluşturmam gerekiyordu; iyi görünen sonuçlar üretirken belleği patlatmadan makul sürede bitirmek için fazla büyüktü.
      Büyük ölçekli mesh’leri kademeli ayrıntı düzeyleriyle render ediyormuş gibi görünen bir noktaya kadar getirdim, ama çok yavaştı ve alt piksel doğruluğunu tutturmak için GPU’yu zorlamazsanız berbat görünüyordu. İlginç bir deneydi, fakat donanım için de fazlasıyla ağırdı ve tek kişinin üstlenmesi için çok büyük bir işti.
      Epic Nanite’ı duyurduğunda gerçekten şaşırdım. Benim yapamadığım şeyi, hayal edebileceğim en iyi hâlinden bile çok daha iyi bir şekilde başarmışlardı. Ortaya çıktığında abartı değil, gerçekten çözüm olan teknolojilerden biri ve modern grafik dünyasının teknik mücevherlerinden biri. Epic halka açık bir şirket olsaydı, sırf Nanite teknolojisine bakarak epey büyük bir para yatırmayı düşünecek kadar etkilenmiştim.
    • Bahsettiğiniz SIGGRAPH sunumu muhtemelen "A Deep Dive into Nanite Virtualized Geometry" olmalı: https://www.youtube.com/watch?v=eviSykqSUUw
      Kısa ve üst düzey tanıtım videosu da fena değildi. "What is virtualized micropolygon geometry? An explainer on Nanite": https://www.youtube.com/watch?v=-50MJf7hyOw
    • Ana akım bir motor değil ama küçük Rust ECS oyun motoru Bevy de "Virtual Geometry" özellik adıyla benzer bir şeyi destekliyor: https://bevyengine.org/news/bevy-0-14/#virtual-geometry-expe...
      Bu özelliğin yazarlarından birinin yazdığı teknik derinlemesine inceleme de var: https://jms55.github.io/posts/2024-06-09-virtual-geometry-be...
    • Makaleleri okuyunca en büyük kazancın kuantize edilmiş koordinatlardan ve tüm mesh yerine küçük patch’ler düzeyinde dinamik ayrıntı seviyesinden geldiği izlenimini edindim.
      Benim anladığım kadarıyla Nanite’ın mantığı, mesh doğruluğunu kabaca 1 piksel hassasiyetinde tutmak. Örneğin perspektif projeksiyondan sonra hata yarım piksel civarında kalıyorsa, koordinatları yaklaşık 10 bit’e yuvarlanmış daha düşük detaylı bir mesh kullanılabilir.
      Kuantizasyonun iki rol oynadığını belirsizce hatırlıyorum. Yalnızca veri depolama boyutunu azaltmakla kalmıyor, tepe noktalarını uzayda aynı konuma snap ederek ayrıntı düzeyi üretimine de yardımcı oluyor; sonrasında da tekrarlar kaldırılabiliyor.

  • Bu başlıkta birkaç kez bahsedildi ama Bevy’de de Nanite fikirlerinin bir uygulaması var. Bazen sanal geometri diye adlandırılıyor. Yazarı ben olduğum için soruları yanıtlayabilirim :)
    Bu proje konusunda Scthe gerçekten çok iyi iş çıkardı. Çalışma sürecinin çeşitli kısımlarını birlikte konuştuk ve o deneyim Bevy kodunun da iyileşmesini sağladı: https://github.com/bevyengine/bevy/pull/15023
    Bu alana daha fazla kişinin girmesi her zaman sevindirici. Nanite’ta gerçekten çok sayıda harika fikir var.

  • Demo, uyumluluk kararını kullanıcı aracısı dizesi ile mi veriyor? Bu iyi değil. Özellik uyumluluğu, belirli özelliği doğrudan algılayarak veya deneyerek vaka bazında değerlendirilmelidir.
    Ben Chrome değil Chromium kullanıyorum ve WebGPU’yu da sürekli kullanıyorum, ama demo Chrome kullanmamı söylüyor. Etik olarak bunu yapamam. Demoyu gerçekten denemek istiyorum; çok emek verilmiş bir proje gibi görünüyor.

    • Bu arada Linux’taki Chrome’da da, Android’de de çalışmıyor. Gerçek gezinme için çoğunlukla Firefox kullanıyorum gerçi. Algılama mantığında oldukça tuhaf bir şey var.
    • Öyle gibi görünmüyor. Deneysel WebGPU desteği açılmış Firefox’ta ayrı bir mesaj yerine shader derleme hatası ile başarısız oluyor.
    • Özellik bazlı algılamayı hedeflemek iyi bir şey.
      Tarayıcılar için kendi bileşen framework’ümü yaparken algılama çoğu zaman mümkün olmadığından tarayıcı sniffer’ına dayanmak zorunda kalmıştım. Modernizr kodunda özellik algılaması için çok zekice, bazen de çok kirli hack’ler var. Güvenilir algılama kodu üretmek için muazzam emek harcanmıştı ve algılama da genellikle yan etkiler üzerinden yapılıyordu.
      Tahminimce Web3D özellik algılaması basit değil. Hızlıca arayınca da belirgin bir Web3D özellik algılama kütüphanesi göremedim.
      Modernizr’in :checked desteğini algılama kodunun bir kısmı şöyle:
      Modernizr.addTest('checked', function(){
      return Modernizr.testStyles('#modernizr input {width:100px} #modernizr :checked {width:200px;display:block}', function(elem, rule){
    • Hangi derlemeyi kullandığınızı bilmiyorum ama ben Ungoogled Chromium kullanıyorum ve kullanıcı aracısı dizesi Google Chrome ile tamamen aynı.
      Site ayarlarında bu site için WebGL iznini açtınız mı? Bende varsayılan olarak kapalıydı sanırım.
    • Sanırım demonun kendisi bozuk. Şu hatayı veriyor:
      WebGPU error [frame][validation]: Fill size (7160950) is not a multiple of 4 bytes.
      • While encoding [CommandEncoder "main-frame-cmd-buffer"].ClearBuffer([Buffer "rasterize-sw"], 0, 7160950).

  • Nanite’ın temelini oluşturan dinamik mesh sadeleştirme algoritmasını icat eden Federico Ponchio’nun, biraz gözden kaçmış 2009 tarihli doktora tezi. Bolca görsel de var.
    https://vcg.isti.cnr.it/~ponchio/download/ponchio_phd.pdf 107 sayfa.

  • Bir dereceye kadar çalışması harika, ama WebGPU’da 64 bit atomik işlemler olmadığı için epey kaba tavizler vermek zorunda kalınmış.
    Bir gün isteğe bağlı bir uzantı olarak eklenirse iyi olur. En azından masaüstü sınıfı donanımlarda donanım desteği neredeyse evrensel. AMD ve Nvidia’da uzun zamandır vardı, Apple ise M3’ten itibaren destekledi.

    • Rasterizer’da atomik işlemler ne için kullanılıyor? Render pipeline içinde atomik işlemlerin ne yaptığını bilmiyorum. GitHub’a da baktım ama atomik işlem beklediğim yeri bulamadım.
    • M2’den itibaren.

  • iPhone 12 Pro Max’te WebGPU olmadığı söyleniyor, ama deneysel özelliklerden açınca başka WebGPU demo sitesi[1] çalışıyor. Bunu iPhone’da çalıştırabilen oldu mu? Web uygulaması neyin başarısız olduğunu daha ayrıntılı söylese iyi olurdu.
    [1] https://webgpu.github.io/webgpu-samples/?sample=texturedCube

    • Safari’de WebGPU’yu açtım ama bir sürü shader hatası görünüyor.
      WebGPU error [init][validation]: 6 errors generated while compiling the shader: 50:22: unresolved call target 'pack4x8snorm' 50:9: cannot bitcast from '⊥' to 'f32' 54:10: unresolved call target 'unpack4x8snorm' 59:22: unresolved call target 'pack4x8unorm' 59:9: cannot bitcast from '⊥' to 'f32' 63:9: unresolved call target 'unpack4x8unorm'
    • Safari’nin WebGPU desteği henüz tamamlanmadığı için deneysel özellik olarak kalıyor.

  • Adı ve açıklaması çok kafa karıştırıcı; ayrıca marka hakkı ihlali potansiyeli de var gibi görünüyor. İddianın aksine UE5’in gerçek Nanite’ı ile tamamen ilgisiz; UE5 ile bağlantısı olmayan birinin benzer bir şeyi uygulamış hali gibi görünüyor.
    Benzer işlev sunan Bevy’nin Virtual Geometry’si de var. Rust ile yazılmış ve oyun motoruna entegre olduğundan çok daha kullanışlı olma ihtimali yüksek: https://jms55.github.io/posts/2024-06-09-virtual-geometry-be...

    • Büyük bir sorun gibi görünmüyor. README’ye bakınca bunun bir uygulama olduğu açık.
      “OpenAI’ın GPT-3’ünü JS ile uyguladım” dersem, teknik dokümandaki mimariyi alıp yeniden uyguladığım anlaşılır.

  • Bu aslında WebGPU’da çalışan UE5 Nanite değil. Nanite ile aynı fikri bağımsız olarak uygulamış bir şey.
    Bu teknik çeşitli yerlerde görülmeye başladı. Nanite’ın bu fikri meşhur ettiği doğru, ama Nanite tekniğin adı değil, belirli bir uygulamanın adı.

  • Diğer motorların ayrıntı seviyesi ve benzer sistemlerde ne durumda olduğunu merak ediyorum
    Godot’ta otomatik ayrıntı seviyesi özelliği var ve kendi başına oldukça iyi görünüyor: https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod...
    Unity’de de bir ayrıntı seviyesi sistemi var, ancak motorun popülerliğine kıyasla ayrıntı seviyesi modellerini elle oluşturmanız gerekiyor: https://docs.unity3d.com/Manual/LevelOfDetail.html tabii Asset Store’da bir eklenti aramazsanız
    Daha az bilinen NeoAxis adlı motorda da ilginç bir yaklaşım gördüm: https://www.neoaxis.com/docs/html/NeoAxis_Levels.htm ama eski RX580’imde performansı çok kötüydü, mevcut A580’imde ise henüz denemedim
    Bana göre ekrana çok şey koyabilme konusunda Unreal rakiplerinin epey önünde. Dezavantajı ise sanatçıların oyuna daha yüksek kaliteli asset’ler koymak istemesi ve bunun kurulum boyutunu ciddi şekilde şişirebilmesi

    • Teoride Nanite, önceden hesaplanmış ayrıntı seviyesinden üstündür. Pratikte bunu bu kadar kesin söylemek zor. Sanatçının elle hazırladığı ayrıntı seviyeleri kadar iyi olması zor ve bunu beklemek de makul değil
      Performans maliyeti de büyük. Nanite ya da sanal geometri modern GPU’larla pek uyumlu değil. Hatırladığım kadarıyla maksimum fill rate yaklaşık 1/4 civarındaydı. Çünkü GPU rasterizasyonu shader’lar gibi piksel bazında değil, 2x2 quad’lar bazında çalışır
    • Intel Arc GPU Nanite render etmede berbat. Çünkü GPU güdümlü renderer’larda yaygın kullanılan indirect draw’u ve Nanite için gereken 64 bit atomic işlemleri donanımda desteklemiyor. Intel, indirect draw’u yazılımla emüle ettiği için yavaş

  • Bu kadar çok tekrarlayan statik geometri içeren render sahneleri gördüğümde, eski bir vaporware videosunda “sınırsız detay” diye konuşup duran o sinir bozucu kişinin sesi aklıma geliyor
    Nanite, o eski şeyin aksine, gerçekten bu problemi çözmüş gibi görünüyor. Onların octree gibi bir şey kullandıklarından bahsedildiğini hatırlıyorum

    • Bu iddiayı ortaya atan şirketin Euclidean olduğunu sanıyorum. Avustralyalı bir şirket gibiydi
      İnternetteki söylentilere göre octree kullandıkları söyleniyordu, ancak sonraki Euclidean videoları bunu kesin bir dille reddetti