Exe - konwersja na C++

[tmj]

Na TD mam taki widok, na Kaliskiej i Bałtyku jest ładnie. Widoczność tej zjawy zależy od kąta patrzenia. W każdym razie z kabiny widać. Na razie taki efekt jest tylko na TD, jeśli gdzieś jeszcze znajdę, dopiszę.

Ten efekt pojawia sie, gdy exe nie uda sie zaladowac tekstury aureoli. Zobacz czy cos tam nie stalo sie z plikiem w folderze textures/fx bo normalnie nie powinno sie to zdarzyc :)

[queuedEU]

Ale czemu one nie sa zrobione na glPoint()? glPoint() mozna kontrolowac, rozmiar, zanikanie i inne i moze byc ich s dziesiatki tysiecy a FPS nie spadnie. Wiem bo snieg mialem na trzech typach obiektow do wyboru - glTriangle(), glLine i glPoint i ten ostatni pozwalal nawet na kilka set tysiecy platkow przy malym spadku FPS.

[Krzysiek626]

Nie wiem jak na to wpadłeś, bo napisałem że w Bałtyku i Kaliskiej jest ok. Miałeś rację, wypakowałem do dwóch paczek i tam gdzie odpaliłem TD musiałem źle upuścić rozpakowane archiwum. Oczywiście jest wszędzie dobrze.

[tmj]

Ale czemu one nie sa zrobione na glPoint()? glPoint() mozna kontrolowac, rozmiar, zanikanie i inne i moze byc ich s dziesiatki tysiecy a FPS nie spadnie. Wiem bo snieg mialem na trzech typach obiektow do wyboru - glTriangle(), glLine i glPoint i ten ostatni pozwalal nawet na kilka set tysiecy platkow przy malym spadku FPS.

- nie trzeba bawic sie z recznym skalowaniem wymiarow na podstawie odleglosci
- bardziej przyjazne dla starego sprzetu, nie wiem jak wyglada teraz obsluga 'punktow' wielkosci 200-300 i wiecej pikseli, ale kiedys raczej nie bylo z tym rozowo
- widocznosc point sprites jest okreslana na podstawie widocznosci punktu centralnego. czyli np w ujeciu jak na zalaczniku aureola po prawej zostalaby obcieta
- spadek fps spowodowany byl obliczaniem punktu centralnego przez wyciaganie matrycy modelview dla kazdego punktu (co jest swoja droga kiepskim rozwiazaniem, ale w kodzie nie ma chyba kalkulacji pozycji poszczegolnych submodeli, ani w ogole danych dla poszczegolnych egzemplarzy, wszystko jest robione w oparciu o pozycje modelu bazowego i matrix push/pop 'w locie' dla poszczegolnych elementow) Czyli samo zastosowanie punktow nie zmieniloby wydajnosci -- co zreszta latwo sprawdzic, podstawowe spotlights to sa glPoints wlasnie, i przy starym kodzie kalkulacje ich pozycji mialo zauwazalny efekt na ogolnej wydajnosc, nawet gdy punktow nie bylo wiecej niz 50-100 :d

Natomiast do rzeczy takich jak snieg czy inne tego typu czasteczki to jak najbardziej. Na upartego aureole tez mozna pozniej przerobic praktycznie w calosci na shader, jak juz beda.

[Stele]

Oj, będzie poprawek w modelach, będzie. Kto puścił 163a z freespotem w końcówkach w takim kolorku?
Nie ma błędu/ficzeru z wolno rozpalającymi się aureolami, dającymi prawie niewidoczne światło u Q.

[queuedEU]

Jak to teraz masz zrobione, w sensie w ktorym miejscu jest renderowanie quada(?) z aurola i co robi funkcja Get() o ktorej mowisz?

[tmj]

Rendering jest wstawiony do funkcji rysujacej przezroczyste submodele, taki symetryczny odpowiednik dla kodu rysujacego 'nieprzezroczyste' freespoty. glGet uzywany byl do wyciagania danych o biezacej konfiguracji matryc, w ten sposob:

Kod: [Zaznacz]

                matrix4x4 modelview;
                ::glGetDoublev( GL_MODELVIEW_MATRIX, modelview.getArray() );
i to jest dosc kosztowne, bo zeby karta graficzna mogla dostarczyc tych danych to przerywane jest renderowanie (zeby ustalic stan itp)

wrzuce troche pozniej uaktualnienie na githuba to sobie bedziesz mogl szczegoly obejrzec~

[firleju]

No to ciekawe czy przejście na shadery też przyniesie wzrost wydajności.

