SYmek

Czyli te najbardziej znane FPS'y nie mają takiego trybu?

witam, przepraszam za głupie pytanie, ale moje doświadczenia z grami są bliskie zeru, a problem mam następujący: Czy któraś z gier typu Quake, Unreal, Half-Life co tam jeszcze jest, umożliwia grę zespołową, ale przeciw komputerowi wewnątrz standardowej fabuły? Nie chodzi mi o boty i turnieje w sieci, tylko grę tak, jak toczy się w single player, ale w zespole? Czy jeśli to możliwe w jakiejś z gier, czy ktoś wie, jak technicznie się to rozwiązuje, to znaczy który komputer rządzi - symuluje fabułę gry? Czy serwer daje sobie radę z przesyłaniem wszystkich informacji o fabule do klientów etc... Jak mówiłem mam marne pojęcie o grach komputerowych a kilka uwag natury ogólnej jest mi teraz potrzebne. dzięki, pozdr., skk.

Na takie pytania nie ma odpowiedzi. To są złożone efekty, które robi się warstwami, rozwiązując problem po problemie. Powoli. Rozbij ujęcie na elementy, pracuj na najprostszych setapach, kształtach. Chciałbyś przepisu na wizualizacje powstawania ziemi? Może taką funkcje w GUI? ;) Tutaj był kiedyś taki wątek: http://www.max3d.pl/forum/showthread.php?p=562993#post562993 Nie wiem, co z tego wyszło, ale o takie podejście chodzi. powodzenia! skk.

Leru, napisałem to już w oryginalnym wątku z czaszka: masz oko, wszystko fajnie wygląda, sporo pracy włożonej w detal, ale cały czas pewne rzeczy, fundamentalne dla takich ujęć, kuleją. Ani czaszka, ani błoto nie maja poprawnej fizyki. Kawałki czaszki nie odbijają się realistycznie, przez co fajny skądinąd efekt traci na jakości. Ten sam mankament dotyczy kawałków betonu w scenie z błotem, chociaż one akurat nie maja wielkiego znaczenia dla sceny, niech będzie, ze wszystko jedno. Błoto ma również za małą rozdzielczość, no ale to rozumiem, problem z policzeniem większej ilości cząsteczek, trudna sprawa ;). pozdr., skk.

No widze, ale nie wszyscy sa ta k bystrzy jak Ty, czasem temat trzeba kawa na lawe ;)

To jest news z wielu wzgledow, ktore dla Ciebie moga nie byc oczywiste, ale to nie powod zeby sie wyzywac, Panowie! News jest ciekawy bo: 1) Posrodnio mowi o tym, co dzieje sie z branza w epoce "globalnej wioski" i hinduskich/chinskich rynkow pracy etc. 2) Mowi cos o tym, jaka pozycje Fusion udalo sie zdobyc u powaznych facetow z powaznymi pieniedzmi (choc nie u mnie ;) ) 3) Mowi cos o tym, jaka bedzie przyszlosc Fusion, bo dla tak powaznego klienta pisze sie cale fragmenty programu! 4) Mowi cos o problemach najnowszego dziecka Autodesk, Toxik, ktore ma problemy z wystartowaniem na rynku, dla ktorego go stworzono. 4) Zagladnij na jakas zachodnia strone branzowa i zobacz, ile sie o tym mowi zamiast robic tutaj raban. Na koniec dodam, ze daleko mi do fana Fusion, powiedzialbym wrecz przeciwnie. Wystarczy natomiast cos wiedziec o tej branzy, zeby rozumiec znaczenie tego newsa. pozdr., skk.

Miejmy nadzieję, że dopływ gotówki pomoże Fusion. Są ponoć takie firmy, które specjalizują się w poprawianiu kodu cudzych pogramów ;)

O! i się przypadkiem znalazło na liście dyskusyjnej wiec wrzuce, bo dodawanie MB w kompozycji do 3d za pomocą optical flow to jakby jechać do Gdańska, żeby złapać pociąg do Zakopanego...: http://www.alamaison.fr/3d/lm_2DMV/lm_2DMV_ref.htm możne się przyda, pozdro! skk. PS Nie ma rożny bez kolców, wiec dorzucę, ze LaMaison, oparte głownie o XSI, ponoć mocno inwestuje w Mantrę ;)

