Załóżmy, że do gry ma być mapa (układana np. w QuArK albo DeleD) z korytarzy i pomieszczeń (Indoor), statyczna. Jak ją oświetlić?

W przestrzeni otwartej świeci zwykle słońce, a jedno światło kierunkowe plus Shadow Mapping do niego to dla karty graficznej nie problem. Czy w Indoor też da radę oświetlić mapę dynamicznie?

Tam zwykle jest wiele świateł. Każde z nich musiałoby powodować od nowa rysowanie całej geometrii w nowym przebiegu (chyba, że zbierzemy tylko te najbliższe widoczne światła i wyrenderujemy na raz). Poza tym co z cieniami? Można oświetlać mapę bez cieni, ale fajnie byłoby żeby jednak światło nie przeświecało przez ścianę do sąsiedniego pokoju, a za drzwiami czy za rogiem faktycznie padał cień tam gdzie światło nie ma prawa bezpośrednio dolecieć. Tymczasem realizować dla każdego z tych świateł osobno Shadow Mapping (w dodatku na teksturze sześciennej - Cube Map - bo są zwykle to światła punktowe) to będzie przecież koszmarnie wolne.

Czy pozostaje tylko oświetlenie statyczne typu Lightmapy? Jeśli tak, to:
1. Jak je zrealizować? Liczyć sobie samemu czy są do tego jakieś gotowe programy?
2. Czy wtedy wszelki Normal Mapping diabli biorą, czy jednak da się coś z tym zrobić? Może pomoże Radiosity Normal Mapping, jak w HL2, albo jeszcze jakieś inne techniki?

Jak to jest robione w grach?

Deferred Shading/Lightning w różnych odmianach jest rozwiązaniem. Renderujesz do G-Buffora geometrię (odpowiednia teksturka/teksturki) i światła dodajesz w post-processingu oczywiście z blendingiem addytywnym. G-Buffer zawiera odpowiednie informacje, takie jak położenie, normalne, indeks materiału, itd (w zasadzie może być ich dowolnie dużo - aby zmniejszyć zajętość pamięci wystarczy inteligentne pakowanie).
Zatem nie ma już potrzeby dla każdego światła renderować całej geometrii, na którą światło wpływa. Co więcej bez trudu można zastosować normal-mapping czy inne efekty powierzchni.
Co prawda to rozwiązanie jest fill-rate bound, ale i na to znaleziono masę sposobów, np. zamiast rysowania full-screen quadów dla małych świateł, renderowane są ich bounding-volumy zrzutowane do przestrzeni widoku, odrzucane są światła o wpływie kilku pikseli itd.

Riddle ma rację - dereferred shading jest ciekawą techniką i powoli sprzęt jest w stanie ją uciągnąć - S.T.A.L.K.E.R., w przyszłości Crysis(? nie pamiętam czy na 100% używali deferred czy tylko screen space depth) i Unreal Engine 3.
Klasyczne rozwiązania mogą ciekawie wyglądać jeśli użyjemy oświetlenia mixed - a'la wspomniany przez Ciebie Reg HL2 (nie mam jednak do tego przekonania - prawie jak dynamiczne oświetlenie :F), albo:
- dobry podział przestrzeni - dużo geometrii odchodzi, ponadto jeśli pobawimy się w portale to również sporo światełek możemy odrzucić metodą portalową :)
- early z-pass - też odrzuci z potoku sporo fragmentów do oświetlenia - zaoszczędzimy fill rate
- attenuation na światła - poza zasięgiem mamy naturalny cień ambient, z punktu widzenia tego światła, w zasięgu wpływ mamy na ograniczoną ilość obiektów i analogicznie z cieniami.
- rozwiązanie a'la NWN2 szybkość vs dokładność - dobieramy liczbę świateł która będzie rzucała cienie (bądź wręcz która będzie obsługiwana!) i teraz wybieramy ze zbioru świateł tę określoną liczbę źródel mając na uwadze jasność świateł i ich odległość od postaci - tutaj pozostaje problem nagłych przeskoków oświetlenia - może rozwiązaniem byłoby wypalanie tymczasowych light-map, updateowanei ich co jakiś czas i blendowanie ze sobą?
Ponadto w indoor dużo efektów oświetleniowych można symulować - jakieś przyciski, wyświetlacze i inne bzdety przecież nie muszą rzucać cieni, więc warto rzucić dla nich emission mapy i użyc efektu glow/bloom/whatever.
//edit:
Carsten Wenzel twierdzi że w CryEngine2 jest klasyczny potok renderingu, więc wygląda na to, że na dzień dzisiejszy na deferred porwał się tylko S.T.A.L.K.E.R. i UE3.

