Streamowanie geometrii w ps3 jest wymogiem, tak jak streamowanie tekstur - GPU ma tylko 256mb i wiele się tam nie mieści wiec trzeba wysyłać to na co się akurat patrzysz. W ps3 jest o tyle dobrze ze pamięć jest współdzielona więc nie ma z tym problemu jakby na PC to chcieli robić. Duże lvl są możliwe dzięki wspoldzieleniu pamięci i strumieniowaniu (nie deferred). A efekty nie są powiązane z żadnym sposobem oświetlenia. Co najwyżej przy dużej ilości świateł może braknąć wydajności i trzeba je wyłączyć... Przy malej ilości świateł jest przeciwnie bo forward da większą wydajność.

Co do tych kamieni to jak najbardziej, ale dalej nie ma to nic wspólnego z deferred. Możesz ten efekt dodać na forward bez zmiany linijki shadera.

Proste shadery oznacza dokładnie to co oznacza. Nie masz pętli gdzie liczysz oświetlenie dla świateł w shaderze. Pętla OFC nie znika tylko przechodzi na CPU i shader w deferred to zawartość tej petli. Ma to spore wady bo każde światło to dużo pracy dla ROP (nie w ps3 gdzie to ma CPU się liczy), podczas gdy w forward ropy niezależnie od ilości świateł robią niewiele bo światła oblicza się przed zwróceniem danych do ROP, a nie jak w deferred sumuje się to co ROP przetworzy (dopiero przy postprocess pracują sporo, ale to też wspólna część niezależna od tego jak robisz oświetlenie).

Bujda na resorach. Nvidia przegrała z AMD ponieważ nie ma procesora x86 w swojej ofercie który mogła by zaoferować sony czy ms razem z gpu.

Pisze straszne bzdury więc odpowiedz mi krótko czy możliwe by było stworzenie KZ3 (zapewne nie grałeś), z taką ilością efektów, 3D, tak dużymi levelami (10x większymi niz w KZ2 - streamowanie leveli i geomotrii) na PS3 (podkreślam na PS3) gdyby liczyli światło w forward. Bo widzę że za bardzo nie kumasz o co mi chodzi.
Prosto Tak czy Nie?

Co do post-processu i wody to można by nałożyć na kamienie efekt animowanego rozmycia by zasymulować rzekę (coś jak efekt gorącego powietrza).
Zacytuje:
Forward Rendering – Single Pass
‣ For each object
‣ Find all lights affecting object
‣ Render all lighting and material in a single shader
‣ Shader combinations explosion
‣ Shader for each material vs. light setup combination
‣ All shadow maps have to be in memory
‣ Wasted shader cycles
‣ Invisible surfaces / overdraw
‣ Triangles outside light influence
Forward Rendering – Multi-Pass
‣ For each light
‣ For each object
‣ Add lighting from single light to frame buffer
‣ Shader for each material and light type
‣ Wasted shader cycles
‣ Invisible surfaces / overdraw
‣ Triangles outside light influence
‣ Lots of repeated work
‣Full vertex shaders, texture filtering
Deferred Rendering
‣ For each object
‣ Render surface properties into the G-Buffer
‣ For each light and lit pixel
‣ Use G-Buffer to compute lighting
‣ Add result to frame buffer
‣ Simpler shaders
‣ Scales well with number of lit pixels
‣ Does not handle transparent objects

Wyjaśnij mi co oznacza Simpler Shaders.

Forward nie potrzebuje gbufforów - ma to wszystko co tam zapisane łatwo dostępne (dlatego w deferred bufory robisz w forward). Forward ma dokłądnie te same dane. Co do MRT... to jasne, że w forward z nich korzystasz... co więcej robisz te same buffory co do deferred - depthmapkę potrzebujesz przykładowo do DoF, normalmapkę do SSAO itp. - te bufory robisz korzystając z MRT przy okazji obliczeń oświetlenia.