Nie pamiętam jak to jest z RealSmartem, ale na przykład Furnace w Shaku akceptuje velocity vectors fields z zewnątrz, jako alternatywa dla obliczanych w locie (albo jako cache, żeby ich w kółko nie przeliczać). A te można sobie wypluć z rendera, minimalizując brak precyzji optical flow...

program do wszystkiego == program do niczego ;)

Dolaczam sie do prosby! Moze cos, co wyglada chocby odrobine inaczej niz dema na stronie producenta...? Dlaczego symulacje fumefx wszystkie wygladaja jakby je robil jeden czlowiek?

tutaj chodzilo, zdaje sie, o to:

Komunista?

No to się zdecydujecie... ;) fotometrycznie czy poprawnie fizycznie? bo jak zauważył peteRlo to nie to samo. Z tego co wiem, fotony niewiele mają wspólnego z fizyką światła, więc co to właściwie znaczy "poprawnie oświetlać scenę"? Że ładnie wygląda, czy że inwestor oczekuje od Was, że w pokoju będzie tyle światła, ile tam naprawdę ma być według projektu, bo go ktoś pociągnie do odpowiedzialności za mistyfikacje ;)?

Dziadku, Dziadku, przez szacunek nie odpowiem na zaczepki, obydwaj wiemy co i jak, szkoda Naszego trudu. Natomiast co do kasy, to owszem, XSI ktoś pisze i chce za to pieniądze, Maxa od lat nikt nie pisze i też chce za to pieniądze. Porównaj listę nowości ostatnich wersji wszystkich czołowych graczy na rynku. Smutek tropików. Stąd Twoja groteska? Salut! skk.

To były tylko testy, ale jeśli chodzi o szczegóły, to zrobiłem więcej niż mapy, to znaczy napisałem banalny parser plików IES, który przerabiał dane fotometryczne na mapę diffuse dla światła. A ponieważ wszytko dzieje się wewnątrz HDA, dzieje się automatycznie. Mapa jest generowana w Halo i automatycznie aplikowana światłu. Więc w pewnym sense działa dokładnie jak IES. Tylko ja po prostu nie wiem, jak IES jest zaimplementowane wewnątrz Maxa, być może chodzi tam o jakieś niesłychane możliwości, na przykład ilość energii emitowanej ze światła zgadza się z danymi producenta i być może jest to wymóg wizualizacji, który nakłada na Was inwestor... Ten eksperyment (w którym tylko parser wymagał Pythona, reszta to standardowe operatory), modeluje tylko kształt światła + cień + volume light, jeśli jest włączony. Nic się tam wielkiego nie dzieje. Zapewne nie działa także z fotonami etc. Reasumując, wydaje mi się to tak banalna funkcja, że trudno mi uwierzyć, że podejmuje się na jej podstawie jakieś decyzje. Pewnie import plików cadowskich ,albo inne wymyślne rzeczy mogą mieć większe znaczenie.

OJ, chyba sie domyślasz... trzymać się z dala od korporacji. IES to ta specyfikacja oświetlenia? Sorry, jeśli coś mylę, ale zakładając ze chodzi Ci i ten format fotometryczny: To naprawdę takie ważne? Pytam, bo sie nie znam na tym. Czy jesteś zobowiązany używać w Viz lamp według tej specyfikacji, czy po prostu wygodnie jest modelować kształt światła tymi plikami. Pytam, ponieważ zainspirowany tym narzędziem, zrobiłem kiedyś szybkie testy, i taka zabawkę, przy pomocy diffuse maps na lampie, można w każdym programie zrobić w godzinę. Najtrudniejsze i najdurniejsze jednocześnie jest to, ze ten format jest jakimś koszmarkiem sprzed 20 lat (wszystko ok, tylko dziś pewnie by go zaprojektowali za pomocą XMLa a nie szeregu linijek ASCII, z których polowa jest opcjonalna + inaczej interpretowana w dwóch istniejących standardach, co czyni napisane parsera dla banalnego skądinąd formatu upierdliwym). Zamiana tego formatu na jakiś generator map w kompozytorze najbardziej mnie wkurzyła, ale zaaplikowanie samego kształtu światła, to już pestka. Wydaje mi sie, ze wystarczy rzucić ten temat na Xsibase.com, a po miesiącu masz swoje narzędzie. Chyba, ze nie rozumiem jakieś wspaniałości w tym narzędziu, sorry naprawdę nie znam się na VIZ. pozdr., skk. PS Tak na marginesie, spędziłem poranek na odtworzeniu Spline UV z nowego Maxa. Godzinka bez jednej linijki kodu. Myślicie, ze mógłbym to zacząć sprzedawać? ;)