Cytat:

Carsten Wenzel twierdzi że w CryEngine2 jest klasyczny potok renderingu, więc wygląda na to, że na dzień dzisiejszy na deferred porwał się tylko S.T.A.L.K.E.R. i UE3.

Serio? A mi się to wydawała tak oczywista i wydajna technika, że powinna być w każdej nowoczesnej grze... Hmm... Przecież to wymaga tylko SM 2.0 (choć SM 3.0 pozwala na dalsze optymalizacje i poprawę jakości). To może ja zostanę przy tym co mam zamiast kombinować z photon mappingiem :)

Z tego co pamiętam Unigine też wspiera deferred shading ;)

Cytat:

Ponadto w indoor dużo efektów oświetleniowych można symulować - jakieś przyciski, wyświetlacze i inne bzdety przecież nie muszą rzucać cieni, więc warto rzucić dla nich emission mapy i użyc efektu glow/bloom/whatever

I to też można zrobić przy użyciu deferred shading.

Zresztą deferred shading ma jeszcze jedną sporą zaletę - genialnie wprasowuje się w silnik/renderer jeśli mamy już napisany jakiś framework post-process, albo odpowiednio elastyczny system materiałów. Więc jego zastosowanie nie wymaga dodatkowej pracy.

Cytat:

Cytat:

Carsten Wenzel twierdzi że w CryEngine2 jest klasyczny potok renderingu, więc wygląda na to, że na dzień dzisiejszy na deferred porwał się tylko S.T.A.L.K.E.R. i UE3.

Serio? A mi się to wydawała tak oczywista i wydajna technika, że powinna być w każdej nowoczesnej grze... Hmm... Przecież to wymaga tylko SM 2.0 (choć SM 3.0 pozwala na dalsze optymalizacje i poprawę jakości). To może ja zostanę przy tym co mam zamiast kombinować z photon mappingiem :)

Z tego co pamiętam Unigine też wspiera deferred shading ;)

A w Uniginie nie wiem :P Wiem że zaimplementowali pod OGRE'a ^^
Niom - nie kojarzę innych tytułów używających deferred shading, jeszcze pogooglam, ale AFAIK tylko te produkcje komercyjne korzystają z tej techniki. Chyba przez fill-rate'ożerność tak mało popularna jest, bo właśnie na pamiątkach się najwięcej oszczędza w kartach budżetowych, poza tym main stream'owe gierki uderzają ciągle w fixed, a deferred słabo się skaluje na ten sprzęt. Main stream kartowy czyli SM2.0 jest ciut za słaby na to często. Zobacz sobie wydajność STALKERa - nie jest z nią rewelacyjnie i myślę że jest to spowodowane właśnie cienowaniem.
W sprzęcie SM3.0 można użyć MRT i wtedy dopiero ta technika pokazuje pazurki :)
//edit:
AAaaaaaa - jeszcze jedno.. Przeciez w starym sprzęcie nie ma filtrowania ani blendowania "egzotycznych" formatów i ciężko generalnie się miesza różne formaty RT itp. Zmienia się to w DX'ie 10 trochę (cąłkiem super jest już w DX10.1, bo tam mozna nawet multisamplować RT różnych formatów IIRC) i pewnie dopiero on otworzy furteczkę dla deferred.

Cytat:

A w Uniginie nie wiem  Wiem że zaimplementowali pod OGRE'a ^^

O Ogrze też wiem :)

Cytat:

W sprzęcie SM3.0 można użyć MRT i wtedy dopiero ta technika pokazuje pazurki

