JacekCichy

Według mnie jest dobrze :) Co do plastiku to żeby wyglądało bardziej plastikowo to musisz pokombinować z ustawieniami materiału i światła, a teksturze daj spokój bo jest dobra ;) Powodzenia! :)

Sprostuje tylko kilka rzeczy Skoti :) A mianowicie: - mówiąc że VBO jest dosyć nowe miałem na myśli że zostało dołączone do OpenGL w wersji 3.0 (już nie jako rozszerzenie) ale to kwestia sporna jak kto postrzega czas więc myślę że nie ma co dyskutować (tak jak z gustami :)) - to że trawę czy ludka lepiej animować poprzez VertexShader (VS) to jest jak najbardziej oczywiste :) Ja w swoich rozważaniach zatrzymałem się epokę wcześniej (pominąłem operacje na shaderach :)) ale w 100% masz rację, ich użycie jest tak powszechne aktualnie że to głupota z mojej strony :) - Co do rzekomej lepszej wydajności DisplayList się nie zgodzę, z moich testów wynikało że oba są tak samo szybkie natomiast jak podają legendy VBO powinno być dużo szybsze. Skąd te legendy? Ano najprawdopodobniej driver karty optymalizuje displaylisty i przetwarza je na VBO :) - To że VA działa jak VBO to też wiadomo natomiast VA jest wolniejsze od VBO :) stąd pisałem o trudnościach bo miałem na myśli wydajność a nie że się nie dało zrobić :) - Poza tym dobrze że włączyłeś się do dyskusji, bo to zawsze powiew świeżości :) o UBO i VAO nie słyszałem jeszcze wogóle więc fajnie że o tym wspomniałeś to sobie zaraz poczytam :)

Co tu wiele gadać :) 5*

- Model wiadomo śliczny :) - kadr - ok (można jeszcze coś wymyślić ale w zasadzie to nie ma się czego czepiać) - materiał - dorzuć cos co imituje stal, bo narazie to tak "modelinowo" :) - niebo, woda - ok - może na pokładzie kilku marynarzy (low poly) tak co by było widać że ten okręt to nie latający holender bez załogi? :D

Ok zgadzam się z Tobą tylko czy w lod#2 którego słabo widać jest to dużym utrudnieniem dla grafika nie wiedzącego o tym o czym piszesz połączyć wszystkie submeshe w całość i z 3 podtekstur zrobić jedną teksturę? Ja swoje teorie piszę odnośnie modelu bazowego oraz o jego optymalizacjach(duzej odpowiedzialności programisty, małej grafika). Co do obiektów dynamicznych/skryptowanych to chyba zależy od silnika :) Ale w tych przysłowiowych ferrari (Idtech, Cryengine, UE) myślę że dbają o takie rzeczy :) A żeś się przyczepił :) tylko nie wiem czy objaśnienia czy budowy zdań :P Chodziło mi ni mniej ni więcej o animację szkieletową i o to że obiekt podlegający jej może być jednym meshem. Dodatkowo animację szkieletową można z dużym powodzeniem wykorzystać nie tylko do animacji postaci gdzie pojedynczy wierzchołek modelu może mieć przypisane więcej niż jedną kość (przez co powstaje np. deformacja skóry) ale np. w animacji skomplikowanego podwozia samolotu które też będzie pojedynczym meshem (w tym przypadku pojedynczy wierzchołek będzie podlegał pod jedną i tylko jedną kość). Wcześniej napisałem to bardziej pseudo-kodem programistycznym :) Jeżeli ktoś nie rozumie dalej niech pyta, zdaję sobie sprawę ze swoich ułomności humanistycznych :) Ok w przypadku wody masz 100% racji :) Ale czy np. w COD było jej tak dużo? W przypadku Silent Huntera na morzu to faktycznie stanowi ona 90 procent ramki ale nie jest to kategoria gier które są popularne wśród graczy, choć może to zły argument :P :) Co do liczenia ilości polygonow to myślę że też są istotne a dodatkowo dochodzi czynnik zwany fillrate który poza wymienionymi przypadkami jest pomijalny. (Pisze o PC bo o urządzeniach mobilny mam małe pojęcie i zero doświadczenia więc niechce kogoś w błąd wprowadzać) BTW. Bardzo fajne rysunki koncepcyjne tworzysz :) Dopiero teraz mi się udało kilka znaleźć. Pozdrawiam :)