Ceny, jak ceny. Bardziej mnie dziwi, że lata lecą, a Wy nie potraficie z tego wyciągnąć żadnych wniosków.

To nie tak panowie. Technika fajna i pewnie, ze sie wygodnie na tym pracuje, ale to nie jest "pelny" render, pelny raytracing - owszem, ale wielu mozliwosci taki algorytm nie bierze pod uwage, wszystko robi po najmniejszej linii oporu, filtry, interpolacje, oszczedza na czym sie da. Zebysmy mieli jasnosc, ile tak naprawde wielkiej technologii za tym stoi, warto spojrzec na ten aplet (kod w processing), ktory renderuje ray tracing i fotony w czasie rzeczywistym na... Javie, fully interactive. I wiecie ile to zajelo? 377 linijki kodu... wielkie mi halo. Taka technologia jest sexy, ale nie dajmy sie zwariowac. To tak dla kontekstu, pozdr., skk.

Ach ten mój brak precyzji... 1. Zdepth z AA oczywiście sprawdził mi się również wielokrotnie, ale warto wiedzieć, że jego użycie nie jest oczywiste i nie powinno być automatyczne. Sformułowanie "Prawidłowa mapa głębi" jest samo w sobie dziwactwem, bo oczywiście prawidłowe jest to, co działa. Chciałem po prostu zaznaczyć, że mapa niefiltrowana to jedyne, co renderer wie w tym temacie a filtrowanie nie czyni jej precyzyjniejszą, tylko wręcz przeciwnie (co z kolei może być w pewnych przypadkach pomocne). 2. Nie jestem wrogiem DOF'a w postprodukcji i sam fakuje co się tylko da. Położyłem nacisk na problemy, które się z tym wiążą, żeby było jasne, że ta metoda wnosi nieusuwalne komplikacje. Ich obejście nie raz oznaczać będzie renderowanie DOF'a w rendererze. 3. No i na koniec, jako ciekawostkę, zaznaczę, że REYESy liczą pewne ujęcia z DOF i MB szybciej niż te same ujęcia bez tych efektów. Wszędzie tam, gdzie kod shadera jest najkosztowniejszą częścią pracy, DOF i MB przyśpiesza rendering. 4. Ciekawostka numer dwa: niektóre REYESy (to znaczy nie wiem które, bo funkcja ta nie jest, jak mi się zdaje, częścią specyfikacji RSL) potrafią liczyć MB wewnątrz shadera, nawet bez włączania MB. Przydaje się to na przykład przy MB wolumetryki, którą oblicza się za pomocą kosztownego ray marching, dla którego włączenie MB zabija rendering. Po prostu shader ma dostęp do pozycji punktu w czasie względnym do otwarcia migawki. To znaczy na przykład w VEX (Mantra), funkcja getblurP(.5), zwraca pozycje punktu w połowie otwarcia migawki, dzięki czemu ławo można kolor tegu punktu interpolować do czasu. To tak na marginesie, sorry za offtop. pozdr., skk.

Wydaje mi się, że Oni zmienili po prostu tzw. "business model". Poważnie. ;). To znaczy, przestali numerować wersje programów, zaczęli podawać rok wydania. Mogło się wydawać, że to kwestia kosmetyczna, a tym czasem nie, to kwestia zasadnicza. Przecież zgodnie z annual upgrade plan, i tak raz do roku byli zobowiązani do nowego wydania, co niestety zmusza do ciężkiej pracy nad programem. Tymczasem rok wydania do niczego nie zobowiązuje. I słusznie. Przecież najpopularniejszy program na ziemi, musi być też najlepszym. A skoro jest najlepszy, nie ma co w nim poprawiać. Trzeba na nim zarabiać. Business model to podstawa. Każdy to wie. pozdr., skk.

