Monio

Duuuude... To są czeskie napisy bo akcja gry dzieje się w czeskiej Pradze. [video=youtube;jh-iX2bxOjI] 25 minutowy gameplay. Cudowne. Dokładnie to czego oczekiwałem od następcy HR. :)

Bynajmniej.

Reynevan - W polsce może kierunki/kursy które uczą 3D na poziomie można policzyć na lapcach jednej ręki, i to przy pomyślnych wiatrach. Jak się idzie na "Grafikę komputerową" na zwykłych uczelniach to albo 3D nie znajdziesz tam wcale albo jest zupełnie rozwodnione pomiędzy naukę "wszystkiego po trochu". Masz zadania typu projekt logo w ilustratorze, 10 szkiców postaci, animowana typografia w afterze, fotografia, malowanie literek patykiem. Nawet Sztuka Nowych Mediów na PeJocie, czyli jeden z najlepszych kierunków graficznych w polsce działa na takich samych zasadach. Te uczelnie nie działają tak że uczą konkretnych umiejętności potrzebnych na rynku pracy tylko pozwalają umoczyć stopy w różnorodnych dziedzinach grafiki żebyś potem sam mógł sobie coś wybrać i potem się w tym szkolić. Nie powiedziałbym że to jest nietrafiona koncepcja. Rozwój ogólno-artystyczny jest potrzebny każdemu grafikowi bo koniec końców mamy robić ładne obrazki a nie znać wszystkie opcje każdego softu. Osoby które nie są zdecydowane na konkretną niszę powinny spróbować wielu różnych dziedzin i dla nich takie studia są kluczowe. Mam wielu znajomych po pejocie, mało który jest zadowolony z tej uczelni czuje w kościach że większość z tych osób właśnie gdzieś w trakcie studiów zdecydowało co chcą robić a czego na pewno nie chcą. Zupełnie nietrafioną koncepcją jest iść na taki kierunek wiedząc w co konkretnie się celuje. Jeszcze słabszym pomysłem jest powyższe w połączeniu z przekonaniem że "papier się przyda". Marnowanie czasu i palenie kasy. Przerywnik- Dopiero teraz przeczytałem całego twojego posta. ;) Nie zrozum mnie źle i nie bierz tego do siebie ale patrząc na ten model stwierdzam że jeszcze się nie nadajesz do gamedevu. Zrób ten licencjat "na odwal się", byleby zaliczyć w pierwszym terminie. Pracodawca będzie miał w pompie to czy dostałeś piątkę czy trójkę. Jest spora szansa że nawet cię nie zapytają o to gdzie i czy w ogóle studiowałeś. W tej branży liczy się tylko portfolio. Poproś rodziców/babcię/żonę/kochankę żeby w nagrodę za skończenie studiów dali ci kasę na dobrej jakości tutoriale. Zamknij się w piwnicy na pół roku i ćwicz. Klasyczne modelowanie, sculpting, retopologia, teksturowanie, import/export do Unity i Unreala. Nie zaszkodzi ci pół godziny dziennie dłubania szybkich szkiców żeby szkolić anatomie, pozy, konceptowanie. Wtedy dopiero zgłoś się na bezpłatny staż, do jakiejś sensownej firmy która ma kilka gier na koncie. Aha jeszcze kilka przydatnych linków: http://www.polycount.com/forum/ http://www.polycount.com/forum/ http://www.polycount.com/forum/ http://www.polycount.com/forum/ http://www.polycount.com/forum/

http://www.polycount.com/forum/showthread.php?t=99126 http://www.polycount.com/forum/showthread.php?t=74780 Popatrz jaki detal z złożoność bryły uzyskują ci ludzie i jak mało polygonów mają ich modele, w stosunku do twojego. Lowpoly które zrobiłeś jest radykalnie za gęste jak na realtime. Musisz cofnąć się jeszcze do retopo. Niepotrzebnie modelujesz rzeczy które spokojnie można wypalić na normalmapie. Ustal sobie jakiś racjonalny polycount i się go trzymaj. Pamiętaj że liczymy trójkąty (tak na prawdę vertexy ale do tego kiedyś tam dojdziesz), czyli na quada składają się 2 trisy. Obecnie główne postaci w grach AAA mają 40 do 100 tysięcy trójkątów, w to wliczają się ciuchy, włosy, przyczepione na stałe akcesoria. Twój sculpt nie ma tyle detalu żeby potrzebował aż takiej ilości trisów więc myślę że możesz celować w rzadszą siatkę. Myślę że 30 tysięcy trisów starczy ci w zupełności. Pamiętaj że możesz korzystać z trójkątów. Jeśli to realtime i nie zamierzasz zagęszczać siatki przez Subdivision Surface to nie ma przeciwwskazań żeby twój model składał się w dużej części z trójkątów. W silnikach gier i tak siatki są triangulowane bo akceleratory dużo wydajniej przeliczają trójkąty niż quady.

