Sanal dokulama aslında nasıl etkili olabilir?


27

Başvuru için atıfta bulunduğum, idTech 5'in MegaTexture teknolojisi ile tanıtılan ilk teknik ("inanıyorum") için "genel ad" dır . Nasıl çalıştığını görmek için videoyu buradan izleyin .

Son zamanlarda bununla ilgili bazı makaleleri ve yayınları inceliyorum ve anlamadığım şey, bunun nasıl etkili olabileceği. UV koordinatlarının "global texture page" alanından sanal doku koordinatlarına sürekli yeniden hesaplanmasını gerektirmiyor mu? Ve bu engelleme, harmanlama geometrisini tamamen denemek için nasıl bir çaba harcamıyor? İsteğe bağlı yakınlaştırmayı nasıl sağlayabilir? Bir noktada, çokgenleri alt bölümlere ayırmayı gerektirmez mi?

Anlayamadığım çok şey var, ve konuyla ilgili kolayca ulaşılabilir bir kaynak bulamadım.

Yanıtlar:


20

genel bakış

Sanal Tekstüre (VT) veya Seyrek Sanal Dokular'ın ana nedeni , bazen denildiği gibi, bir hafıza optimizasyonudur. İşin özü, video belleğe yalnızca görüntülenen bir kare için gerek duyabileceğiniz gerçek dokuları (sayfa / döşeme olarak genellenir) taşımaktır. Böylece çevrimdışı ya da yavaş depolamada (HDD, Optik Disk, Bulut) daha fazla doku verisine sahip olmanıza izin verir, aksi halde video belleğe ya da ana belleğe sığdırır. Modern İşletim Sistemleri tarafından kullanılan Sanal Bellek kavramını anlıyorsanız, özünde aynı şeydir (isim kazayla verilmez).

VT, bir mesh oluşturmadan önce her karenin bunu yapacağınız anlamında yeniden hesaplanmasını gerektirmez, ardından vertex verilerini yeniden gönderir, ancak gelen UV'lerden dolaylı arama yapmak için Vertex ve Fragment gölgelendiricilerinde bazı önemli çalışmalar gerektirir. Bununla birlikte, iyi bir uygulamada, sanal bir doku veya geleneksel bir yapı kullanıyorsa, uygulama için tamamen şeffaf olması gerekir. Aslında, çoğu zaman bir uygulama hem sanal hem de geleneksel doku türlerini karıştıracaktır.

Dozajlama teoride çok işe yarar, ancak bunun ayrıntılarına hiç bakmadım. Geometri gruplama için genel kriterler dokular olduğundan ve VT ile, sahnedeki her çokgen aynı "sonsuz büyük" dokuyu paylaşabilir, teorik olarak, 1 çizim çağrısı ile tam sahne çizimini elde edebilirsiniz. Ancak gerçekte, bu pratik olmayan diğer faktörler devreye girer.

VT ile ilgili sorunlar

Bir VT kurulumunda yakınlaştırma / uzaklaştırma ve ani fotoğraf makinesi hareketi en zor işlerdir. Statik bir sahne için çok çekici görünebilir, ancak işler hareket etmeye başladığında, harici depolama için yayınlayabileceğinizden daha fazla doku sayfası / fayans istenir. Eşzamansız dosya IO ve iş parçacığı yardımcı olabilir, ancak bir oyunda olduğu gibi gerçek zamanlı bir sistemse, her seferinde hi-res olanlar gelene kadar düşük çözünürlüklü plakalarla birkaç kare oluşturmak zorundasınız. bulanık bir doku ile sonuçlanır. Burada gümüş kurşun yok ve IMO tekniği ile ilgili en büyük sorun bu.

Sanal Tekstüre alma da saydamlığı kolay bir şekilde ele almaz, bu yüzden şeffaf çokgenler onlar için ayrı bir geleneksel görüntü oluşturma yoluna ihtiyaç duyar.

