Co to jest najnowocześniejszy sposób renderowania tekstu w OpenGL od wersji 4.1? [Zamknięte]

Jest już wiele pytań dotyczących renderowania tekstu w OpenGL, takich jak:

• Jak renderować tekst na żywo w OpenGL dla GUI?

Ale głównie omawiane jest renderowanie teksturowanych quadów przy użyciu potoku o stałej funkcji. Z pewnością shadery muszą mieć lepszy sposób.

Naprawdę nie przejmuję się internacjonalizacją, większość moich ciągów będzie etykietami znaczników wydruku (data i godzina lub czysto numeryczna). Ale wykresy zostaną ponownie renderowane z częstotliwością odświeżania ekranu i może być całkiem sporo tekstu (nie więcej niż kilka tysięcy glifów na ekranie, ale wystarczająco, aby układ z akceleracją sprzętową byłby miły).

Jakie jest zalecane podejście do renderowania tekstu przy użyciu nowoczesnego OpenGL? (Powoływanie się na istniejące oprogramowanie wykorzystujące to podejście jest dobrym dowodem na to, że działa ono dobrze)

• Moduły cieniujące geometrię, które akceptują np. Pozycję i orientację oraz sekwencję znaków i emitują teksturowane kwadraty
• Moduły cieniujące geometrię, które renderują czcionki wektorowe
• Jak wyżej, ale zamiast tego używasz shaderów teselacyjnych
• Moduł obliczeniowy do rasteryzacji czcionek

Kontury renderowania, chyba że renderujesz tylko kilkanaście znaków, pozostaje „nie do przejścia” ze względu na liczbę wierzchołków potrzebnych na znak do przybliżenia krzywizny. Chociaż zamiast tego pojawiły się metody oceny krzywych Beziera w module cieniującym piksele, cierpią one na to, że nie można ich łatwo wygładzić, co jest trywialne przy użyciu quada z teksturą mapy odległości, a ocena krzywych w module cieniującym jest nadal obliczeniowo znacznie droższa niż to konieczne.

Najlepszym kompromisem między „szybkim” i „jakością” są nadal teksturowane quady z podpisaną teksturą pola odległości. Jest bardzo nieznacznie wolniejszy niż zwykły quad o zwykłej fakturze, ale nie tak bardzo. Z drugiej strony jakość jest zupełnie inna. Rezultaty są naprawdę oszałamiające, są tak szybkie, jak to tylko możliwe, a efekty takie jak blask są również banalnie łatwe do dodania. W razie potrzeby technikę można również obniżyć do starszego sprzętu.

Zobacz słynną pracę Valve na temat tej techniki.

Technika ta jest koncepcyjnie podobna do tego, jak działają powierzchnie niejawne (metabelki i tym podobne), chociaż nie generuje wielokątów. Działa całkowicie w module cieniującym piksele i przyjmuje odległość próbkowaną od tekstury jako funkcję odległości. Wszystko powyżej wybranego progu (zwykle 0,5) jest „na wejściu”, wszystko inne jest „na zewnątrz”. W najprostszym przypadku, na 10-letnim sprzęcie nieobsługującym modułu cieniującego, ustawienie progu testu alfa na 0,5 zrobi to dokładnie (choć bez efektów specjalnych i antyaliasingu).
Jeśli ktoś chce dodać nieco więcej ciężaru do czcionki (faux pogrubienie), nieco mniejszy próg załatwi sprawę bez modyfikowania jednego wiersza kodu (wystarczy zmienić mundur „font_weight”). Aby uzyskać efekt blasku, po prostu traktuje się wszystko powyżej jednego progu jako „wejściowe”, a wszystko powyżej drugiego (mniejszego) progu jako „wyjściowe, ale w blasku”, a LERP między nimi. Antialiasing działa podobnie.

Dzięki zastosowaniu 8-bitowej wartości odległości ze znakiem zamiast pojedynczego bitu ta technika zwiększa efektywną rozdzielczość mapy tekstury 16-krotnie w każdym wymiarze (zamiast czerni i bieli używane są wszystkie możliwe odcienie, dlatego mamy 256 razy więcej informacje przy użyciu tego samego magazynu). Ale nawet jeśli powiększysz znacznie powyżej 16x, wynik nadal wygląda całkiem akceptowalnie. Długie proste linie w końcu staną się nieco kręte, ale nie będzie typowych „blokowych” artefaktów próbkowania.

