Skyrim na nowym silniku graficznym

Na pewno będzie pięknie a animacja postaci żywcem wyjęta z morrowinda :E (kocham ta gre, ale ma juz pare latek. )

Wreszcie. Ile można klepać gry na Gamebryo, które eksploatowane jeszcze chwilę zaczęłoby wypalac gałki oczne graczom. Po FNV można mieć naprawdę dość tego silnika, braku cieniowania obiektów, archaicznych modeli postaci, tragicznej animacji i świecących się nienaturalnie jak psu jaja tekstur.

oo tak bejbi bejbi kaczuch hepi

gooralesku, wszystko co wymieniłeś w zasadzie nie ma nic wspólnego z samym silnikiem. 🙂

Silnik silnikiem, ale wiele zalezy od tego jak zostana przygotowane obiekty i tekstury. Swoja droga rzeczy typu oswietlenie czy ruch postaci obsluguje engine ;)Zgadzam sie z gooralesko ze Fallouty wygladaja jak kupa i naprawde ciezko sie w to gra, szczegolnie ze jest dziecinnie prosta. Gre ratuje wlasciwie tylko swiat Fallouta, ktory od zawsze mial fajny klimat. Jednak multiplatformowosc ESV nei wrozy rewolucji pod wzgledem graficznym. No ale zobaczymy co tam wepchna. Miejmy tez nadzieje ze skupia sie na porzadnej fabule, a nie jakiejs durnej bijatyce dla malych dzieci.

Przypominam że przy premierze Obek graficznie zwalał z nóg

To było 4 lata temu. Dziś FNV wygląda w sumie gorzej.

Swoja droga rzeczy typu oswietlenie czy ruch postaci obsluguje engine 😉

Animacje przygotowuje grafik, a oświetlenie obsługuje karta graficzna i napisane dla niej shadery. Jeśli graficy w firmie boją się CG i nie potrafią skrobnąć shaderka to oni są problemem, a nie silnik. To samo dotyczy jakości modeli czy tekstur. Na forach poświęconych tworzeniu gier lub konkretnym silnikom bardzo często przewijają się pytania o to, ile dany silnik może wyświetlić trójkątów lub jak duże tekstury „uciągnie”. Odpowiedź jest zawsze ta sama — to nie silnik o tym decyduje. Maksymalna ilość trójkątów i obiektów oraz rozmiar i ilość tekstur na mapie jest definiowana przez docelowy sprzęt (głównie kartę graficzną i pamięć) i nie ma praktycznie nic wspólnego z samym silnikiem, o ile tylko trzyma się on kilku prostych standardów (a że Gamebryo to jeden z najpopularniejszych i najbardziej wszechstronnych silników wszech czasów, to raczej można stwierdzić, że się ich trzyma). To już nie są czasy, kiedy raczkował DirectX i rzeczywiście było możliwe, żeby jakiś silnik potrafił coś, czego nie dało się zrobić w innych. Teraz silniki są w zasadzie jedynie nakładkami na DX/OGL a różnią się głównie edytorami i innymi dodatkami oraz wyborem języka skryptowego. Niestety, lata bzdur i bredni masowo wypisywanych przez nie mających pojęcia o temacie recenzentów gier sprawiają, że większość ludzi a) nie wie kompletnie czym właściwie jest silnik gry, b) znacznie przecenia rolę engine’ów w kształtowaniu ostatecznego wyglądu gier. I nie mówię tu tylko o mechanice, ale również o wyglądzie w sensie dosłownym. Oczywiście, bywają silniki, które nie nadają się do niczego. Bywają błędy w kodzie silników, które powodują spadki wydajności. Ale najczęściej, kiedy gra wygląda lub działa słabo, to znaczy, że problem leży w zupełnie innym miejscu. Niestety, większości graczy wydaje się, że magiczne (tak jak „silnik”) słowo „optymalizacja” ogranicza się do kodu. Nic bardziej mylnego. Najwięcej krzywd wydajność gier doznaje z ręki projektantów poziomów i grafików, którzy często nie posiadając odpowiedniej wiedzy i nie będąc nadzorowanymi przez programistów po prostu źle przygotowują mapy. Każdy gracz, powtarzając za próbującymi brzmieć mądrze recenzentami, wini silniki za wszelkie niedomagania gier. A ilu potrafiłoby powiedzieć co jest ważniejsze dla wydajności gry — ilość obiektów czy ilość tekstur czy ogólna ilość trójkątów na mapie? Kto zna odpowiedź na to pytanie niech pierwszy rzuci kamieniem. Uwierzcie mi, że wystarczy schrzanić rozstawienie obiektów na mapie (mówi coś komuś occlusion culling?) albo dać ich tam za dużo, a nawet najlepszy i najbardziej zoptymalizowany silnik się zatnie ponieważ karta graficzna ma swoje ograniczenia. I pozostawanie w obrębie tych ograniczeń nie leży, niestety, w 100% w gestii programistów piszących silniki. Jeśli o cokolwiek można mieć pretensje do silników jako takich, to jedynie o niedostarczanie odpowiednich narzędzi ułatwiających optymalizację map czy tworzenie shaderów. Niestety, nawet ich brak zwyczajnie nie usprawiedliwia schrzanienia tych elementów w jakiejkolwiek grze. Dlaczego? Chociażby dlatego, że obie te rzeczy można załatwić uniwersalnymi narzędziami dostępnymi, na dokładkę, za darmo. Chociażby od NVidii. Natomiast oskarżanie silników o takie rzeczy, jak niska jakość modeli postaci, to już naprawdę woła o pomstę. . . W CryEngine da się zrobić postacie, które będą wyglądać jak z pierwszego Half Life’a, a w Gamebryo dałoby się zrobić takie, jakie są w Crysis. Naprawdę. Także apeluję. Proszę. Błagam. Przestańmy powtarzać te brednie. . .