Z tego co pamiętam już w niektórych kartach wykorzystujących SM 2.0 było MRT, ale może źle pamiętam :) . Zresztą jak się uprzeć to parametry dla DSa można upchnąć w 1 teksturze (nie licząc diffuse'a): jedna wartość na pozycję (trzymaną jako dystans od piksela do kamery), 2 na normalne i jedna na indeks materiału (większość efektów, jak glow/emission/anisotropy/cokolwiek innego jest przecież określona per surface/materiał). Czy to tak dużo? Oczywiście później dochodzi koszt w instrukcjach shaderka na upakowanie/rozpakowanie tych danych ale w sumie nie jest ich tak dużo.

Cytat:

Cytat:

A w Uniginie nie wiem  Wiem że zaimplementowali pod OGRE'a ^^

O Ogrze też wiem :)

Cytat:

W sprzęcie SM3.0 można użyć MRT i wtedy dopiero ta technika pokazuje pazurki

Z tego co pamiętam już w niektórych kartach wykorzystujących SM 2.0 było MRT, ale może źle pamiętam :) . Zresztą jak się uprzeć to parametry dla DSa można upchnąć w 1 teksturze (nie licząc diffuse'a): jedna wartość na pozycję (trzymaną jako dystans od piksela do kamery), 2 na normalne i jedna na indeks materiału (większość efektów, jak glow/emission/anisotropy/cokolwiek innego jest przecież określona per surface/materiał). Czy to tak dużo? Oczywiście później dochodzi koszt w instrukcjach shaderka na upakowanie/rozpakowanie tych danych ale w sumie nie jest ich tak dużo.

Patrz wyżej :) Operujesz na render targetach tego samego formatu (jesli chcesz się bawić w MRT), których nie możesz filtrować ani blendować (albo będziesz miał AA - Atak Artefaktów ^^). Popakować tez za dużo nie popakujesz, bo o prawdziwym pakowaniu i zabawie mogłaby być mowa gdybyś miał bitwise operations, a to dopiero w SM4.0.
A od kiedy jest MRT to nie wiem, stwierdziłem że bezpiecznie założyć że w SM3.0 już powinien być :) Poczekamy na Krzyśka, on zapewne sporo poprostuje, dopowie i poprawi ^^

Cytat:

Patrz wyżej  Operujesz na render targetach tego samego formatu (jesli chcesz się bawić w MRT), których nie możesz filtrować ani blendować (albo będziesz miał AA - Atak Artefaktów ^^).

Niestety. Dlatego czasem warto zrezygnować z MRT. Bo niestety te ograniczenia bardzo utrudniają czasem pracę.

Cytat:

Popakować tez za dużo nie popakujesz, bo o prawdziwym pakowaniu i zabawie mogłaby być mowa gdybyś miał bitwise operations, a to dopiero w SM4.0.

To prawda, ale i tak można zjechać z kilkudziesięciu MB do kilku-kilkunastu, a to już niemało jeśli założymy że przeciętna karta ma te 256 MB.

Cytat:

Deferred Shading/Lightning w różnych odmianach jest rozwiązaniem.

A co z cieniami? Jeżeli byśmy zakładali, że nie ma cieni, to zwykle doskonale można sobie poradzić i bez deferred shadingu. Deferred może mieć sens jeżeli mamy gigantyczne ilości trójkątów i/lub dodatkowe techniki typu parallax occlusion mapping. :)

Cytat:

A mi się to wydawała tak oczywista i wydajna technika, że powinna być w każdej nowoczesnej grze... Hmm... Przecież to wymaga tylko SM 2.0

Z samym SM 2.0 wiele nie zdziałasz, bo do wydajnego deferred shading potrzebujesz jeszcze floatowych render-targetów i Multiple Render Target. Drugim nawet ważniejszym problemem jest to, że wszelkiego rodzaju FSAA w tym przypadku kompletnie biorą w łeb, na co żaden silnik nie mógłby sobie pozwolić. Jakoś nie wyobrażam sobie, żeby w UE3 nie działał FSAA, więc wątpię, zeby deferred shading był tam wprowadzony zamiast klasycznego potoku - raczej widzę to jako jedną z opcji materiału.

Cytat:

Niestety. Dlatego czasem warto zrezygnować z MRT. Bo niestety te ograniczenia bardzo utrudniają czasem pracę.

Żeby poprawnie zadziałał sprzętowy FSAA, to musisz niestety całkowicie zrezygnować z deferred shadingu.


