Autor Wątek: Recast+Detour - darmowy, otwarty silnik do pathfindingu w 3D  (Przeczytany 3243 razy)

Offline Angru

  • Użytkownik

# Październik 13, 2009, 12:07:43
Chciałbym się zorientować, czy jest wśród nas więcej użytkowników tej biblioteki. Kod jest otwarty, wiec może ktoś już dopisał sobie coś ciekawego i będzie można wymienić się doświadczeniami.

Dla niezorientowanych recast to kod autorstwa Mikko Mononena, potrafiący generować siatki nawigacyjne ze statycznej geometrii etapu (wykorzystując rastry voxelowe). Do tego dochodzi Detour, zajmujący się 'rozumowaniem przestrzennym', czyli mamy tam A* ładnie śmigającą na grafie siatki nawigacyjnej, plus parę pomocnych metod.

W sumie kluczową zaletą Recast'a jest właśnie automatyczne tworzenie navmesha, z czym radzi sobie naprawdę nieźle i daje duże możliwości dostrajania. Do statusu pełnego silnika pathfindingu jednak sporo brakuje. Na przykład, przydałby się format pliku z navmeshem, by móc wyciągnąć generację siatek do preprocessingu, czy omijanie dynamicznych przeszkód.

Offline Mr. Spam

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

Offline Kos

  • Użytkownik
    • kos.gd

# Październik 13, 2009, 12:23:58
Nie używałem, ale skoro takie fajne i darmowe, to z miłą chęcią potestuję. :)

Offline Angru

  • Użytkownik

# Październik 13, 2009, 12:57:05
Ogólnie polecam. Niestety nie ma żadnej dokumentacji, ani tutoriala. Jest za to przykładowa aplikacja z czytelnym kodem i komentarzami, którą można (trzeba) potraktowac jako 'how-to'. Używam jej zresztą także jako narzędzia do sprawdzenia tego jakie siatki wychodzą przy takich a takich ustawieniach. Jeżeli temat Cię zainteresuje, a nie chce Ci się czegoś rozgryzać, to może będę mógł pomóc. Autor kodu, także szybko i chętnie odpowiada na pytania, choć obawiam się, że to się zmieni, kiedy liczba użytkowników urośnie. Mam nadzieję, że do tego czasu powstanie jakiś API reference.

Offline Capad

  • Użytkownik

# Październik 13, 2009, 14:54:50
Proponuję dodać do Warsztatowej Wiki ;)

Offline Angru

  • Użytkownik

# Październik 13, 2009, 20:13:25
Proponuję dodać do Warsztatowej Wiki ;)
Głupio się przyznać, ale nie zdawałem sobie sprawy, że coś takiego istnieje. W sumie jest tam dział "Jakich bibliotek używać", ale pozwolę sobie zapytać, czy to wiki w ogóle żyje? (nie bijcie!) Chodzi mi o to, że jest tam sporo pustych 'place holderów', które w sumie nie problem wypełnić, a jednak nic tam nie ma...

Offline Capad

  • Użytkownik

# Październik 13, 2009, 22:47:14
Wiesz, "wypełniaczy" jest tylko garstka, a i tak odwalili kawał dobrej roboty - na przykład dział "Z czego się uczyć" ;)
Każda pomoc się przyda, więc zapraszam do redagowania ;)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Październik 14, 2009, 11:50:21
Dzięki za linki, zapowiada się wyśmienicie i kto wie, czy tego nie użyję gdzieś w swoich projektach. :)

Offline Dab

  • Redaktor
    • blog

# Październik 14, 2009, 15:21:56
U, szkoda, że nie ma obsługi dynamicznych przeszkód. Ale i tak go przetestuję. :)

Offline Angru

  • Użytkownik

# Październik 14, 2009, 17:20:21
Bardzo możliwe, że będzie już w następnej wersji, bo jest taki punkt na liście zaakceptowanych i otwartych spraw do zrobienia w googlowym issue trackerze (swoją drogą dziwaczny ten tracker). Obecnie niby pracuje nad wprowadzaniem danych użytkownika dla sektorów w podanej objętości. Też fajnie, jeżeli dobrze rozumiem będzie można w ten sposób oznaczać 'hide spoty' i takie tam. Albo na przykład dodatkową wagę połączenia dla A* by zasymulować trudny teren.

Offline Dab

  • Redaktor
    • blog

# Październik 18, 2009, 06:55:53
Bardzo pozytywnie zaskoczyła mnie ta biblioteka. Dodatkowe zastosowanie to generowanie podziału mapy na sektory + tworzenie grafu połączeń między tymi sektorami.

Offline Angru

  • Użytkownik

# Październik 18, 2009, 15:48:35
No tak, takie stronnicowanie będzie raczej warunkiem koniecznym używalności biblioteki w prawdziwych gierkach. Sprawdzałeś już może jak recast się spisuje na tym polu (z punktu widzenia użytkownika API)? Sam jak dotąd używałem tylko prostych, statycznych siatek, bo jest to na razie wystarczające na potrzeby prototypu. Jakiś czas nie będę miał czasu na dalsze eksperymenta, ale jeżeli okaże się, że Recast to pewny grunt dla pathfindingu, rzeczywiście warto będzie napisać coś o tym na warsztatowej wiki.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Październik 18, 2009, 17:34:22
Cytuj
No tak, takie stronnicowanie będzie raczej warunkiem koniecznym używalności biblioteki w prawdziwych gierkach.
Przesada. Wystarczy żeby dane dla jednego levelu miały sensowny rozmiar i tyle. :)

Offline yarpen

  • Użytkownik

# Październik 18, 2009, 17:47:13
Cytuj
No tak, takie stronnicowanie będzie raczej warunkiem koniecznym używalności biblioteki w prawdziwych gierkach.
Przesada. Wystarczy żeby dane dla jednego levelu miały sensowny rozmiar i tyle. :)
Ciekawa wypowiedz. Jak rozumiem, analogicznie, akcelerator graficzny nie jest potrzebny, bo wystarczy, zeby level mial malo geometrii?

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Październik 18, 2009, 17:50:13
Ciekawa wypowiedz. Jak rozumiem, analogicznie, akcelerator graficzny nie jest potrzebny, bo wystarczy, zeby level mial malo geometrii?
Wszystko zależy od wymagań gdy/silnika - do takich casuali nawet akceleratora na dobrą sprawę nie potrzebujesz. Ale wracając do tematu, przykładowo takiemu Bioshockowi podział na levele wcale nie przeszkodził w staniu się hitem. :)

Offline yarpen

  • Użytkownik

# Październik 18, 2009, 21:33:45
Ciekawa wypowiedz. Jak rozumiem, analogicznie, akcelerator graficzny nie jest potrzebny, bo wystarczy, zeby level mial malo geometrii?
Wszystko zależy od wymagań gdy/silnika - do takich casuali nawet akceleratora na dobrą sprawę nie potrzebujesz. Ale wracając do tematu, przykładowo takiemu Bioshockowi podział na levele wcale nie przeszkodził w staniu się hitem. :)
Podzial na levele to jedno, a siatka do nawigacji to drugie. Wiedzmin tez nie mial streamowanego swiata, ale gdybysmy wyszukiwanie sciezek robili bez podzialu na sektory, to bylaby turowka, a nie RPG.