No to jeszcze wyjaśnij nam, dlaczego wszystkie gry na UE wyglądają prawie tak samo, dlaczego gry na Gamebryo wyglądają jak kupa, a CryEngine wypala gałki oczne? Tak dla graficznych laików, bo pierwszy wniosek jaki mi się nasunął po Twoim poście to to, że silniki ułatwiają prace. Czyli na moje pytania można odpowiedzieć przede wszystkim zwalając na lenistwo tudzież brak czasu?

@TwilitekidNo i dobry Ci się wniosek nasunął. Silniki ułatwiają pracę i to jest ich główny cel. Ni mniej ni więcej. Chronią programistów przed „urokami” pisania bezpośrednio w OGL/DX (a kiedyś i tego nie było. . . ) oferując bardziej przyjazne API. Choć, gwoli ścisłości, API OGL/DX oraz CG/HLSL/GLSL (czyli języki, w których pisze się shadery) cały czas są dostępne, jeśli tylko ktoś ma chęć i czas z nich skorzystać i napisać sobie coś, czego dany silnik nie oferuje OOTB. Ale mało kto może sobie na taki luksus pozwolić. Tym niemniej, silniki rzeczywiście różnią się od siebie. Różnią się oferowanymi w pakiecie shaderami, gotowymi kawałkami kodu, modelami, teksturami itd. Bo to wszystko dostaje się w pakiecie z silnikiem (nie mówcie nikomu!). Kiedy kupujesz (kupujesz, a nie ściągasz jako UDK, to duża różnica) Unreal Engine, to dostajesz całe mnóstwo gotowych do wykorzystania kawałków gier Epic. Fragmenty Gearsów czy UT. I teraz odpowiedz sobie sam, dlaczego wszystkie gry na UE3 wyglądają praktycznie tak samo. Oczywiście pomijając te, które nie wyglądają, np. Mirror’s Edge, które też było wykonane w tej technologii (ze względu na workflow, do czego wrócę), a jeśli mi ktoś powie, że ta gra wygląda jak Gears of War czy Mass Effect to zapytam kiedy ostatnio był u okulisty. Przykład mniej wyrazisty, ale jednak — Borderlands. Również powstał na UE3. Ale wracając do Mirror’s Edge. To świetny dowód na to, że za wygląd i mechanikę odpowiadają projektanci i graficy, a nie silnik. Oczywiście, widać tam pewne naleciałości, ale wynikają one tylko z wykorzystania dostarczonych z silnikiem shaderów. Gdyby się tylko grafikom i/lub programistom (chociaż w sumie UE3 ma chyba edytor shaderów na węzłach, więc po cholerę tu programiści?) chciało, to mogliby napisać własne od początku do końca. I nawet najbardziej wprawne oko nie poznałoby, że to UE3. Dlaczego CryEngine wygląda tak dobrze? Może zapytajmy raczej dlaczego Crysis wygląda tak dobrze, bo tak się składa, że ta gra jest (oh what a surprise biorąc pod uwagę mój wywód w poprzednim poście o niezrozumieniu tematu) utożsamiana z tym silnikiem tak samo, jak Gearsy są utożsamiane z UE3. Tymczasem CryEngine 2 to również kilka istniejących i zapowiedzianych MMO, które ni w ząb nie przybliżają się efektownością do Crysis (a wyglądają raczej jak z ery monitorów kineskopowych). Ale ok, ktoś może powiedzieć, że MMO, więc to zrozumiałe (a ja na to, czyli nagle silnik przestał definiować grafikę?), ale w takim razie pokażcie mi istniejącą grę third party na CryEngine 2. Niestety, takich praktycznie nie ma, a to, że Crytek, firma, której celem i hasłem przewodnim jest robienie zabójczej grafiki robi zabójczą grafikę niczego nie dowodzi w kwestii jako takiego silnika. A Gamebryo? Patrz Unreal Engine. Ja mam na to nawet słówko ukute. „Middlewarizm”. Oznacza bezmyślne używanie tylko tego, co przyszło z silnikiem z uwagi na brak czasu, umiejętności lub lenistwo. Nadużywanie middleware’ów jest plagą dzisiejszego świata gier. W samych middleware’ach nie ma nic złego. Ba, one są bardzo dobrą rzeczą a robienie nowego silnika do każdej gry, co już wielokrotnie pisałem chociażby w kontekście Wiedźmina 2, jest głupie. Niestety, kierunek „make it bigger make it faster” zmusza zwyczajnie do korzystania niemal wyłącznie z tego, co już jest. Bo tak jest, oczywiście, szybciej. W rezultacie graficy, przy dobrym wietrze, przerabiają tekstury, które dostali z silnikiem, lub które zostały z poprzedniej gry, wykorzystują dostarczone lub zakupione shadery bez żadnych praktycznie zmian oraz kupują tekstury i modele w tych samych sklepach (kiedyś była o to nawet afera, dziennikarze zrobili szum, że gry X i Y ukradły tekstury z gry Z, a okazało się, że pochodziły po prostu z tego samego zestawu kupionego w jednym sklepie). Teraz złóż to do kupy i zastanów się dlaczego gry wyglądają tak samo. Podsunę dwa inne silniki, jeśli pozwolicie. Na początek — dlaczego gry na Chrome Engine wyglądają niemal tak samo? Bo większość tych gier robi ta sama firma — City Interactive. A teraz z grubej rury — dlaczego gry na Source wyglądają niemal tak samo (no, pomijając Team Fortress 2, które w zasadzie rozwala mi tu sarkastyczną koncepcję wypowiedzi)? Dlaczego nawet Portal zdawał się być przemalowanym na biało Half Life’em 2? Bo, jak powszechnie wiadomo, szeroko wykorzystywał assety z HL2 w celu skrócenia developmentu i zmniejszenia kosztów tej eksperymentalnej gry. A reszta? Cóż, ogromną większość gier na Source zrobiło Valve, więc aż dziwne by było, gdyby gry te wyglądały zupełnie inaczej. Z innej strony, third party Dark Messiah of Might and Magic bardziej przypomina, nawet z wyglądu moim zdaniem, Obliviona niż Half Life. Zbliżając się do końca — każdy silnik umożliwia to samo, bo każdy ma w podstawie OGL/DX i języki shaderowe. Różnice istnieją, nawet na tym fundamentalnym poziomie, ale są minimalne i zawsze można je obejść bez większego trudu odwołując się do niższej warstwy, czyli wspomnianego DX/OGL. Żeby bardziej uwidocznić podobieństwa nie tylko między grami, co między samymi silnikami (a tym samym dowieść, że chodzi o dostarczane/kupowane/odgrzewane assety a nie kod) powiem, że Gamebryo korzysta w dużej mierze z tych samych technologii, z których korzysta większość pozostałych popularnych silników, z UE3 i CryEngine2 (popularny? dobra, niech mu będzie) włącznie. Speedtree, Scaleform, NaturalMotion, Umbra, PhysX, Beast, Kynapse — sprawdźcie tu (Gamebryo) i tu (UE3). Gry buduje się z klocków. Z tych samych klocków. Aha, miałem jeszcze wrócić do Mirror’s Edge. Dlaczego DICE zdecydowało się skorzystać z Unreal Engine kiedy tworzyło Mirror’s Edge, skoro gotowy był in-house Frostbyte? To proste — dodatki i ograniczanie kosztów i ryzyka. Tak samo jak Valve i Portal używający assetów z HL2. Mirror’s Edge było eksperymentalną grą, a przy takich liczą się dwie rzeczy: ograniczenie kosztów i ryzyka do absolutnego minimum oraz łatwość prototypowania. Unreal Engine 3, za sprawą Kismeta, Unreal Script i innych świetnych dodatków stanowi doskonałą odpowiedź na te potrzeby. Przy czym DICE podeszło do tego z głową i zrobiło grę, która na dodatek wygląda oryginalnie, więc nie użyli UE3 bezmyślnie, jak robi to większość developerów w sweatshopach. Eh, chyba wystarczy, co? No, myślę, że tak. Słuchajcie, temat silników i ich kształtu w dzisiejszych czasach to temat rzeka ale zrozumcie jedno — każdy nowoczesny silnik jest w stanie wyświetlić dokładnie, piksel w piksel, shader w shader, trójkąt w trójkąt to samo. Czasem wymaga to odwołania się jedną warstwę niżej albo napisania shadera, ale dostarczone shadery to, jak mówiłem, dodatki. Nawet kiedy developerzy jakiegoś silnika ogłaszają, że „renderer został w całości przepisany” to możliwe są tylko dwie opcje (najczęściej występujące wspólnie) — 1) jest to bełkot marketingowy, 2) rzeczywiście został, ale tylko po to, żeby lepiej pasował do zmian w API DirectX czy OpenGL, ewentualnie dlatego, że developerzy uznali, że jego dalsze rozwijanie wymaga przemeblowania kodu w celu zwiększenia jego przejrzystości (kod ma to do siebie, że „mętnieje”) i wygody jego używania. Bo jeśli taki silnik powstał, powiedzmy, w czasach DirectX 9. 0c to przepisywania w innym celu zwyczajnie nie potrzebuje i najpewniej długo potrzebować nie będzie (przy przejściu z DX9 na 9c było to przydatne w wielu przypadkach z uwagi na wprowadzenie Shader Model 3. 0, ale nawet wtedy dałoby się bez tego obejść. Dość powiedzieć, że Crytek dodał do pierwszego CryEngine (FarCry) obsługę SM3. 0 bez większego problemu). To, co da się wyświetlić określa karta graficzna, nie silnik. Kropka. Natomiast za to, że gry obecnie są jakie są odpowiadają głównie wydawcy, koszty produkcji, rozmiary studiów, cięcie kosztów, krótkie deadline’y i cała reszta szamba, które osobiście określam wspomnianym mianem „middlewarizm”. Albo po prostu modern game industry. Hawk!EDIT bo doszedł post Boro.