Poza tym robicie OT, bo Regedit miał głównie na myśli cienie, których zupełnie nie widzę w przypadku deferred shadingu. Z oswietleniem indoor per-pixel bez cieni bez deferred radzi sobie nawet GeForce 2, Intel i845, czy Mobility Radeon 9000 bo na takich sprzętach odpalałem mój silnik i uzyskiwałem FPS'y pozwalające na granie (oczywiście większośc technik z pierwszego posta mINY była zastosowana). Problem pojawia się właśnie jak chcemy zrobić ładne dynamiczne cienie (na statyczne cienie już mam wykombinowaną inną technikę na wyżej wymienione karty). :)


EDIT:

Cytat:

To prawda, ale i tak można zjechać z kilkudziesięciu MB do kilku-kilkunastu, a to już niemało jeśli założymy że przeciętna karta ma te 256 MB.

Błędne założenie, bo o ile wiem, jednym z najpopularniejszych modeli kupowanych kart był GeForce 6600 z 128MB pamięci, który jeszcze trochę się u graczy utrzyma.

Cytat:

A co z cieniami? Jeżeli byśmy zakładali, że nie ma cieni, to zwykle doskonale można sobie poradzić i bez deferred shadingu. Deferred może mieć sens jeżeli mamy gigantyczne ilości trójkątów i/lub dodatkowe techniki typu parallax occlusion mapping.

Efekty typu parallax occlusion lada w chwila będą powszechne w grach (no dobra może przesadzam, ale zaczną się pojawiać), więc zapotrzebowanie pewnie będzie.

Cytat:

Z samym SM 2.0 wiele nie zdziałasz, bo do wydajnego deferred shading potrzebujesz jeszcze floatowych render-targetów i Multiple Render Target.

Zgadzam się, co nie zmienia faktu, że pierwsze znane mi implementacje (ale mówię o samym DS, często oderwanym od kontekstu) były pisane pod sprzęt z SM 2.0 właśnie.

Cytat:

Żeby poprawnie zadziałał sprzętowy FSAA, to musisz niestety całkowicie zrezygnować z deferred shadingu.

Na upartego można np. podbić rozdzielczość render-targeta. Jakiś AA to da. Cóż nie można mieć wszystkiego.

Cytat:

Błędne założenie, bo o ile wiem, jednym z najpopularniejszych modeli kupowanych kart był GeForce 6600 z 128MB pamięci, który jeszcze trochę się u graczy utrzyma.

To taka optymalizacja ma jeszcze większy sens ;)

A co do cieni to tu faktycznie jest problem - dlatego nie poruszałem tego zagadnienia ;) . Sam dopiero zastanawiam się co z tym fantem zrobić, bo u siebie oparłem się o deferred shading (który i tak później zamierzam zastąpić/połączyć z ładniejszym photon mappingiem).

Cytat:

Na upartego można np. podbić rozdzielczość render-targeta. Jakiś AA to da. Cóż nie można mieć wszystkiego.

Jeżeli cierpisz na nadmiar fill-rate'u, to tak. ;)

Cytat:

Sam dopiero zastanawiam się co z tym fantem zrobić, bo u siebie oparłem się o deferred shading (który i tak później zamierzam zastąpić/połączyć z ładniejszym photon mappingiem).

Dlatego ja na razie odpuszczam sobie deferred shading całkowicie. Shadow mapy także jeszcze musząi u mnie poczekać, bo jak na razie sprzęt przeciętnego Polaka raczej nie poradzi sobie z soft shadowami (implementacja SM bez zmiękczania to IMHO nieporozumienie). Jak na razie w planach jest silniczek śmigający sobie na twardych cieniach i per-pixel na GeForce 2. :)

Hmm jakie sa problemy z cieniami przy deferred? Bo w S.T.A.L.K.E.R.ze są, w prezentacjach opisują jak podejść do technik cieniowania, ja też w sumei nie widzę aż takiego problemu w przypadku shadow map.. hmmm coś przeoczyłem? :)

UE będzie targetowął również w DX10 a ten obsługuje multisampling ładnie dla fp i MRT, więc na platformach DX10 będzie AA.

W ogóle - na platformach DX10 da sie robić ładnie FSAA przy deferred shadingu.

Krzysiek a coś jeszcze dodałbyś do pomysłów na efektywne renderowanie in-door'u? :)

Cytat:

Hmm jakie sa problemy z cieniami przy deferred?

W sumie to takie same jak i bez deferred. :)

Cytat:

W ogóle - na platformach DX10 da sie robić ładnie FSAA przy deferred shadingu.

Nie chodzi o sam fakt obsługi FSAA dla fp i MRT, ale o jego sensowność. FSAA dla zapisywanych normalnych i głębokości nie ma większego sensu (podobnie jak FSAA nie ma sensu dla klasycznych shadow map), chyba że znasz jakąś genialną sztuczkę. :)

Cytat:

Krzysiek a coś jeszcze dodałbyś do pomysłów na efektywne renderowanie in-door'u? :)

Statyczne twarde cienie przeliczane offline (wymiatają na starym sprzęcie). ;)

Cytat:

Cytat:

Hmm jakie sa problemy z cieniami przy deferred?

W sumie to takie same jak i bez deferred. :)

A... lol.. nie no myślałem że dochodzą jakieś ultra-trudne nie do przeskoczenai problemy związane z odmiennym podejściem do cieniowania ^^

Cytat:

Cytat:

W ogóle - na platformach DX10 da sie robić ładnie FSAA przy deferred shadingu.

Nie chodzi o sam fakt obsługi FSAA dla fp i MRT, ale o jego sensowność. FSAA dla zapisywanych normalnych i głębokości nie ma większego sensu (podobnie jak FSAA nie ma sensu dla klasycznych shadow map), chyba że znasz jakąś genialną sztuczkę. :)

Ano - good point, ale można robić FSAA dla końcowego wyniku. Co do genialnych sztuczek to hardware PCF, ale to ciut inna bajka, inny format powierzchni ^^
Nie pamiętam dokładnie tych prezentacji, ale w DX 10.1 czy wręcz 11 nie planowali jakoś pohaczyć multisamplingu?

Cytat:

Cytat:

Krzysiek a coś jeszcze dodałbyś do pomysłów na efektywne renderowanie in-door'u? :)

Statyczne twarde cienie przeliczane offline (wymiatają na starym sprzęcie). ;)

Light mapki czy proxy geometria? A może po prostu wypalasz od razu w texturce statycznej geometrii? Na ile statyczne, że tak wymiatają? :P

Cytat:

jak na razie sprzęt przeciętnego Polaka raczej nie poradzi sobie z soft shadowami

Dlatego ja nie targetuję nigdy w Polskę ;) Odpalą Ci co mają odpowiednio wypasione kompy.

Cytat:

A... lol.. nie no myślałem że dochodzą jakieś ultra-trudne nie do przeskoczenai problemy związane z odmiennym podejściem do cieniowania ^^

Nie no bez przesady. Bardziej chodzi o to, że korzystanie z DS nie wiąże się tu z jakimkolwiek zyskiem ;) Ani na jakości, ani na wydajności.

Cytat:

Co do genialnych sztuczek to hardware PCF, ale to ciut inna bajka, inny format powierzchni ^^

Oj tak... genialna sztuczka :)

Cytat:

Krzysiek a coś jeszcze dodałbyś do pomysłów na efektywne renderowanie in-door'u?

Co prawda było do Krzyśka, ale ja bym jeszcze proponował pół-dynamiczny ambient-occlussion (dynamiczny to chyba tylko slogany reklamowe) :) Za pomocą occlussion-fields i tym podobnych rzeczy.

Cytat:

Ano - good point, ale można robić FSAA dla końcowego wyniku.

Tyle, że to nic nie da, bo i tak wszystko już wcześniej masz wypalone na rendertargetach jako pojedyncze piksele. Na sam koniec to możesz jedynie sobie przefiltrować krawędzie bounding boxów świateł, co raczej przydatne nie jest. :)

Cytat:

Co do genialnych sztuczek to hardware PCF, ale to ciut inna bajka, inny format powierzchni ^^

To akurat znam, ale to tylko NVidia się w to bawi, a w dodatku nie widzę sposobu, jak by to sensownie zastosować do eliminacji aliasingu na krawędziach przy DS.

Cytat:

Light mapki czy proxy geometria? A może po prostu wypalasz od razu w texturce statycznej geometrii? Na ile statyczne, że tak wymiatają? :P

Proxy geometria, a właściwie jej brak (usuwamy kawałki geometrii leżące w cieniu), dzięki czemu cienie pozwalają zaoszczędzić fill-rate, zamiast go zżerać. :)