Autor Wątek: Implementacja c-buffora  (Przeczytany 970 razy)

Offline sergiusz308

  • Użytkownik

# Styczeń 21, 2013, 13:14:28
Panowie, na stronie swojego projektu tutaj zamieściłem screenshot, który polecam Waszej uwadze:

http://warsztat.gd/screen/12910/implementacja_cbuffora

Generalnie chciałbym przedyskutować pewien problem związanych z tą techniką. Ogólnie to dla niewtajemniczonych to c-buffer działa to tak, że:

1) robimy dowolne testy frustrum kamery - z tego nam wyjdzie lista obiektów sceny, które powinniśmy narysować. Wiadomo jednak, że przy złożonych scenach, przy określonych parametrach widoku kamery, może się okazać, że duża część tych obiektów będzie przysłonięta przez inne. Generalnie nic się nie stało, ale po co tracić czas pixel shaderów na coś, czego nie widać?
2) rysujemy zatem te obiekty do oddzielnego render-targeta - w moim przypadku 4x mniejszego od backbuffera, specjalnym pixel shaderem, który wyrzuca id obiektów (plus np. głębie)
3) sciągamy ten RT do CPU i analizujemy (zwyczajnym scanlinem) jakie obiekty tak naprawdę widać
4) na podstawie wyniku z kroku 3) budujemy listę obiektów do opędzenia w głownym wątku renderingu

Teraz wszystko gra, jest super - oprócz pewnego problemu: w niektórych sytuacjach obiekty, które powinny być widoczne w full rozdzielności, nie są renderowane w RT bo uwzględniając jego wielkość finalnie wychodzi za mało pixeli i są odrzucane. Prowadzi to do takiego efektu, gdzie np. jakiś obiekt w oddali zaczyna "migać" - raz przechodzi test widoczności, raz go obala.

Problem jest znany i częściowe rozwiązanie jest opisane w załączniku - zrzut ekranu z prezentacji Cryteka "Secrets of CryENGINE 3 Graphics Technology" gdzie opisują tę technikę. Natomiast nie dokońca rozumiem o co im chodzi z tą "reprojekcją"...

Tak czy inaczej będę wdzięczny za sugestie jak to można ugryźć.

Offline Mr. Spam

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

Offline mihu

  • Użytkownik
    • mihu

# Styczeń 21, 2013, 18:46:20
Zajrzałem do tej prezentacji (gdzie ten załącznik btw?) i tam do analizy używają zmniejszonego Z-bufora z poprzedniej klatki. Z twojego opisu wynika, że ten mały bufor rysujesz osobno, w tej samej klatce. Wtedy reprojekcja jest zbędna.

Teraz pytanie, czy ty implementujesz coś innego niż jest w tej prezentacji? To jakaś wariacja na temat tej metody?
Bo piszesz o zapisywaniu ID obiektów i ich testowaniu. Tam nic takiego nie ma. Test jest na podstawie samej głębi i patrząc na jego sformułowanie wydaje mi się, że jest "konserwatywny" - nigdy nie utnie czegoś, co tak naprawdę jest widoczne. Co najwyżej nie utnie czegoś, co nie jest.
« Ostatnia zmiana: Styczeń 21, 2013, 18:54:01 wysłana przez mihu »

Offline sergiusz308

  • Użytkownik

# Styczeń 22, 2013, 02:50:02
Tak, robię to trochę inaczej bo chcę uniknąć rasteryzowania po stronie CPU.

Crytek rasteryzuje BBoxy na CPU i dla każdego wynikowego fragmentu odnajdują fragment z głębią z depth-passa z poprzedniej ramki i w ten sposób mają widoczność.

Natomiast tak czy inaczej pozostaje problem "migotania" obiektów - chwilowego braku widoczności pomiędzy poszczególnymi ramkami. Jak oni to robią to właśnie nie rozumiem tej części dalej, to "stiching holes" itd.


Offline mihu

  • Użytkownik
    • mihu

# Styczeń 22, 2013, 11:52:21
Właśnie oni nie mają tego problemu, bo korzystają z Z-bufora (full-res) z poprzedniej klatki pomniejszonego z filtrowaniem maksimum - więc nie tracą żadnej informacji mając jednocześnie niższą rozdzielczość. Tzn. jakąś tam tracą - ale tak jak pisałem co najwyżej nie odrzucą czegoś co mogłoby być odrzucone (czyli będzie zbędne rysowanie), ale nie zdarzy się tak, że nie narysują czegoś co powinno być widać - bo taki obiekt w poprzedniej klatce na ekranie był widoczny i dzięki filtrowaniu maksimum w tym punkcie bufora zostanie zapisana jego głębia (albo większa, jeżeli w pobliżu był zrasteryzowany jeszcze dalszy obiekt).

A te problemy które oni opisują, wynikają z używania bufora z poprzedniej klatki, potencjalnie z inną pozycją kamery. Być może objawy są podobne do twoich, ale u ciebie moim zdanie wynika to z czego innego - jeżeli rasteryzujesz w mniejszej rozdzielczości ID obiektów, to wtedy nawet na nieruchomej scenie coś możesz zgubić. Tzn. migotanie oczywiście będzie widać dopiero jak zaczniesz ruszać, ale już na statycznej klatce może nie być czegoś widać. U nich problemy będą występować tylko w momentach ruchu.