Mówiąc o mistrzach oby najmniej nie miałem na myśli siebie :D Mi daleko do mistrzów zarówno modelowania jak i teksturowania skończywszy na renderingu :) Natomiast mam nadzieje że inni pomogą :) Co do scenki to ta którą przedstawiłeś bardziej przypomina atlantyk niż pacyfik ;) Pacyfik jest w zasadzie zawsze spokojny i takich potężnych mgieł na nim napewno nie ma. Spróbuj jakąs wyspę np wulkaniczną dorzucić w tle, dużo zieleni, plaża, a na pierwszym planie okręt. Co do wody to KoMic bardzo dobrze prawi. Poza tym pogodne niebo i delikatna mgiełka przy wodzie. Tak bym to widział. Natomiast jak to zrobić to niestety nie doradzę :) Jeżeli potrzebujesz jakąś bitmapę do displacementu owej wyspy to proponuję to: niższa rozdzielczość: http://earthobservatory.nasa.gov/Features/BlueMarble/Images/srtm_ramp2.world.5400x2700.jpg wyższa rozdzielczość: http://earthobservatory.nasa.gov/Features/BlueMarble/Images/srtm_ramp2.world.21600x10800.jpg Wytnij odpowiedni kawałeczek, użyj jako displace mape i jedyne co do zostaje teksturowanie :) Powodzenia!

Model jest niesamowity i przepiękny :) Natomiast nie byłbym sobą jakbym się troszkę nie przyczepił :D A mianowicie, jak już go skończysz i tylko i wyłącznie wtedy to poproś któregoś z miejscowych mistrzów aby coś doradził w sprawie renderingu. Bo ja osobiście widzę ten model na froncie! :D