Oczywiscie ze oswietlenie generuje GPU, ale jak sam zauwazyles na podtsawie kodu ktory jest w engine gry.

Nie do końca. Pomijając już, że zarówno Gamebryo jak i UE3 korzystają z tych samych oświetleniowych i cullingowych middleware’ów to trzeba powiedzieć, że oświetleniem rządzą shadery. A te pisze się w CG/HLSL lub w GLSL. I powiem krótko — one całkowicie omijają wszystko, co dzieje się w kodzie silnika. Oczywiście, silnik może mieć własny język shaderowy wyższego poziomu, ale to nie zmienia faktu, że shader „prawidłowo” i tak się napisać da zawsze bo CG i spółka omijają warstwę silnika i trafiają prosto do karty graficznej. Inaczej mówiąc, jeśli weźmiesz shadery (dostarczone ootb) z UE3 i użyjesz ich w grze napisanej w CryEngine to gra będzie wyglądała jak UE3. Ot wszystko.

Grafik tez nie przygotowuje pelnej animacji tylko korzysta z algorytmu odpowiedzialnego za ruch, ktory tez najczesciej jest zaimplementowany w sam engine, lub jest jakims tam dodatkowym modulem.

To prawda. Ale nie do końca. Rzeczywiście w dzisiejszych czasach korzysta się z middleware’ów generujących animacje postaci, ale prawda jest taka, że wszystkie silniki korzystają z tych samych. Z drugiej strony, kiedy mamy do czynienia z mo-capem to do gry trafia dokładnie to, co zostało złapane. Ni mniej ni więcej. I silnik jest tu wyrobnikiem, który ma wyświetlić to, co dostał i nie narzekać. A że dostaje cały czas to samo, czyli to, z czym przyszedł, to już jest inna kwestia. . .

