Na czym polega najnowocześniejsze renderowanie tekstu w OpenGL od wersji 4.1? [zamknięte]

Renderowanie konturów, o ile nie wyrenderuje się łącznie tylko kilkunastu znaków, pozostaje "no go" ze względu na liczbę wierzchołków potrzebnych do przybliżenia krzywizny na znak. Chociaż istnieją podejścia do oceny krzywych Beziera w shaderze pikseli zamiast tego, cierpią one z powodu braku łatwego antyaliasingu, co jest trywialne przy użyciu kwadratu z teksturą mapy odległości, A ocena krzywych w shaderze jest nadal znacznie droższa niż jest to konieczne.

Najlepszy kompromis pomiędzy "szybkie "i" jakość " to nadal teksturowane quady z podpisaną teksturą pola odległości. Jest to bardzo nieznacznie wolniejsze niż użycie zwykłego kwadratu o zwykłej fakturze, ale nie tak bardzo. Jakość z drugiej strony, jest w zupełnie innym polu. Wyniki są naprawdę oszałamiające, jest tak szybko, jak to możliwe, a efekty, takie jak blask, są trywialnie łatwe do dodania. Ponadto, technika może być ładnie obniżona do starszego sprzętu, w razie potrzeby.

Zobacz słynny Papier Valve dla technika.

Używając 8-bitowej wartości odległości podpisanej zamiast pojedynczego bitu, technika ta zwiększa efektywną rozdzielczość mapy tekstur 16-krotnie w każdym wymiarze (zamiast czerni i bieli używane są wszystkie możliwe odcienie, dlatego mamy 256 razy więcej informacji przy użyciu tej samej pamięci masowej). Ale nawet jeśli powiększysz znacznie ponad 16x, wynik nadal wygląda na całkiem akceptowalny. Długie proste linie w końcu staną się nieco wiotkie, ale nie będzie typowych" blokowych " artefaktów próbkowania.

Możesz użyć shadera geometry do generowania quady poza punktami (zmniejszają przepustowość magistrali), ale szczerze mówiąc zyski są raczej marginalne. To samo dotyczy renderowania postaci z instancji, jak opisano w GPG8. Narzut instancji jest amortyzowany tylko wtedy, gdy masz lot tekstu do narysowania. Moim zdaniem zyski nie mają związku z dodaną złożonością i brakiem możliwości obniżenia ratingu. Dodatkowo, jesteś ograniczony ilością stałych rejestrów lub musisz czytać z obiektu bufora tekstury, który nie jest optymalny dla pamięci podręcznej spójność (a intencją było Optymalizacja na początek!).
Prosty, zwykły stary bufor wierzchołków jest tak samo szybki (być może szybszy), jeśli zaplanujesz przesyłanie z wyprzedzeniem i będzie działać na każdym sprzęcie zbudowanym w ciągu ostatnich 15 lat. Nie ogranicza się do żadnej określonej liczby znaków w czcionce ani do określonej liczby znaków do renderowania.

Jeśli masz pewność, że nie masz więcej niż 256 znaków w czcionce, tablice tekstur mogą być warte rozważenie usunięcia pasma magistrali w podobny sposób, jak generowanie quadów z punktów w shaderze geometry. Podczas używania tekstury tablicy, współrzędne tekstury wszystkich quadów mają identyczne, stałe współrzędne s i t i różnią się tylko współrzędną r, która jest równa indeksowi znaków do renderowania.
Ale podobnie jak w przypadku innych technik, oczekiwane zyski są marginalne kosztem niekompatybilności ze sprzętem poprzedniej generacji.

Jest poręczny narzędzie Jonathana Dummera do generowania tekstur odległości: strona opisu

Update:
Jak ostatnio wspomniano w Programmable Vertex Pulling (D. Rákos, "OpenGL Insights", str. 239), nie ma znaczącego dodatkowego opóźnienia lub narzutu związanego z programowym pobieraniem danych wierzchołków z shadera na najnowszych generacjach GPU, w porównaniu do robienia tego samego przy użyciu standardowej stałej funkcji.
Również najnowsze generacje GPU 1536kib na nvidia Kepler), więc można się spodziewać niespójnego problemu z dostępem, gdy wyrywa się losowe przesunięcia dla narożników quad z tekstury bufora, będąc mniejszym problemem.

To sprawia, że pomysł pobierania stałych danych (takich jak rozmiary quad) z tekstury bufora jest bardziej atrakcyjny. Hipotetyczna implementacja mogłaby zatem zredukować do minimum transfery PCIe i pamięci, a także pamięci GPU to:

• prześlij tylko indeks znaków (po jednym na każdy znak, który ma być wyświetlony) jako jedyne wejście do modułu cieniującego wierzchołki, który przekazuje ten indeks i gl_VertexID, i zwiększ go do 4 punktów w module cieniującym geometry, nadal mając indeks znaków i identyfikator wierzchołka (będzie to "gl_primitiveID udostępnione w module cieniującym wierzchołki") jako jedyne atrybuty, i przechwyć to poprzez sprzężenie zwrotne transformacji.
• będzie to szybkie, ponieważ istnieją tylko dwa atrybuty wyjściowe (główne wąskie gardło w GS), i jest blisko "no-op" inaczej w obu etapach.
• Bind teksturę bufora, która zawiera, dla każdego znaku w czcionce, teksturowane wierzchołki czworokąta względem punktu bazowego (są to zasadniczo "metryki czcionek"). Dane te mogą być skompresowane do 4 liczb na kwadrat, przechowując tylko przesunięcie lewego dolnego wierzchołka i kodując szerokość i Wysokość pola wyrównanego do osi (zakładając połowy pływaków, będzie to 8 bajtów stałego bufora na znak -- typowy Czcionka 256 znaków może zmieścić się całkowicie w 2kiB pamięci podręcznej L1).
• Ustaw uniform dla linii bazowej
• wiąże teksturę bufora z poziomymi przesunięciami. Te mogłyby być prawdopodobnie nawet obliczone na GPU, ale jest to znacznie łatwiejsze i bardziej wydajne dla tego typu rzeczy na CPU, ponieważ jest to operacja ściśle Sekwencyjna i wcale nie trywialna (pomyśl o kerningu). Wymagałoby to również kolejnego przejścia sprzężenia zwrotnego, który byłby kolejnym punktem synchronizacji.
• Render the wcześniej wygenerowane dane z bufora sprzężenia zwrotnego, shader wierzchołków pobiera poziome przesunięcie punktu bazowego i przesunięcia narożnych wierzchołków z obiektów bufora (używając prymitywnego identyfikatora i indeksu znaków). Oryginalny identyfikator przesłanych wierzchołków jest teraz naszym "prymitywnym identyfikatorem" (pamiętaj, że GS zamieniło wierzchołki w quady).

W ten sposób można by idealnie zredukować wymagane pasmo wierzchołków o 75% (amortyzowane), chociaż byłoby to tylko w stanie renderować pojedyncza linia. Jeśli ktoś chciałby móc renderować kilka linii w jednym wywołaniu rysowania, musiałby dodać linię bazową do tekstury bufora, zamiast używać jednolitej (zmniejszając przyrosty przepustowości).

Jednak nawet zakładając redukcję o 75% - ponieważ dane wierzchołków do wyświetlania "rozsądnych" ilości tekstu są tylko około 50-100kib (co jest praktycznie zero dla GPU lub magistrali PCIe) - nadal wątpię, że dodatkowa złożoność i utrata kompatybilności wstecznej jest naprawdę warto. Zmniejszenie zera o 75% to nadal tylko zero. Przyznaję, że nie próbowałem powyższego podejścia, a więcej badań byłoby potrzebne, aby złożyć prawdziwie kwalifikowane oświadczenie. Ale i tak, chyba że ktoś potrafi wykazać naprawdę oszałamiającą różnicę w wydajności (używając "normalnych" ilości tekstu, a nie miliardów znaków!), mój punkt widzenia pozostaje, że dla danych wierzchołków prosty, zwykły stary bufor wierzchołków jest na tyle dobry, że można go uznać za część "najnowocześniejszego rozwiązania". To proste i proste, działa i działa dobrze.

Nawiązując już do "OpenGL Insights" powyżej, warto również zwrócić uwagę na Rozdział "renderowanie kształtów 2D przez pola odległości" autorstwa Stefana Gustavsona, który szczegółowo wyjaśnia renderowanie pól odległości.

Aktualizacja 2016:

Tymczasem istnieje kilka dodatkowych technik, które mają na celu usunięcie artefaktów zaokrąglania narożników, które stają się niepokojące w ekstremalnych powiększenia.

Jedno podejście po prostu używa pól pseudo-odległości zamiast pól odległości (różnica polega na tym, że odległość jest najkrótszą odległością nie do rzeczywistego konturu, ale do konturu lub wyimaginowanej linii wystającej ponad krawędź). Jest to nieco lepsze i działa z tą samą prędkością (identyczny shader), używając tej samej ilości pamięci tekstur.

Inne podejście wykorzystuje medianę z trzech w trójkanałowych szczegółach tekstury i implementacji [[80]}dostępny na github . Ma to być poprawa w stosunku do hacków and-or używanych wcześniej do rozwiązania problemu. Dobra jakość, lekko, prawie nie zauważalnie, wolniej, ale wykorzystuje trzy razy więcej pamięci tekstur. Ponadto, dodatkowe efekty (np. blask) są trudniejsze do uzyskania.

Wreszcie, przechowywanie rzeczywistych krzywych Beziera tworzących znaki i ocenianie ich w cieniowaniu fragmentów stało się praktyczne , z nieco gorszą wydajnością (ale nie tak bardzo, że jest to problem) i oszałamiające wyniki nawet przy najwyższych powiększeniach.
Demo WebGL renderowanie dużego pliku PDF z tą techniką w czasie rzeczywistym dostępne tutaj .