Sonuç olarak, VT ilginç, ama bunu herkes için tavsiye etmem. İşe yarayabilir, ancak uygulanması ve iyileştirilmesi zordur, ayrıca zevkim için gereken çok sayıda köşe çantası ve duruma özel ayarlamalar var. Ancak büyük açık dünya oyunları veya veri görselleştirme uygulamaları için, tüm içeriği mevcut donanıma sığdırmak için tek olası yaklaşım bu olabilir. Çok fazla iş varken, PS3 görmek ve kimliğinin ait XBOX360 versiyonları olabilir gibi, hatta sınırlı donanım üzerinde oldukça verimli çalışmasına yapılabilir Rage .

uygulama

VT'yi, OpenGL-ES ile iOS üzerinde belirli bir dereceye kadar çalışmasını sağladım. Uygulamam "gönderilebilir" değil, ancak isterdim ve kaynaklarım varsa makul bir şekilde yapabilirdim. Kaynak kodunu burada görüntüleyebilir , parçaların nasıl bir araya geldiği hakkında daha iyi bir fikir edinmenize yardımcı olabilir. İşte iOS Sim'de yayınlanan bir demo videosu . Simülatör gölgelendiricileri taklit etmekte berbat olduğu için çok çılgınca görünüyor, ancak bir cihazda sorunsuz çalışıyor.

Aşağıdaki şemada, uygulamamdaki sistemin ana bileşenleri gösterilmektedir. Sean'ın SVT demosundan biraz farklıdır (aşağıdan aşağıya bağlantı), ancak mimaride , ilk GPU Pro kitabında ( aşağıdan yukarıya bağlantı) bulunan CUDA'yı Kullanarak Sanal Tekstüre Etme Hızlandırması makalesinde sunulana daha yakındır .

sanal tekstüre sistemi

  • Page Filesönceden işlenmiş bir adım olarak fayanslara (AKA sayfaları) kesilmiş sanal dokulardır; Bir sayfa dosyası ayrıca sanal mipmapler olarak da adlandırılan tüm mipmap kümesini içerir .

  • Page Cache ManagerPage Tableve Page Indirectiondokuların uygulama tarafı gösterimini tutar . Bir sayfayı çevrimdışı bellekten belleğe taşımak pahalı olduğundan, zaten mevcut olanları yeniden yüklememek için bir önbelleğe ihtiyacımız vardır. Bu önbellek çok basit bir Son Kullanılan (LRU) önbellektir. Önbellek aynı zamanda fiziksel dokuları kendi yerel veri sunumuyla güncel tutmaktan da sorumludur.

  • Page ProviderSahnenin belirli bir görünüme ilişkin gerekli sayfa çektiğini ve onları önbelleğe gönderecek bir zaman uyumsuz iş kuyruğu olduğunu.

  • Page IndirectionDoku gelen UV'lerinizi eşler sanal doku her sayfa / karo için bir piksel, bir doku olan Page Tablegerçek texel verilere sahip önbellek dokusu. Bu doku oldukça büyüyebilir, bu nedenle RGBA 8: 8: 8: 8 veya RGB 5: 6: 5 gibi bazı kompakt formatlar kullanmalıdır.

Ancak burada hala kilit bir parçayı özlüyoruz ve bu, depolamadan hangi sayfaların önbelleğe ve dolayısıyla da içine yüklenmesi gerektiğinin nasıl belirleneceğidir Page Table. Geribildirim Geçidi ve Page Resolvergirilen yer burasıdır .

Geribildirim Geçişi, istenen sayfaların kimliklerini renkli çerçeveye yazacak şekilde özel bir gölgelendirici ve daha düşük bir çözünürlükte olan görünümün önceden oluşturulmuş halidir. Yukarıdaki küp ve kürenin renkli patchwork'ü, RGBA rengi olarak kodlanmış gerçek sayfa indeksleridir. Bu ön-geçiş oluşturma işlemi daha sonra ana belleğe okunur Page Resolverve sayfa indekslerinin kodunu çözmek ve yeni isteklerle birlikte ateşlemek için işlenir Page Provider.