[HTD]

Aureole są OK (dobra, są SUPER), chociaż drobna uwaga: odnoszę wrażenie, że anty-aliasing się jakby zepsuł trochę, ale dziwnie, bo widać to wyłącznie na 2 elementach - poziomych elementach trakcji (no na tych co druty są podwieszone) i na wskazówkach od haslera w ED72.

W niektórych wersjach exe wokół tych wskazówek pojawia się biała obwódka wyglądająca super kijowo. W tej przykładowo jest.

Co do nowego interfejsu to jest miód i poziomki. O to chodziło. To wygląda, że zostały do zrobienia już tylko te światła na shaderach i hamulce od aut.

[Stele]

Obwódka to efekt lipnej tekstury filtrowanej anizotropowo. Kiedyś załatwimy to globalnie automatem, tylko ktoś musi siąść i go zaprogramować.

[jakubg1]

Znalazłem 2 błędy:
1. Przez drzwi od wewnątrz w EN57-20xx nie widać sieci trakcyjnej, cieni i niektórych lamp.
2. Aureola gryzie się z lampami.

[Krzysiek626]

Gdzie mam szukać tych błędów? Sceneria jaka (Quark?) i ewentualne przybliżona lokalizacja.

[jakubg1]

Tak, Quark. Błąd z kiblem to przystanek Dejawy Kopalnia, chociaż występuje wszędzie i na każdej scenerii. Drugi błąd to Koniewice - tarcza manewrowa od strony szlaku jednotorowego.

[Stele]

W obu przypadkach o sortowanie przezroczystości chodzi. Problem stary jak grafika 3d.
Tylko dlaczego drutów nie widać?

[Krzysiek626]

Tu trzeba dopowiedzieć, że nie tylko kibel ma ten błąd, także siódemka posiada problemy z przezroczystościami okienek maszynowni. Problem nie dotyczy exe C++, występuje także na exe borlandowym z PC. Jeśli chodzi o karzełki. cóż oświetlenie terenu lampami w Quarku jest żenujące, Te tekstury rzucone na grunt symulujące oświetlony teren gryzą się z innymi przezroczystościami. Też nie jest to problem C++. Efekt jest widoczny tylko w nocnym wizerunku scenerii.

[tmj]

W przypadku EU07 bledem jest to, ze sciana wnetrza low poly zwyczajnie nie ma chyba wycietego srodkowego okna po prawej stronie. Wiec patrzac z lewej na prawo widzisz lita sciane. Z prawej na lewo widac jak trzeba, bo tam okno zostalo wyciete.

edit: co do przedsionka en57-2000 zaslaniajacego elementy przezroczyste, patrzac na szybko, to bierze sie z chyba tego ze te przedsionki sa wspawane w pudlo i renderowane razem z pudlem, w trakcie rysowania obiektow dynamicznych, a nie jako "kabina na samym koncu) Gdyby wszystko bylo zaaranzowane poprawnie to nie przeszkadzaloby to specjalnie -- obiekty przezroczyste powinny byc renderowane od najdalszych do najblizszych -- ale zdaje sie exe robi to dosc srednio, i np druty itp rysowane sa na koncu. Czyli w tym wypadku po tym, jak narysowane zostalo pudlo z przedsionkami, a na tym etapie karta graficzna stwierdza ze nie warto rysowac drutow ktore z jej punktu widzenia "zasloniete" sa sciana przedsionka ktory z jej punktu widzenia przezroczysty nie jest.

edit2: do pewnego stopnia blad drzwi mozna usunac, poprawiajac maske alfa tekstury pojazdu -- na etapie obiektow z przezroczystosciami exe traktuje jako "nieistniejace" wszystko oteksturowane z wartoscia kanalu alpha 10/255 lub mniejsza. Szyby przedsionka EN57 sa minimalnie "mniej przezroczyste" i jako takie sa renderowane.

[Milek7]

Trochę informacji z tego w czym grzebię.
Przeniosłem operacje na stosie macierzy opengl na macierze glm przekazywane w argumentach metod. @tmj, możesz zobaczyć czy coś z tego wykorzystasz https://github.com/Milek7/maszyna/commit/b92a1e58ae9b91713f789b8be3f58b86198b87a5 (póki co tylko VBO działa, ale przenieść to na DL to kilka linijek)

