Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - Ventor

Strony: 1 2 [3] 4
31
DirectX / Wydajność statycznych buforów.
« dnia: Marzec 02, 2008, 20:16:57 »
Napotkałem dzisiaj na dziwny problem, choć może się okaże, że to całkiem normalne tylko ja żyję w nieświadomości ;)

Do tej pory robiłem tak, że każdy statyczny mesh miał swój VB i IB, oczwiście statyczne, D3DUSAGE_WRITEONLY, D3DPOOL_DEFAULT, bo tak mi było wygodniej. Cały czas byłem przekonany że nie jest to za bardzo wydajne rozwiązanie bo trzeba ciągle ustawiać SetStreamSource i SetIndices, a jak "głosi legenda" są to wywołania kosztowne (tak przynajmniej kiedyś czytałem :P)

Dzisiaj zabrałem się za optymalizację i zrobiłem jeden duży VB i IB (też statyczne), wrzuciłem tam całą statyczną geometrię i co się okazało - na pierwszy rzut oka bez zmian. Szukałem, kombinowałem z 16 i 32 bitowym IB, flagami, optymalizacją pod kątem cache i nic. Zainstalowałem PerfHUD-a i... ewidentnie widać że jest o kilka procent wolniej.

Pytanie brzmi: czy takie optymalizacje nadal się stosuje, czy może obecne sprzęty tak dobrze sobie radzą z przełączaniem VB/IB że nie warto? A może jednak nie powinno być wolniej i gdzieś robię błąd?

//Edit
Dodam jeszcze, że GPU jest dłużej bezczynny w przypadku jednego VB i IB, ale sterownik dłużej się wykonuje. Może problemem jest ustawianie przez sterownik offsetów w buforach, a w przypadku wielu buforów zawsze rysowane są całe i nie ma tego problemu?

33
Silniki / Odp: Cry Engine 2
« dnia: Luty 25, 2008, 11:33:14 »
Czajniczki są na pewno renderowane kilkoma DrawCall-ami, ale jest jeszcze jakaś ściema z nimi, bo około 1:12 widać jak jeden żółty czajniczek znika.

34
Cytat: drean
-bledy ktore pokazales nie leza po stronie silnika, problem tkwi w karcie/sterownikach. niestety nie posiadam 6600 wiec nie moge przeprowadzic testow by znalezc jakies obejscie tych "dziwolagow" (gre testowalem na kartach 9600pro, 8600m gt, 8800gtx, 2600, 2900 i dzialala bez zadnych problemow)
Być może masz rację, bo przy pierwszym uruchomieniu kaszaniło się dużo bardziej, a po zainstalowaniu najnowszych sterownik jest sporo lepiej.

Cytat: drean
-slow motion o ktorym piszesz rowniez nie jest to wina silnika lecz tego ze masz slaba karte graficzna i momentami gra dziala u ciebie az tak wolno ze systemowe timery zwracaja 'bullshit'
Z tym się absolutnie nie zgodzę, bo dzieje się to nawet w 640x480 przy około 60-70fps, ale jest to prawdopodobnie związane z timerami, bo fps nie spada, nadal jest płynnie tylko że wolniej.

Cytat: drean
-nawet gdy ustawisz opcje na minimum to nie zapomiaj ze i tak pozostaje normal mapping, per pixel lighting, wolumetryczna mgla, miekkie czasteczki, minimum 3 dynamiczne swiatla no i realistyczna fizyka a nie sa to trywialne efekty
Efekty fakt, trywialne nie są, ale ilość geometrii jest niewielka, a tekstur dosłownie kilka. Co się stanie jak level będzie bardziej skomplikowany, dojdzie trochę leżących przedmiotów, więcej tekstur?

Cytat: drean
-dokumentacja jest caly czas uaktualniana a i tak jest o niebo lepsza niz wiekszosc komercyjnych silnikow, poza tym najlepsza nauka zawsze pochodzi z tutoriali
Nie oszukujmy się, przecież nikt nie zapłaci za silnik którego nie będzie umiał wykorzystać, tym bardziej, że są dobre darmowe silniki z dobrymi dokumentacjami.

Mi to w zasadzie nie przeszkadza, że ta dokumentacja jest słaba, że są błędy i wolno działa - Twój silnik - Twoja sprawa co dalej z tym zrobisz. Ja po prostu zwracam uwagę na te fakty, bo większość forumowiczów wpada w zachwyt nie zauważając drugiej strony medalu.

35
Pograłem chwilę w demo i prawdę mówiąc nie robi na mnie większego wrażenia. Po pierwsze znalazłem kilka błędów po kilku minutach grania, więc pewnie jest ich sporo więcej:
- problem ze stencil shadow.
- coś szarego
- brak tekstury bohatera
- kolorowe spodnie

Po drugie gra czasem dziwnie zwalnia, taki slow motion. Próbowałem wyczaić od czego to zależy, ale nie wiem, raczej losowo się to dzieje.

