494 odpowiedzi na ten temat

[fingus]

Projekcja - niekiedy grając mam wrażenie, że coś z nią nie tak. Zachowuje się przyzwoicie przy małym kącie patrzenia (czy to nazywa się FOVem?), ale przy dużym odchodzą już jakieś kosmosy blisko krawędzi ekranu. A przecież ludzkie oko ma bardzo duży kąt widzenia - a kosmosów nie widać. Nie wygląda to realistycznie. Może to kwestia tego, że oko rzutuje na siatkówkę, która płaska nie jest, a w grafice rzutuje się na płaską powierzchnię. O, zresztą właśnie znalazłem coś na ten temat:
http://pl.wikipedia....a_krzywoliniowa
A zatem: życzę sobie perspektywy krzywoliniowej (co chyba wymaga liczenia projekcji w punkcie, a nie dla wierzchołków - jak obecnie).
Z kwestiami widoku wiążą się jeszcze dwa drobiazgi - gdy kręcimy głową, w grach oś obrotu znajduje się w punkcie położenia kamery - a w rzeczywistości znajduje się ona parę cm za "kamerą". Druga rzecz (ważniejsza) - przeważnie odległość jest obliczana "od płaszczyzny rzutowania" - to fatalne uproszczenie generuje masę bardzo nieprzyjemnych efektów - począwszy od zmiany koloru lub oświetlenia obiektów przy ruchu głowy/kamery, a skończywszy na popupie uaktywniającym się, gdy nie zmieniam położenia, a tylko się obracam - bo w nowym wyliczeniu obiekt znajduje się nagle dalej. Widziałem to w wielu grach i zawsze mi przeszkadzało.

[torq314]

Projekcja - niekiedy grając mam wrażenie, że coś z nią nie tak. Zachowuje się przyzwoicie przy małym kącie patrzenia (czy to nazywa się FOVem?), ale przy dużym odchodzą już jakieś kosmosy blisko krawędzi ekranu. A przecież ludzkie oko ma bardzo duży kąt widzenia - a kosmosów nie widać. Nie wygląda to realistycznie. Może to kwestia tego, że oko rzutuje na siatkówkę, która płaska nie jest, a w grafice rzutuje się na płaską powierzchnię. O, zresztą właśnie znalazłem coś na ten temat:

chyba chodzi też o coś innego - projekcja obrazu na oko jest INTERPRETOWANA przez mózg. czytałeś pewnie przecież o eksperymentach, w których nakładano ludziom okulary zniekształcające obraz. i to jest kwestia do tygodnia, kiedy mózg uczy się interpretować obraz na nowo. nie mówiąc już o tym, że przecież interpretuje, bo ODWRACA obraz, oseski mylą górę z dołem bo do mózgu trafia obraz odwrócony.

począwszy od zmiany koloru lub oświetlenia obiektów przy ruchu głowy/kamery, a skończywszy na popupie uaktywniającym się, gdy nie zmieniam położenia, a tylko się obracam - bo w nowym wyliczeniu obiekt znajduje się nagle dalej. Widziałem to w wielu grach i zawsze mi przeszkadzało.

to chyba nie jest problem tego gdzie jest płaszczyzna rzutowania, tylko tego jak działa clipping obiektów. clipping w teorii może obcinać dowolnie, niekoniecznie do płaszczyzny rzutowania. nie wiem jak to się rozwiązuje w praktyce, moja wiedza nabyta przy pisaniu pracy mgr lata temu się trochę przeterminowała.

[Ryan]

@Dante: trójkątów i tesselacji.
@torq: NEVER!