Ja natomiast uwielbiam taką reżyserie w grach, o ile scenki są dobrze wkomponowane w gameplay. Świetnie to wygląda, jak dla mnie jedna z najfajniejszych gier z tegorocznych targów. :)

[video=youtube;D-epev7cT30] Zwiastun Deus Ex: Mankind Divided z tegorocznej konferencji E3 oraz prezentacja silnika Dawn Engine.

Pozamiatane. :D Ciekawe po jakim czasie wyjdzie na inne platformy. Obstawiam rok.

Taka ciekawostka. Animacja i raytraceingowy renderer napisany w jako shader OSL. Tak więc nie poddawaj się Aniu, twój problem na pewno da się rozwiązać. :)

Linkujce trailery również w oryginalnej wersji. Wiele osób, w tym ja, dostają wysypki jak słyszą dubbing. Bardzo fajnie ta animka się zapowiada. :)

Generated coordinate. On uwzględnia deformacje mesha (lub nie uwzględnia, zależy jak to rozumieć. ;) ). (Zamiast separacji kanałów możesz tam Mapping node wstawić żeby dodatkowo tym obracać jeśli potrzebujesz.)

Nezumi- Nie zrozumieliśmy się. Chodziło mi o to że będą implementować PBR na podstawie dobrze przetestowanych i udokumentowanych rozwiązań od EPIC/Disney a nie sami będą na nowo odkrywać koło czyli testować wszystkie możliwe algorytmy do liczenia diffuse, speculara itd. Biorąc pod uwagę ilość możliwych elementów składowych takich shaderów można je zrobić na tysiąc sposobów uzyskując bardzo duże różnice w wydajności i przede wszystkim odbiorze wizualnym. Psy-fi ma łeb na karku więc wie że nie warto się pakować w projektowanie czegoś co już zostało dobrze zaprojektowane przez mądrzejszych od niego gości. Pokora jest cnotą. :) rice- Jak się przełączysz na sculpt (multires) w branchu Gooseberry to z palcem w nosie da się rzeźbić na 40 milionach poly (nawet move nic nie zamula, jest bez porównania lepiej niż w mudboxie i zbrushu). W przypadku dyntopo to problemem może być nie tyle wydajność wyświetlania co sam kod który przelicza trisy, on jest napisany pod CPU. Dałoby się go przepisać na GPU ale to kupa roboty (w sumie napisanie wszystkiego od zera) a mają przed sobą bardziej priorytetowe rzeczy związane z wydajnością.

https://docs.google.com/file/d/0B5CLsFk4D9wHNzdJQVI1RV9oUXc/edit Proposal przebudowania viewportu od Psy-fi. Dyskusja tutaj: http://lists.blender.org/pipermail/bf-viewport/2015-June/thread.html Wyglada na dopakowaną idee shaderfx z mocnym naciskiem na workflow i customizacje. PBR bazowany na researchu od EPICa czyli aproksymacja i optymalizacja a nie akademickie pierniczenie. Dla mnie bomba. Ja chce to wszystko ASAP! ;)

http://www.shapeways.com/tutorials/exporting_to_vrml_and_x3d_for_color_printing AUV to zawsze najgorsze wyjście czego byś nie robił, on każdą ściankę lowpoly rozkłada osobno tworzący tyle seamów ile masz krawędzi na modelu. Tak na logikę, im więcej seamów dasz eksporterowi tym bardziej będzie to skomplikowana operacja. Jesteś narażony na fuckupy przez interpolowanie sąsiednich pixeli. Lepiej się ubezpieczyć i mieć taką UV która nie wymaga od eksportera samplowania pixeli porozwalanych po całej teksturze = najmniej seamów jak się da. W realtime czy offline renderingu to działa podobnie, wszystko rozchodzi się o interpolacje/ samplowanie sąsiednich pixeli. Rozplackuj model na dużo polygrup -> uvmaster -> bejk z polypainta.

