[Delphi][OpenGL] Edycja terenu w czasie rzeczywistym

[Brainer]

Witam!

 

Od dłuższego już czasu próbuję bawić się z edytorem terenu. Na potrzeby mojego projektu tworzę program, który pozwoli mi, w czasie rzeczywistym, tworzyć świat gry. Program będzie pozwalał na edycję terenu za pomocą myszy.

 

Szło mi nawet nieźle. Stworzyłem sobie kilka fajnych klas:

http://www.glsoftworks.pastebin.com/f29375c3d

 

Wszystko było w porządku, gdy edytowany teren był rozmiarów 64x64. Gdy spróbowałem zwiększyć rozmiar heightmapy na 512x512, mój licznik klatek wskazywał, zamiast 400, ok. 5 FPS. Jak widać, używam tu tablic wierzchołków, a mimo to wszystko strasznie się ślimaczy. Próbowałem list wyświetlania. Niestety przeznaczone są jedynie dla statycznej geometrii, więc nie mogę ich użyć w edytorze.

 

Co na to poradzicie?

[Spider100]

Witam!

 

Teraz zaszalałeś o_O daj exe protestujemy pobawimy się, bo suchego kodu to za bardzo nie chce się analizować tym bardziej 525 linijek.

Nie zagłębiłem się w to co tam robisz ale z tego co mi wiadomo to teren się edytuje na zasadzie malowania heightmapy, a z tego generuje się siatkę tu polecam renderować do tekstury za pomocą końcówek stworzonych blendignegim.

 

Jeśli dla rozmiarów 64x64 działa dobrze to może podziel teren na takie kawałki i edytuj je, jeszcze lepsze podejście to użycie drzewa oct wtedy będziesz edytował takie kawalki jaki romzmiar ma końcówka.

 

To takie moje pomysły na szybko bo nigdy nie robiłem ...

 

Pozdrawiam!

Spider^*^

[Brainer]

daj exe protestujemy pobawimy się, bo suchego kodu to za bardzo nie chce się analizować tym bardziej 525 linijek.

 

Hehe! Trzymajcie!

Edytor

[Spider100]

U mnie działa dobrze Jeśli chodzi o 512x512 to jednak rozmiar takiego terenu jest bardzo duży i należy go trochę rozciągnąć, podzielić nie wyświetlać niewidocznej części wtedy powinno działać w miarę płynnie polecam drzewa ósemkowe albo czwórkowe.

[Brainer]

U mnie działa dobrze Jeśli chodzi o 512x512 to jednak rozmiar takiego terenu jest bardzo duży i należy go trochę rozciągnąć, podzielić nie wyświetlać niewidocznej części wtedy powinno działać w miarę płynnie polecam drzewa ósemkowe albo czwórkowe.

 

Hmm... Niestety, nie wiele mi wiadomo na temat tych drzew. Masz może jakieś dobre tutoriale lub kody źródłowe? Może być C++ - jakoś może dam sobie radę przekonwertować to na Pascala.

[Spider100]

Ja się z tego nauczyłem .

http://www.delphigl.com/do_download.php?f=5226

 

Widzę że powstaje kolejny maniak pascalowy nice

[Force]

W książce "Programming an RTS Game with Direct3D" w której autor poświęca rozdział na mapy terenu, takie duże wraz z ich teksturowaniem nawet używa PixelShaderów i jeszcze można znaleźć jak wyszukiwać drogę na takiej mapie oraz żeby były na niej drzewa, budynki itp. Jest też jak zrobić prosty edytor, a teksturowanie polega nie na malowaniu myszką, ale pobierana jest wysokość wierzchołka. No ale to jest w DirectX, ale metodę chyba można podglądnąć. Z grafiki to mocny nie jestem, lubie tylko 2D

[Brainer]

CYTAT(Spider100 @ wto, 21 sie 2007 - 10:22) Ja się z tego nauczyłem .

http://www.delphigl.com/do_download.php?f=5226

 

Dzięki!

 

Widzę że powstaje kolejny maniak pascalowy nice

 

I to nawet nie wiesz, jak wielkim maniakiem jestem.

 

@Force: Masz może tę książkę?

[Force]