@fingus: Problemy w percepcji wynikają z kąta widzenia człowieka. Masz blisko 180 stopni, ale połowa z tego to widzenie peryferyczne. Twój mózg oczekuje, że po boku (tam, gdzie kończy się tiwik/monitor) ruch będzie zgodny z tym, co w punkcie, na którym jesteś skupiony. Tak się nie dzieje. Pewien odsetek czuje dyskomfort tak jak Ty, pewien odsetek wymiotuje (jak mnie się zdarzyło na 2 grach). To jak bardzo widzenie peryferyczne wpływa na odbiór zależy od FOV. FOV z kolei zależy od wielkości ekranu i odległości od oczu. W skrócie: póki nie mamy holodeków, problem będzie występował. Perspektywa krzywoliniowa ma znaczenie przy wyświetlaniu bardzo blisko oczu (sprawdź twitter carmacka - ostatnio pokazywał zaimplementowaną korektę dla HUDa).

[fingus]

Ach właśnie, holodek! Wiedziałem, ale nie umiałem nazwać. Tego właśnie oczekuję po następnej generacji!

To ja bym chciał się jeszcze dowiedzieć, jakie są nadzieje na zrobienie porządnie przeźroczystych płaszczyzn (przede wszystkim tych zniekształcających obraz, np. falującej wody lub porowatego szkła). W tej chwili problem jest taki, że zniekształcają one nie tylko to, co jest za nimi, ale i to co jest przed nimi - a może raczej "obraz tego, co jest przed nimi", co wynika pewnie z tego, że nie sortuje się trójkątów, tylko najpierw renderuje (rasteryzuje?) powierzchnie nieprzejrzyste, a potem wrzuca na to efekt falującej wody, czy czego tam, zaglądając tylko do z-bufora gdzie go położyć. No ale wtedy widać na falach pełzający obraz np. trzymanej w rękach broni (lub samego bohatera w tpp), co jest idiotyczne, bo nie ma prawa wystąpić w naturze. Może niektórzy nie zwracają na to uwagi, ale ja tak.

[Ryan]

Przezroczystość wynika z oszczędności albo błędów w implementacji. CryEngine 3 ma lokalne odbicia, które działają dla nieprzezroczystych powierzchni (poniżej), ale można je tez zastosować do przezroczystych. Ich implementacja wody też jest niezła (na PC ;P) i bierze pod uwagę kąt patrzenia, typ wody i masę innych rzeczy. Co do kaustyków - to kosztowne nawet w przypadku RT. Kolejność renderowania, Z-bufor itp. nie są powodem takiego, a nie innego wyglądu wody.

[fingus]

Nie chodzi mi o odbicia. I nie o samą przeźroczystość, a powierzchnię, która jest przeźroczysta i zniekształca obraz za nią - może to być falująca woda, często widać to też w różnych "polach siłowych" albo ornamentowym szkle. Nie wiem, jak jest w Cry Engine, nie wydaje mi się, abym grał w jakąkolwiek grę na nim. Ale wiem, że co jakiś czas to widuję, o np. w Skyrimie też jest:

Nie wiem, czy to błąd, czy "taka technologia". Wiele gier to ma. Nie zawsze jest to od razu widoczne. Na pewno nie jest to odbicie (nie miałoby prawa być tutaj). Kiedyś czytałem (mogło się wiele zmienić od tamtej pory), że na przeźroczyste powierzchnie są dwie metody: albo sortujemy trójkąty i rysujemy je w kolejności od najdalszych do najbliższych, albo najpierw rysujemy wszystkie nieprzeźroczyste, a potem wszystkie przeźroczyste. W tym pierwszym podejściu, gdyby efekt falowania był nakładany w momencie rysowania trójkąta (choć w sumie nie wiem czy jest), to falowałoby tylko to, co już zostało narysowane. W tym drugim - narysowane jest już wszystko nieprzeźroczyste i jak falujemy, to nie sposób zdecydować co powinno falować, a co nie (bo, jak rozumiem, gdy wiemy, że w danym pikselu obraz powinien falować, to liczymy sobie, że należy tu wkleić piksel leżący o pięć w prawo i dwa do góry, ale jeśli tam jest piksel obiektu, który jest przed powierzchnią, to nie zgadniemy jaki kolor był "pod spodem", więc wzdychamy ciężko i wklejamy to, co mamy do dyspozycji).

[Ryan]

