Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - Angru

Strony: 1 [2] 3 4 5 6 7
16
Matematyka i fizyka / Odp: Algorytm łączenia wierzcgołków w trójkąty
« dnia: Październik 21, 2009, 12:32:34 »
Poczytaj o delaunay triangulation.

17
Szkółka / Odp: Poradnik Początkującego Programisty
« dnia: Październik 21, 2009, 10:42:52 »
Fajny artykuł i bardzo fajna inicjatywa. Dorzucę głos by nie zapominać o Javie (przynajmniej początkujący programista nie będzie jej mylił z javascriptem). Bardziej przeleciałem niż przeczytałem, ale widzę, że masz tam dużo trafnych rad i uwag. Aż mnie korci, żeby podesłać co niektórym kolegom z pracy...

18
@Troll
Pięknie, powinno wystarczyć. Bardzo lubię takie rozwiązania :) W niektorych przypadkach mogę dorzucić dochodzenie do punktu o najfajniejszej heurystyce, by agent mógł zobaczyć co tam dalej znajdzie, a nóż coś się zmieni. Dzięki, niech żyją Trolle!

@revo
Też dobre i jeszcze szybsze. Wtedy też mogę znaleść szybko stan grafu o najlepszej heurystyce szukając w ramach jednej składowej.

@Liosan
Z jednego końca. Obiekt ogrodzony małym murkiem może być częstym przypadkiem ale jeszcze nie wiem jak częstym. Twoja druga propozycja - w innym prototypie robiłem graf na zasadzie drzewa czwórkowego i jest to ogólnie fajne rozwiązanie. Nie pasuje jednak do tej konkretnej specyfiki problemu.

@Xion
Chyba tak właśnie będę kombinował i zobaczę co się najlepiej sprawdza.

Dzięki wszystkim za odpowiedzi. Nie ma to jak rozproszona burza mózgów :)

19
Myślałem o tym. Koncept jednak polega na tym, że zadaniem gracza będzie przeszkodzić wrogowi w szybkim i sprawnym dotarciu do pewnego celu. Przy tym rozwiązaniu będzie wystarczało, że gracz nastawia wrogowi różne crapowate kłody pod nogi, a ten będzie się z wielkim zaangażowaniem o nie wszystkie przewracał. Niestety musi być trochę bardziej przebiegły  ;)

20
Sztuczna inteligencja / Jak szybko wykryć, że nie da się gdzieś dojść
« dnia: Październik 20, 2009, 22:41:12 »
Załóżmy, że mamy prostą mapę z kratką taktyczną. Kratki mogą być dynamicznie blokowane i zwalniane (np. w sytuacji kiedy coś gdzieś wejdzie, lub zniszczymy jakąś barykadę). Potrzebuję wykonać wiele, częstych testów szukania drogi w stylu "jeżeli nie da się dojść do żadnego obiektu jednej klasy, to poszukajmy obiektów innej, mniej interesującej klasy itd.). Znajdowanie drogi robię na A*, która staje się bardzo nieoptymalna w sytuacji kiedy aktualnie nie istnieje żadna możliwa ścieżka. Co więcej muszę założyć, że takie sytuacje będą bardzo częste. Problem wydaje się być klasyczny dla różnego typu gier RTS (jak nie mogę iść wtłuc jednostkom wroga, to zabiorę się chociaż za mur). Sam jednak nie bardzo wiem jak to rozwiązać. Będę wdzięczny za błyskotliwe pomysły, a jeszcze bardziej za wskazanie jakiegoś standardowego rozwiązania.

21
OpenGL / Odp: Texture splatting + shadery
« dnia: Październik 20, 2009, 14:39:19 »
Texture splattingu na atlasie tekstur nie rób, bo jest z tym mnóstwo problemów. Może zrób raczej jeden wysokorozdzielczy sampler z mapą koloru nakładaną na cały teren jeden raz (gdzie trawa gdzie skały itp). Do tego dobierz parę dobrych detali i alfa mapę nakładaną na cały teren wskazującą gdzie jaki detal położyć. Do tego możesz dorzucić sampler na strome zbocza i znajdować je już w shaderze licząc normalne z samplera heightmapy.

A i żeby obniżyć ilość używanych tekstur, możesz spróbować z jakimiś proceduralnymi.

22
Póki co rzeczywiście boli brak dokumentacji. W sumie w kodzie nie ma jakiegoś podziału między bibliotekę a demko, do tego wymieszana jest logika, grafika, fizyka i GUI.
Nie zapominaj o loggingu ;) To fakt, design kiepski i da się to jakoś ruszyć chyba jedynie dla tego, że jest wciąż dość małe. Generacja siatki i sam pathfinding jest niby odseparowany, ale co robi w bibliotece taki DebugDraw, możemy tylko zgadywać. Nie ma też wewnętrznej walidacji danych i obsługi błędów (już się naciąłem przez to na jeden ciekawy problem). Najwyraźniej autor jest algorytmiarzem i myślę, że będzie warto mu zasugerować jakiś mały refactoring w przyszłości. Póki co importuję tylko kod detoura i recasta (bez modułów DebugDraw, bo są na SDLu). Co do RecastDemo z założenia częścią biblioteki nie jest. Raczej zalecam się temu przyjrzeć i obczaić jak się biblioteki używa, a potem zbudować sobie jakąś prostą i bezpieczną fasadę (bo kto wie jakie zmiany zajdą w przyszłych wersjach).

23
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.

24
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.

25
Szkółka / Odp: C++, 3d!!, ruch postacią
« dnia: Październik 13, 2009, 22:36:25 »
No to chociaż reprezentacja obrotu za pomocą macierzy, lub kwaternionu. Wtedy, drogi dwd, będziesz mógł sobie przemnożyć ten obrót przez jednostkowy wektor wskazujący 'światowe' do przodu (np. dla OpenGL {0.0f,0.0f,-1.0f}). Tak dostaniesz wektor wskazujący kierunek w którym chcesz wykonać krok. Możesz go sobie pomnożyć jeszcze przez odległość jaka ma być przebyta i dodać do pozycji. Żadnej trygonometrii. A jeżeli Irrlicht tego nie ma to chyba czas się przesiaść...

26
Szkółka / Odp: C++, 3d!!, ruch postacią
« dnia: Październik 13, 2009, 22:14:00 »
To Irrlicht nie ma czegoś takiego jak graf sceny??? Każdy choćby nędzny silnik ma coś takiego więc pewnie Irrlich także. W takim wypadku prawodpodobnie nie musisz sam liczyć wektora translacji, tylko wykonać translację 'do przodu', tylko, że w lokalnym układzie współrzędnych obiektu (z uwzględnieniem jego obrotu względem rodzica).

27
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...

28
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.

29
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.

30
Szkółka / Odp: problem z release
« dnia: Październik 12, 2009, 00:07:17 »
To trochę jak wróżenie z fusów. Jak bym miał interpretować ten error, to powiedziałbym, że jakaś dllka deklaruje użycie funkcji eksportowanej przez inną dllkę (niejawna zależność), z tym, że podana dllka takiej funkcji nie udostępnia. W takim przypadku dependency walker powinien pomóc Ci namierzyć problem.

Właściwie to dlaczego nie chcesz sprawdzić tego debuggerem?

Strony: 1 [2] 3 4 5 6 7