Na AA nie wpływa - wpływał kiedyś, ale już masz dostęp do próbek MSAA czy CSAA z poziomu shaderów, więc już nie. Co do dużego rozmiaru bufforu to nie pomyliło Ci się z Supersamplingiem? Bo standardowe MSAA się nie zmieniło (jest duży, przez ilość próbek na teksel, ale tak zawsze było - żadnej zmiany). OFC dzięki temu, że kiedyś AA było w technikach postprocess ograniczeniem (i to nie przy DS, a przy DoF czy HDR też) powstało wiele fajnych algorytmów - nie tylko MLAA od Intela, a SRAA i FXAA od Nvidii, czy inne jak GSAA, GPAA, SDAA... które mają małe rozmiary.
W cieniach realtime w żaden sposób nie przeszkadza (dlaczego by miało?). Dokładnie tak samo robisz dla świateł mapki i dokładnie tak samo je rzutujesz... tu to już się zupełnie nic nie zmieniło. Przezroczystość jest w deferred jako procesie postprocess nieosiągalna o czym pisałem i to jedyna różnica... przez to w przeciwieństwie do tego co mówisz, z przezroczystością ucieka się od postprocess i wraca do forward (rysujesz ją tak jak wcześniej w forward sortując obiekty przezroczyste w kolejności od najdalszego do najbliższego i rysujesz dopiero po całej reszcie (tak samo jak wcześniej, bo przez to, że GPU to rasteryzatory, jesteś zmuszony i w forward przesunąć przezroczyste obiekty na koniec kolejki i posortować (chyba, że stosujesz inne techniki niezależnej przezroczystości od odległości, ale to już zupełnie inna bajka, i też nic się nie zmienia w stosunku do samego forward))).

PS. Co do wody przezroczystej jako postprocess, to czyżbyś się nie oczytał za bardzo papierków Riddlemastera, bo pamiętam, że spłodził coś na temat tworzenia wody w oceanach jako postprocess (podobnie robi Nvidia w fluidach), ale to jest jeszcze zupełnie inne podejście nie mające nic wspólnego z tym, czy korzystasz z deferred czy nie (jedynie to, że współdzielić może buffory, bo potrzebuje podobnych).



To o czym piszesz to straszne bzdury. Streamowanie geometrii jest możliwe, dzięki współdzielonej pamięci i braku konieczności przeciskania przez szynę PCIE jak w PC. Nie ma to nic wspólnego z tym czy odroczysz czy nie oświetlenie. levele to geometria dla GPU (masło maślane - napisz jeszcze modele, siatki, poligony, trójkąty, aby było więcej słów opisujących jedną rzecz), animacje to to samo. Animacja jest robiona przed renderingiem na CPU niezależnie od tego co się dzieje później, albo w Vertex Shaderach - niezależnie od tego co robisz, zawsze przed tym jak nawet pomyślisz o oświetleniu.


O tym, że w DoF nie ma Uncharted nic nowego. Inne efekty mają fajne i fajnie poskładali to w całość, ale to nie zmienia, tego, że to co mają fajne jest dalekie od tego co sugerujesz, że takie jest.