Nie chodzi mi o odbicia. I nie o samą przeźroczystość, a powierzchnię, która jest przeźroczysta i zniekształca obraz za nią - może to być falująca woda, często widać to też w różnych "polach siłowych" albo ornamentowym szkle. Nie wiem, jak jest w Cry Engine, nie wydaje mi się, abym grał w jakąkolwiek grę na nim.

Ale przezroczystość z odbiciem sprowadza się w przypadku rasteryzacji do złożenia kilku efektów. CE3 radzi sobie całkiem dobrze z wodą (włącznie z kaustykami), ale konsole sobie z tym nie radzą. :>

Ale wiem, że co jakiś czas to widuję, o np. w Skyrimie też jest:

Nie wiem, czy to błąd, czy "taka technologia".

A co ja niby widzę na tym rozmazanym JPGu? Bo nie mam bladego pojęcia co starasz się przekazać.

Wiele gier to ma. Nie zawsze jest to od razu widoczne. Na pewno nie jest to odbicie (nie miałoby prawa być tutaj). Kiedyś czytałem (mogło się wiele zmienić od tamtej pory), że na przeźroczyste powierzchnie są dwie metody: albo sortujemy trójkąty i rysujemy je w kolejności od najdalszych do najbliższych, albo najpierw rysujemy wszystkie nieprzeźroczyste, a potem wszystkie przeźroczyste.

Półprawdy czytałeś albo pomerdało Ci się coś odrobinę. Generalnie z przezroczystością na każdym sprzęcie (za wyjątkiem naszego ;P) jest tak, że musisz posortować przezroczyste obiekty od tyłu do przodu i musisz to zrobić po wyrenderowaniu całej nieprzezroczystej geometrii. To wynika z wzoru na blending: c_new = c_translucent*alpha + c_old*(1-alpha) -- nie możesz policzyć koloru wynikowego piksela, jeśli nie znasz koloru pod półprzezroczystą powierzchnią. No i kolejność dokładania przezroczystych obiektów wpływa na kolor wynikowy. To, czy *nieprzezroczyste* rzeczy renderujesz od przodu czy od tyłu wpływa jedynie na overdraw (zmarnowane piksele) na każdym sprzęcie (za wyjątkiem naszego ;P) ale nie na wynikowy kolor (chyba, że masz z-fighting, ale to jest bardzo rzadkie przy 32- albo nawet 24-bitowym z-buforze i jakichkolwiek LODach). Sam blending jest niesamowicie kosztowny na każdym sprzęcie (z wyjątkiem naszego ;P) bo wymaga odczytania z bufora ramki koloru, do policzenia nowego koloru na który wpłynęła przezroczysta powierzchnia. Im więcej przezroczystości, tym gorzej. Dlatego np. dla roślinności stosuje się alpha test zamiast alpha blendingu (ustalanie widoczności na podstawie wartości progowej alfa z pominięciem blendowania) albo alpha-to-coverage (dither widoczności/niewidoczności na podstawie wartości alfa), które są stosunkowo tanie na każdym sprzęcie (za wyjątkiem naszego ;P). Są alternatywy do renderowania przezroczystości tył->przód, ale są dosyć kosztowne -- np. depth peeling -- i konsole ich nie uciągną. No i na naszym sprzęcie to jest zbędne, skoro blending jest tani.

W tym pierwszym podejściu, gdyby efekt falowania był nakładany w momencie rysowania trójkąta (choć w sumie nie wiem czy jest), to falowałoby tylko to, co już zostało narysowane. W tym drugim - narysowane jest już wszystko nieprzeźroczyste i jak falujemy, to nie sposób zdecydować co powinno falować, a co nie (bo, jak rozumiem, gdy wiemy, że w danym pikselu obraz powinien falować, to liczymy sobie, że należy tu wkleić piksel leżący o pięć w prawo i dwa do góry, ale jeśli tam jest piksel obiektu, który jest przed powierzchnią, to nie zgadniemy jaki kolor był "pod spodem", więc wzdychamy ciężko i wklejamy to, co mamy do dyspozycji).