Po trzecie jest wolne, wszystko na minimum, rozdzielczość 1280x1024 na GF6600 około 15fps - wiem że nie jest to demon prędkości, ale przy tak małej ilości geometrii to raczej słabo.

Na koniec dokumentacja silnika - jest bardzo kiepska, nie wynika z niej jak używać silnika. Opisy bardziej pasują na komentarz w samym kodzie niż na dokumentację. Jedyna możliwość żeby coś zrobić to analizować przykłady i sam kod silnika, a z tym jest kolejny problem - nieintuicyjne nazewnictwo i miejscami lawina niepotrzebnych komentarzy.


Dobra, koniec narzekania ;) K++ za to że w ogóle udało się zrobić coś działającego, za udostępnienie i za wkład jaki w to włożyłeś. Nie przejmuj się tak do końca tym co piszę, potraktuj to jak konstruktywną krytykę, która może Cię zmobilizuje do poprawienia błędów, optymalizacji itp.

36
DirectX / Odp: Bump Mapping
« dnia: Luty 20, 2008, 06:29:42 »
Cytat: Krzysiek K.
Cytuj
D3DTOP_BUMPENVMAPLUMINANCE to taki "prawdziwy" bump zwany również parallax mappingiem.
To nie parallax mapping, tylko pomieszanie bumpmap z environment mapping'iem. Parallax mapping to już zupełnie co innego. :)
Racja, już poprawiłem.

Cytat: Krzysiek K.
Co do dyskusji "to shader or not to shader", to śmieszności całej sprawie dodaje fakt, że nie istnieje żadna karta, która by wspierała D3DTOP_BUMPENVMAPLUMINANCE, a nie wspierała chociazby pixel shaderów 1.1. Polecam raczej pobawić się z DOT3, a zabawę z bumpowanym environment mappingiem zostawić chociażby na shadery 1.1. :)
Kilka by się może znalazło: Matrox G400, Radeon 7200.

37
DirectX / Odp: Bump Mapping
« dnia: Luty 19, 2008, 22:39:40 »
Jeżeli wiesz o co w tym chodzi to jest dosyć przejrzyste, choć może nie bardziej niż shadery, ale jeżeli Ufos uparł się że tak chce to zrobić to dlaczego mu odbierać tą przyjemność. Czasem warto znać też starsze rozwiązania, żeby docenić zalety nowszych ;)

38
DirectX / Odp: Bump Mapping
« dnia: Luty 19, 2008, 19:03:24 »
...ech ta młodzież, tylko shadery im w głowie ;)

Spróbuj tak
d3dDevice->SetTexture( 0, d3dBaseTexture );
d3dDevice->SetTexture( 1, d3dBumpMap );
d3dDevice->SetTexture( 2, d3dEnvMap );

d3dDevice->SetTextureStageState( 0, D3DTSS_COLOROP, D3DTOP_MODULATE );
d3dDevice->SetTextureStageState( 0, D3DTSS_COLORARG1, D3DTA_TEXTURE );
d3dDevice->SetTextureStageState( 0, D3DTSS_COLORARG2, D3DTA_DIFFUSE );
d3dDevice->SetTextureStageState( 0, D3DTSS_ALPHAOP, D3DTOP_SELECTARG1 );
d3dDevice->SetTextureStageState( 0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE );
d3dDevice->SetTextureStageState( 0, D3DTSS_TEXCOORDINDEX, 0 );

d3dDevice->SetTextureStageState( 1, D3DTSS_TEXCOORDINDEX, 0 );
d3dDevice->SetTextureStageState( 1, D3DTSS_COLOROP, D3DTOP_BUMPENVMAPLUMINANCE);
d3dDevice->SetTextureStageState( 1, D3DTSS_COLORARG1, D3DTA_TEXTURE );
d3dDevice->SetTextureStageState( 1, D3DTSS_COLORARG2, D3DTA_CURRENT );

d3dDevice->SetTextureStageState( 1, D3DTSS_BUMPENVMAT00, F2DW(1.0f) );
d3dDevice->SetTextureStageState( 1, D3DTSS_BUMPENVMAT01, F2DW(0.0f) );
d3dDevice->SetTextureStageState( 1, D3DTSS_BUMPENVMAT10, F2DW(0.0f) );
d3dDevice->SetTextureStageState( 1, D3DTSS_BUMPENVMAT11, F2DW(1.0f) );

d3dDevice->SetTextureStageState( 1, D3DTSS_BUMPENVLSCALE, F2DW(0.5f) );
d3dDevice->SetTextureStageState( 1, D3DTSS_BUMPENVLOFFSET, F2DW(0.0f) );

d3dDevice->SetTextureStageState( 2, D3DTSS_TEXCOORDINDEX, 0 );
d3dDevice->SetTextureStageState( 2, D3DTSS_COLOROP, D3DTOP_ADD );
d3dDevice->SetTextureStageState( 2, D3DTSS_COLORARG1, D3DTA_TEXTURE );
d3dDevice->SetTextureStageState( 2, D3DTSS_COLORARG2, D3DTA_CURRENT );