No dobra i co to niby ma pokazywać? Pokazuje, że masz normalmapkę, wygenerowaną z danych dostępnych w forward, to że masz głębokość (okrojone dane dostępne w forward i musisz je później 'odzyskiwać", to że masz Specular dostępny z forward i intensywność Specular aka Shininess też dostępna z forward (to wszystko jest łatwo dostępne z forward i właśnie tam obliczasz oświetlenie, albo zapisujesz te dane na później w bufforach i po prostu obliczasz to samo później). Ot masz te same dane tylko odroczone ich przeliczanie - nic mniej nic więcej. Jest tam też korekcja kolorów, której obojętne jak liczyłeś oświetlenie - na wejściu ma uniformy i teksturę już z obliczonym oświetleniem (nie ważne jak). Czyli co to twoim zdaniem ma pokazywać?

@skoti48
Dla ciebie forward i deferred to to samo, dla mnie to dwie inne techniki i tyle. I niech tak zostanie OK? Jak nie wiem czym się różni? W deferred masz dwie oddzielne fazy w których liczysz geometrię i światło, w forward liczysz światło dla każdego obiektu oddzielnie. Dla mnie to dwie całkiem odmienne techniki renderingnu, o innej wydajności i innych możliwościach. Dla ciebie to to samo - tylko się wydajność różni.
Forward ma G-Buffer i MRT? To co widze na ekranie w KZ2 jest praktycznie całe schowane w G-buffer i skończmy. Nie wiem mam wrazenie, ze próbujesz mi wmówić ze sposób działania deferred i fakt istnienia G-buffer nie wpływa na inne obliczenia takie jak AA, Transparency, real-time shadow? Przecież użycie Deferred niesie wiele ograniczeń. Nie ma informacji o wierzchołkach, trzeba korzystać z MSAA albo MLAA (np. zastosowanie MSAA wymusza by render target był znaczenie większy niż to co na ekranie), przezroczystość to post-process podobnie jak woda itd itp. Ty mi wmawiasz że to te same techniki bo ładujesz te same algorytymy Phonga by policzyć jak światło się załamuje na przedmiocie. Spoko wiem że masz ogromną wiedzę i znasz tysiące haseł ale nie wmawiaj mi że to takie same techniki i nie kumam w co w ogóle w tym biega.
Nie wiem czy możliwe by było streamowanie geometrii, leveli i animacji w KZ3 gdyby użyli forward. Musiałbyś mieć chyba farmę do tego z TitanGTX.
Tutaj już totalnie nie wiem o czym w końcu rozmawiamy. O grach czy o zdjęciach? Fakt jest taki że U2 jako jedyny na rynku posiada taki blur, obok dziesiątek innych genialnie wykonanych efektów (dlatego dostali nagrodę na GDC 'Best Technology' ).

Polecam real-time render. Mozna robić podgląd każdej tekstury w G-buffer (naciska się krzyżak).
http://www.youtube.com/watch?v=0FxG0YfiECU
Powiedz mi jak to możliwe że mogę real-time podglądać każda teksturę (w 3/4 filmiku to widać)? Dla mnie to nałzone na siebie zdjęcia (na podstawie niektórych liczy się oświetlenie) które tworzą finalną kompozycję.

Kiedy renderujesz do bufforów to ograniczają ropy, później robisz obliczenia oświetlenia i musisz te dane z bufforów pobrać (przykładowo masz 4 buffory to na każdy wynikowy pixel obciążający rop przy każdym dodatkowym świetle musisz zrobić fetch 4rech texeli).

A jak to jest, jak dane do bufora laduja sie to dzialaja ropy a przy odczycie dzialaja tmu?

Wydajność rop i jednostek teksturujących. Deferred tak jak wszystkie efekty postprocess są dla fillrate sporym obciążeniem.

Fillrate to masz na mysli wydajnosc ropow ?

Kiedyś GPU były inne. Wtedy fillrate było za niskie, GPU potrafiły renderować tylko do jednego bufforu na raz itp (z tych powodów nie stosuje się deferred, na mobilkach, chociaż już na Tegra 3 (gdzie jest MRT i do 4x tekstur na raz pisze) czy Adreno 320 udało mi się zrobić prawie tak wydajne implementacje, żeby wprowadzić to do mobilnej wersji silnika). Teraz GPU mają potężne fillrate, podczas jednego przebiegu mogą pisać do 8 tekstur (jeden przebieg geometrii i wszystkie gbuffory gotowe, a nie jak wcześniej dla 4x gbufforów musiałeś 4x geometrie przeciskać, a wymagania fillrate dalej były wysokie).
Dawniej defered był za kosztowny, więc całkowicie rezygnowano z dużej ilości świateł (po kilka na całą scenę), ale teraz mamy MRT, mamy duży fillrate i nie jest to tak kosztowne, a dodawanie kolejnych świateł nie jest kosztowne i można mieć setki świateł na scenie przy dobrej wydajności (co przy forward jest niemożliwe, bo przepuszczając miliony trójkątów geometrii dla każdego światła zabiłoby każde GPU).
Po prostu zmieniła się charakterystyka GPU to zmieniły się też wąskie gardła i to co kiedyś było niedopuszczalne ze względu na wydajność, dziś niedopuszczalnym jest tego nie stosować ;p.

To ja teraz troche nie rozumiem, kiedys defferend nie mozna bylo stosowac bo gpu byly za slabe a teraz sie stosuje zeby performance byl lepszy?

Nie masz pojęcia czym różni się deferred rendering od forward, więc dla Ciebie może być cokolwiek.
Te gry o których mówisz są naszpikowane efektami, które mylnie łączysz z deferred, a nie mają nic z nim wspólnego. Druga sprawa to tak - te gry beż deferred by tak nie wyglądały - bo robiąc to w forward, brakowałoby wydajności i z niektórych dodatkowych efektów (z deferred w żadnym wypadku nie związanych) trzeba by zrezygnować.



Zabawne jest to, że do efektów znanych z fotografii (statyczne obrazy) potrzebujesz dynamicznych ujęć.

Totalnie Cie nie rozumiem. Dla mnie Deferred to CAŁKOWICIE inna technika renderingu (bo światło przekazuje tak naprawdę informacje o wszystkim). Podkreślam całkowicie. Jeśli dla ciebie efekt końcowy w deferred jest taki sam jak w forward na dziś dzień to nie mamy o czym więcej gadać. Zagraj w inFamous, Killzone, U2 czy LBP. Te gry nigdy by tak nie wyglądały (jako ogół) na PS3 gdyby nie DR. Po prostu nie dało by się osiągnąć takiego efektu. Dopóki nie ograsz tych gier nie masz pojęcia czym się różnią te techniki. Powaga.
(Od siebie dodam, że mam wrażenie, że niektóre exy od SONY wykorzystują http://en.wikipedia.org/wiki/XvYCC ale to tylko przypuszczenie - bo na PDP/CRT trochę lepszy jest efekt). Ogólnie dość sporo bawią się kolorem.
Co do screenu który dałeś rozbawiło/zadziwiło mnie że dajesz STATYCZNY obrazek by mi pokazać jak wygląda głębia ostrości i bokeh (normalne efekty w fotografii).
Pozdrawiam.
Czas spać.

Nie - jest tam DoF z Bokeh - ale tak traficznie przedstawiony, że wygląda na zwykły blur (amator programista nie ma grafików, aby to lepiej przedstawić)


Szkoda, że cytujesz pracę Riddlemastera, a nic z niej nie rozumiesz.
Zmienia się podejście - tak, o czym już pisałem, ale zmienia się podejście ze względów wydajnościowych. Nie zmienia za to wyglądu w żaden sposób. Ostatnie zacytowane powyżej zdanie świadczy o strasznej ignorancji.


Czym są algorytmy cieniowania jak nie składaniem właśnie tych składowych do kupy w różne sposoby, bo różne materiały inaczej rozpraszają światło (składowa Diffuse i różne algorytmy do tego zostały stworzone jak Phong, Oren–Nayar, Lambert, Minnaert, Strauss i inne), inaczej odbija (Specular i algorytmy Blinn, Phong, Ward, Cook-Torrance, Strauss, Beckmann, Ashikhmin-Shirley i inne). Tu nie ma nic na czuja i jeśli chcesz wiedzieć jak rozbić coś na skłądowe, poczytaj o powyższych algorytmach i badaniach nad nimi.


Różni się podejściem, obciążeniem sprzętu w różny sposób, ale nie efektem końcowym.

Kurde wyskakujesz mi z obrazkiem w którym jest blur DoF, no kaman. Albo mnie bierzesz za idiotę albo Cię lekko poniosło. Dla mnie najważniejsze jest to
„Deferred Shading” całkowicie zmienia podejście do oświetlenia.
Zamiast rysować światła dla każdego obiektu oddzielnie, tak jak ma to
miejsce w tradycyjnym podejściu, dzieli proces renderingu oświetlenia na
dwie zależne fazy:
1. Fazę geometrii
2. Fazę oświetlenia
http://ngene.wdfiles.com/local--files/down...red_Shading.pdf
Wiesz forward nawet mnie nie interesuje bo to technika w której światło wygląda fatalnie.

Ja idę się założyć, że rozpoznam w ruchu deferred. Ty patrzysz na algorytmy a ja się zastanawiam jak rozbić światło które dobiega do twojego oka na składowe. Czym jest cieniowanie jak nie załamaniem światła tak naprawdę? Jak się cofniemy do źródła to wszystko się zaczęło kanałem Alfa w Gwiezdnych Wojnach Lucasa i róznym podejściem do rozbijania obrazu na składowe koloru
http://upload.wikimedia.org/wikipedia/comm...29/Barn-yuv.png
Zaraz się pewnie dowiem że forward nie różni praktycznie niczym od deferred.

Znam tą prezentacje GuerillaGames. Co do reszty to chyba nie wiesz czym się różni deferred od forward.

Forward rendering polega na tym, że zaraz po przetworzeniu geometrii w VS, obliczasz oświetlenie w PS. Deferred (z angielskiego odroczenie) to po prostu ze względu na wydajność obliczeń wielu świateł opóźnienie obliczania oświetlenia. Czyli zaraz po VS w PS nie obliczasz cieniowania, a zapisujesz wszystkie dane jakie używasz do tego w forward renderingu w teksturach, aby to obliczyć później. Efekt końcowy Deferred i Forward jest identyczny (poza tym, że tracisz przezroczystość czy możesz stracić jakość w Deferred (jak w KZ2 nie masz kolorowego Speculara, tylko skalę szarości, aby zapisać w jednym kanale zamiast w 3ch) przez oszczędność na teksturach usuwając niektóre dane łatwo dostępne w forward). Deferred to optymalizacja wydajnościowa. to jak zachowuje się Specular (tylko suche dane do niego masz w buforach przechowywane, a jak algorytm na nie działa już nie jest sprawą Deferred), Difuse... to już jest zadanie dla algorytmów cieniowania - kilka z nich wymieniłem wyżej - i też nie ma znaczenia dla efektu czy z nich korzystasz w Forward czy w Deferred - efekt jest ten sam (te same dane wchodzą do algorytmów cieniujących, które wypluwają to samo, niezależnie gdzie i kiedy to się liczy).


Jesteś w dużym błędzie, bo po efekcie jeśli na scenie nie ma dziesiątek świateł i nie widać problemów z precyzją czy przezroczystością to nie masz szans rozpoznać. Za to często jesteś w stanie rozpoznać algorytm cieniowania, a że porzucono już plastikowego phonga w grach do wszystkiego i stosuje się teraz rozwiązania stosowane od lat w rendererach filmowych (przykładowo te wyżej stworzone aby materiały wyglądały jak metal), ale to z deferred nie ma nic wspólnego.


Czyli tak jak mówię - najnormalniejszy DoF ze zmienianym focusem na obiekt, na który aktualnie się patrzysz.
Dla kontrastu dodam zupełnie amatorską implementację z jakiegoś bloga standardowego DoF'a
http://3.bp.blogspot.com/-c0Hh1m5eo8g/TqhZ...600/dof_low.jpg
http://4.bp.blogspot.com/-CQMUEO0UFu8/TqhZ...600/dof_med.jpg
A tu masz filmik innego amatora implementująca przykład z książki ShaderX (powiązana z ATI, a ten konkretny rozdział był przez 3ch ludzi z ATI pisany) - książka z 2003 roku:
http://vimeo.com/798278
I też to co uważasz za nowe (a będące podstawowe dla każdego DoF) jest - może nieciekawie to koleś przedstawił, ale to już inna sprawa.

To każdy silnik ma tak zaimplementowane - to, że rzadko się korzysta w trakcie rozrywki ze zmiany focusa to już inna sprawa.

Wracając do Focal Blur to wygląda to mniej więcej tak (czerwona kropka to celownik broni FAL):
Orginalna scena:
http://pics.tinypic.pl/i/00349/zibssvstx0u4.jpg
Pokolei blur:
http://images.tinypic.pl/i/00349/0rmw7wd51ags.jpg
http://pics.tinypic.pl/i/00349/yyrfv8zwdnpe.jpg
http://images.tinypic.pl/i/00349/wmmgvdgggflr.jpg
http://pics.tinypic.pl/i/00349/cshnhbvq6vw4.jpg
http://images.tinypic.pl/i/00349/u30611nsw87q.jpg
Sorrki za jakość komórkową.

@SNC
Fakt zagalopowałem się mówiąc o łączeniu deferred z forward ale i tak jest oczywiste, ze to dwie rózne techniki renderingu, a ND po prostu je świetnie połączyło.

@skoti48
Ja się opieram głównie na opracowaniu polskiego WAT na temat deferred i publikacji Isomniac i GuerillaGames.
http://www.guerrilla-games.com/publication...2_rsx_dev07.pdf
Trochę nie za bardzo nie rozumiem o co Ci chodzi z twierdzeniem Deferred nic nie odbija, nic nie wygląda - to po prostu optymalizacja wydajnościowa.

Dla mnie w KZ2 cały silnik hula na deferred, a informację zawarte w G-buffer to praktycznie to co widzę na ekranie. Choć nie jestem ekspertem (bardziej pasjonatem) to dla mnie sama konstrukcja jest dość czytelna (strona 18), 3x8-bitRGB + kanał Alfa 8-bit, do tego tekstury które mówią jak odbija się światło od przedmiotu, gdzie on leży, jaki ma kolor itd. Dla mnie obraz ze strony 9 nie różni się tak bardzo od obrazu na stronie nr 16 (deferred composition) - dodano motion blur i 'dodatkowe tekstury'
Wspomniałeś o specular - dokładnie - ale jest to część G-buffera więc dla mnie to oczywiste, że to deferred. Po prostu w grach Isomniac, SantaMonica i ND materiały metalowe wyglądają jak naprawdę metalowe (najlepiej to widać na CRT lub PDP - coś co ma 'normalną' saturację) - ratchet i clank miał chyba tu najlepszą kompozycję jeśli chodzi o pierwsze gry na PS3. Spokojnie deferred da się odróżnić po cieniowaniu i odbiciach od forward, po prostu to widać na ekranie.
Z miłą chęcią wysłucham wywodu. Pzdr.

Tak, to dokładnie obrazuje jakim to pragmatyzmem się Grave kierujesz.

Ten Twój 'pragmatyzm' to dla reszty świata są brednie lub debilizm.

A prosze bardzo: 'Studia first-party nie tylko piszą silniki ale tworzą nowe techniki przy renderingu - jak choćby HighFrequencyDetailMapping (GuerillaGames), SuckerPunch SSAO (http://reedbeta.com/talks/ ), czy połączenie forward i deferred (Uncharted).' Oczywiscie sam traktujesz GuerillaGames rownowaznie z Sony(jest wlascicielem wkoncu). To byl Twoj argument majacy potwierdzic ze technologicznie sa lata do przodu w porownaniu z Nvidia