olaf

ok nie jestem fanem wielkim nvidii, lubie ich ceo za charyzmę, ale na kazdym CES gniota amd w ilosci nowosci. Niemniej czekam co ciekawego wykoncypują jak już włożyli swoje karty do maka pro, to fajnie by one coś tam mogly poza obługą monitorów (jak na razie widzialem video z niezlym boostem pakietu CC na nvidiach).

Owacje na stojąco dla kazdego kto uznał Maka Pro z kartami AMD za maszynę do video ;)

tak dobry program ze trzeba go bedzie retuszowac

ktos tam wspominal ostatnio, ze mobile są tak strasznie z tyłu: - ostatnia minuta porównanie chipu z xbox 360 i ps3 jedyne czego brakuje komórkom, poza tym chipem, to mozliwoscie odpalania nienatywnych rozdzielczości, bo 2500x2000, czy hd zabije kazda karte. unreal engine na tegra k1: GI: to chyba leci w 720p

nie rozumiem skąd ten sarkazm. Ile lat chcesz czekać na tego typu silniki do symulacji obiektow?

ok wrzucam intro - to nie jest finalna wersja - finał pewnie zobaczycie w samej grze - konczymy etap produkcji ale balansowanie gameplayu jeszcze troche nam zabierze + jakieś socialowe pierdy typu facebook. http://blue-box.com.pl/klienci/samples/runGame/introRabbit.html Kilka kolejnych uwag z produkcji: 1. trzeba niestety trzymać się indeksowanych kolorów. Pamięć karty to nie przelewki. Na słabszych maszynkach wymiana zawartości pamięci jest zauważalna. 2. w związku z powyzszym cacheowanie w locie obiektow to fikcja - musiałem się nieźle namęczyć, by pliki były małe do webu i oszczędne w vramie do mobili (z lenistwa robię jedną kompilacje na obie platformy, a framework tym zarządza) 2 i pół. Indeks wyklucza 8bitową alfę. 3. Na szczęście wszystko wygląda całkiem fajnie, a w animacji naprawdę poza klatkami kluczowymi to ilość kolorów pow. 16 często jest kompletnie zbyteczna ;) 4. nie mam pojęcia jak jest zrobione odświeżanie w panelach smartfonów ale zgaduje, ze nie całej matrycy, bo bateria by nie dała rady. Jakkolwiek by to nie było, płynne zmiany framerate są naprawde fajne, nie widać interpolacji klatek np. przy 45fps, co pozwala na dobijanie fps do górnej granicy urządzenia - czyli na dobrym fonie user zobaczy 60fps, na słabym 30fps + obiekty dalszego tła 15fps. Przy dobrej kontroli roznice nie są wielke, a na pewno nie przeszkadzają osobie, która nie ma porównania z lepszym fonem. 5. flash ładuje do karty tylko obiekty widoczne (co z jednej strony zabija animacje jak się coś pojawia i trzeba wyładować poprzedni obiekt, oczyścić vram i władować kolejny - nie wiem czy tu nawala adobe czy mozliwosci karty) ale plusem jest, ze mozna trzymać rozne sprajty i pokazywać na lepszym fonie 64kolorowe, na słabszym np. 16kolorowe. 6. Oczywiście małe karty umierają przy sprajtach pow. 512px. Przy pracy nad appką na tablet i smartfon jednocześnie ma to znaczenie, bo trzeba nawet tło z 1280px (w moim przypadku) pokroić na plasterki. 7. Podmiana sprajtów na 2x mniejsze w czasie animacji i powrotna zamiana jak wszystko np. zatrzymuje się też ułatwia płynne animowanie. Dzięki temu mamy 30klatek animacji zamiast jednego skalowanego sprajta + kilku sparków. Plus jeżeli robi się autorskie animacje, jeden chU. jeżeli uzywa się np. Starlinga czy innych automatów. Kilka z tych uwag wynia z faktu, ze robię jedna kompilację na mobile/tablety/przeglądarki oraz pracuję z grafiką 2D ale naprawdę robienie rzeczy trzy razy to dobre jak ma się tyle ludzi co Rovio. Jestem względnie zadowolony, bo przerabiam jednocześnie starszą grę - puzzle na andka i udało się wygiągnąć wydajność znacznie lepszą niż nowej aplikacji promującej Frozen - też puzli mającą mniejsza tablicą kafli. Zabawne, bo wszystkie obliczenia są znacznie wydajniejsze jeżeli trzymamy się liczb całkowitych - nie wiem czy te army nie mają kooprocesora, czy jest on tak niewydajny. Chyba też cache CPU w desktopach daje kopa nieporównywalnego do obecnej generacji arm. Zrobiłem fatalną pętlę, która w puzzlach wykonwała się (po wydawało mi się optymalizacji) do miliona razy po każdym kliknięciu puzzli. Na x86 nie ma nawet ułamka spowolnienia, na arm wszystko siadło. Na szczęście udało się zmniejszyć iteracje (chyba dobrze uzylem tego slowa) do 400-20tys razy. Spora zmiana ale puzzle mają wbudowany silnik grawitacji, stąd takie nadprogramowe obliczenia. Niemniej nawet na gównofonach spada wtedy do max 20fps (z 30). Za to mnie nie bashujcie - ta produkcja jeszcze nie korzystała z mojego nowego 8bitowego silnika kolizji.