W Twoim przykładzie mieszasz DP3 z bumpem, a to nie to samo. D3DTOP_DOTPRODUCT3 liczy kolor z normalmapy, a D3DTOP_BUMPENVMAPLUMINANCE to taki "prawdziwy" bump zwany również parallax environment mappingiem.

//Edit
environment oczywiście, nie parallax

39
Branża / Odp: CD Project przejmuje Metropolis
« dnia: Luty 19, 2008, 08:12:53 »
Cytuj
Co daje więcej zysków, co z kolei pozwala na wykupienie kolejnego studia i koło się zamyka :)
Niestety, PCF'a już CDProjektowi zdążył podkupić Epic (ale za to Farm 51 został). ;)
Farm 51 teraz klepie casuale dla Codeminion ;) obstawiałbym raczej, że następny będzie Techland.

40
DirectX / Odp: Kolizje z wieloma obiektami
« dnia: Luty 18, 2008, 10:36:24 »
Jeżeli chcesz żeby mapa była jedną siatką to musisz liczyć kolizje z każdym trójkątem tej siatki, a jeżeli chcesz kolizje na BBoxach, to każdy budynek powinien być osobnym obiektem.

41
Wygląda na to że nie działa z-bufor, więc spróbuj zmienić jego format i ustaw D3DRS_ZFUNC np na D3DCMP_LESSEQUAL i jeszcze zabrakło "f" w ostatnim parametrze D3DXMatrixPerspectiveFovLH.

42
OpenGL / Odp: Głupi problem w poczatkach - nie wyswietla trojkatow
« dnia: Luty 08, 2008, 10:01:24 »
Cytat: RageX
typedef struct? hmm... mi to wygląda na braki w podstawach cpp.
Mi też to wygląda na braki w podstawach C++... ale Twoje  ;D
Ja przyznaję że jestem początkujący w C++, ale ten kod od razu wydał mi się prawidłowy, bo już wcześniej z podobnym się spotkałem. Z ciekawości jeszcze sprawdziłem czy kompilator nie będzie miał problemu i nie miał.

piotr1992, może problem jest z backfaceculling - spróbuj wyłączyć, albo wprowadzić wierzchołki w odwrotnej kolejności.

43
DirectX / Odp: vertex buffer
« dnia: Luty 07, 2008, 21:31:07 »
Ja to robię w dosyć prosty choć może nie najlepszy sposób. Pobieram każdy trójkąt osobno, zapisany jako trzy wierzchołki zawierające współrzędne, normalne, współrzędne teksturowania itp. Jak już mam wszystkie trójkąty, to tworzę pusty vertex buffer i index buffer. Przeglądam po kolei każdy wierzchołek każdego trójkąta i porównuję z istniejącymi w VB. Jeżeli identyczny wierzchołek już jest w VB to zapisuję jego indeks w IB, a jeżeli nie ma to dodaję nowy wierzchołek do VB i też zapisuję jego indeks do IB.

Rozwiązanie to jest dosyć wolne, ale kogo to obchodzi ;) i tak nie robi się tego w real time.

44
C++ / Odp: O wydajności - klasyczne błędy z użyciem języka
« dnia: Luty 06, 2008, 20:47:37 »
Cytat: Reg
EDIT: Ventor: Ameryki nie odkryłeś :) http://en.wikipedia.org/wiki/Introsort
... a jednak odkryłem bo introsort to połączenie quick z heap, a nie quick z insertion i wydaje mi się (choć nie sprawdzałem tego), że będzie wolniejsze. Insertion dla małych tablic jest szybszy od quick i to wykorzystałem, a heap nie jest szybszy od quick w żadnym przypadku, więc nawet jeżeli jest jakiś zysk z tego połączenia to wydaje mi się, że niewielki. Poza tym jak pisałem ten program to nie wiedziałem o istnieniu introsorta, więc z mojego punktu widzenia odkryłem Amerykę ;)

45
C++ / Odp: O wydajności - klasyczne błędy z użyciem języka
« dnia: Luty 06, 2008, 20:19:19 »
Według mnie ta prezentacja dowodzi, że jednak warto poświęcić czasem trochę czasu na optymalizację, nawet w assemblerze, a nie bezmyślnie klepać wierząc, że kompilator wszystko zoptymalizuje. Oczywiście nie zawsze to ma sens, bo np sortowanie bąbelkowe napisane w assemblerze nigdy nie będzie szybsze od Quicksorta napisanego w czymkolwiek.

Skoro już mowa o sortowaniu to kiedyś pisałem komuś na zaliczenie program (link) porównujący różne metody i okazało się że najlepiej wypada połączenie quicksorta z insertion sortem. Ten drugi jest bardzo szybki dla małych tablic i właśnie to zostało wykorzystane.


Strony: 1 2 [3] 4