@Chico - Ciesze że Ci się podoba :) :P @PAINbringer - Tak na wstępie to mam nadzieję że Cię nie obrażam, dla mnie to dyskusja techniczna lub ewentualnie mały spór techniczny :P :) Dlaczego ważny to jeszcze wrócę do tego tematu ale najpierw chciałbym się odnieść do tego co piszesz. Wracając do nieszczęsnych DrawCalli.. Jeżeli się całkiem w to wgłębić to masz częściowo rację, np. VBO jest tworem stosunkowo nowym, a zanim wszedł do użycia to w zasadzie jeżeli chciało się mieć jakiś obiekt animowany (czy to postać czy to robocik z siłowniczkami i innymi szpejami) to DrawCalle było ciężko wepchnąc do jednego. Natomiast w obecnej erze tak jak już pisałem, model który utworzył grafik i składa się choćby z 50 submeshy, z których każdy jest niezależnie animowany, można wepchnąć do jednego Drawcalla. Jak? No w bardzo prosty sposób, po prostu dodać informację do każdego wierzchołka w tablicy pod którą kość podlega lub pod którą macierz(w zasadzie to to samo :)), w przebiegu pętli pomnożyć każdy wierzchołek przez macierz która się do niego odnosi po czym całą tablicę wyświetlić w jednym drawcallu. Co do wielu tekstur zamiast jednej, też coś się da zrobić. Wiadomo że fajnie jeżeli i graficy i programiści mają pracę rozłożoną w miarę po równo a wynikiem jest fajna gra, silnik lub aplikacja. A celowe zażnięcie programisty tylko dlatego że jest programistą i sobie poradzi jakoś jest równie bez sensu jak zrobienie tego samego z grafikiem. Jednak wiele rzeczy można zrobić. Co do wielkości renderowanego obiektu to jeżeli jest skomplikowany i daleko to powinien być stosowany system LOD ewentualnie Siatka adaptacyjna i to rozwiązuje problem, jeżeli natomiast jest blisko i jest mały i bardzo skomplikowany no to cóż... nie będe się spierał że to jest sensowne, ale to ma niewiele chyba z DrawCallami wspolnego :). Co do fillrate to muszę przyznać że jak na kogoś kto nie jest programistą to albo jesteś bystrzacha albo po prostu dużo wiesz :) Tutaj Cię trochę zaskoczę bo przyznałeś mi słuczność, a i ja ją Tobie również przyznam. Fakt obiekty przeźroczyste mi trochę umknęły. W tym przypadku masz rację :) Co prawda w grach raczej nie stosuje się dużej ilości obiektów przeźroczystych, a jeżeli są to rzadko są one skomplikowane, natomiast jeżeli Pan Temat zechce zrobić grę pod tytułem żelkowe misie w żelkowej krainie to w przypadku urządzeń mobilnych faktycznie fillrate może odgrywać ważną rolę :) Chciałem jeszcze napisać dlaczego uważam że szczegóły są ważne, otóż w swojej programistycznej karierze (nie jest ona taka długa więc bodajże 2 lata temu) miałem śmieszno-straszną historię. A mianowicie gdzieś wyczytałem i ktoś kto nie napisał żadnego programu mi tę złą informację potwierdził jakoby mnożenie, dodawanie i odejmowanie zajmowało procesorowi podobną ilość taktów a dzielenie było ponad sto razy wolniejsze i że dzielenia należy wystrzegać się jak ognia. Jako iż wtedy doszedłem do etapu detekcji kolizji a dokładnie do najtrudniejszego i najbardziej zasobożernego przypadku czyli kolizji trójkąt-trójkąt więc chciałem ten problem rozwiązać jak najlepiej. W sieci natrafiłem na jeden bodajże z dwóch dokumentów oczywiście po ang. opisującego jak to też ten temat matematycznie ugryźć, niestety pomimo języka ang. na jako takim poziomie, opis matematyczny mnie dobił i stwierdziłem że trzeba się samemu zastanowić. Na szczęście mam jednego kumpla którego matematyka fascynuje, ot tak hobby. Nie jest kujonem ani nikim kto by się niechciał podzielić wiedzą więc telefon, mówię jaki problem i jakie założenia (0 dzieleń za wszelką cenę) no i na pewien czas temat ucichł. Kolega myślał intensywnie tydzień w końcu po tygodniu siedząc "za przeproszeniem" kiblu doznał olśnienia i wymyślił :P Ponieważ oczywiście kolizje miały zachodzić w 3D i spełnione miały być wszystkie przypadki więc rozwiązanie też nie było takie proste. Podczas demonstracji rozwiązania tego problemu potrzebny był dodatkowy kolega żeby to wszystko w "przestrzeni" zobrazować :P W szczegóły nie będę się wgłębiał natomiast występowało dużo iloczynów skalarnych, wektorowych, "obudowywań" trójkątów w ostrosłupy itp. Szczerze mówiąc byłem pod wrażeniem, natomiast to co okazało się smutne to to że dzielenie wcale nie jest takie straszne i że owszem dodawanie i odejmowanie są podobne jeżeli chodzi o czas procesora natomiast mnożenie jest dużo wolniejsze a dzielenie ok. dwa razy wolniejsze od mnożenia. Tak więc najprawdopodobniej lepiej by było zastosować dwa dzielenia zamiast 40 mnożeń :P wiadomo wiedza i doświadczenie zostało natomiast jak się okazało mały szczegół a cały wysiłek trochę bez sensu :P EDIT: Spieramy się o szczegóły bo definicje znamy te same, tylko ja uważam że DrawCalli powinien pilnować programista, Ty że grafik :) Pozdrawiam!