dzięki man, na pewno się przyda jak bede ruszał do inwestorów z produktem. Oglądałem za namową kumpla możliwości OpenCV (open sourcowa biblioteka do trakowania) ale jednak nie współgra to z moją ideą. Na chwilę obecną mam w xMind rozpisane sporo rzeczy, głownie założeń edytora, bo styczeń jest miesiącem premier gier mobilnych, ale postanowienie noworoczne mam, by wypuścić dwa programy uzytkowe bazujące na tym silniku. Ten drugi zapowiada się masywnie i pewnie trafi na kickstarter ale muszę zdobyć know-how podczas pracy nad pierwszym ;)

fajne. mam nadzieje ze za kilka lat takie animacje nie beda pomijac mielenia. to polskie studio?

swietne !

zrozumialem. to byl sarkazm.

@zadybski: brawo za kreatywny spam

nom Nezumi ma racje, wtedy byla taka era pc jak teraz era windows surface :D

długo pisałeś ten emulator mateusz?

[ATTACH=CONFIG]92737[/ATTACH] . .

czuje wtopione zlecenie za ok 5dni :)

WTF, a gdzie dystrybucja na vhs? Kung Fuhrer bedzie ikoną pop kultury :D Mam nadzieje ze da sie to obejrzeć choć do połowy.

rozlicz się w naturze/barterze jak jest sposobność, oni nie będą mieli problemu i czyste sumienie, Ty na pewno relatywnie najwiecej wyciągniesz w ten sposób.

e-papier przyjmie wszyściej.

nic tak nie katatlizuje procesu myslenia jak rodzinne spotkania.

w spoczynku cpu i karty jak najbardziej realne.

a nie wolisz lenovo? w tej konfiguracji bedzie na pewno tanszy. Od siebie moge polecic - o ile 17 nie jest koniecznoscią y510p, mnie z 8gb ramu kosztowal 3500

Faktycznie otrzymanie w miare czystego modelu ruchów, dodatkowo na tyle czułego by dało się skalować ekspresję będzie trudne więc podczas pracy nad innymi rzeczami myślałem o rozwiązaniu. Wstępnie wymyśliłem coś takiego - będę to jeszcze dopracowywał - jak mapy elastyczności. Coś jak specular map w modelu 3D. Poniżej wstępnie wymalowana mapa dla twarzy ruszającej się w jednej osi (zielone) i w obu osiach (czerwone). W miarę produkcji będę dopracowywał detale tej mapy (8bitow dla kazdej wartosci). Dzięki temu skrypt będzie wiedział gdzie może oczekiwać punktu w następnej klatce, co pozwoli mu interpolować rozmazane/zgubione punkty. Dzieki temu będę musiał trackować dokładnie jedynie np. dwa punkty na całej twarzy, reszta nawet błędnie odczytana nadal pozostanie w granicy wiarygodności i zaoszczędzi mi kilkudziesięciu suwaków. To jest model, ktory bedzie dojrzewał, to czy jest juz w pełni gotowy pokaze próbny skrypt, ktory wygeneruje przypadkowy setup twarzy bez trackowania - cała twarz powinna wygladac nadal wiarygodnie. Podobnie w sytuacji, gdy skrypt zgubi np. 80% punktów ale wytrakuje poprawnie oczy i 20% punktów, powinno się udać wiaygodne odtworzenie mimiki uchwyconej kamerą. Oczywiscie nie bede tego rozpisywał na wzorce tylko - jako grafik - na dane wizualne. Sorry ze pokazuje to na takiej małpiej mordzie, ale tylko taką twarzą dysponuję ;)

