Symulator EU07 (i nie tylko) > Poszukuję, chcę zrobić
Optymalizacja symulatora
panthero:
--- Cytat: youBy w 21 Kwietnia 2008, 15:21:35 ---150 FPS w Mocznikach mam, gdy renderuje się tylko kabina; Normalnie w granicach 15 - 30, a
maksimum wyciągane na moim sprzęcie to jakieś 350-400 FPS. Jak widać to rendering daje ostro po czasie przetwarzania.
(Dane zostały zebrane przypadkowo podczas testów funkcji - wynik negatywny).
A najbardziej aktualne źródła ma chyba @KURS90.
--- Koniec cytatu ---
Oczywiście przetwarzanie grafiki w największym stopniu będzie obciążać... no właśnie co - w OpenGL operuje się na tzw. primitives - w zasadzie podejście do programowania grafiki w OpenGL nie jest podejściem czysto obiektowym - jeśli dla ułatwienia sobie pracy programiści "opakowali" w klasy zbiory funkcji OpenGL'a to faktycznie duża ilość obiektów nie będzie wpływać na spowolnienie renderowania - dzisiejsze karty graficzne są kilkakrotnie bardziej skomplikowane w architekturze zewnętrznej niż dzisiejsze CPU, spowolnienie bierze się ze specyficznego operowania obiektami w programie - zależy też jak są wiązane metody - czy statycznie, czy w tzw. runtime - to już się przedkłada na szybkość działania gdyż zawsze przed wywołaniami metod odpowiednio są obliczane ich adresy a to spowalnia - zwłaszcza przy wielu obiektach... Temu zaradzić za bardzo się nie da bo wszystko trzeba by od nowa - z innym podejściem pisać, nie w tym rzecz. Przecież nawet w metodach klas odpowiedzialnych za tworzenie i "układanie" wierzchołków można wykorzystać instrukcje SIMD - a najlepiej tam gdzie na większej liczbie nie powiązanych ze sobą danych (współrzędne wierzchołków) wykonuje się takie same operacje. Większość aplikacji, które korzystają z OpenGL używa także natywnych funkcji OpenGL np GL_NV_... ale na tym niestety się nie znam.
Podsumowując - owszem to karta graficzna (i jej sterownik) zajmuje się przetwarzaniem i realizowaniem poleceń OpenGL, ale... dane wierzchołków - ich współrzędne oblicza procesor. Tak samo zresztą wykrywanie kolizji - tego OpenGL nie zrobi - to wszystko robota CPU - optymalizując funkcje obliczające wierzchołki i całą resztę graficznych detali - można znacząco przyspieszyć wydajność aplikacji. Aha - ja na razie źródeł nie chcę - miną tygodnie zanim pewnie - doczytam się o co chodziło developerom - z całym szacunkiem dla Was - to Wy wiecie gdzie są "wąskie gardła" - na razie potrzebna mi taka jakby "dokumentacja" Waszego projektu - pro prostu - jak poradzono sobie z konkretnymi rzeczami - czy projekt używa wielu wątków, jak zorganizowano program w klasy itp. Potem można zacząć właściwą pracę - nie można tuningować silnika w aucie znając tylko metody tuningu - trzeba znać i silnik i całe auto.
ABu:
--- Cytat: panthero w 21 Kwietnia 2008, 17:12:45 ---Tak samo zresztą wykrywanie kolizji - tego OpenGL nie zrobi - to wszystko robota CPU
--- Koniec cytatu ---
Kolizje są poza podejrzeniami. Detekcji kolizji z prawdziwego zdarzenia w symulatorze nie ma. Jest pseudodetekcja - ale tylko z pojazdami znajdującymi się na torze. To są bardzo proste funkcje, dodatkowo wywoływane niezwykle rzadko (raz na sekundę albo nawet rzadziej).
Fizyka, włącznie z Ground.Update(); również nie będzie raczej wąskim gardłem. O ile aktualne źródła są wersją zoptymalizowaną przeze mnie to jest tam zastosowana sprytna sztuczka pozwalająca zdecydowanie uprościć liczenie. Cała fizyka (siły między sprzęgami, przesunięcia) liczona jest na pociągu rozciągniętym tylko w jednym wymiarze, dopiero potem pociąg jest wpasowywany w tor. Umożliwia to wyrzucenie ogromnej liczby obliczeń funkcji trygonometrycznych. Fakt, że jest to uproszczenie, ale błędy są pomijalnie małe, za to obserwowany wzrost wydajności znaczny.
Gdybym miał sugerować kierunek optymalizacji to wybrałbym optymalizację grafiki, bo to jest zdecydowanie najwęższe gardło obecnej wersji.
Pozdrawiam
panthero:
Dzięki @KURS90 mam aktualne źródła i muszę przyznać, że łącznie z header'ami ponad 2 000 000 linii kodu robi wrażenie. Do rzeczy - obecnie od dłuższego czasu pracuję nad przenosinami kodu pod C++ Builder 6 - jakoś się udaje - trochę jest błędów w header'ach, ale powoli praca postępuje - jeśli po kompilacji symulator zadziała normalnie to przyjrzę się bliżej źródłom odpowiedzialnym za 3D - jest tam sporo zamieszania, ale widziałem już kilka funkcji, które ładnie będą mogły być zoptymalizowane.
acze:
Witajcie; Jestem tu nowy, ale dorzucę swoje 3 grosze, myślę, że nikt się nie obrazi :).
Asembler w tym projekcie to raczej dobry wybór, zwłaszcza, że cały projekt powstał z tego co słyszałem w cepie.
Zastanawiam się jednak czy tu chodzi o to, że kod jest wolny algorytmicznie, czy koncepcyjnie.
<cite>Oczywiście niekiedy nie można pisać "wyrwanych z kontekstu" metod, ale myślę, że dam radę:)</cite>
Co racja to racja; aczkolwiek w jezykach obiektowych enkapsulacja jest jak najbardziej zalecana; kod powinien być jak najbardziej uniwersalny i pozwalać się używać w wielu miejscach.
PS. jak koordynujecie pracę nad kodem? Jakiś system wersjonowania, typu CVS, SVN? Forum developerskie?
PS2. Jestem programistą javy, z 3 letnim doświadczeniem; przed tym przez 5 lat programowałem w c pod dosem i linuksem. Interesuję się fizyką przemian cieplnych, troszkę fizyką ruchu. Zapoczątkowałem projekt openrail.net . Jeśli mogę się na coś przydać, to chętnie pomogę, zwłaszcza koncepcyjnie.
uetam:
Mhm, skoro tyle sie dzieje moze warto zalozyc dla symka konto na sourceforge lub znow postawic traca i svna?
Nawigacja
[#] Następna strona
Idź do wersji pełnej