@PAINbringer - Piszesz w dość prowokacyjnym stylu ale spokojnie nie dam się sprowokować :) Mam do Ciebie kilka pytań: Pierwsze: czemu twierdzisz że to co napisałem jest opinią wyssaną z palca i że wprowadzam zamęt plus że nie wiem o czym piszę? Drugie: Zacznijmy od drawcalli. A więc twierdzisz że to zależy od liczby i budowy modelu. Jeżeli założymy że programista nie ma zielonego pojęcia jak to wpływa na wydajność i że nie ma się ograniczać to owszem.. tak, bo w prosty i przyjemny sposób część rzeczy sobie załatwi. Natomiast jeżeli programista jest dobry i chce napisać dobry program to o tym fakcie wie. A więc załóżmy że ma model samolotu z podwoziem o ilości 10k tris, znając wpływ ilości drawcalli nie będzie rysował osobno samolotu, klapki od podwozia, siłowniczka, kółeczka itd. Tylko wrzuci sobie do VBO wszystkie wierzchołki owego modelu po czym jak będzie chciał aby kółeczko się schowało to wywoła jeden drawcall z tym że wcześniej odpowiednie wierzchołki przemnoży przez odpowiednią macierz. Owszem utrudni mu to sprawę bo będzie musiał stworzyć czy to klase czy jakis system odpowiadający za animację szkieletową itd. Zamiast wywołać po prostu kolejnego drawcalla i narysować sobie kółeczko. Idźmy dalej, weźmy drzewo, weźmy trawę, chcemy to animować, owszem możemy użyć osobnych drawcalli do każdej gałęzi czy do każdej kępki trawy, ale jeżeli wiemy że nie jest to dobry pomysł to będziemy używać pojedynczych drawcali i będziemy używać dynamicznego VBO. Tak więc nie skomplikowanie modelu wpływa na ilość drawcalli a jedynie to to że jeżeli chcemy mieć w grze 20 samolotów osobno sterowanych przez AI to raczej musimy zrobić 20 osobnych drawcalli bo one nie bardzo od siebie zależą, natomiast skomplikowanie modelu według mnie spokojnie można pominąć i jest to jak najbardziej prawidłowe podejście. Zapomniałem o pytaniu :P proszę napisz mi jak to według Ciebie skomplikowanie modelu ma wpływać na ilość drawcalli :) Trzecie: Fill-rate. Co oznacza parametr dobrze wiem. I znowu masz rację zakładając że programista po prostu sobie wyświetlił skomplikowany model i się bardzo cieszy że szczęśliwie mu się on pokazał i na tym zakończył swoją ambitną pracę. Natomiast jeżeli wysilił swoje szare komórki to doszedł do wniosku że rysowanie tylnich ścianek i brak sortowania obiektów zje mu bardzo dużo rzeczonego fillrate bo będzie go tracił na rysowanie czegoś czego nie widać bo jest "nadpisywane". Ten nasz programista po dojściu do tego wniosku zrobi sortowanie obiektów, nie będzie rysował tylnich ścianek i postara się na taką optymalizację aby fillrate praktycznie uniezależnić od skomplikowania modelu. Zapytasz pewnie hmm no fajnie to dlaczego nie mogę sobie wyświetlić 1miliona trójkątów na urządzeniu mobilnym? Odpowiedź jest taka że wpływa na to przepustowość (częstotliwość) taktowania rdzeni procesorów shaderów, ilość tych rdzeni, bo coś musi przetwarzać ten 1m trójkątów(wierzchołków), dodatkowo algorytmy sortowania itp. też troche zżerają mocy więc jeżeli będą miały sortować 1m trójkątów to procesor najprawdopodobniej może mieć w pewnym momencie problem. Reasumując fillrate pewnie trochę będzie miał wpływ jeżeli będziemy stosować uproszczone algorytmy sortowania w zamian za zachowanie trochę wolnej mocy procesora. (mówimy tu o jedno rdzeniowym raczej wolnym procesorze) Natomiast Czy jest to główny wskaźnik którym należy się przejmować i ograniczać z jego powodu budowę modelu... według mnie nie. Ma on tak znikomy wpływ w zoptymalizowanym programie(silniku) że można go pominąć. Słowo końcowe: Też jestem programistą i wiem że można zrobić coś szybciutko co jest w miare funkcjonalne i założyć że użytkownik kupi sobie najnowszy komputer bo przecież działa, po co się będę wysilał itd. Natomiast powiem szczerze że denerwuje mnie takie podejście bo wbrew pozorom bardzo dużo gier i nie tylko mogło by być uruchomionych na dużo słabszym sprzęcie tylko programistom się niechce albo firma ma terminy i tak naprawdę ma ona w głębokim poważaniu użytkownika. Piszę tą opinię trochę z doświadczenia bo pracowałem w firmie wtedy jeszcze jako grafik i główny programista dość leniwy i wygodnicki po ukończeniu przeze mnie wszystkich modeli które były zoptymalizowane i spokojnie mogły być wyświetlone w grze na ówczesnych komputerach stwierdził że 1k-2k trójkątów to stanowczo za dużo bo jego silnik nie daje rady.. i nie wyświetli sceny składającej się z 20k trójkątów na komputerach z kartą lepszą niż GF3, nie wspominając o tym że nie było tam zabardzo fizyki, a AI było bardzo uproszczone. Co więcej przekonał szefa (mało znającego się w temacie) i musiałem grzecznie starać się zrobić świetnie wyglądające modele z ograniczeniem do 128 trójkątów... (MISSION IMPOSSIBLE) Cóż wtedy wydawało mi się bardzo dziwne bo różne ówczesne gry ładnie wyglądały trójkątów było więcej niż 1k na całą scenę, miały dobrą wydajność a u nas w firmie się nie dało. No ale mało znałem temat w dodatkowo jak ma się polecenie od szefa to można porozmawiać ale nieraz to mało wnosi. Tak więc jakoś podjąłem wyzwanie no i wyszło też jakoś. Tak więc grafik musi się starać ale programista również, wtedy to ma sens a produkt łączy w sobie cechy ładnie wyglądającego i wydajnego. Pozdrawiam!