Neeee. Na pewno nie wrzucałem nic o naszym firmowym toolu. Pewnie ci chodziło i moje próby unfuckowania bakeu w blenderze (z których raczej nici bo developerzy olali ten feature). Co do obsługi sprajtów w silniku to masz świętą racje. Bardzo uczulam na taką niby oczywistą rzecz jak skala. Inicjalizowanie jej na podstawie wielkości obrazka to śmierć... Ja łudziłem się że uda mi się przekonać nasz team 2d (całe 2 osoby) do tego żeby dostarczali grafiki w odpowiedniej wielkości, ekranowej rozdziałce gry pod retinę. Jednak po paru miesiącach widzę że to jest nieosiągalne bez ciągłego patrzenia im przez ramie. Ja będę zabiegał żeby nasz tool dostał sprytne opcje reskalowania sprajtów (w procentach oczywiście). Po to żeby to grafik techniczny (czyli ja) mógł dokładnie ustalić w jakiej jakości/rozdziałce będą w grze i żeby nasz edytor bezboleśnie czytał ich skalę z konfiga atlasu. Techniczni powinien mieć kontrolę gdzie zaoszczędzić na RAMie i gdzie poprawić jakość grafiki, bez proszenia ludzi od artu o ponowy eksport czegokolwiek. Polecam. Nie wiem jak bardzo w twoim przypadku musisz optymalizować swoje gry. W naszym wypadku to jest konieczne, gry na iOS przekraczające limit 100 mega mają z miejsca o 20% mniejsze dochody. Teraz inwestujemy głównie w dobre zarządzanie zasobami i optymalizacje wszystkiego. Siłujemy się ze wszystkimi możliwymi rodzajami kompresji realtime, kompresji w paczce, musimy rozbijać atlasy pod kontent (żeby odpinać z RAMu) i te różne kompresje. Hardcore. :)

Kengi dobrze mówi. Kompozycja kadru kuleje. Jest masa przedmiotów po lewej stronie które odwracają uwage od dziewczyny i samochodu, wprowadzają chaos a nie dodają nic szczególnego do odbioru pracy. Chce patrzeć na samochód i laskę a nie jakiś rozmyty kompresor i beczkę a prawdę powiedziawszy to są pierwsze rzeczy które na dłużej zatrzymują wzrok. Brakuje w tej scenie jakiejś volumetryki która pomogłaby rozbić plany i nadać głębi. Nawet proste triki z zdepth by pomogły. Modele i texy superowe.

Ja w sumie ledwo liznąłem OSLa i skupiam się na proceduralnych teksturach a nie shadingu więc wiele ci nie pomogę. Niżej masz fajną prezentacje o OSLu. Opisuje elementarne podstawy. http://blog.selfshadow.com/publications/s2012-shading-course/martinez/s2012_pbs_osl_slides.pdf Jeśli będziesz chciała dłubać coś na własną rękę to powinnaś zapoznać się ze specyfikacją OSLa która jest na githubie projektu. https://github.com/imageworks/OpenShadingLanguage/blob/master/src/doc/osl-languagespec.pdf Nie ma w OSLu czegoś takiego jak shader napisany "od zera". ;) OSL nie funkcjonuje w ten sposób, on przekazuje rendererowi instrukcje (Closure) jak ma zachowywać się światło. Powiedzmy że działa jak taki mixshader który łączy w sobie wiele wbudowanych niskopoziomowych shaderów (diffuse) i ich poszczególnych parametrów (color, roughness). Tak w dużym uproszczeniu. OSL nie tworzy wynikowego koloru pocieniowanego pixela jak RSL. Sposób w jaki Closure jest interpretowany jest zależny od implementacji renderera więc komponent 'diffuse' czy "emmision" może być kalkulowany innymi metodami w zależności od silnika. To jest główna rzecz która odróżnia ten język i jego największa zaleta. Dzięki takiemu podejściu ciężar pisania zaawansowanych algorytmów renderingu jest przeniesiony na twórców renderera a nie osobę która pisze shader. Jednak ta prostota działa kosztem elastyczności. Problem jest taki że to język z natury przystosowany do rendererów PBR więc robienie w nim shaderów NPR wymaga bardzo mocnego kombinowania. Nie da się od tak nałożyć ColorRampy na gotowy shading i wymieszać go z teksturą. OSL nie obsługuje też staromodnych light loopów więc jeśli chcesz uwzględniać światło trzeba by było je sobie napisać własnoręcznie... Wyższa szkoła jazdy. ;) Na BlenderArtist jest trochę osób które bawią się OSLem. Opisz tam dokładnie swój problem to może ci coś doradzą. Tylko zaznacz że chodzi ci o teksturowanie względem oświetlenia wyginaniem Normali.