A w kwestii shaderów, popatrzyłem na specyfikację GLSL i dowiedziałem się, że faktycznie są tam zdefiniowane uniformy na wartości przekazywane przez fixed pipeline. Więc na dobrą sprawę to oświetlenie blinnphong da się zrobić na shaderach praktycznie bez żadnych zmian w kodzie, działające zarówno na DL i VBO. No ale to już dowiedziałem się po tym jak zrobiłem wstępnie działające shadery na własnych uniformach. Ze względu na to że funkcjonalności fixed pipeline i tak są zdeprecjonowane w nowym opengl to i tak przydało by się kontynuować te prace na własnych uniformach, wywalić DL i przenieść na opengl 3.2 core profile. Jednak z tego powodu że wymaga to jeszcze troche dopieszczenia, plan jest taki: robię dzisiaj oświetlenie shaderem kompatybilnym z opengl2 i starym kodem DL/VBO, a później na spokojnie przenosimy wszystko na 3.2 core profile i własne uniformy.

Jeszcze ze zmian w build systemie: przygotowałem paczkę z zależnościami do budowania które nie mają własnego oficjalnego windowsowego instalatora oraz dołączyłem skrypt uruchamiający cmake z odpowiednimi ścieżkami w owej paczce. Czyli żeby zbudować moje repo trzeba: zainstalować visuala, cmake i pythona, sklonować repo, i builds/cmake_win32/64.bat które ściągnie paczkę z pozostałymi zależnościami i wygeneruje pliki projektu vs.
Korzystając z automatyzacji tego skonfigurowałem CI na AppVeyor https://ci.appveyor.com/project/Milek7/maszyna .

[RoboBatman]

@tmj: właśnie jestem po pierwszych prowizorycznych testach exe z zaimplementowaną aureolą. Mam jedną wątpliwość co do tego ficzeru. O ile jeszcze w nocy taka aureola na semaforach się pojawia i można to zauważyć, to w czasie dnia kiedy jest słońce lub jest widoczność dzienna nawet w czasie pochmurnych dni, mam wątpliwość, żeby taki ficzer w czasie dnia stosować bo nigdy takowej aureoli w czasie dnia na semaforach (nawet nowych) nie zauważyłem. Czy dałoby radę rozdzielić w exe, od kiedy do kiedy ( w konkretnych godzinach) ta aureola ma się pojawiać? Sam efekt w nocy mi się bardzo podoba-jak najbardziej na plus. Zaznaczam, iż jest to jest tylko propozycja a nie krytyka. Dziękuję z góry za odpowiedź na moją kwestię.

[tmj]

Trochę informacji z tego w czym grzebię.
Przeniosłem operacje na stosie macierzy opengl na macierze glm przekazywane w argumentach metod. @tmj, możesz zobaczyć czy coś z tego wykorzystasz https://github.com/Milek7/maszyna/commit/b92a1e58ae9b91713f789b8be3f58b86198b87a5 (póki co tylko VBO działa, ale przenieść to na DL to kilka linijek)

Widzialem :) na razie ich nie ruszam, bo chce przeniesc reszte funkcji rysujacych do modulu renderujacego (tak jak jest to na razie zrobione dla czesci DL), a jak juz tam beda to renderer bedzie mial te macierze "pod reka", bez potrzeby podawania ich dla kazdej funkcji z osobna. Ulatwi to tez spiecie razem funkcji renderujacych, bo tak z 75% powtarza sie w obu wariantach, a roznice sa glownie na poziomie skad sub-modele czerpia dane geometrii (a to juz mozna zalatwic czyms w stylu ogolnej klasy bufora danych, specjalizowanej dla VBO i DL) No i latwiejsza bedzie konfiguracja renderowania w zaleznosci od celu (kolor, shadowmaps, item picking itd)

Jednak z tego powodu że wymaga to jeszcze troche dopieszczenia, plan jest taki: robię dzisiaj oświetlenie shaderem kompatybilnym z opengl2 i starym kodem DL/VBO, a później na spokojnie przenosimy wszystko na 3.2 core profile i własne uniformy.

W sumie jak juz robiles na wlasnych uniformach to mozna bylo jechac na tym dalej, ale ok, lepsze oswietlenie szybciej tez nie zaszkodzi ;)

Czy dałoby radę rozdzielić w exe, od kiedy do kiedy ( w konkretnych godzinach) ta aureola ma się pojawiać? Sam efekt w nocy mi się bardzo podoba-jak najbardziej na plus. Zaznaczam, iż jest to jest tylko propozycja a nie krytyka. Dziękuję z góry za odpowiedź na moją kwestię.