Ja tam nie widzę falowania, nie wiem o co chodzi. :S

[fingus]

No to mniej więcej zgadza się z tym, co pisałem. Ale sortowanie nieprzeźroczystych chyba nie jest potrzebne? W końcu chyba do tego służy z-bufor. A przeźroczyste nie mogą być normalne sortowane wraz z przeźroczystymi? Najpierw rysuję najodleglejsze - powiedzmy dno jeziora, potem jego taflę (przeźroczystą), a potem bliższe: drzewa, łódkę i ramię z bronią - a zatem rysują się na tym, co już jest - mniejsza o to, czy było przeźroczyste, czy też nie.

A co do tego, co na obrazku - widać tu stylisko topora u nogi bohatera. I ono jest takie, jak być powinno. Ale widać też wybrzuszenie po prawej - jego powielony obraz pływający na falach. Tego być nie powinno. Fala faluje, załamuje kształty pod wodą (np. schody, co widac na obrazku - kamienie są równe, a wyglądają na zniekształcone). Ale bohater z toporem są ponad wodą, ruch powierzchni nie powinien załamywać ich obrazu. Podobnie wyżej widać powieloną dłoń. Oczywiście ten obraz cały czas się rusza i to powielenie pływa sobie wraz z falą. Jeśli nie widziałeś tego w żadnej grze, to znaczy że grasz mało uważnie.

[ACZ]

fingus, juz w drugim poscie źle piszesz.
piszemy przeZroczysty. jednak w mowie obie formy sa poprawne.

[Ryan]

@fingus: Rysując od tyłu generujesz overdraw. Np. masz niebo, przed niebem górę, przed górą domek a przed domkiem beczkę. Rysując od najdalszych najpierw policzysz w punkcie pixel shader dla nieba, później dla góry, później dla domu, wreszcie dla beczki. 4xPS na jeden piksel - masa mocy zmarnowana. Rysując w odwrotną stronę z-bufor odrzuci piksele z tyłu. Alternatywnie bierzesz SGX/RGX i na naszym sprzęcie samo się wszystko sortuje.

Co do obrazka - dla mnie to był ziomek na schodach. Błąd wynika z tego, że wykorzystano metodę, w której liczone są odbicia w screen space. Zatem żadna informacja niewidoczna na ekranie nie będzie odbita w wodzie. To prowadzi do błędów tego typu. Dlaczego tak robią? Bo screen space jest tani, a object space nie.

[fingus]

Może napiszę coś więcej, jak nie będę siedział na iPadzie, ale na razie tylko: w moim słowniku, ACZ, dopuszczalne są obie wersje i nie ma mowy o "mowie". Obie są też legalne w Scarbble, ale przeźroczysty jest wart więcej punktów.

[ACZ]

8 czerwca na GTTV bedzie pokazówka UE4.

[Sylvan Wielki]

Pokazówka to się zacznie jak zaczną wypuszczać stosowne dema - jak lata temu z Kz2. To było coś. Szoka jak przy TTT/The Bouncer na PS2.

[Cr0ss2500]

[fingus]

W 1:16 blok w tle znika i pojawia się bez powodu.

[Ryan]

Dobre oko. Occlusion culling mają mało konserwatywny najwyraźniej.

[Ryan]

Epic twierdzi, że UE4 starczy na 10 lat. 10 lat to jakiś nowy fetysz?

http://www.vg247.com...t-for-a-decade/

[Danteusz]

Dopasowują silnik do cyklu życia PS4

[Cr0ss2500]

patrząc się na to, żę UE3.0 został pierwszy raz pokazany w 2004r. to 10 lat dla UE4.0 wydaje się ok.

[Stan]

Silnik zaprezentowany przez square, ponoć wszystko jest real time. Wierzycie w to? Zwie sie to Agnis Philosophy.

[Ryan]

