Optymalizacja siatki dla krajobrazów kostek wokseli

12

Bawiąc się tworzeniem krajobrazów świata Minecraftish / Lego w Unity 3D (generowane proceduralnie krajobrazy wokselowe z kostkami), stwierdzam, że siatki stworzone dla tych krajobrazów zajmują dużo pamięci. Siatka składa się obecnie tylko z wierzchołków widocznych boków sześcianu. Zużycie pamięci w złożonym terenie może zająć 6 lub 7set megapikseli.

Te siatki można zoptymalizować, ale staram się znaleźć porządny algorytm, aby to zrobić.

Algorytm musi wziąć pod uwagę, że nie chcesz „scalać” bloków różnych typów terenu. Wydaje mi się, że naprawdę prostym początkiem może być po prostu przetworzenie wszystkich bloków wzdłuż jednej osi i wykonanie dodatkowych przeciągnięć dla pozostałych dwóch osi.

Muszę zachować kształt siatki, czyli nie scalać wierzchołków do punktu, w którym zmienia się pusta lub pełna przestrzeń. Powodem jest to, że mogą istnieć stworzenia / itp., Które nadal muszą poruszać się po siatce. Nie mogę więc po prostu stworzyć zniekształconej siatki o bardzo niskim poziomie szczegółowości.

Wszelkie przemyślenia / sugestie / wskazówki na ten temat?

James Livingston
źródło
2
Dlaczego przechowujesz wierzchołki kostki o znanym rozmiarze? Zrób to algorytmicznie; lub użyj wspólnego bufora wierzchołków.
spowolniłaviar
Dlaczego siatka wielokątna? Voxel można renderować całkiem skutecznie, tak jak są . Dla jednej kostki wokseli potrzebujesz 3 pływaków (x, y, z), dla 1 pudełka potrzebujesz około 8 * 3 pływaków (8 wierzchołków), i to w przypadku, gdy masz niejawne krawędzie i wielokąty. Może Unity nie jest narzędziem tego problemu z wokselami.
user712092,

Odpowiedzi:

5

Moje pytanie brzmi:

Dlaczego potrzebowałbyś samej siatki do poruszania się stworzeń?

Nie możesz wykonać obliczenia ścieżki na macierzy 3D ID?

Myślę, że Minecraft używa matrycy 3D z blokiem 4 bitów na blok. Symuluje także stworzenia o określonym promieniu wokół gracza.

Możesz przechowywać swoje części w strukturze drzewa-oc, gdzie każda część jest kompresowana.

Jeśli przechowujesz skompresowane dane w pamięci RAM, możesz w razie potrzeby dość szybko zdekompresować dane.

alternatywny tekst

Mistrz
źródło
Opierałem się na siatce do wbudowanego wykrywania kolizji w Unity, ale nic nie powstrzyma mnie od testowania kolizji / ścieżkowania względem niestandardowej struktury danych. Jednak nadal muszę utworzyć widoczną siatkę do wyświetlania terenu i właśnie to muszę zoptymalizować.
James Livingston,
Jeszcze jeden punkt ... jak widać na zrzucie ekranu ... nie ma dużo tego płaskiego terenu. Siatki są ogólnie szorstkimi powierzchniami kostek, ale myślę, że jest miejsce na optymalizację powierzchni / wierzchołków siatki. Wygląda na to, że oktree byłby najlepszy dla danych, które zawierają wiele podobnych bloków danych, zamiast danych „postrzępionych”. Czy to nie jest poprawne?
James Livingston,
@Gatorfrog: Pamiętaj, że puste miejsce to także dane. jeśli jest postrzępiony, to na pewno będzie wiele bitów sygnalizujących, że jest pusty. Oktree jest po to, abyś mógł dowiedzieć się, które fragmenty należy zdekompresować przed ich renderowaniem. Puste miejsce będzie tylko wiązką zer. Moja praca polega na pracy z bardzo wyrafinowaną biblioteką renderowania wokseli. Mój następny post opisuje, co robią.
Nailer
Biblioteka, z którą pracuję, wykonuje następujące czynności: Tworzy fragmenty danych i przechowuje je w płaskiej bazie danych plików. Każda część ma identyfikator. Każda kostka składa się z wielu części. Dla każdego fragmentu tworzona jest pewna liczba poziomów szczegółowości. Tam, gdzie najwyższy poziom szczegółowości ma 100% wokseli, drugi najwyższy ma 25% wszystkich wokseli, a następnie dzieli się przez 4 dla każdego kolejnego poziomu. Fragmenty znajdujące się w pobliżu można wizualizować przy użyciu najwyższego poziomu szczegółowości.
Nailer
wszystkie dane są przesyłane w formie skompresowanej z pamięci RAM do pamięci VRAM, gdzie są nadmuchiwane przez algorytmy kompresji GPGPU działające w CUDA. Oszczędza to dużo pasma pamięci. Więc: Sprawdź, gdzie jest gracz i uzyskaj tam wysoki poziom szczegółów, najdalsze rzeczy można łatwo wizualizować za pomocą jednego z niższych poziomów wykrywalności.
Nailer
1

Co powiesz na użycie oktetu do przechowywania terenu?

Np. Powietrze = brak węzła, wszystkie inne typy terenu miałyby węzeł z typem terenu.

Podczas wstawiania / usuwania węzłów można sprawdzić, czy wszystkie osiem potomków każdego węzła na zmodyfikowanej ścieżce drzewa ma ten sam typ terain i scalić je w razie potrzeby. W ten sposób duże bloki tego samego materiału zajęłyby tylko jeden węzeł.

Exilyth
źródło
0

Czy tworzysz tylko kostki dla części geometrii, które gracz może zobaczyć? To byłby mój pierwszy krok. W zależności od wielkości terenu nie musisz mieć załadowanego / rysowanego / widocznego / całego świata.

Tetrad
źródło
Tworzę siatkę tylko dla boków kostek, które mają puste powietrze obok nich. Jeśli chodzi o nie rysowanie siatek, których gracz nie widzi ... Pomyślałem o wykluczeniu kawałków, które nie miały żadnych widocznych bloków, takich jak podziemne jaskinie lub dziury prowadzące pod kątem do ziemi. Jednak w tym momencie zdecydowanie nie byłbym w stanie polegać na moich siatkach w przypadku kolizji / ścieżki.
James Livingston,