Który nadal nie ma nic wspólnego ze światłem. ;) Gość po prostu przekręca ręcznie normale obiektu a nie oświetlenie. Nie da się zrobić tego co chce Ania na wbudowanych nodach Cyclesa. Trzeba to napisać w OSLu fejkując shading.

Znać blendera a potrafić pisać shadery w OSLu to raczej 2 inne rzeczy. To nie zadziała w przypadku Ani. LayerWeight to odchylenie względem kamery a nie cieniowanie ze świateł. Wbudowane nody w ogóle tutaj nie zadziałają . Nie ma w cyclesie noda który może wypuścić shading materiału jako output dla innego noda. Cycles jest mocno oparty o OSLa. Shader przekazuje do renderera Closure czyli definicje interakcji światła z powierzchnią. Nie kolory pixeli jak to ma miejsce np w RSLu. Większość pathtracerów teraz tak działa.

Dziwne, to brzmi jak bug. Zgłosisz? Tak na teraz spróbuj dodać po tym obrazku z alfą nody z matmą żeby podkręcić wartości. Na dole linkuje pliczek z nodem interpolacji linowej. Przydaje się do wielu różnych rzeczy. http://www.pasteall.org/blend/36458

Reanimator - Gdzieś w środku filmiku gość wykonywał transformy podając przemieszczenie czy rotacje obiektów na danych osiach. Siatki nie zedytuje się bez możliwości zaznaczana vertów ale blocking modelu dałoby się wykonać. Jest jeszcze eyetracking, osoby z paraliżem wszystkich kończyn mogłyby zaznaczać verty patrząc na nie i mówiąc "select". Zależy od rodzaju niepełnosprawności, przede wszystkim determinacji. Mookie- Niby dlaczego? Niektórzy niepełnosprawni mają taką tytaniczną determinacje że robią rzeczy które nie śnią się osobom zdrowym. ;) Mamy w polsce jednego ziomka w gamedevie który modeluje stopami lepiej niż 3/4 osób na tym forum. :D Edit: Pomieszałem coś. Mamy programistę który urodził się bez rąk, Maksymilian Strzelecki. Modeler był z jakiegoś dużego europejskiego studia.

Ten addon ma jedną zajebistą zaletę. Umożliwia korzystanie z blendera niepełnosprawnym.

Zastanawiało mnie czy nie mogłeś wykorzystać do tego texturepackera i tylko trochę to wspomóc akcjami shopa żeby mieć obsługę warstw/grup. Bardzo wydajny algorytm pakowania sprajtów, czyta pliki PSD (spłaszczone niestety, chyba że coś się zmieniło) i można napisać do niego własny eksporter tak jak lubisz. Korzystaliśmy w firmie do czasu aż nie zrobiliśmy własnego ubertoola do zarządzania wszystkimi zasobami grafiki projektu. Jednak widzę że twój tool służy raczej do czegoś innego niż kompozycja/dekompozycja atlasu.

Ładne to, od tej artowej strony. Grafika nie urywa, miejscami jest bardzo słabo, niektóre modele postaci jak z poprzedniej generacji. Przynajmniej nie będzie narzekania że w konsolowych wersjach przycięli grafę. ;)

Do czego właściwie służy ten tool? Dekompozycja atlasu?

Podbijam. :D Jeszcze 80 eurosów!