2013-02-25 14 views
8

Jest to raczej pytanie, jak poprosić o poradę, na którym schemacie/podejściu powinienem użyć. Przeprowadziłem pewne badania tego problemu - przy słabych wynikach.XNA - Symulowany śnieg

Zasadniczo mam pomysł na grę, w której kluczowa mechanika rozgrywki opiera się na opadającym śniegu - lub, w przypadku tej idei, na spadające cząstki.

Śnieg/cząsteczki muszą spaść na dół ekranu - ale kumulują się w stosach. Problem polega na tym, że muszę "spływać" po bokach stosów, gdy mają one określony kąt i nadal się gromadzą. Jest możliwe, że otwory otwierają się pod stertami śniegu, a śnieg musi wypaść - myśl jak piasek spadający przez klepsydrę.

Próbowałem, to jest Box2d - jasne jest, że Box2d nie jest właściwym wyborem dla 10.000 małych cząstek - które utrzymują się przez długi czas. Pudełko 2D chrobało dość szybko.

Próbowałem rysować 1 bitmapy na ekranie, ale przetworzenie 10 000 kolizji każdej aktualizacji okazało się również mało skuteczne.

Wszelkie pomysły będą mile widziane.

Cheers

+0

Prawdopodobnie skończysz z konkurentem 3dMark ... 10000 trwałych cząsteczek brzmi jak praca dla CUDA tak czy inaczej – Alex

+0

czy możesz wyjaśnić - czy to 2d czy 3d, czy tylko śnieg akumuluje się spadając z góry i jaki rozmiar, jeśli grasz w okolicy? – Stuart

+0

Tworzę platformową grę 2D opartą na kaflach, a kiedy narysuję 200'000 duszków na pełnym ekranie daje mi to 60 klatek na sekundę na przeciętnym pulpicie w 2008 roku, więc nie sądzę, że powinno być 10'000 duszków dotyczyć. Logika kolizji może być wadliwa, co daje słabe wyniki, na przykład OP może przeprowadzać kontrole między wszystkimi płatkami śniegu, gdy niektóre z nich są zbyt daleko, aby kwalifikować się do kontroli. – user1306322

Odpowiedz

1

Cóż, tak jak odkrył, nie istniejąca biblioteka pomoże, chyba że jest nastawiony bardzo konkretnie w kierunku scenariusza. Z XNA niestety nie ma zbyt wielu rzeczy do wyboru i wygląda na to, że żadna z istniejących bibliotek systemów cząstek nie obsługuje fizyki cząstek elementarnych.

Musisz więc samemu dużo pracować. Przede wszystkim musisz myśleć o wszystkich optymalizacjach, jakie możesz ewentualnie wykonać. Jak powiedział komentarz, nie powinieneś uruchamiać kontroli między wszystkimi cząstkami w każdej klatce. Powinieneś używać sprawdzania kolizji punktowych zamiast bardziej wyszukanych rzeczy zwykle używanych przez silniki fizyki. Powinieneś upewnić się, że cząstki są zawsze tego samego rozmiaru, w tym przypadku (w stosunku do układu współrzędnych odniesienia, co nie oznacza, że ​​nie można było powiększyć). I oczywiście należy pominąć jak najwięcej kontroli kolizji - cząstki, o których wiesz, że są w spoczynku, nigdy nie powinny być sprawdzane, jak te, które mają sąsiadujące cząstki ze wszystkich stron - co prowadzi mnie do myślenia o siatkach. Być może mógłbyś reprezentować cały "świat" jako siatkę i uprościć logikę z tego punktu widzenia - podobnie jak w przypadku Minecrafta, nie zgodziłbyś się?

W każdym razie, ja realizuję ja pnący się trochę, ale to taka otwarta przedmiotem ... :)

1

Czy możliwe jest monitorowanie, które cząstki są aktualnie przetwarzane przez silnik fizyki? Jeśli tak, czy istnieje sposób, w którym można przerwać przetwarzanie swojej fizyki lub surowo ograniczyć to, co jest przetwarzane, jeśli ich prędkość jest mniejsza niż 0,01 lub coś podobnego?

Jeśli przetwarzasz tylko cząsteczki, które wymagają przetworzenia, możesz mieć ich tyle, ile chcesz, zakładając, że nie wszystkie są w ruchu!

Jeśli to nadal stanowi problem, wydaje się, że rozwiązanie dynamiki płynów może być bardziej odpowiednie, ponieważ dynamika płynów to w zasadzie wiele małych, ruchomych cząstek.

Oto kilka ciekawych informacji o 2D dynamiki płynów:

http://www.ibiblio.org/e-notes/webgl/gpu/fluid.htm

Twój silnik fizyki może już zawierać co trzeba.

+0

Niestety - śnieg jest interaktywny dla użytkownika - dzięki za twoja odpowiedź :) –

+0

OK, odpowiednio zaktualizowałem swoją odpowiedź. – rhughes

+0

@DaveBish Jak się masz? – rhughes