2009-07-03 10 views
5

Myślę o zacinaniu ruchu w moim programie 2D, ale wątpię w wyniki mojego obecnego algorytmu.2D rozmycie ruchu rozwiązania

Moje podejście wygląda to w tej chwili:

  • Draw do Backbuffer.
  • Gdy czas do aktualizacji bufora przedniego, mieszamy bufor bufora na przednim buforze.
  • Powtórz

Co spowoduje, że „motion blur” efekt jest oczywiście mieszanie, jak obiekty w ruchu pozostawi ślad blaknięcie.

Oczywiście nie jest to bardzo wymagające dla sprzętu, podwójne buforowanie zostanie wykonane, a jedynym dodatkowym krokiem jest mieszanie alfa, które jest prostym obliczeniem. Jednak szlaki będą bardzo ostre, a nie rozmyte, co może wydawać się nieco dziwne. Mogłem zrobić rozmycie pudełkowe na tylnym buforze przed etapem mieszania, ale wydaje mi się, że może to być bardzo podatne na systemy low-end, takie jak Nintendo DS.

Czy istnieją rozwiązania, które pozwolą mi to zrobić bardziej efektywnie lub uzyskać lepszy wynik?

Odpowiedz

5

Naprawdę powinieneś renderować wiele ramek pośrednich i mieszać je w jeden wynik. Załóżmy na przykład, że wyjściowa liczba klatek na sekundę to 50 klatek na sekundę. Prawdopodobnie uzyskasz rozsądny wynik, jeśli renderujesz wewnętrznie z szybkością 500 klatek na sekundę i mieszane grupy po dziesięć klatek przed wyświetleniem tego użytkownikowi.

Podejście, którego obecnie używasz, symuluje utrwalanie, tak jak w przypadku renderowania na stary CRT z wolnym fosforem. To nie jest tak naprawdę to samo, co rozmycie ruchu. Jeśli czas trwania klatki wynosi 20 ms (1000/50), wówczas ramka z rozmytym ruchem składa się z renderingów obejmujących czas trwania ramki 20 ms, wszystkie o tym samym współczynniku alfa. Rozwiązanie oparte na trwałości składa się z renderingów z 20, 40, 60, 80, 100 ms temu, stopniowo zanikających.

+0

To jest dobra sugestia, jednak wygląda na to, że może to zająć dużo mocy obliczeniowej. – Skurmedel

+1

Rzeczywiście. W zależności od rodzaju generowanych prymitywów prawdopodobnie istnieją pewne optymalizacje, które można zastosować. Lub możesz spróbować hybrydy mojej sugestii i twojej. Algorytm, który zaproponowałeś, był standardową sztuczką kodującą demo w latach 90-tych. Może przynieść dobre rezultaty. Jeśli jednak szukasz ogólnego celu, prostej i szybkiej realizacji rozmycia, nie masz szczęścia. Właśnie dlatego prawie nigdy go nie zaimplementowano. –

1

Może wcale nie być zbyt ostry. Wszystko zależy od zastosowanej funkcji mieszania. Na przykład, odpowiednio 0,1/0,9 dla poprzedniego/bieżącego obrazu zapewni pewną słabą ścieżkę.

dodam, że jest to w zasadzie jak rozmycie ruchu w OpenGL jest zrobione (przez bufor akumulacji)

+0

Dzięki za dane wejściowe. Dobrze wiedzieć, że mój pomysł nie był zbyt amatorski :) – Skurmedel

1

Nie ma prawdziwego sposób to zrobić bardziej efektywnie do mojej wiedzy. To prawie tak wydajne, jak to tylko możliwe. Wygląda całkiem nieźle, jeśli liczba klatek na sekundę jest dobra, a ruch nie jest zbyt ostry.

Najlepiej wyglądającym planem byłoby, dla każdego piksela, narysować półprzezroczystą linię z nowej pozycji do starej pozycji. Nie jest to jednak trywialne obliczenie.

+0

Powinienem dodać, że nawet ten lepiej wyglądający plan będzie wyglądał źle, jeśli między ramkami obiekt nie poruszał się liniowo. – Goz

+0

Dzięki. To interesująca myśl, Goz, nie zastanawiał się nad tym. Może wyglądać dziwnie, jeśli obiekt przejdzie z jednego końca ekranu na drugi w pojedynczej ramce, jeśli stopień przezroczystości bufora wstecznego jest niski. – Skurmedel