Mam, ale jest po angielsku i w c++. Rozdział o tym ma 60 stron to jak chcesz to mogę zrobić zdjęcia apratem

I podoba mi się że te przykłady dziają na Turbo Delphi, może zacznę sie też uczyć

[Brainer]

Mam, ale jest po angielsku i w c++. Rozdział o tym ma 60 stron to jak chcesz to mogę zrobić zdjęcia apratem

To Ty to zamówiłeś? Myślałem, że masz e-booka. Nie szkodzi, że po angielsku.

[Force]

Nie tyle zamówiłem co dostałem, po za tym powiedziałem "mam książkę" a nie "mam e-booka"

[Jason]

Nie tyle zamówiłem co dostałem, po za tym powiedziałem "mam książkę" a nie "mam e-booka"

Nic nie mówiłeś, tylko napisałeś :]

[Force]

Mówiłem, ale wy nie słyszeliście, bo mówiłem do siebie

[Brainer]

Jeśli dla rozmiarów 64x64 działa dobrze to może podziel teren na takie kawałki i edytuj je, jeszcze lepsze podejście to użycie drzewa oct wtedy będziesz edytował takie kawalki jaki romzmiar ma końcówka.

 

Poczytałem dokładniej to, co mi wcześniej napisałeś. Miałem taki pomysł, żeby zrobić sobie siatkę, która podzieli teren 512x512 na kilka mniejszych kawałków 64x64 i będzie przełączać je na listy wyświetlania, jeżeli edycja nie będzie się odbywać na nich. Natomiast, gdy będziemy edytować którąś z nich, listy wyświetlania zostaną wyłączone. Pomysł chyba dobry, ale nie mam zbytnio pojęcia, jak wykrywać, na którym kawałku obecnie się pracuje.

 

Jakieś pomysły?

[Jason]

może heightmapę podzielisz na takie kawałki ? - może takie coś by wyszło

[Brainer]

może heightmapę podzielisz na takie kawałki ? - może takie coś by wyszło

 

Ale heightmapę w pamięci, czy plik na dysku?

[Gifanonim]

chyba oczywiste ze w pamieci bo chyba niechcesz ladowac danych z dysku co klatke ? :>

[Brainer]

chyba oczywiste ze w pamieci bo chyba niechcesz ladowac danych z dysku co klatke ? :>

 