Sure, nie ma tu niczego, czego najnowsze karty z piecyka by nie uciągnęły. (co znaczy, że jest super, tak btw)

[Danteusz]

Ech, mam nadzieję że nextgeny będą miały tego Keplera...

[Ryan]

Wątpię. Ale z drugiej strony odległość między API a sprzętem będzie niższa, więc ze słabszego o kilkanaście procent sprzętu będzie można wycisnąć to samo (no i przy stałym HW będzie można optymalizować w kosmos, więc kolejnych kilka procent wydajności się zyska).

Generalnie jednak nie należy oczekiwać takiej grafy na nextgenach. Także z powodu mega kosztownej produkcji treści tej jakości. ;]

[xell]

Część gier będzie mogła sobie pozwolić na taką grafikę, np. Gears of War, bo Epic będzie chciał wszystkim pokazać, jak potężny jest UE4, Halo, bo MS będzie chciało pokazać, jak potężny jest Xbox, Crapcharted, bo Sony będzie chciało zrobić to samo z PS4 itp.

[Danteusz]

Wątpię. Ale z drugiej strony odległość między API a sprzętem będzie niższa, więc ze słabszego o kilkanaście procent sprzętu będzie można wycisnąć to samo (no i przy stałym HW będzie można optymalizować w kosmos, więc kolejnych kilka procent wydajności się zyska).

Generalnie jednak nie należy oczekiwać takiej grafy na nextgenach. Także z powodu mega kosztownej produkcji treści tej jakości. ;]

X360 i PS3 miały w momencie premiery grafiki na poziomie high-endu PC sprzed roku, do premiery nextgenów jest 1.5 roku, może dadzą radę wcisnąć coś w okolicach dzisiejszych mocarzy. Z drugiej strony mogą chcieć utrzymać cenę niewiele wyższą od WiiU, więc pewnie władują szmelc

Co do cen contentu, mam nadzieję że część ficzerów nowych kart będzie na tyle prosta do implementacji że nawet niskobudżetowe gry będą je mieć, co znacznie poprawi ich grafikę

[xell]

PS3 miało w momencie premiery grafiki na poziomie high-endu PC sprzed roku

Fixed. 360 miał najnowszy featureset w momencie premiery i moc obliczeniową nieznacznie gorszą od najwyższych modeli.

[MaxVarEmreis]

Z drugiej strony mogą chcieć utrzymać cenę niewiele wyższą od WiiU, więc pewnie władują szmelc

Módlmy się o to, żeby Nintendo dowaliło cenę 400$ na start

[Danteusz]

Fixed. 360 miał najnowszy featureset w momencie premiery i moc obliczeniową nieznacznie gorszą od najwyższych modeli.

Jak Ryan czepiał się szczegółów to marudziłeś.

Jeśli PS4 i Xbox 3 będą kontynuacją tego co pokazała obecna generacja to możemy liczyć na coś w okolicy Keplera, ale pewnie będą czymś innym, więc trzeba nastawić się na graficzne rozczarowanie

[Ryan]

X360 i PS3 miały w momencie premiery grafiki na poziomie high-endu PC sprzed roku, do premiery nextgenów jest 1.5 roku

W 2005 rynek kart był ciut mniej hardkorowy. Teraz możesz kupić stockową kartę graficzną ze złotymi radiatorami, dwoma układami na płytce, wentylami do chłodzenia cieczą, poborze mocy 0,5kW i bóg wie czym jeszcze. Kepler (GTX 680) w szczycie pobiera 230W. Całe 360 pobiera 115-205W, zależnie od wersji, a i tak ma problem z odprowadzaniem ciepła. PS3 pobiera 200-380W i już działa jak mały pokojowy grzejnik. Sądzę, że należy patrzeć na układy o TDP do maksymalnie 130W (czyli w najlepszym wypadku lowendowe Keplery, a nie 680/690 no i zdecydowanie node nie niższy niż 28nm).

[Stan]

Nie znam się, ale w jednym się mylisz. Mój żydoboks działa jak grzejnik, a nie pysy3