@PAINbringer - za to ile jest drawcall'i odpowiada programista a nie model, fill rate z tego co mi wiadomo to po prostu wspolczynnik wydajnosci karty wiec tez nie ma to z modelem wiele wspolnego. To tak w celu sprostowania :) @Temat - Ja zajmuje się programowanie w C/C++ i Java w obu z wykorzystaniem OpenGL. Co do urzadzen mobilnych to niestety nie mam zadnego doswiadczenia bo zajmuje się czystym PC natomiast z tych parametrów które podajesz to na moim starym komputerze: Duron - 750Mhz, GeForce 3 (200-230Mhz) Czyli sprzęt o podobnych parametrach, to jak sięgam pamięcią wstecz to dobrze chodziły takie tytułu jak: Quake 3, Jedi Academy, Call of Duty 2, Need for speed 5. Jeśli włączysz sobie gry-online.pl lub inna stronę o grach to znajdziesz trochę screenów po których można zobaczyć ile polygonów przypada na postać, teren, samolot/samochód itd. I w jakiej mniej więcej rozdzielczości są tekstury. Z tego co mi wiadomo to na główne modele w tych grach nie przypada więcej niż 2-3k trójkątów a co do tekstur to raczej nie przekracza się 512^2. Teren jest najczęściej uproszczony i takie bajery jak np trawa na całym terenie w postaci billboardów nie wchodzi w grę. Natomiast to co jest bardzo ważne to poczytaj coś więcej o specyfikacji tej karty i o tym czy ma wsparcie sprzętowe do directx albo opengl bo wydaje mi się że powinno być ;) I słowo zakańczające to zarówno aplikacje Java i C# na nowych procesorach PC chodzą porównywalnie do aplikacji pisanych w językach natywnych natomiast np na moim starym komputerze (duron 750mhz) widać dużą przepaść wydajności. Dodatkowo to to co pisze kolega wyżej: ważne jak napiszesz swój kod, czy będziesz używał optymalizacji (system LOD, drzewa binarne ósemkowe lub inne, oszczędność drawcalli, zoptymalizowany prosty silnik fizyki (raycasting)), jeżeli tak to może uda Ci się stworzyć coś porównywalnego do wyżej wypisanych tytułów lub troszke nawet lepsze, jeżeli nie no to może być problem z paroma oteksturowanymi boxami. Pozdrawiam i powodzenia!