Dlaczego nie ma lepszych animacji przez cztery gry na gamebryo? TES III, IV, F3 i FNV. Każda gra to szansa dla twóców na zrobienie porządku z tym elementem a jednak nie dało się. W FNV nawet jest zmieniona animacja ale jak każdy widzi nadal jest koślawa jak chód kaczki.

Bo to są współdzielone assety, o czym mówi coppertop. Ale i tak wniosek z tego co copper piszesz jest jeden. I tak trzeba było się przerzucić na nowy silnik, bo męczenie się swoimi sposobami na gamebryo jest nieopłacalne, skoro gdzie indziej można dostać to samo już zrobione. Idąc tym samym tropem można powiedzieć, że po co pisać pewne rzeczy w językach wyższego poziomu, skoro i tak to wszystko można nabazgrać w C+ASM ;]

No to animację wyjasniłeś bo przeczytałeś to samo w tekscie Coppertopa co ja. A wyjaśnij teraz sprawę braku cieniowania jakże mi przeszkadzająca w grach na Gamebryo.

Poniekąd się zgadzam, Twilitekid, ale prawda jest taka, że żaden z nas tak naprawdę nie wie jak wygląda praca z Gamebryo. Szczególnie, że o tym silniku generalnie mało wiadomo poza tym, że jest dość popularny i że śmiga na tym wszystko, od Fallouta 3, przez Cywilizację, przez Empire Earth aż po Epic Mickey. Być może ma jakieś zalety, które o tym decydują. Pamiętajcie, że na Unreal Engine też powstają bardzo różne gry. Ale powstaje ich też bardzo, bardzo dużo. Znacznie więcej niż na jakimkolwiek innym silniku, więc się tych słabych nie zauważa. A jest ich sporo. Także nie ferowałbym wyroków na sam silnik. To samo można powiedzieć o CryEngine — Crysis wygląda fantastycznie, ale mimo to silnik nie jest popularny, mimo, że dołączone do niego edytory wyglądają całkiem smacznie. Na ten temat też można by się rozpisać ;). Aczkolwiek powiem tak. Nie było, bynajmniej, moim zamiarem deprecjonowanie wyboru technologii. Sam korzystałem z kilku silników i wiem, że ona może wiele zmienić. Chociażby umożliwiając (jak w przypadku DICE i Mirror’s Edge) skupienie się na tych elementach gry, które się naprawdę liczą. Ale jednocześnie nie jest tak, że czegoś się zrobić w danym silniku nie da szczególnie, kiedy wszystkie tak naprawdę siedzą na tych samych middleware’ach (vide dwa linki z poprzedniego posta). Tym niemniej, to, do czego przyczepił się Gooralesko naprawdę nie miało z silnikiem nic wspólnego. Owszem, gdyby Beth skorzystało z UE3 (bo, let’s be honest, to jedyna opcja) to być może Oblivion i Fallout wyglądałyby lepiej (wcale nie jest to takie pewne, bo modele postaci i otoczenia oraz przynajmniej niektóre tekstury nadal robiliby ci sami ludzie), ale za cenę wyglądania tak samo jak każda inna gra. A gdyby chcieli, żeby wyglądał inaczej to na jedno by wyszło — i tak musieliby sobie skrobać shaderki ręcznie ;). Do tego wcale nie jest pewne, że gra byłaby bardziej wydajna niż na Gamebryo, bo jeśli niezoptymalizowaliby map to nadal byłaby kicha. Możliwe, że Fallout i Oblivion niedomaganiem graficznym nadrabiają właśnie spadki wydajności powodowane brakiem optymalizacji map. I tak dalej, i tak dalej. Widzicie o co mi chodzi? Czynniki. Całe mnóstwo czynników. @GooraleskoMoże najpierw uściślijmy, co masz na myśli pisząc „cieniowanie”. Bo ja może w Fallouta 3 długo nie grałem (leży rozgrzebany zaraz po wyjściu z krypty i nie mam kiedy do niego wrócić) ale jakoś nie wydaje mi się, żeby brakowało w nim normal mapek i spółki.

Cieniowanie to rzucanie cieni przez budynki, konary drzew, i inne statyczne obiekty nie wliczając w to cieniowania postaci które w F3 zostao zdegradowane do smukłego cienia postaci bez samocieniowania któe zostało usunięte po Oblivionie. Oblivion w mieście http://images1. wikia. nocookie.net/__cb20060330. . . Market. jpgFallout 3 http://xbox360media. gamespy. com/xbox360/image/. . . 7_640w. jpgFNV http://www.uncrate. com/men/images/2010/10/fall. . . gas-xl. jpgw porównaniu z cieniowaniem w Assassins Creed 2 http://i. neoseeker. com/p/Games/Playstation_3/A. . . elarge. jpggdzie samocieniowanie jest wszechobecne prawie każdego statycznego obiektu. czy brak tego elementu wprowadzającego realizm sceny gry może być spowodowany niezoptymalizowaniem Gamebryo Bethesdy do jego wyświetlania. Już Morrowind po uruchomieniu cieni klatkował na większości sprzętów a w nim równiez nie było mowy o rzucaniu cienia przez budynki drzewa i tym podobne.

