Autor Wątek: Kolizje z terenem  (Przeczytany 3727 razy)

Offline raver

  • Użytkownik
    • Moja strona domowa.

# Lipiec 16, 2007, 11:12:18
Hi,
Mam taki problem, nie wiem jak rozwiązać problem kolizji z nierównym terenem. Szukałem w internecie ale nic nie mogę znaleźć. Chodzi mi o te kolizje co występują w np. worms'ach (tych 2d).

PS: Te pixele powinny wszystko wyjaśnić:


Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Gravell

  • Użytkownik
    • Teyan

# Lipiec 16, 2007, 11:23:39
Musisz znać wys. terenu w danym punkcie i nie pozwolić by postać była wyświetlana niżej...

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Lipiec 16, 2007, 11:25:03
Wszystko zależy jak masz opisany ten teren i jak bardzo dokładnie chcesz to policzyć.

Jeśli teren jest opisany tablicą wysokości dla kolejnych pikseli czy innych jednostek szerokości, to trzebaby sprawdzać, czy w miejscu w którym leży piłeczka na X, pozycja jej środka minus jej promień jest większa, niż wysokość terenu w tym miejscu. To taki pierwszy pomysł. Dalej można podobnie sprawdzić na lewym i prawym końcu piłeczki. Jeśli chcesz jeszcze dokładniej, to sprawdzaj w kilku miejscach :) Jeśli chcesz naprawdę dokładnie, to musisz policzyć kolizję okręgu z odcinkami - które będą tworzyły kolejne fragmenty terenu pokrywające się na X z miejscem, które zajmuje piłeczka.

Offline raver

  • Użytkownik
    • Moja strona domowa.

# Lipiec 16, 2007, 11:28:53
A co powiecie na taką sytuację:


Zastanawiałem się, czy teren nie opisać dużą tablicą boolean'ów, (true tam gdzie jest teren i false gdzie go nie ma), ale na to sposobu też nie znalazłem  :-\

Offline revo

  • Użytkownik

# Lipiec 16, 2007, 12:35:09
Możesz też dla każdego X pamiętać listę punktów posortowaną po y, która oznaczałaby po kolei przejścia teren / nie teren

Offline spacja

  • Użytkownik

# Lipiec 16, 2007, 15:31:11
Możesz też dla każdego X pamiętać listę punktów posortowaną po y, która oznaczałaby po kolei przejścia teren / nie teren

revo karma - 10, za takie podejście

W sieci jest pełno artów o siatkach 2D. Nawet na warsztacie jest jakiś cykl "Wedrowki w świecie 2D"
Lepiej jest sprawdzać indeks kostki planszy świat 2D . Powiedzmy krzywizna terenu- granica jakaś tam ma indeks 7 No to konflikt.

Kości świata 2D przez które przebiega linia góry, zawierają linię "czerwoną". To widzi gracz. Program widzi co innego indeksy  kostek. Popatrz na wyże wspomniane arty. Inne rozwiązania to dupa. Czasowo są zabójcze  dla szybkości gry.

 Co tu będę dalej pisać

Rys. pogladowego ukladu siatki


RageX

  • Gość
# Lipiec 16, 2007, 20:09:24
W preprocesie dzielisz teren hierarchicznie na sektory (na te puste i na te w których jakiś teren jest), te sektory dzielisz na mniejsze sektory(takie same jak tamte, tyle że mniejsze) i tak kilka razy, a na końcu per pixel, lub nie. 

Offline Xion

  • Redaktor
    • xion.log

# Lipiec 16, 2007, 21:50:51
To co proponuje RageX to drzewo czwórkowe. Prostszą wersją jest podział na kafle o stałym rozmiarze i sprawdzanie kolizji per pixel po ustaleniu, w którym kaflu (kaflach) znajduje się obiekt.

Offline Kuririn

  • Użytkownik

  • Zbanowany
# Lipiec 16, 2007, 22:29:31
Sprawdzanie kolizji per pixel może doprowadzić do tego, że gra będzie się zachowywała różnie w zależności od tego w jakiej zostanie uruchomiana rozdzielczości. Lepiej będzie sprawdzać kolizję według tablicy kafli o stałym rozmiarze, dzięki czemu system kolizji będzie niezależny od rozdzielczości ekranu, czyli zawsze będzie zachowywał się tak samo.

// Edit
@Down: Tego nie wziąłem pod uwagę, jeśli grafika nie będzie skalowana w zależności od rozdzielczości to racja.

// Edit 2
@Down: Jeśli kolizje będą sprawdzane na bitmapach w oryginalnym rozmiarze, przed przeskalowaniem i wyświetleniem na ekranie to też racja :D. Z leksza mnie tu naszło błędne rozumowanie :P
« Ostatnia zmiana: Lipiec 16, 2007, 22:57:07 wysłana przez Kuririn »

RageX

  • Gość
# Lipiec 16, 2007, 22:33:33
Ale my mówimy o mapie ala wormsy, zrobionej z obrazków(jakieś .png, .bmp, .tga)... pixeli. A nie grafiki wektorowej, krzywych. Jest to coś zupełnie innego.
EDIT: Hmm, może ty czegoś nie rozumiesz, mape kolizji tworzysz z pliku, obrazku, a nie z ekranu... dlatego to jest bez znaczenia  w jakiej rozdzielczości działasz.

Xion: jak pewnie wiesz może być też binarne, oraz o nie koniecznie stałym rozmiarze... ale wymaga to pewnej wprawy w pisaniu algorytmów.
« Ostatnia zmiana: Lipiec 16, 2007, 22:52:14 wysłana przez RageX »

Offline ziomber

  • Użytkownik

  • Zbanowany
# Lipiec 17, 2007, 00:10:50
a jakby dzialalo dynamiczne kompresowanie obrazka? nie wiem wg kolorów :]

Offline Xion

  • Redaktor
    • xion.log

# Lipiec 17, 2007, 00:15:51
a jakby dzialalo dynamiczne kompresowanie obrazka? nie wiem wg kolorów :]
Raczej nijak, bo takie mapy kolizji są najczęściej monochromatyczne :)

Offline ziomber

  • Użytkownik

  • Zbanowany
# Lipiec 17, 2007, 10:13:40
a jak maja sie kwateriony do kompresji wideo, na tej zasadzie czytać dane po skopresowaniu od razu by było mniej odlibczeń do przperowadzenia i dodatkowo mozna by uzyc (chyba) kolziji miedzy kolorami

bo w sumie kodeki pikselizują rózne rzeczy tworzą z nich kwadraty czy tam prostokąty i jakoś to tam pakują :P

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Lipiec 17, 2007, 10:20:29
Cytuj
Sprawdzanie kolizji per pixel może doprowadzić do tego, że gra będzie się zachowywała różnie w zależności od tego w jakiej zostanie uruchomiana rozdzielczości. Lepiej będzie sprawdzać kolizję według tablicy kafli o stałym rozmiarze, dzięki czemu system kolizji będzie niezależny od rozdzielczości ekranu, czyli zawsze będzie zachowywał się tak samo.
Najmniejsze węzły drzewa czwórkowego nie muszą być pojedynczymi pikselami. To mogą być te kafle o których mówisz. Tak czy inaczej drzewo czwórkowe oszczędzi tutaj dużo i pamięci, i obliczeń.

Offline counterClockWise

  • Użytkownik

# Lipiec 17, 2007, 22:31:16
Albo jeżeli bardzo by Ci się chciało możesz reprezentować taki teren jako B-REP (Boundary-Representation Solid) - używany głównie w CAD do definiowania między innymi takich ograniczonych obszarów.