Bardzo słuszna uwaga, zupełnie zapomniałem o Gelato, bo się raczej nie przyjął. A tymczasem Gelato, to prawie Renderman i to darmowy. Tyle, że renderowaniu na farmie można zapomnieć. Bardzo dobra jakość obrazu w animacji, bardzo elastyczny dla kogoś, kto się na tym zna. Dopóki wystarczą nam rzeczy, które przychodzą z Gelato (shadery i plugin) wszystko gra. Gorzej, jeśli coś nie działa, jakbyśmy tego chcieli... Gelato do opisu sceny używa Pythona, jakby co ;) pozdr., skk.

Walnąłeś właśnie głową w problem, który jest bardzo charakterystyczny dla post DOF'a. Zależnie od ujęcia i programów, czasem da się to obejść a czasem nie. W każdym razie, jak ktoś Ci mówi, że DOF w kompozycji może w całości zastąpić DOF'a z rendera, to nie wie, co mówi. W stillach to możliwe, ale w animacji już nie. A niby dlaczego w enginach do animacji tyle pracy włożono w szybkiego DOF'a? Właśnie dlatego, że w niektórych ujęciach (powiedziałbym w większości) nie da się fakować głębi ostrości w postproducji. W szczególności fakowanie nie działa w ujęciach takich, jak Twoje, czyli wiele nachodzących na siebie obiektów (spróbuj zrobić jeszcze animacje kamery w lewo/prawy i zobacz, co się dzieje z obiektami, kiedy zaczynają na siebie nachodzić!) Tak trochę zwlekam z konkretami, bo coś czuję, że ktoś zaraz wyskoczy ze świetnym plugiem do AFX, który załatwi Ci problem z *tym ujęciem, ale nie poradzi nic na tuzin innych ujęć. Ja w każdym razie nie widziałem takiego narzędzia, a pewnie bym o nim słyszał, bo byłby to święty Graal kompozycji. Do rzeczy: 1. Po pierwsze twoja mapa głębi jest przefiltrowana, co jest dziwne. Prawidłowa mapa głębi nie ma prawa być potraktowana AA. ZDepth wygląda jak surowy obrazek bez AA, bo kolor piksela reprezentuje jego odległość od kamery, a piksel nie może być jednocześnie w dwóch miejscach... ;). Wydaje mi się, że jest to podstawowy powód Twoich problemów. Przefiltrowana krawędź boxa na mapie źle pokazuje odległość krawędzi dla obrazka rgb. Technicznie rzecz biorąc ZDepth map powinien być przefiltrowany filtrem "minmax max", czyli że każdy piksel, którego choćby jedna próbka należała do boxa, powinien być zaliczony do boxa. 2. Czy Twoja mapa jest przynajmniej w 16bitach? Powinna.(Powinna być w 32, ale to inna sprawa). 3. Pobaw się filtrami delete erode, median, blur (Convolve), czyli krótko mówiąc popracuj nad krawędziami mapy głębi. Przygotuj się jednak na to, że kiedy włączysz motion blur, ten problem pogłębi się. Zaprawieni w boju kompozytorzy animują roto maski, maluję pędzlem klatka po klatce problematyczne miejsca. No wiesz, takie tam... 4) Renderuj obiekty oddzielnie i aplikuj DOF na każdy z nich osobno, dopóki obiekty nie zmieniają dramatycznie pozycji względem kamery, pozbędziesz się w ten sposób części problemu. 5). Jeśli powyższe metody zawiodą (plus tuzin pluginów, które zaproponują koledzy), renderuj z DOF'em, jak to robią faceci, którzy się na tym znają ;) Decyzje o fakowaniu musisz po prostu podejmować dla konkretnego ujęcia... da się, czy nie da się...? pozdr., skk.

Tu chyba nie o ignorancje chodzi, tylko o oczekiwania. Nie zauważyłem, żeby Klicek dal Ci powód do takiej opinii. Na pewno sa rzeczy, ktorych nie wie ;), ale sprawy na tym watku nawet o to nie zahaczyly. Rozmowa (o ile mozna to nazwac rozmowa), dotyczyla tego, czy takie nody to juz powod do radosci, czy nie. I mozna miec w tej sprawie rozne opinie. Moim zdaniem takie bajery maja z nodami tyle wspolnego, co schematic view w Combustion. Jakby mi ktos powiedziel, ze Combustion to program na nodach, byc moze wtedy byloby miejsce na slowo "ingorancja".

Brzmiało bardziej jak Indie... ;) Kawałek z presetami na materiałach robi na mnie największe wrażenie!