Powiem Ci Komic że mnie rozczarowałeś i zarazem zraniłeś aż na wskroś... wchodze i myśle sobie nooo to teraz będzie istna uczta dla moich oczów bo Komic wrzucił upka, a tu co? Dupa... Z mojej strony przesyłam Ci wór motywacji bo model jeżeli chodzi o pancerne to pokusze się o stwierdzenie że najlepszy jaki widziałem a cholerka brak scenki... Pracuj! EDIT: Acha i te cegły w ostatnim upie naprawdę wyglądają świetnie więc się nie zrażaj xD

Ja pier**** 6 dni??!! Żuchwa mi wypadła i już jej chyba nie znajde... Zniszczyłeś mi psychike maksymalnie i to nie tylko czasem wykonania :P :D Pozdrawiam no i przekazuje 5 tłustych gwiazdek.

Dzięki za bump-mapke no i powodzenia w walce z Karasiem! :D

Dzięki :) Suczka doczekała się już stateczników pionowych ale wstrzymam się narazie z updatem do momentu aż dodam więcej różnych szpejów :)

Z racji że nie byłem pewny czy wytrwam w modelowaniu długo się zastanawiałem czy tworzyć ten wątek :) Ale ponieważ w ciągu ostatnich 2 tygodni udało mi się w miarę poradzić z różnymi problemami dotyczącymi siatki to jestem optymistą :D Oto KnAAPO Su-35 BM:

Mam prośbę, pokazałbyś fragment bump-mapy z nitami? :)

Trawożerca jest po prostu THE BEST! Muszę przyznać że podziwiam za umiejętności animacyjne. A co do samego filmiku to robi furore :D Moja lepsza połowa ostatnimi czasy cały czas mi mowi "puść mi pierścienice" tak więc masz powodzenie wśród kobiet! :D

bardzo prosze ;) Na pierwszy rzut oka:

Model jest naprawdę świetny! I powiem Ci że szczerze mówiąc mam dylemat bo za dużo na 4* a za mało na 5* :P No ale też rozumiem Cie z tym że niechce Ci się robić tekstur bo osobiście też mam do tego uprzedzenia.. :D Masz 5* na zachęte :D

No mam troche wiedzy na temat OpenGL (inżynierka w Javie, aktualnie magisterka w C++) więc jak coś to pytaj śmiało :D

Praca jak zwykle na wysokim poziomie, natomiast daj spokój już spitfire'om i zrób jakiś nowy model :D Widziałem na Twojej stronie w dosyć zaawansowanym stadium MFI... :D

Zajefajnie Ci idzie i podziwiam za dopieszczanie detalu :D ode mnie 5* choć i tak pewnie sie nie pojawi :)

Dorzuć brudy i daje 5* :D

Dla mnie bomba! Tak trzymaj! :D

Jak dla mnie to jest świetnie i nie ma co się czepiać :D Powodzenia w jakiejś kompleksowej animacji czy w czym tam planujesz! :D