Geri bildirim ön geçişinden sonra, sahne, VT arama gölgelendiricileriyle normal şekilde görüntülenebilir. Ancak, yeni sayfa isteğinin bitmesini beklemeyeceğimizi unutmayın, bunun korkunç olacağını, çünkü senkronize GÇ dosyasını engelleyelim. İstekler eşzamansızdır ve nihai görünümün oluşturulduğu zamana kadar hazır olabilir veya olmayabilir. Hazırlarsa, tatlılar, ama olmasalar da, önbellekte düşük çözünürlüklü bir mipmap kilitli bir sayfasını her zaman bir geri dönüş olarak tutarız, bu nedenle kullanmak için bazı doku verilerimiz vardır, ancak bulanık olacaktır.

Diğer kaynaklara göz atmaya değer kaynaklar

VT hala Computer Graphics'te biraz daha sıcak bir konu, bu nedenle tonlarca iyi malzeme var, daha fazlasını bulabilmelisiniz. Bu cevaba ekleyebileceğim başka bir şey varsa, lütfen sormaya çekinmeyin. Bu konuda biraz paslanmışım, geçen sene hakkında pek bir şey okumamıştım, ama hafızanın tekrar gözden geçirilmesi iyi bir şey :)


Mükemmel cevap için teşekkürler. Bunun genellikle kaşlarını çattığını biliyorum ama çeşitli sorunlarım var, bu yüzden çoğunlukla sadece bazı şeyleri gözden geçiririm - gelecekle ilgili konulara sezgisel bir bakış atmak için (işleri doğru bir şekilde öğrenmek ve uygulamak şu an için elimde değil. ) - yine de, eğer mümkünse, sürecin kendisini, ideal olarak ama zorunlu olarak resmedildiği şekilde gösteren bir sahte kod örneği gönderebilir misiniz?
Llamageddon

1
@Llamageddon, bu yüzden hala elimde bir diyagram vardı; olur;) Korkarım sözde kodun sağlanması biraz zor olacak, çünkü bunun için bir miktar gerçek kod var. Fakat umarım genişletilmiş cevap, teknik hakkında genel bir fikir verilmesine yardımcı olur.
glampert

3
Çoğu modern donanımın artık yeniden yönlendirme dokusuna olan gereksinimi ortadan kaldıran programlanabilir sayfa tabloları gösterdiğini belirtmek gerekir. Bu, örneğin , directx11 karolu kaynaklar veya opengl seyrek dokular üzerine inşa edilen directx12 ayrılmış kaynaklar aracılığıyla ortaya çıkar .
MooseBoys,

1
@Llamageddon, geri besleme ön geçişi, mümkün olduğunca fazla bilgi işlem ve bellek tasarrufu yapmak için daha düşük bir çözünürlükte yapılabilir, çünkü bir sayfa için pikseller genellikle tekrarlanacaktır (demomdaki büyük renkli kareleri fark edebilirsiniz). Sonunda bunun gibi görünür bir sayfayı kaçırabileceği konusunda haklısınız, ancak bu genellikle büyük bir görsel etkiye sahip olmayacak, çünkü sistem her zaman en azından önbellekte bulunan VT'nin en düşük mipmap'ini tutmalı. Bağladığım ikinci makalenin ekinde yer alan tüm gölgelendirici örnekleri var, kendi projem için repoya da başvurabilirsiniz, benzerler.
glampert

1
@glampert Ahh, görüyorum; bu mantıklı. Yine de, saydamlıklarla başa çıkmak için birçok seçenek olduğunu düşünüyorum; sayfa kimliği geçişinde, çok büyük saydam katmanlar olmadıkça histogramlama tüm sayfaları görecek şekilde dither olabilirdi, ya da bir k-buffer yaklaşımı kullanır , hatta nesnelerin yakınında bulunan saydam doku dokusunu temel alır. kamera (onları geri bildirim geçişinde göstermektense).
Nathan Reed

11

Sanal Tekstüre, doku atlaslarının mantıksal aşırı noktasıdır.


Doku atlası, içindeki tek kafesler için dokular içeren tek bir dev dokudır:

Doku Atlası Örneği

Doku atlasları, değişen dokuların GPU'da tam bir boru hattı hizasına yol açması nedeniyle popüler hale geldi. Ağlar oluşturulurken UV'ler sıkıştırılır / kaydırılır, böylece bütün doku atlasının doğru 'kısmını' temsil ederler.

Yorumlarda @ nathan-reed'den bahsedildiği gibi, doku atlaslarının ana dezavantajlarından biri tekrar, kelepçe, kenarlık, vb. Gibi sarma modlarını kaybediyor. filtreleme yaparken bitişik bir dokudan numune alın. Bu kanama artefaktlarına yol açabilir.

Doku Atlaslarının bir büyük sınırlaması vardır: boyut. Grafik API'leri bir dokunun ne kadar büyük olabileceğine yumuşak bir sınır koyar. Bununla birlikte, grafik belleği sadece çok büyük. Bu yüzden v-ram'ınızın boyutuna göre, doku boyutunda da sert bir sınır vardır. Sanal dokular, kavramları sanal bellekten ödünç alarak bu sorunu çözer .

Sanal dokular, çoğu sahnede, tüm dokuların yalnızca küçük bir kısmını gördüğünüz gerçeğinden yararlanır. Bu nedenle, yalnızca bu doku alt kümesinin vramda olması gerekir. Gerisi ana RAM'de veya diskte olabilir.

Uygulamanın birkaç yolu var, ancak Sean Barrett tarafından açıklanan uygulamayı GDC konuşmasında açıklayacağım . (ki izlemenizi şiddetle tavsiye ederim)

Üç ana öğemiz var: sanal doku, fiziksel doku ve arama tablosu.

Sanal doku

Sanal doku, herşeye uyacak kadar vram olsaydı sahip olacağımız teorik mega atlası temsil eder. Aslında hiçbir yerde bellekte yok. Fiziksel doku, aslında sahip olduğumuz piksel veriyi temsil ediyor. Arama tablosu ikisi arasındaki eşleşmedir. Kolaylık sağlamak için, her üç elemanı da eşit boyuttaki plakalara veya sayfalara böldük.

Arama tablosu, döşemenin sol üst köşesinin konumunu fiziksel dokuda saklar. Öyleyse, tüm sanal dokuya bir UV verilmişse, fiziksel dokuya karşılık gelen UV'yi nasıl elde ederiz?

İlk önce, sayfanın konumunu fiziksel doku içinde bulmamız gerekiyor. Ardından UV'nin sayfa içindeki konumunu hesaplamamız gerekir. Sonunda UV'nin fiziksel doku içindeki yerini bulmak için bu iki ofseti bir araya getirebiliriz.

float2 pageLocInPhysicalTex = ...
float2 inPageLocation = ...
float2 physicalTexUV = pageLocationInPhysicalTex + inPageLocation;


Sayfa hesaplamaLocInPhysicalTex

Arama tablosunu sanal dokudaki döşemelerin sayısıyla aynı boyutta yaparsak, arama tablosunu en yakın komşu örneklemesiyle örnekleyebiliriz ve sayfanın sol üst köşesinin fiziksel doku içindeki konumunu elde ederiz.

float2 pageLocInPhysicalTex = lookupTable.Sample(virtTexUV, nearestNeighborSampler);


İnPageLocation'ın hesaplanması

inPageLocation, tüm dokunun sol üst kısmına değil, sayfanın sol üst kısmına göre olan bir UV koordinatıdır.

Bunu hesaplamanın bir yolu, sayfanın sol üst kısmındaki UV ışığını çıkarmak, sonra da sayfanın boyutuna ölçeklendirmektir. Ancak, bu biraz matematik. Bunun yerine, IEEE kayan noktalarının nasıl temsil edildiğini kullanabiliriz. IEEE kayan nokta, bir sayının kesirli kısmını, bir dizi baz 2 kesir ile saklar.

görüntü tanımını buraya girin

Bu örnekte, sayı:

number = 0 + (1/2) + (1/8) + (1/16) = 0.6875