I jeszcze jedno pytanie na koniec. Czy możliwe jest, że pod popularnym swtierdzeniem „brand new engin” kryje się wywalenie elementów nadających archaiczne kształty w ostatnich czterech grach i zastąpienie ich nowoczesnymi „klockami” lub w przypadku animacji wreszcie sesją motion capture?

Cieniowanie to rzucanie cieni przez budynki, konary drzew, i inne statyczne obiekty

Na początek żeby nam się następnym razem łatwiej rozmawiało ;). To o czym mówisz to jest shadow mapping, albo shadowing. Czyli rodzaj „cieniowania”. Taka różnica pomiędzy angielskim „shading”, czyli tym, co robią shadery, i „shadowing”, czyli tym, co shadery mogą robić jak się im jeszcze kamerkę albo inne smakołyki podsunie. Dodatkowo nie ma to nic wspólnego z „samocieniowaniem”, czyli self-shadowing. Self-shadowing dotyczy dynamicznych cieni i dynamicznych obiektów. Obiekty statyczne nie mają z tym nic wspólnego. Pozwolę sobie tu na drobną refleksję. Widzicie, i to jest właśnie rezultat notorycznego mylenia pojęć przez recenzentów, szczególnie w Polsce (bo w anglojęzycznych odpada przynajmniej wypaczony pseudo-przekład), oraz ciągłego bełkotu wciskanego przy okazji każdej większej premiery przez marketingowców, którzy też rozumieją temat mniej więcej tak samo, jak ja neurochirurgię. . . Wracając do meritum. Gdy pytają mnie. . . dlaczego nie ma statycznych cieni. . . odpowiadam. Nie ma, bo się ludkom z Beth nie chciało ich zrobić albo nie potrafili zrobić ich tak, żeby działały szybko i wyglądały dobrze. Nie wierzę, żeby jakikolwiek nowoczesny silnik tego nie obsługiwał. Ba, będę musiał sobie włączyć F3 żeby, na żywo, przekonać się, że tego tam rzeczywiście nie ma, bo mi się wierzyć nie chce. Nie chcę już wchodzić w szczegóły, bo się znowu rozpiszę, ale statyczny czy nawet dynamiczny shadow-mapping to naprawdę żadna filozofia. Kamera, projekcja i wio. Nawet techniki soft shadows są na tyle dobrze opisane, że poważni programiści z dużej firmy nie powinni mieć problemu z ich zaimplementowaniem, a poważny silnik po prostu powinien je oferować. Jedyne wyjaśnienie, jakie przychodzi mi do głowy to to, co napisałem wcześniej. Po prostu mapy są niezoptymalizowane (pomijam kwestię pecetów, konsol i zlewozmywaków bo nie ma tu nic do rzeczy) i trzeba było to czymś nadrobić. Innego wyjaśnienia nie znajduję i raczej nie znajdę, chyba że ktoś mi zapewni dostęp do kodu gry i silnika.

Czy możliwe jest, że pod popularnym swtierdzeniem „brand new engin” kryje się wywalenie elementów nadających archaiczne kształty w ostatnich czterech grach i zastąpienie ich nowoczesnymi „klockami” lub w przypadku animacji wreszcie sesją motion capture?

Nie tylko możliwe, ale wręcz bardzo prawdopodobne. Większość developerów tego nie przyzna (bo by wylecieli z pracy), ale w bardzo wielu „autorskich” silnikach da się znaleźć elementy kody idTech3 (czyli silnika Quake Arena), a w Unreal Engine 3 majaczą kawałki pierwszego UE. I bardzo dobrze, zresztą.

Ja wiem co to jest self-shadowing i wiem, że jest różnica pomiędzy shaderem, a shadow. Debila ze mnie nie trzeba robić pomimo bycia amatorem w tych tematach. Self-shadowing czyli wspominane przez mnie samocieniowanie występuje na obiektach w AC 1 więc wychodzi na to, że tam jest pełne dynamiczne samo-cieniowanie wszystkiego (Cień z beczki – czyli obiektu statycznego w grze – „leży” na teksturze podłoża i pod odpowiednim kątem jego część „leży” na pozostałych beczkach stojących obok oraz na niej samej) czyli cienie przesuwają się płynnie w zależności od położenia jednego źródła światła. A co do Gamebryo. Odpal, odpal. Zwróć uwagę jakim wielkim błędem jest brak cieni dla budynków, skał, wzniesien itp. Jak masz możliwość odpal Obliviona który jest super cukierkowy i korzysta z pełnej palety barw więc widac tą graficzną niedogonośc jeszcze mocniej. Dokładnie to samo jest w Morrowindzie i FNV. Cienie rzucają jedynie modele postaci. W Obku próbowano unowocześnić ten archaiczny system i dodano samocieniowanie na postaciach, które przez kilka miechów działało błędnie do wydania patcha. Po tym widać, że implementacja czegoś bardziej skomplikowanego, a jednocześnie normalnego w UEIII (dobrze wykonane w GOWach, Mass Effectach) sprawia ogromne problemy w przypadku Gamebryo. Gdyby larum odnośnie oprawy podniosło się wcześniej zaraz po niby pięknym Oblivionie to może zmiana silnika lub jego gryntowna przebudowa nastąpiłaby wcześniej niżtrzy gry poźniej. Na koniec przyznam szczerze, że jestem zaskoczony. Osoba siedząca tak mocno w temacie nie wiedziała, że ostatnie Fallouty i TESy chulają sobie bezczelnie bez cieni połowy obiektów, które są na ekranie przeważnie wyświetlane. Myślałem, że wystarczy o tym napomnieć, a momentalnie będziesz wiedział OCB. Wychodzi na to, że takie poważne zaniedbanie graficzne uchodzi Bethesdzie na sucho bo nikt do tego nie przywiązuje wagi. Nawet ludzie, którzy powinni pod tym kątem gry oglądać gdy w nie grają.