Mozna zrobic to tak samo jak sa w danym momencie robione swiatla, tzn sila jest modyfikowana przez ogolny poziom oswietlenia generowany przez slonce i niebo. Wstawilem to do dzisiejszego uaktualnienia, prosze sobie porownac i zdecydowac, ktora opcja lepsza :d

[Stele]

Kod: [Zaznacz]

float fNearAttenStart;
float fNearAttenEnd;
bool bUseNearAtten; // te 3 zmienne okreslaja rysowanie aureoli wokol zrodla swiatla
int iFarAttenDecay; // ta zmienna okresla typ zaniku natezenia swiatla (0:brak, 1,2: potega 1/R)
float fFarDecayRadius; // normalizacja j.w.
float fCosFalloffAngle; // cosinus kąta stożka pod którym widać światło
float fCosHotspotAngle; // cosinus kąta stożka pod którym widać aureolę i zwiększone natężenie światłaTakie mamy parametry dla freespota. Z tego co widzę, fCosFalloffAngle wpływa na krycie flary, ale na krycie wpływa też odległość od źródła, a tego w kodzie nie umiem znaleźć. Możesz rozpisać jak to teraz działa? Warto by użyć parametrów ile się da, skoro i tak są w modelu. Myślę nad wywaleniem skaczących billboardów i gwiazdki na rzecz tego, tylko trzeba przemyśleć jak wyświetlać flarę freespota by ładnie wyglądała dla różnych zastosowań. Nie mam teraz głowy do wymyślania konkretnego algorytmu niestety, ale jak nikt nie podchwyci, to kiedyś pewnie mi się zachce. :)

[tmj]

Na ta chwile tak swiatla freespot jak i aureole uzywaja tylko parametrow fCosFalloffAngle i fCosHotspotAngle -- swiatlo jest widoczne gdy obserwator znajduje sie 'wewnatrz' stozka o kacie zdefiniowanym przez fCosFalloffAngle (w stopniach, zazwyczaj jest to wartosc ~45 stopni od osi obiektu) W 'zewnetrznej' czesci tego stozka nastepuje stopniowe zwiekszenie sily swiatla, od 0 do max. Standardowo ta strefa jest bardzo waska, jakies 2-3 stopnie, wiec swiatlo punktowe pojawia sie i znika niemal natychmiast.

Aureola jest generowana podobnie, z tym ze jej sila rosnie stopniowo miedzy zewnetrzna powierzchnia stozka widocznosci i osia srodka, tak ze jej pojawienie sie i znikanie jest bardziej stopniowe.

Jesli jest zapotrzebowanie, mozna dodatkowo podpiac pozostale parametry (sila dodatkowo zalezna od odleglosci obserwatora, co do pozostalych to nie wiem jak mialy byc uzywane, w starym kodzie wystepuja tylko raz, modyfikujac zakres widzialnosci, i jest to zakomentowane) z tym ze nie wiem czy zdefiniowane wartosci domyslne beda sensowne, bo chyba nigdy nie byly wprowadzone/testowane. Co do billboardow i gwiazd to zostawilbym je jak sa, bo maja nieco inne funkcje i mozliwosci (billboards nie znikaja w zaleznosci od kata i pozwalaja zdefiniowac inna teksture, a aureole dla "gwiazd" i tym podobnych grup punktow bylyby chyba przegieciem :)

Przy okazji, w ostanim uaktualnieniu przy okazji porzadkow wkradl sie blad, mogacy prowadzic to wysypu przy logowaniu niektorych eventow. W zalaczniku poprawka.

[Stele]

Chodzi mi tylko o poświatę latarni. Teraz są tam 3 fazy billboardów i punkt świetlny wokólny (star). Można to zastąpić freespotem o szerokim kącie. By uzyskać podobny efekt, trzeba by dodać zanik i skalowanie flary w funkcji odległości. I to w obie strony. Dla małego dystansu mały quad o wysokiej alfie, skalujący się liniowo wraz z odległością, ale z ekstremum krycia blisko źródła...  Jest tam coś, pod co idzie podpiąć różne tryby działania freespota. Trzeba to przemyśleć, poeksperymentować i zobaczyć jak by to wyglądało. Może spokojnie poczekać w obecnej formie aż nie będę miał systemu wspierającego VS i sam się z tym pobawię.
Obecnej flarze zmieniłbym tylko teksturę na większy placek z krótszymi promieniami, co wymusiłoby zmniejszenie rozmiaru quada. Gołym okiem nigdy takich promieni nie doświadczysz.

[tmj]