Şimdi sanal dokunun basitleştirilmiş bir versiyonuna bakalım:

Basit Sanal Doku

1/2 biti bize, dokunun sol yarısında mı yoksa sağ mı olduğumuzu söyler. 1/4 bit bize hangi yarıda olduğumuzu söyler. Bu örnekte, doku 16 veya 4'e bir kenara ayrıldığından, bu ilk iki bit bize hangi sayfada olduğumuzu söyler. bit, bize sayfanın içindeki konumu söyler.

Kalan bitleri, float'ı exp2 () ile değiştirerek ve onları fract () ile çıkartarak elde edebiliriz.

float2 inPageLocation = virtTexUV * exp2(sqrt(numTiles));
inPageLocation = fract(inPageLocation);

NumTiles, dokunun her bir yüzündeki fayans sayısını veren bir int2'dir. Örneğimizde, bu (4, 4) olur

Öyleyse yeşil nokta için inPageLocation değerini hesaplayalım, (x, y) = (0.6875, 0.375)

inPageLocation = float2(0.6875, 0.375) * exp2(sqrt(int2(4, 4));
               = float2(0.6875, 0.375) * int2(2, 2);
               = float2(1.375, 0.75);

inPageLocation = fract(float2(1.375, 0.75));
               = float2(0.375, 0.75);

Yapmadan önce yapılacak son bir şey. Şu anda, inPageLocation sanal dokudaki 'boşluk' içindeki bir UV koordinatıdır. Bununla birlikte, fiziksel dokuda 'uzayda' bir UV koordinatı istiyoruz. Bunu yapmak için, inPageLocation'ı sanal doku boyutunun fiziksel doku boyutuna oranıyla ölçeklememiz gerekiyor

inPageLocation *= physicalTextureSize / virtualTextureSize;



Yani bitmiş fonksiyon:

float2 CalculatePhysicalTexUV(float2 virtTexUV, Texture2D<float2> lookupTable, uint2 physicalTexSize, uint2 virtualTexSize, uint2 numTiles) {
    float2 pageLocInPhysicalTex = lookupTable.Sample(virtTexUV, nearestNeighborSampler);

    float2 inPageLocation = virtTexUV * exp2(sqrt(numTiles));
    inPageLocation = fract(inPageLocation);
    inPageLocation *= physicalTexSize / virtualTexSize;

    return pageLocInPhysicalTex + inPageLocation;
}

Hayır, idTech 5'in MegaTexture teknolojisi olarak bilinen sanal dokuyu kastediyorum . Ayrıca bunu ve bunu da görün . Birçok modern motorun işleme boru hatlarına genel bir bakışta ve gölge haritaları için benzer bir yaklaşım kullanan birkaç makalede bahsetmiştim. Doku atlasları ile ortak bir yönü vardır, evet, onları bir şekilde kullanır, ancak onu doku atlaslarıyla karıştırmam.
Llamageddon

Ahh. Bağlantılar için teşekkürler. Onları soruya ekleyebilir misin? Buna göre cevabımı güncelleyeceğim
RichieSams

3
Basit doku atlaslarının (sanal dokular değil) ana dezavantajı IMO, tekrarlama ve kıskaç gibi sarma modlarını kaybetmenizdir ve süzme / mipmaplama - kayan nokta hassasiyetinden dolayı kanama meydana gelir. Normal (sanal olmayan) dokular için kayan nokta hassasiyetinin bir sorun haline gelmesine şaşırdım; 16K'lık bir doku bile (mevcut API'ler tarafından izin verilen maksimum değer) şamandıra hassasiyetini zorlayacak kadar büyük değil.
Nathan Reed

@RichieSams Btw, bence cevabınız farklı bir soru olsa bile, iyi bir cevap. Soru-Cevap yazısı yazmalısınız.
Llamageddon

Hmm, bu oldukça iyi açıklıyor, ancak mip seviyelerinde nasıl çalıştığını gerçekten anlamıyorum. Keşke kendi sorunumu anlamak için
yazabilseydim
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.