uff przeczytałem całość. Tak czy inaczej nie zmienia to faktu, że jak słyszę o nowej grze na UE3 to rzygać mi się chce. Obojętne czy wynika to z ograniczeń silnika, czy lenistwa deweloperów gry. Recenzenci wcale nie muszą się zagłębiać w temat grunt żeby rzetelnie opisali to w co grają, a że na ogół gry na UE3 wyglądają tak samo :/

Debila ze mnie nie trzeba robić pomimo bycia amatorem w tych tematach.

Nie mam absolutnie takiego zamiaru. Nazewnictwo w grafice komputerowej bywa niejednoznaczne dlatego chciałem mieć pewność, że mówimy o tym samym.

Na koniec przyznam szczerze, że jestem zaskoczony. Osoba siedząca tak mocno w temacie nie wiedziała, że ostatnie Fallouty i TESy chulają sobie bezczelnie bez cieni połowy obiektów, które są na ekranie przeważnie wyświetlane. [. . . ]

Wiesz, wytłumaczenie jest bardzo proste. W Fallouta 3 grałem do tej pory, jak wspomniałem, chyba z 10 minut. I to na szybko, bo mnie czas gonił. Nie miałem zwyczajnie czasu przyjrzeć się czemukolwiek ani rozebrać gry na czynniki pierwsze, jak to zwykle robię. Chociaż nie, skupiałem się na jednej rzeczy — interfejsie. Przed F3 nadrabiałem Mass Effect, od którego odbiłem się kompletnie i nie mam zamiaru do niego wracać choćby mnie kołem łamali, i którego GUI i reszta designu były tak wielkim horrorem, że odpalając F3 skupiłem się głównie na tym elemencie, chcąc się upewnić, że jest lepiej (gorzej już chyba być nie mogło). Ale i tak nie zdążyłem go przeanalizować tak, jak bym chciał, bo ledwo wyszedłem z krypty. I to sprintem. Dlaczego natomiast gram dopiero teraz? Ano dlatego, że dopiero od niedawna mam komputer, który mi na to pozwala. Wcześniej moja maszynka nie pozwalała nawet na odpalenie Obliviona, dlatego teraz nadrabiam, w miarę ograniczonych możliwości czasowych. Life is life. . . .

Myślałem, że wystarczy o tym napomnieć, a momentalnie będziesz wiedział OCB

Domyślałem się, choć przyznam, że ciężko było mi przyjąć do wiadomości brak cieni w nowożytnej grze komputerowej. . . Dlaczego tego nie zauważyłem, też już wyjaśniałem. A potem po prostu chciałem się upewnić o co Ci chodzi, bo niestety terminologia w grafice kompuerowej to kompletny i stuprocentowy burdel, więc czasem trudno zrozumieć co rozmówca ma na myśli. Szczególnie w obrębie shadingu, shadowingu i okolic.

Po tym widać, że implementacja czegoś bardziej skomplikowanego, a jednocześnie normalnego w UEIII (dobrze wykonane w GOWach, Mass Effectach) sprawia ogromne problemy w przypadku Gamebryo.

Po tym nic nie widać. Naprawdę, bazując tylko na braku-czegoś nie jesteś w stanie stwierdzić dlaczego tego czegoś nie ma. Jak napisałem, jeśli silnik po prostu nie obsługuje podstawowych technik shadow mappingu to rzeczywiście jest beznadziejny. Z drugiej strony Beth, które tak go chwali i używa od lat, mogłoby sobie te elementy spokojnie dopisać, bo do najbardziej skomplikowanych to one nie należą. . . Ale jeśli ta funkcja tam jest, a jestem pewny, że jest (w jakiejś postaci), to znaczy, że wina za niewykorzystanie tych możliwości może leżeć po stronie developerów z Bethesda. Może, ale nie musi.

Recenzenci wcale nie muszą się zagłębiać w temat grunt żeby rzetelnie opisali to w co grają, a że na ogół gry na UE3 wyglądają tak samo :/

Owszem, ale najczęściej jest „gra jest na silniku UE3 więc wygląda jak Gearsy”. A to jest półprawda, czego dowodziłem w poprzednich postach. Poza tym, bardzo często zdarza się, że recenzenci starają się, niejako na siłę, powrzucać do swoich tekstów trochę technicznie brzmiącej gadki, która robi tylko wodę z mózgu graczom.

to ja mam takie pytanie odnośnie cieni: w wszystkich grach na UE3 wyglądają kiepsko, bo są jakby „poszarpane”, a na innych silnikach cienie są cacy. To wina shadera z UE3, czy coś innego?

rafparis – to wina wyliczenia shadowmap (statycznego oświetlenia) w niskiej rozdzielczości. Czym wyższą rozdzielczość ustawisz w edytorze do wyliczenia, tym dłużej się ona liczy, więc to prawdopodobnie kwestia zbliżającego się wielkimi krokami deadline’u 🙂 Oczywiście mam na myśli, że mówisz o statycznych cieniach, czyli takich, które nie zmieniają się podczas ruchu świateł.

digital_cormac-> właśnie nie, mówię o tych dynamicznych, np na zbroi czy twarzy. zawsze mi to jakoś przeszkadzało przy grach na UE3 🙂