Hmm... Więc co polecacie? W moim programie heightmapę przechowuje klasa THeightMap:

 { .: THeightData :. }
 THeightData = class(TObject)
 p]]B]]HX][BZY^H&b6ćvĆSdć&3'&b'&bDffćUfV7F#(a%Ń(e%Ń(MŃ!ghts(X, Y: Integer; const Value: Single);
   function GetHeYĘN[YN[N[[]X[ĘNFVvW\"DffćUfV7F#V&Ć0V&Ć2FV6Ć&F2ŃŃ
ŃĄae%Ń((alculateNormals();

   property XDim: Integer read FXDim;
HQ[N[YXYQ[NHZYFVvW%Ó6ćvĆR&VBvWDVvG2w&FR6WDVvG3Ń9ąm`d%ŃtQYŃŃ9ą
 end;

 

Jakieś pomysły?

[Gifanonim]

ehh... słuchaj sposób w jaki przechowujesz dane jest zupełnie obojętny haczyk tkwi w tym jak to wyświetlasz, bo właśnie wyświetlanie dużej ilości poly ci spowalnia edytor a nie sposób w jaki przechowujesz o nich dane.

 

Jeśli na ekranie mieszczą ci się załóżmy tylko 64 pola na szerokość i 64 na wysokość to po co renderować wszystkie 512x512 pól, renderuj te które aktualnie widać.

 

Najbardziej banalnym sposobem na to, to trzymanie hmapy w tablicy 2d i renderowanie po prostu jej fragmentu, który aktualnie jest widoczny a i dzięki temu możesz łatwo tez edytować siatkę, bo zmieniasz tylko wartość konkretnej komórki tablicy. No chyba ze robisz bardziej zaawansowany edytor do map ala Quake to już musisz użyć z bardziej rozwiniętych algorytmów obcinania niewidocznych poly.

[Brainer]

Kiedyś słyszałem, że zawsze trzeba pytać, więc będę pytał dalej.

 

Najbardziej banalnym sposobem na to, to trzymanie hmapy w tablicy 2d i renderowanie po prostu jej fragmentu, który aktualnie jest widoczny a i dzięki temu możesz łatwo tez edytować siatkę, bo zmieniasz tylko wartość konkretnej komórki tablicy.

 

Wiesz, nie do końca to rozumiem. Przecież może być widać jednocześnie wiele takich fragmentów. Kamera nie będzie statyczna, więc można będzie zrobić podgląd terenu z lotu ptaka. Lepszym pomysłem byłoby, tak jak już wspomniałem, stworzenie siatki 2D, która będzie przełączać między sposobami wyświetlania jej fragmentów. O co chodzi? Załóżmy, że heightmapę 512x512 podzieliłem na 8 części - 64x64 każda. Przypuśćmy, że pracujemy na drugim fragmencie siatki. Zatem, edytor musiałby wykrywać, (jeszcze nie wiem jak ) na którym fragmencie pracujemy i renderować go bez listy wyświetlania. Pozostałe fragmenty można renderować przy użyciu listy - ważne jest, że każdy fragment ma swoją listę wyświetlania. Nie ma obawy, że braknie mi list, gdyż tak dużych terenów nie planuję w swojej grze.

 

Problem mój jest teraz taki, że nie wiem, w jaki sposób edytor mógłby wykrywać, na którym fragmencie aktualnie się pracuje. Macie jakieś pomysły?

 

Czekam na odpowiedzi.

[Jason]

Możesz spróbować po chamsku funkcją glFrustrum (albo glPerspective) obciąć pole widzenia

[Force]

Może zasymulować że myszka jest w każdym rogu i pobrać jaki tam byłby obszar i rysować te obszary oraz te pomiędzy nimi jeśli są, ale jeśli obraz jest z lotu ptaka to może warto rysować wtedy co drugi wierchołek w poziomi i w pionie, bo różnice będą niewielkie

[Brainer]

Może zasymulować że myszka jest w każdym rogu i pobrać jaki tam byłby obszar i rysować te obszary oraz te pomiędzy nimi jeśli są, ale jeśli obraz jest z lotu ptaka to może warto rysować wtedy co drugi wierchołek w poziomi i w pionie, bo różnice będą niewielkie

 

Nie do końca rozumiem, o co Ci chodzi. Mógłbyś to wyjaśnić lepiej?

 

Cóż, miałem pomysł, żeby konwertować globalne współrzędne myszy na lokalne i po koordynatach jakoś to szukać, ale to chyba porażka-pomysł.

[Spider100]

Jeśli na ekranie mieszczą ci się załóżmy tylko 64 pola na szerokość i 64 na wysokość to po co renderować wszystkie 512x512 pól, renderuj te które aktualnie widać.

Oj gifanonim ile razy mam Ci mówić że to co jest po za obszarem widzenia nie jest renderowane

Chodzi o to by nie wysyłać całej siatki do karty graficznej bo to właśnie wymaga najwięcej czasu.

 

Brainer jak podzielisz teren na 4 równe części to utworzysz dla każdej części boundingboxa sprawdzisz tylko kolizje brusha (który ma pewien zasięg) z każdym boungingboxem otaczającym podzielone obszary. Wtedy będziesz wiedział które części edytujesz.

 

Po za tym jak chcesz teren wyświetlać na ekranie to... nie tak gęsto. Rozumiem ze chcesz wszystko widzieć ale tak szczegółowy teren jest niepraktyczny i nawet najlepsze metody odrzucania niewidocznych fragmentów geometrii nie pomogą. ROZCIĄGNIJ TO TROCHĘ

[Brainer]

Brainer jak podzielisz teren na 4 równe części to utworzysz dla każdej części boundingboxa sprawdzisz tylko kolizje brusha (który ma pewien zasięg) z każdym boungingboxem otaczającym podzielone obszary. Wtedy będziesz wiedział które części edytujesz.

 

Hmm... Ale brush nie jest obiektem sceny, tylko jest abstrakcyjny. Podejrzewam jednak, że pisząc to zdanie wygłupiłem się bardzo.