Jaka jest najlepsza metoda LOD do renderowania planet?

Obecnie pracuję nad moją tezą, jest to silnik do renderowania terenów o rozmiarach planet.

Wciąż kończę badania i napotkałem wiele rzeczy na ten temat, problem polega na tym, że nie mogę zdecydować, którą metodę poziomu szczegółowości (LOD) powinienem zastosować.

Wiem o geomipmapowaniu, mapowaniu geometrii (GPU) i dzielonym LOD firmy Ulrich, które działają dobrze na dużych terenach i mogą być używane do renderowania 6 ścian sześcianu, a następnie „sfotografowania” sześcianu za pomocą tej metody i rozumiem, jak zaimplementować wszystkie te metody na GPU przy użyciu C ++ / OpenGL / GLSL (przy użyciu metod takich jak ROAM lub jakakolwiek inna metoda, która nie używa kostki, jest poza moim zasięgiem, ponieważ teksturowanie jest uciążliwe). Również niedawno dostał w tutorialu terenów renderingu z wykorzystaniem shaderów teselacji tutaj

Nie mam czasu na wdrażanie WSZYSTKICH metod i sprawdzanie, która z nich jest najlepsza i bardziej odpowiednia dla skali planetarnej, i pytam tutaj, czy ktoś dokonał tego rodzaju porównania i pomógł mi zdecydować, która metoda powinienem wdrożyć i używać (mój nauczyciel jest trochę szalony i chce, żebym zrobił coś z dwudziestościanem, ale nie mogę zrozumieć tej metody, chyba że użyję ROAM)

W każdym razie, jeśli możesz mi pomóc w podjęciu decyzji lub uzyskać inną sugestię lub metodę, którą naprawdę docenię. Jednym z warunków jest to, że metoda powinna być w stanie zaimplementować stronę GPU (przynajmniej większość), aby uniknąć wąskiego gardła procesora.

Kolejna prośba jest taka, że ​​wiem, że istnieją problemy numeryczne dotyczące precyzji z pływakami podczas uzyskiwania wielu szczegółów w terenie, nie wiem, jak to rozwiązać, czytam rozwiązanie na forum, ale nie mogę zrozumieć, jak to zrobić implement, straciłem kontrolę nad tym wątkiem i chciałbym wiedzieć, jak rozwiązać ten problem z precyzją.

Obecnie czytam o niektórych transformacjach macierzy, aby rozwiązać precyzję ruchu zmiennoprzecinkowego, problemy z walką z Z, wybijanie frustum za pomocą dynamicznych wartości Z i reprezentację danych dla fragmentów (użycie przestrzeni łat z liczbami zmiennymi i jej pozycji we współrzędnych świata jako podwójnych), więc Myślę, że mogę łatwo rozwiązać problem precyzji. Nadal potrzebuję porównania metod LOD z Twoimi opiniami i sugestiami, aby zdecydować, które rozwiązanie jest lepsze dla tego projektu. Weź pod uwagę trudność implementacji vs jakość wizualna vs wydajność, chcę tego, co najlepsze.

Coś, o czym zapomniałem wspomnieć, to że generacja jest hybrydowa, mam na myśli, że powinienem być w stanie renderować planetę całkowicie przy użyciu GPU (wysokości obliczane w locie) i / lub przy użyciu podstawowego obrazu mapy wysokości i dodawać szczegóły za pomocą GPU (wierzchołek shader). Teksturowanie będzie częścią boczną, z którą będę się później zajmować, teraz cieszę się, że używam tylko kolorów w zależności od wysokości, a może używam jakiegoś rodzaju tekstury szumu generowanej na module cieniującym fragmenty.

Wreszcie, po wielu badaniach, mogę stwierdzić, że, jak ktoś wcześniej powiedział, nie ma uniwersalnej „najlepszej” metody. Ale moje badania doprowadziły mnie do znajomości następujących rzeczy:

W zależności od siatki w końcu użyjesz:

• Spherified Cube: każda metoda LOD z implementacją quadtree będzie działać dobrze, musisz tylko zadbać o specjalne przypadki, takie jak granice między twarzami, w którym to przypadku twój quadree musi mieć wskaźnik do sąsiada na sąsiedniej twarzy na każdym poziomie.
• Każda inna: myślę, że ROAM (nowsza wersja 2.0 lub dowolne inne rozszerzenie jak BDAM, CABTT lub RUSTIC) poradzi sobie dobrze, jednak te algorytmy są trudne do pracy, wymagają więcej pamięci i są nieco wolniejsze niż inne podejścia z kostkami.

Istnieje wiele metod LOD, które mogą dobrze pasować, ale moje osobiste 5 najlepszych to:

1. Ciągłe zależne od odległości LOD (CDLOD)
2. Geomety Clipmaps oparte na GPU (GPUGCM)
3. Chunked LOD
4. Renderowanie terenów z teselacją GPU OpenGL (książka: OpenGL Insight, rozdział 10)
5. Geometrical MipMapping

Każdy z nich oferuje unikalny sposób renderowania terenów, na przykład CDLOD ma bardzo łatwą implementację za pomocą shaderów (GLSL lub HLSL), ale może być również implementowany na procesorze (dla starszych urządzeń), jednak celem Planet Rendering jest eksplozja najlepszy na współczesnych procesorach graficznych, więc GPUGCM jest najlepszy, gdy chcesz ścisnąć swój GPU. Oba działają bardzo dobrze w przypadku renderowania dużych terenów w oparciu o dane, procedury lub mieszane (teren oparty na ustalonych danych lub mapach wysokości i szczegółach dodanych do prac proceduralnych).