Widzisz. Dynamiczne cienie są liczone w silnikach w zasadzie tylko na dwa sposoby. Pierwszy z nich, ten bardziej archaiczny (co wcale nie znaczy że gorszy), stosowany między innymi w ID Tech 4, polegał na zastosowaniu tak zwanego Stencil Buffera. Po polsku, na każdej powierzchni na którą padał cień, był tworzony zrzutowany do przestzrni 2D obiekt rzucający cień. Skutkowało to cieniem o ostrych, wyraźnych krawędziach (tzw. hard shadows). Dodawało to również dość sporo geometrii do liczonej sceny, ponieważ sam cień był również obiektem (tylko płaskim i generowanym co ramkę przez silnik). Drugim sposobem jest tworzenie co klatkę mapy cieni przy pomocy metody raycastingu. W skrócie z pozycji światła rysowane są wektory w kierunki obiektu i jeżeli te wektory przetną się z jego meszem, rysowana jest do bufora mapa cieni dla tego właśnie mesza. Mapa ta następnie jest nakładana na obiekty znajdujące się za meszem rzucającym cień. I teraz bardzo prosta sprawa. Czym więcej tych wektorów i czym większa rozdzielczość mapy cieni, tym lepszej jakości masz cień, ale tym większe obciążenie dla sprzętu. Rozdzielczości map cieni reguluje się zmiennymi wewnątrz edytora map, więc to, że w jakiejś grze są kiepskiej jakości, poszarpane cienie, zależy tylko i wyłącznie od decyzji developerów. Dodatkowo mapa cieni, to upraszczając zwykła bitmapa, więc można ją programowo rozmywać, tworząc cienie o gładkich krawędziach (soft shadows). Oczywiście to co powyżej napisałem to straszliwy skrót, jakość mapy cieni zależy też od wielu innych czynników (jak np. rodzaju źródła światła) ale mniej więcej tak to właśnie wygląda.

Z tego co wiem projekcja cieni w grach bardzo rzadko jest robiona za pomocą raycastów. Ta technika jest imho zdecydowanie za ciężka (bardziej odpowiednia do klasycznej grafiki), dlatego korzysta się raczej z jej prostszego odpowiednika. Zamiast robić dziesiątki promieni ze źródła światła stawia się zwyczajnie w jego miejscu odpowiednio ustawioną kamerę, która w zasadzie widzi tylko obiekty oznaczone jako shadow caster. W każdej klatce robi się projekcję obrazu na teksturę, a dalej to już jak opisał Cormac. Mamy bit mapę, która następnie jest obrabiana celem uzyskania miękkich cieni. Projekcja cieni, jak opisał Cormac, ma generalnie jedną dużą wadę — dla dobrych rezultatów potrzebna jest naprawdę konkretnych rozmiarów tekstura. Jeśli jest mała to nie ma mowy o dobrych rezultatach. Tym niemniej, w grach na UE3 widać jeszcze coś. Mianowicie że dynamiczne shadow mapy są nie tylko małe, ale dodatkowo kiepsko nakładają się na obiekty. To znaczy, że shader, który używany jest do ich nałożenia na pozostałe tekstury (color, normal i cała reszta) jest zwyczajnie kiepsko napisany. I to też nie ma nic wspólnego z silnikiem natomiast fakt, że w każdej grze pojawia się to niedomaganie dowodzi tylko jednego — developerzy uznają, że taka sytuacja jest „good enough” i zostawiają wszystko na, że tak powiem, ustawieniach domyślnych.

Jap. Zapomniałem, kamerą też można. 🙂 Te raycasty natomiast wcale nie są aż tak ciężkie. Wykorzystuje się je do rozmaitych celów poza cieniami i serio, można ich wypuszczać tysiące bez widocznej utraty prędkości. Sprawdzone na żywym organizmie 😉

@GooraleskoTak jak napisał Cormac, dużo zależy od wielkości tekstury. A ja dodałem, że również od jakości shadera „mieszającego” mapę koloru z mapą cieni. I w tym leży cała tajemnica. Jeśli w Mass Effect 2 wygląda to lepiej niż w jedynce (grałem tylko w jedynkę i po dwójkę nie zamierzam sięgać po tym traumatycznym doświadczeniu) to wynika to z tego, że developerzy zmienili ustawienia (być może optymalizując coś innego i w ten sposób robiąc sobie miejsce na większą rozdzielczość) i ewentualnie poprawili shader. Natomiast co do przełożenia wydajności konsol na PC. . . Wiedziałem, że ten temat się w końcu pojawi. Ale tego nie można przekładać w ten sposób. Rzeczywiście, nie zdziwiłbym się, gdyby domyślne shadery oraz ustawienia jakości map cieni były w UE3 zoptymalizowane pod konsole. Ba, jestem niemal pewny, że tak jest. Ale niezależnie od tego, samo zwiększenie rozdziałki, które już by wiele dało, nie jest żadnym problemem — wymaga zmiany jednej wartości (choć trzeba robić to z głową), więc nie usprawiedliwia to twórców i nie jest też postawą do psioczenia na konsole jako takie. Shader „mieszający” to trochę inna sprawa bo wymaga trochę więcej pracy, ale też wykonanie lepszego nie powinno być dla takiej firmy jak Bioware wielkim problemem. Sądzę, że gdyby dobrze poszukać to dałoby się nawet taki w Cg na necie znaleźć. . . @D_CI stand corrected ;). Ostatecznie co jak co, ale machanie wektorami kartom graficznym dość dobrze idzie ;D. W sumie nawet się teraz zacząłem zastanawiać co jest wydajniejsze. . . Ale jednak sądzę, że projekcja kamerą. Wydaje mi się też, że powinna być prostsza, bardziej „automatyczna”, w implementacji.