Możesz użyć modułu cieniującego geometrię do generowania quadów poza punktami (zmniejsz przepustowość magistrali), ale szczerze mówiąc, zyski są raczej marginalne. To samo dotyczy instancji renderowania znaków, jak opisano w GPG8. Narzut instancji jest amortyzowany tylko wtedy, gdy masz dużo tekstu do narysowania. Zyski nie są moim zdaniem związane ze zwiększoną złożonością i brakiem możliwości obniżenia. Dodatkowo albo jesteś ograniczony liczbą stałych rejestrów, albo musisz czytać z obiektu bufora tekstur, który nie jest optymalny dla spójności pamięci podręcznej (a celem była optymalizacja na początek!).
Prosty, prosty stary bufor wierzchołków jest równie szybki (być może szybszy), jeśli zaplanujesz wysyłanie nieco wcześniej i będzie działał na każdym sprzęcie zbudowanym w ciągu ostatnich 15 lat. I nie ogranicza się do określonej liczby znaków w czcionce ani do określonej liczby znaków do renderowania.

Jeśli masz pewność, że czcionka nie zawiera więcej niż 256 znaków, tablice tekstur mogą być warte rozważenia w celu usunięcia przepustowości magistrali w podobny sposób, jak generowanie quadów z punktów w module cieniującym geometrię. Podczas korzystania z tekstury tablic współrzędne tekstur wszystkich quadów mają identyczne, stałe si twspółrzędne i różnią się tylko rwspółrzędnymi, które są równe indeksowi znaków do renderowania.
Ale podobnie jak w przypadku innych technik, oczekiwane korzyści są marginalne kosztem niezgodności ze sprzętem poprzedniej generacji.

Istnieje przydatne narzędzie Jonathana Dummera do generowania tekstur odległości: strona opisu

Aktualizacja:
jak ostatnio podkreślono w Programowalnym ciągnięciu wierzchołków (D. Rákos, „OpenGL Insights”, s. 239), nie ma znaczącego dodatkowego opóźnienia ani obciążenia związanego z programowym wyciąganiem danych wierzchołków z modułu cieniującego w najnowszych generacjach GPU, w porównaniu do robienia tego samego przy użyciu standardowej stałej funkcji.
Ponadto najnowsze generacje procesorów graficznych mają coraz bardziej rozsądne rozmiary pamięci podręcznych L2 ogólnego przeznaczenia (np. 1536kiB na nvidii Kepler), więc można się spodziewać niespójnego problemu z dostępem podczas wyciągania losowych przesunięć dla kwadratowych narożników z faktu, że tekstura bufora jest mniej problem.

To sprawia, że ​​pomysł pobierania stałych danych (takich jak rozmiary quadów) z tekstury bufora jest bardziej atrakcyjny. Hipotetyczna implementacja mogłaby zatem ograniczyć do minimum transfery PCIe i pamięci, a także pamięci GPU przy takim podejściu:

• Prześlij tylko indeks znaków (jeden na znak do wyświetlenia) jako jedyny sygnał wejściowy do modułu cieniującego wierzchołków, który przekazuje ten indeks gl_VertexID, i wzmocnij go do 4 punktów w module cieniującym geometrię, wciąż mając indeks znaków i identyfikator wierzchołka (to będzie „gl_primitiveID udostępniony w module cieniującym wierzchołki”) jako jedyne atrybuty i przechwyci 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), a poza tym na obu etapach jest ono zbliżone do „braku operacji”.
• Powiąż teksturę bufora, która zawiera, dla każdego znaku w czcionce, pozycje wierzchołka teksturowanego kwadratu względem punktu bazowego (są to w zasadzie „metryki czcionki”). Dane te można skompresować do 4 liczb na kwadraty, przechowując tylko przesunięcie lewego dolnego wierzchołka i kodując szerokość i wysokość wyrównanego do osi pola (przy założeniu, że półpłynne, będzie to 8 bajtów stałego bufora na znak - typowa 256-znakowa czcionka może całkowicie zmieścić się w 2 kB pamięci podręcznej L1).
• Ustaw jednolitą linię bazową
• Powiąż teksturę bufora z poziomymi przesunięciami. Te mogłyby prawdopodobnie nawet być obliczane na GPU, ale jest o wiele łatwiejsze i bardziej wydajne, aby tego rodzaju rzeczy na CPU, ponieważ jest ściśle sekwencyjne działanie i wcale trywialne (myślę o kerningu). Potrzebny byłby także kolejny sygnał zwrotny, który byłby kolejnym punktem synchronizacji.
• Renderuj wcześniej wygenerowane dane z bufora sprzężenia zwrotnego, moduł cieniujący wierzchołki wyciąga poziome przesunięcie punktu bazowego i przesunięcia wierzchołków narożnych z obiektów buforowych (używając pierwotnego identyfikatora i indeksu znaków). Oryginalny identyfikator wierzchołka przesłanych wierzchołków jest teraz naszym „prymitywnym identyfikatorem” (pamiętaj, że GS zamienił wierzchołki w kwadraty).