nie szukałem, bo jakby było, to bym wiedział, bo wszystkie animacje dookoła wyglądałyby inaczej ;) ale faktycznie AE ma bardzo fajne narzędzie: tylko problem w tym, że zawsze czegoś brakuje w takim rozwiązaniu. Mi potrzebne są krzywe ekspresji, bo szukam raczej czegoś takiego: dodatkowo w otwartym formacie pozwalającym generować animację w grze z danych zamiast z klatek w czasie rzeczywistym, plus łączyć kolejne sekwencje zwyczajnie dodając je do timeline, z taką łatwością z jaką łączy się ze sobą sekwencje dźwięków. A na koniec - dzięki presetom (wspomnianym krzywym ekpresji) mieć bazę najpopularniejszych gestów, ktore mozna dopasować do każdej postaci w przyszłości. Np. jeżeli zrobię klucze dla ust, to moja postać może żonglować własnymi ustami i rozglądać się na boki normalnie oczami, a całość powinna nadal działać poprawnie jako recytowana przez aktora kwestia z jednego obiektu. Albo zrobić chór podobnych postaci z różnymi wartościami eksprecji i kazdy z jednego presetu i jednego obiektu nieco inaczej będzie się zachowywał śpiewając ten sam refren. I takie tam. Nie wspominajac o fakcie, ze mozna ten sam preset uzyc dla postaci z profilu, półprofilu i stojącej bokiem. Dlatego na początku napisałem, że gdyby coś takiego było, to by animacje - głownie - domorosłych animatorów wyglądały inaczej.

wyslijcie linka do tego licznika

na chwilę obecną mam kilka koncepcji, którymi się podzielę, bo moze ktoś będzie miał jakieś sugeste. 1. doszedłem do wniosku, ze zrobię wszystko na prostej kamerze HD z lapka. Inaczej nie mialoby to sensu. Chcę by grafik nie musiał inwestować kasy w sprzęt, by stać się animatorem, o to chodzi przecież w technologii. Poza tym niezbyt zamożni ludzie mogliby tak dorabiać pracując zdalnie. Po prostu walnę jakieś suwaki do kalibracji i jak defaultowo nie zatrybi (mogę wykryć dosyć prosto zakłócenia widma) to wyświetlę tutorial do suwaków. 2. Ponieważ samo zadanie nie wydaje się tak skomplikowane jak napisanie oprogramowania do montażu scen (takiego przygotowującego zgrzebną sekwencję i wstępnie 'odszumiającą' wynik) pomyślałem, by produkcję sesji FC (facial capture) wykonać w takich krokach. -najpierw nagrywamy video audio w naturalny sposób jako preview -następnie wycinamy sobie (w tym właśnie programie) fragment sceny jaka będzie nas interesowała -software rozpoczyna odtwarzanie sceny z audio 2x wolniejszym, tak by każda 30fps kamerka mogła zarejestrować bardziej płynną sekwencję - w przypadku twarzy jest to do wykonania przez operatora - w motion capture byłoby pewnie trudnejsze ;) -oglądamy podgląd takiej sceny z podwójną prędkością, by zobaczyć czy nie przesadziliśmy z mikroekspresjami (zakładam, ze operator będzie musiał zrobić za pierwszym razem kilka prób, by się tego nauczyć) -video '60fps' jest przetwarzane na ruch cartoonka -operator ma timeline i krzywe ekspresji (czyli np. moze w chwili podnoszenia brwi podbić hiperekspresje w wyniku czego brwi postaci podniosą się 4x wyżej tworzac naturalnie cartoonkowy przerysowany facial expression), pozwoli to też z jednego setupu tworzyc rozne warianty dopasowane do charakteru postaci (moze z czasem powstanie baza takich sekwencji do podpięcia bez tworzenia wlasnej sesji). @Symek - tak to będzie w zasadzie papierek lakmusowy dla przydatności całej aplikacji więc faktycznie jest to coś co może być najtrudniejsze. Mam olbrzymią nadzieję, że krzywe ekspresji załatwią sprawę, plan B jest taki, że na%^$bie suwaków i będę się tydzień wyginał do kamery budując optymalny preset, który pozniej user w mniejszym stopniu zmodyfikuje. I nie pytajcie o kod, jestem zbyt leniwy i nie znam matmy więc stosuje 'brute force'.