Swietny watek! Wielkie dzieki za duzo objasnien i przyblizenie nieco kwesti silnikow/grafiki. @coppertop a moze chialoby Ci sie napisac jakis art na ten temat? Ja bym bardzo chetnie cos takiego przeczytal!Swoja droga to nieco mnie to smuci. . . bo z tego wszystkiego wynika, ze gry sa w wiekszosci tworzone przez bezmozgie, leniwe beztalencia :/

dokłądnie, świetny wątek chłopaki, dzięki 🙂

Swoja droga to nieco mnie to smuci. . . bo z tego wszystkiego wynika, ze gry sa w wiekszosci tworzone przez bezmozgie, leniwe beztalencia :/

Oj nie, taki wniosek jest mocno przesadzony. Oczywiście, większość członków teamów developerskich to wyrobnicy, których zadaniem jest wystruganie konkretnej animacji albo naskrobanie konkretnego kodu „na wczoraj”, ale nazywanie ich „leniwymi beztalenciami” to spore nadużycie. Niektórzy oczywiście są leniwi, ale nie są beztalenciami ;). A już na pewno nie można powiedzieć, że są pozbawieni umiejętności. Gry są po prostu. . . cóż, biznesem. I to jest, dla mnie, cholernie przykre. „But that’s the way of all things” w obecnym świecie, niestety. Gry są produktem więc robi się je jak produkty. Dla ludzi trzymających władzę nad studiami developerskimi gry komputerowe niespecjalnie się różnią od parówek — to produkt, który ma być zrobiony, ma być good enough i ma przynieść kasę. Ot wszystko. Akcjonariuszy nie interesuje „wartość artystyczna”. Taki jest stan rzeczy i dobrze jest zdawać sobie z tego sprawę. Gorzej, jeśli się to uważa za normalne. . . Ale to już jest raczej temat na zupełnie inną dyskusję. Choć myślę, że Bill Hicks miałby tu coś do dodania: http://www.youtube. com/watch?v=gDW_Hj2K0wo

a moze chialoby Ci sie napisac jakis art na ten temat? Ja bym bardzo chetnie cos takiego przeczytal!

Szczerze mówiąc nie wiem, czy miałbym kiedy. . . Szczególnie teraz. Nawet te posty pisałem z doskoku. W sumie już kiedyś wypociłem artykuł o silnikach i shaderach. Choć teraz, z perspektywy, wygląda on dla mnie dość śmiesznie, jeśli mam być szczery. Doświadczenie, jakie zdobyłem w międzyczasie zrobiło swoje i teraz trochę się krzywię czytając to, co wtedy napisałem. Co prawda nie ma tam może jakichś rzeczy, które wprowadzałyby istotnie w błąd, ale jednak teraz napisałbym go inaczej ;). I w sumie nawet napisałbym go chętnie, ale to niestety trwa. . . A czas to towar wiecznie (pun intended) deficytowy. Tym niemniej, nie mówię nie. To byłoby również ciekawe dla mnie samego, więc jeśli uda mi się kiedyś znaleźć czas to chętnie. D_C — dołączyłbyś się, gdybyś miał czas? 😉

Trzymamy kciuki. . a z tymi beztalenciami, przyznam sie bez bicia, to byla lekka prowokacja :)Co do czasu to sie zgodze. . wiecznie go brak! Ale to chyba tylko znaczy, ze jestesmy aktywni i mamy zainteresowania ;)Swoja droga, jesli mozna zapytac, co Ty robisz zawodowo skoro tak duzo o tym wiesz? Bo hobbistycznie to chyba na wgryzanie sie w te occlusion cullingi by czasu nie starczylo!

Co do czasu to sie zgodze. . wiecznie go brak! Ale to chyba tylko znaczy, ze jestesmy aktywni i mamy zainteresowania 😉

Jest takie znane Chińskie przysłowie mówiące, że jeśli ma się za mało czasu to trzeba znaleźć sobie dodatkowe zajęcie ;). Osobiście jakoś to do mnie nie przemawia ;D.

Swoja droga, jesli mozna zapytac, co Ty robisz zawodowo skoro tak duzo o tym wiesz? Bo hobbistycznie to chyba na wgryzanie sie w te occlusion cullingi by czasu nie starczylo!

No właśnie rzecz w tym, że mi czasu nie starcza na nic właśnie przez wgryzanie się w takie rzeczy. I przez ich wykorzystywanie. Co robię? Grę robię, o czym już kiedyś tam wspominałem na Valhalli. Yes, it takes time, move on. Czy zawodowo? Na pewno „na poważnie” i z perspektywami zawodowymi, ale póki co nic mi za tą harówkę nie wpada. Moja obecna sytuacja jest trochę dziwna, bo w zasadzie funkcjonuję, że tak powiem, poza systemem. W sumie działam trochę w stylu doliny krzemowej (tylko trudniej bo bez venture capital, haha) — rzuciłem studia, postawiłem wszystko na jedną kartę i „ciułam” grę, która wysadzi świat w powietrze ;). No dobra, trochę żartuję. Po prostu taką, na której bardzo dużo się nauczę, z której będę zadowolony (choć z moim przerostem ambicji to chyba niemożliwe) i na której zarobię na następne (i tak dalej, mam nadzieję). Co mi z tego wyjdzie? Szklanej kuli nie posiadam ;). To tak w skrócie ;). Wielu pewnie stwierdziłoby, że zwariowałem. I pewnie mieliby rację szczególnie, że pieniądze nie są priorytetem (co nie znaczy, że są poza spektrum celów) w tym co robię — a jak wiadomo to oznaka skrajnego szaleństwa.