W ten sposób można idealnie zmniejszyć wymaganą szerokość pasma wierzchołków o 75% (amortyzowaną), chociaż byłby w stanie renderować tylko jedną linię. Jeśli ktoś chciałby być w stanie renderować kilka linii w jednym wywołaniu losowania, musiałby dodać linię bazową do tekstury bufora, zamiast używać jednolitego (zmniejszając przepustowość).

Jednak nawet przy założeniu zmniejszenia o 75% - ponieważ dane wierzchołków wyświetlające „rozsądne” ilości tekstu wynoszą tylko około 50-100kiB (czyli praktycznie zerodo procesora graficznego lub magistrali PCIe) - wciąż wątpię, aby dodatkowa złożoność i utrata kompatybilności wstecznej naprawdę były warte kłopotu. Zmniejszenie zera o 75% to wciąż tylko zero. Wprawdzie nie wypróbowałem powyższego podejścia i potrzeba więcej badań, aby uzyskać prawdziwie kwalifikowane oświadczenie. Ale jeśli ktoś nie jest w stanie wykazać naprawdę oszałamiającej różnicy w wydajności (używając „normalnych” ilości tekstu, a nie miliardów znaków!), Mój punkt widzenia pozostaje taki, że w przypadku danych wierzchołków prosty, zwykły stary bufor wierzchołków jest wystarczająco dobry być uważane za część „najnowocześniejszego rozwiązania”. To proste i jednoznaczne, działa i działa dobrze.

Odnosząc się już do „ OpenGL Insights ” powyżej, warto również zwrócić uwagę na rozdział „Rendering kształtu 2D według pól odległości” autorstwa Stefana Gustavsona, który wyjaśnia szczegółowo renderowanie pola 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 przy ekstremalnych powiększeniach.

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 obrysu, ale do obrysu lub wyimaginowanej linii wystającej ponad krawędź). Jest to nieco lepsze i działa z tą samą prędkością (identyczny moduł cieniujący), wykorzystując tę ​​samą ilość pamięci tekstur.

Inne podejście wykorzystuje medianę z trzech w trzykanałowych szczegółach tekstury i implementacji dostępnych w github . Ma to na celu poprawę w stosunku do i-lub hacków używanych wcześniej do rozwiązania tego problemu. Dobra jakość, nieco, prawie nie zauważalnie, wolniej, ale zużywa trzy razy więcej pamięci tekstur. Ponadto trudniej jest uzyskać dodatkowe efekty (np. Blask).

Wreszcie, przechowywanie rzeczywistych krzywych Beziera tworzących postacie i ocena ich w shaderze fragmentów stało się praktyczne , z nieco gorszą wydajnością (ale nie tak bardzo, że to problem) i oszałamiającymi wynikami nawet przy największych powiększeniach.
Demo WebGL renderujące duży plik PDF z tą techniką w czasie rzeczywistym dostępny tutaj .

http://code.google.com/p/glyphy/

Główną różnicą między GLyphy a innymi rendererami OpenGL opartymi na SDF jest to, że większość innych projektów próbkuje SDF do tekstury. Ma to wszystkie typowe problemy związane z próbkowaniem. To znaczy. zniekształca kontur i jest niskiej jakości. Zamiast tego GLyphy reprezentuje SDF przy użyciu rzeczywistych wektorów przesłanych do GPU. Powoduje to renderowanie bardzo wysokiej jakości.

Minusem jest to, że kod jest dla iOS z OpenGL ES. Prawdopodobnie zamierzam utworzyć port OpenGL 4.x systemu Windows / Linux (mam nadzieję, że autor doda trochę prawdziwej dokumentacji).

Najbardziej rozpowszechnioną techniką są nadal teksturowane quady. Jednak w 2005 roku LORIA opracowała coś, co nazywa się teksturami wektorowymi, tj. Renderuje grafikę wektorową jako tekstury na prymitywach. Jeśli użyjesz tego do konwersji czcionek TrueType lub OpenType na teksturę wektorową, otrzymasz:

http://alice.loria.fr/index.php/publications.html?Paper=VTM@2005

Jestem zaskoczony, że dziecko Marka Kilgarda, NV_path_rendering (NVpr), nie zostało wspomniane przez żadne z powyższych. Chociaż jego cele są bardziej ogólne niż renderowanie czcionek, może również renderować tekst z czcionek i przy użyciu kerningu. Nie wymaga nawet OpenGL 4.1, ale w tej chwili jest to rozszerzenie tylko dla dostawców / Nvidii. Zasadniczo zamienia czcionki w ścieżki, glPathGlyphsNVktórych użycie zależy od biblioteki freetype2, aby uzyskać metryki itp. Następnie można również uzyskać dostęp do informacji o kerningu za pomocąglGetPathSpacingNV i użyć ogólnego mechanizmu renderowania ścieżki NVpr do wyświetlenia tekstu z użyciem czcionek „przekonwertowanych” na ścieżkę. (Umieszczam to w cudzysłowie, ponieważ nie ma prawdziwej konwersji, krzywe są używane w obecnej postaci).

Nagrane demo możliwości czcionek NVpr za nie jest niestety szczególnie imponujące. (Być może ktoś powinien stworzyć taki, jak w przypadku bardziej snajperskiego dema SDF można znaleźć na intertubach ...)

Omówienie prezentacji API NVpr 2011 dla części dotyczącej czcionek rozpoczyna się tutaj i jest kontynuowane w następnej części ; to trochę niefortunne, jak ta prezentacja jest podzielona.

Bardziej ogólne materiały na NVpr:

• Centrum Nvidia NVpr , ale niektóre materiały na stronie docelowej nie są najbardziej aktualne
• Praca Siggraph 2012 dla mózgów metody renderowania ścieżek, zwana „szablonem, a następnie okładką” (StC); artykuł krótko wyjaśnia również, jak działają konkurencyjne technologie, takie jak Direct2D. Bity związane z czcionkami zostały przeniesione do załącznika artykułu . Istnieją również dodatki, takie jak filmy / wersje demo .
• Prezentacja GTC 2014 dla statusu aktualizacji; w skrócie: jest teraz obsługiwany przez Google Skia (Nvidia napisała kod pod koniec 2013 i 2014), który z kolei jest używany w Google Chrome i [niezależnie od Skii, jak sądzę] w wersji beta Adobe Illustrator CC 2014
• oficjalna dokumentacja w rejestrze rozszerzeń OpenGL
• USPTO udzieliło co najmniej czterech patentów Kilgard / Nvidia w związku z NVpr, o których prawdopodobnie powinieneś wiedzieć, na wypadek, gdybyś chciał sam wdrożyć StC: US8698837 , US8698808 , US8704830 i US8730253 . Zauważ, że istnieje coś takiego jak 17 innych dokumentów USPTO związanych z tym jako „również opublikowane jako”, z których większość to wnioski patentowe, więc jest całkiem możliwe, że z nich można uzyskać więcej patentów.

A ponieważ słowo „szablon” nie spowodowało żadnych trafień na tej stronie przed moją odpowiedzią, wydaje się, że podgrupa społeczności SO, która uczestniczyła w tej stronie, mimo że jest dość liczna, nie była świadoma braku mozaikowania, bufora szablonów - ogólne metody renderowania ścieżek / czcionek. Kilgard opublikował post podobny do FAQ na forum Opengl, który może wyjaśnić, w jaki sposób wolne od mozaikowania metody renderowania ścieżek różnią się od standardowych torfowisk 3D, mimo że nadal używają procesorów graficznych [GP]. (NVpr potrzebuje układu obsługującego CUDA.)

Z historycznego punktu widzenia Kilgard jest także autorem klasycznego „A Simple API opartego na OpenGL dla Text Mapped Text”, SGI, 1997 , którego nie należy mylić z NVpr opartym na szablonach, który zadebiutował w 2011 roku.