Istnieje również rozszerzenie sferyczne podstawowej metody Geometrical Clipmaps, ale ma pewne problemy, ponieważ próbki płaskie mapy wysokości muszą zostać sparametryzowane za pomocą współrzędnych sferycznych.

Chunked LOD, z drugiej strony, jest idealny dla starszego sprzętu, nie wymaga żadnych obliczeń po stronie GPU do pracy, jest idealny dla dużych zestawów danych, ale nie może obsługiwać danych proceduralnych w czasie rzeczywistym (może z pewnymi modyfikacjami, może)

Korzystanie z shaderów Tessellation to kolejna technika, bardzo nowa, odkąd pojawił się OpenGL 4.x. Moim zdaniem może być najlepszy, ale mówimy o renderowaniu planet, napotykamy problem, który inne metody mogą poradzić sobie bardzo łatwo i jest to o precyzji.

Jeśli nie chcesz, aby Twoja precyzja wynosiła tylko 1 km między wierzchołkami, wybierz shadery Tesselacji. Problem z naprawdę dużymi terenami z tą metodą polega na tym, że jitter jest trudny do rozwiązania (a przynajmniej dla mnie, ponieważ jestem nowy w shadery teselacyjnym).

Geomipmapping jest świetną techniką, wykorzystuje quadtree i ma niski błąd rzutowania pikseli, ale do renderowania planetarnego będziesz musiał ustawić co najmniej 16+ poziomów szczegółów, co oznacza, że ​​będziesz potrzebował (do zszywania celów) dodatkowych łatek łączenie różnych poziomów i dbanie o poziom sąsiada może być żmudne do rozwiązania, szczególnie przy użyciu 6 ścian terenu.

Istnieje jeszcze jedna metoda, szczególnie sama w sobie: „Mapowanie siatki projekcyjnej dla terenu planetarnego” doskonała do wizualizacji, ale ma swoje wady, jeśli chcesz dowiedzieć się więcej, przejdź do linku.

Problemy:

• Jitter : Większość współczesnych układów GPU obsługuje tylko 32-bitowe wartości zmiennoprzecinkowe, co nie zapewnia wystarczającej precyzji do manipulowania dużymi pozycjami w terenach o skali planetarnej. Jitter pojawia się, gdy przeglądarka powiększa się, obraca lub porusza, a następnie wielokąty zaczynają się odbijać w przód iw tył.

  Najlepszym rozwiązaniem jest użycie metody „Rendering względem oka za pomocą GPU”. Metodę tę opisano w książce „3D Engine Design for Virtual Globes” (jestem pewien, że można ją również znaleźć w Internecie), w której zasadniczo musisz ustawić wszystkie swoje pozycje z podwójnymi wartościami na procesorze (łatki, clipmapy, obiekty, frustrum, kamera itp.), a następnie MV jest wyśrodkowany wokół widza, ustawiając jego tłumaczenie na (0, 0, 0) T, a podwójne są kodowane w stałej reprezentacji przy użyciu bitów ułamkowych (mantysy) dwóch pływaków, nisko i wysoki jakąś metodą (przeczytaj o użyciu implementacji Ohlarika i biblioteki Fortran DSFUN90).

  Chociaż moduł cieniujący wierzchołki wymaga tylko dwóch dodatkowych odejmowań i jednego dodania, GPU RTE podwaja ilość pamięci bufora wierzchołków wymaganej dla pozycji. To niekoniecznie podwaja wymagania dotyczące pamięci, chyba że przechowywane są tylko pozycje.

• Precision Buffer Depth : walka Z. Ponieważ renderujemy bardzo duże tereny, w tym przypadku: planety, bufor Z musi być OGROMNY, ale nie ma znaczenia, jakie wartości ustawisz dla znear i zfar, zawsze będą problemy.

  Ponieważ bufor Z zależy od interwału punktu zmiennoprzecinkowego, a także jest liniowy (chociaż rzut perspektywiczny jest nieliniowy), wartości w pobliżu oka cierpią z powodu walki Z, ponieważ brak precyzji 32-bitowych pływaków ma.

  Najlepszym sposobem rozwiązania tego problemu jest użycie „Logarithmic Depth Buffer” http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

  Logarytmiczny bufor głębokości poprawia precyzję bufora głębokości dla odległych obiektów dzięki zastosowaniu rozkładu logarytmicznego dla zscreen. Wymienia precyzję na bliskie obiekty na precyzję na odległe obiekty. Ponieważ renderujemy za pomocą metody LOD, dalekie obiekty wymagają mniejszej precyzji, ponieważ mają mniej trójkątów.

Należy wspomnieć o tym, że wszystkie wymienione metody (oprócz siatki rzutowej) są bardzo dobre podczas fizyki (głównie kolizje) z powodu podstawy Quadtree, co jest obowiązkowe, jeśli planujesz stworzyć grę.

Podsumowując, po prostu sprawdź wszystkie dostępne opcje i wybierz tę, którą uważasz za wygodniejszą, moim zdaniem CDLOD robi świetną robotę. Nie zapomnij rozwiązać problemów z fluktuacjami i buforem Z, a co najważniejsze: baw się dobrze!

Aby uzyskać więcej informacji o LOD, sprawdź ten link .

Aby uzyskać pełną prezentację dotyczącą sfingowania sześcianu, sprawdź ten link .

Aby uzyskać lepsze wyjaśnienie dotyczące rozwiązywania problemów związanych z drganiami i buforowaniem Z, zapoznaj się z tą książką .

Mam nadzieję, że ta mała recenzja okaże się przydatna.