No golym okiem to w ogole poswiaty raczej nie doswiadczysz, bo to artefakt soczewek uzytych w aparatach itp ;)  Akurat takie byly na zdjeciach sygnalizatorow ktore znalazlem, o w miare dobrej jakosci, ale jesli ktos chce to zmienic to nie problem, wystaczy pobawic sie tekstura w katalogu textures/fx (ksztalt poswiaty jest w alpha channel)

[Krzysiek626]

Na poprzedniej kompilacji nie odpaliłem żadnego Bałtyku, po kompletnym załadowaniu zdychał. Nie zdążyłem zgłosić. Teraz jest dobrze.

Obecnej flarze zmieniłbym tylko teksturę na większy placek z krótszymi promieniami, co wymusiłoby zmniejszenie rozmiaru quada. Gołym okiem nigdy takich promieni nie doświadczysz.

Teraz wygląda jakby zdjęcie robione było przez filtr na obiektywie używany do takich efektów. Ograniczenie w dzień wydaje się trafione, z tym należałoby rozważyć jak to wygląda w bardzo mglistą i wilgotną pogodę. Mam jeszcze uwagę do latarni, z pewnej odległości poświata wyłazi także przez górą powierzchnię obudowy, co jest dość nienaturalne. Postaram się pokazać screen. To nie jest krytyka, jak napisał @Stele, jak na początek jest zajefajnie.

[RoboBatman]

Przy okazji testowania exe 170323b, wyczaiłem następny błąd/niedopatrzenie (nieodpowiednie skreślić). Podczas testowania aureoli na exe 170323b od @tmj, z racji tego, że korci mnie czasami potestować inne rzeczy na nowym exe, postanowiłem również zobaczyć podświetlone kabiny/kabinę (w zależności od sytuacji) widać również na zewnątrz. Owszem widać. Problem jest tego typu, że w rzeczonej EU07-1512 ( w reszcie EU07 podejrzewam również) zauważyłem błąd tego typu, iż gdy zapalam światło w kabinie numer 1, to wychodząc na zewnątrz, świecą się światła w obydwu kabinach i obydwie kabiny są podświetlone choć dałem podświetlenie tylko do jednej (do kabiny numer 1). Podgląd sytuacji zapodałem na obrazku "kabiny". Nie wiem czy problem leży po stronie exe czy po stronie modelu.

[tmj]

Nie wiem czy problem leży po stronie exe czy po stronie modelu.

Kombinacja obu czynnikow -- exe na ta chwile aplikuje oswietlenie dla calego modelu low poly, a dla wprowadzenia oswietlenia indywidualnych czesci, model low poly musialby zostac na takie submodele podzielony (z odpowiednimi nazwami dla kazdej czesci) Troche dyskusji na ten temat bylo w watku na bugtrackerze, nt. oswietlenia wnetrz, ale ktos musi sie poswiecic i zrobic model 3d na ktorym mozna testowac zmiany wprowadzane do exe, inaczej to jest praca na slepo.

[Krzysiek626]

W załączniku obrazek o którym wspominałem, widoczne z kabiny świetliste bańki. Od góry należałoby je ograniczyć. Widać z określonych odległości i kątów ustawienia kamery. Można by poprawić. Widoczność poświaty w dzień poprawiona, załącznik. Ponowię pytanie, czy można uzależnić od wpisów atmo? W nocy wygląda całkiem fajnie. Można zrobić ten placek o którym pisał Stele.

[Siecool]

Jest coś o czym należy wiedzieć, żeby na nowych exe wygenerować sobie plik e3d terenu scenerii? Póki co program się sypie (crashdump w załączeniu), ostatni wpis w logu "saving e3d model..".

[miko22]

należałoby rozważyć jak to wygląda w bardzo mglistą i wilgotną pogodę.

To samo można by zrobić dla reflektorów, jeśli nie ma z tym dużo roboty, tzn. we mgle dodać widoczne smugi światła dla poszczególnych lamp: https://youtu.be/xULWZx6JzyA Wtedy też przyciemnienie reflektorów nabiera większego sensu, bo zmniejsza te smugi i poprawia widoczność w miejscach oświetlonych latarniami: https://youtu.be/6pDz_uFYDEY?t=23s
A tutaj macie wygląd sygnalizatorów we mgle: https://youtu.be/sYtI1wT2VuE?t=36s, https://youtu.be/sYtI1wT2VuE?t=1m21s

[Milek7]

Jest coś o czym należy wiedzieć, żeby na nowych exe wygenerować sobie plik e3d terenu scenerii? Póki co program się sypie (crashdump w załączeniu), ostatni wpis w logu "saving e3d model..".

Na jakiej scenerii to można przetestować?