Większość, jeśli nie wszystkie najnowsze metody omówione na tej stronie, w tym metody oparte na szablonach, takie jak NVpr lub metody oparte na SDF, takie jak GLyphy (których nie omawiam tutaj dalej, ponieważ inne odpowiedzi już to obejmują) mają jednak jedno ograniczenie: są nadaje się do wyświetlania dużych tekstów na konwencjonalnych monitorach (~ 100 DPI) bez postrzępień na dowolnym poziomie skalowania, a także ładnie wyglądają, nawet przy małych rozmiarach, na wyświetlaczach o wysokiej rozdzielczości DPI przypominających siatkówkę. Nie zapewniają one jednak w pełni tego, co oferuje Direct2D + DirectWrite firmy Microsoft, a mianowicie podpowiedzi małych glifów na ekranach głównego nurtu. (Ogólną ankietę dotyczącą podpowiedzi można znaleźć na przykład na stronie z typografią . Bardziej szczegółowe zasoby znajdują się na antigrain.com .)

Nie jestem świadomy żadnych otwartych i produkowanych rzeczy opartych na OpenGL, które mogłyby zrobić to, co Microsoft może teraz zrobić z podpowiedziami. (Przyznaję, że ignorowanie wewnętrznych elementów systemu Apple OS X GL / Quartz, ponieważ o ile mi wiadomo, Apple nie opublikowało, w jaki sposób robią czcionki / ścieżki renderujące na podstawie GL. Wygląda na to, że OS X, w przeciwieństwie do MacOS 9, nie w ogóle rób podpowiedzi, co denerwuje niektórych ludzi .) W każdym razie istnieje jeden artykuł badawczy z 2013 r., który zajmuje się podpowiedziami za pomocą shaderów OpenGL napisanych przez Nicolasa P. Rougiera z INRIA; prawdopodobnie warto przeczytać, jeśli potrzebujesz podpowiedzi z OpenGL. Choć może się wydawać, że biblioteka taka jak freetype już wykonuje całą pracę, jeśli chodzi o podpowiedzi, tak naprawdę nie jest tak z następującego powodu, który cytuję z gazety:

Biblioteka FreeType może rasteryzować glif przy użyciu wygładzania subpikseli w trybie RGB. Jest to jednak tylko połowa problemu, ponieważ chcemy również uzyskać pozycjonowanie subpikseli w celu dokładnego umieszczenia glifów. Wyświetlanie teksturowanego kwadratu we współrzędnych ułamkowych pikseli nie rozwiązuje problemu, ponieważ skutkuje interpolacją tekstury na poziomie całego piksela. Zamiast tego chcemy osiągnąć precyzyjne przesunięcie (między 0 a 1) w domenie subpikseli. Można to zrobić w shaderze fragmentów [...].

Rozwiązanie nie jest do końca trywialne, więc nie zamierzam tutaj tego wyjaśniać. (Papier jest otwarty).

Inną rzeczą, której nauczyłem się z pracy Rougiera (i której Kilgard wydaje się nie brać pod uwagę), jest to, że moc czcionki, którą są (Microsoft + Adobe), stworzyła nie jedną, ale dwie metody specyfikacji kerningu. Stary oparty jest na tak zwanej tabeli kern i jest obsługiwany przez freetype. Nowy nazywa się GPOS i jest obsługiwany tylko przez nowsze biblioteki czcionek, takie jak HarfBuzz lub pango w świecie wolnego oprogramowania. Ponieważ NVpr wydaje się nie obsługiwać żadnej z tych bibliotek, kerning może nie działać od razu z NVpr dla niektórych nowych czcionek; według tej dyskusji na forum są niektóre z nich na wolności .

Na koniec, jeśli potrzebujesz wykonać złożony układ tekstu (CTL) , wydaje ci się, że nie masz szczęścia z OpenGL, ponieważ wydaje się, że nie istnieje dla niego biblioteka oparta na OpenGL. (DirectWrite z drugiej strony może obsługiwać CTL.) Istnieją biblioteki o otwartym kodzie źródłowym, takie jak HarfBuzz, które mogą renderować CTL, ale nie wiem, jak sprawić, by działały dobrze (tak jak przy użyciu metod opartych na szablonach) za pośrednictwem OpenGL. Prawdopodobnie będziesz musiał napisać kod kleju, aby wyodrębnić zmienione kształty i wprowadzić je jako rozwiązania do rozwiązań opartych na NVpr lub SDF.

Myślę, że najlepszym rozwiązaniem byłoby zajrzenie do grafiki Cairo z backendem OpenGL.

Jedynym problemem, jaki miałem podczas tworzenia prototypu z rdzeniem 3.3, było przestarzałe użycie funkcji w backendu OpenGL. To było 1-2 lata temu, więc sytuacja mogła się poprawić ...

W każdym razie mam nadzieję, że w przyszłości sterowniki graficzne OpenGL do komputerów stacjonarnych będą implementować OpenVG.