Pokaż wiadomości
1
Poszukuję, chcę zrobić / Ekrany w lokomotywach.
« dnia: 13 Października 2012, 18:39:59 »
Witam, mam propozycję ożywienia ekranów montowanych w lokomotywach (na chwilę obecną to chyba kwestia jedynie ET22-2000 oraz ST45 która ekran w MaSzynie ma wyłączony, ale spodziewam się, że z czasem więcej nowoczesnego taboru pojawi się w zasobach MaSzyny). Propozycja sprowadza się do “zlecenia” dynamicznego tworzenia tekstury wyświetlacza językowi skryptowemu (moja propozycja to Python, z założenia tekstura wyświetlacza tworzona była by od nowa przy każdym kolejnym renderowaniu scenerii/kabiny).
Jako, że nie jest to propozycja idealna zacznę od negatywów tego podejścia:
* zachodzi potrzeba dodania do paczki plików wykonywalnych Pythona (aby nie zachodziła potrzeba instalacji środowiska wykonalnego; około 80MB)
* Python nie jest mistrzem szybkości (problem dotyczy większości języków interpretowalnych) co może powodować spowolnienia symulacji (w tym miejscu trudno mi określić jak duży wpływ na symulację może to być, rozwiązania typu tworzenie tekstury co którąś klatkę potencjalnie mogą wchodzić tutaj do gry jako niwelacja spowolnień)
* tworzenie tekstry sprowadzi się do wykonania praktycznie dowolnego kodu, co oznacza, że w którymś momencie osoby o złych intencjach mogły by w nieoficjalnych dodatkach próbować przemycić tutaj potencjalnie szkodliwy kod (teoretycznie można spróbować ograniczyć środowisko wykonywalne tak aby np. funkcje sieciowe pythona nie były dostępne; z drugiej strony pytanie czy ktoś by się pokusił na taki atak na mimo wszystko stosunkowo małą społeczność)
Na co pozwoliło by wprowadzenie tego pomysłu w życie:
* możliwość tworzenia dowolnie zachowującego się wyświetlacza w lokomotywie bez potrzeby dalszych zmian w exe (“program wyświetlacza” ładowany by był w trakcie procesu inicjacji kabiny) na podstawie wcześniej ustalonego zestawu danych przesyłanego z symulatora
* pełna kontrola nad zachowaniem wyświetlacza - aktualnie wyświetlacz w ET22-2000 jest realizowany przez nakładanie kolejnych tekstur na siebie, co w momencie gdy użytkownik nie włączy podświetlenia instrumentów - co zmienia teksturę wyświetlacza z wyłączonego na włączony - widzi kontrolki nakładane na teksturę wyłączonego wyświetlacza, co wygląda poniekąd komicznie.
Stworzyłem małe demo / proof of concept takiego rozwiązania - kręcący się sześcian teksturowany dynamicznie przez Pythona. Dla zainteresowanych udostępniam do pobrania paczkę ze źródłami programu (i kawałkiem Pythona potrzebnym do kompilacji; przykład dla Visual Studio 2010 (budować w konfiguracji Release); bez kawałka Pythona potrzebnym do uruchomienia) oraz paczkę uruchomieniową zawierającą wszystko co jest potrzebne w momencie uruchomienia.
Kod: ( http://eu07.pl/userfiles/21430/priv-py_screen_src.7z ) (458 KB)
Demo: ( http://eu07.pl/userfiles/21430/priv-py_screen_bin.7z ) (16,5 MB)
(do uruchomienia może być potrzebna paczka bibliotek visual studio 2010 do pobrania tutaj: http://www.microsoft.com/en-us/download/details.aspx?id=5555 )
Demo co minutę zmienia program wykorzystany do generowania tekstury sześcianu:
* prosty zegarek
* interfejs mający symulować ET22-2010 na podstawie
* Hasler nowego typu (żółte diody chyba się w rzeczywistości tak nie zapalają, ale chciałem pokazać coś więcej)
(naciśnięcie klawisza r włącza i wyłącza rotacje, naciśnięcie klawisza p przełącza tryby odświeżania tekstury przez Pythona)
Trochę dłuży opis proponowanej architektury jest następujący: Symulator podczas ładowania inicjuje klasę Pythona po której wszystkie klasy odpowiadające za rysowanie ekranów dziedziczą. Klasa ta implementuje inicjację identyfikatora tekstury i może zwrócić go do symulatora, z wykorzystaniem wrapperów dla OpenGL wysyła teksturę do środowiska OpenGL - dzięki wykorzystaniu pyOpenGL nie ma potrzeby przesyłania obrazu pomiędzy symulatorem a pythonem gdyż jest to realizowane na poziomie kodu pyOpenGL. Klasy implementujące poszczególne ekrany implenetują dwie funkcje: konstruktor który ma zainicjować teksturę (poprzez wywołanie dziedziczonego konstruktora) oraz załadować do pamięci wszystkie potrzebne obrazy oraz metodę renderującą ekran zwracającą obiekt obrazu (PIL.Image; dziedziczone metody wywołane przez symulator zajmą się resztą - aktualizacją tekstury) przyjmującą jako argument słownik (mapę) z aktualnym stanem symulacji pojazdu.
Do inicjacji klasy potrzebna jest ścieżka do pliku w którym jest zawarta oraz jej nazwa.
Jako, że w przypadku Visual Studio wszystkie opcje kompilacji zaszyte są w plikach konfiguracji, ekwiwalent flag kompilacji dla g++ prezentował by się następująco: -Lpython/lib -Ipython/include -lpython33
W przypadku gdy pomysł zostanie zaakceptowany i wdrożony w życie spodziewam się, że w połączeniu ze skanowaniem torów na potrzeby prowadzenia pojazdów przez AI mogło by to być wyjściem dla stworzenia MaSzynowej sygnalizacji kabinowej. (luźna propozycja)
Kolejnym tematem do rozważenia po integracji Pythona i symulatora może być przekazanie części sterownia maszynami sterowanymi przez mikroprocesory - dla przykładu ET22-2000 i tempomat. W ramach planów wprowadzenia obsługi elektryki lokomotyw przez schematy drabinkowe można rozważyć taką współpracę (nie wiem w jakim stopniu schematy drabinkowe miały by być używane, jak również zdaję sobie sprawę że za ich pomocą można odwzorować sterowanie poprzez mikroprocesory - bo przecież tak je się programuje - ale wykorzystanie tutaj typowego języka programowania wydaje się ciut prostszym rozwiązaniem). (luźna propozycja)
Z mojej strony oferuję się z pomocą przy integracji proponowanego rozwiązania w exe, jak również przygotowania krótkiego kursu tworzenia ekranów na przykładzie tych zawartych w demo. Jako, że nie mam kontaktu z lokomotywami dla tworzenia bardziej rzeczywistych programów ekranów potrzebował bym dodatkowych materiałów i opisów od ludzi którzy mają z nimi styczność na co dzień.
Osobiście uważam, że zastosowanie języka skryptowego może zmobilizować pewną grupę użytkowników (zapewne niewielką) mającą umiejętności programistyczne ale nie wykorzystującą ich do rozwoju symulatora z uwagi na dostępu do kodu exe i przekonanie, że nie mają wystarczająco dużo czasu aby się o taki dostęp starać - w przypadku użycia języków skryptowych rozwój rozszerzenia jest niezależny od exe (z dokładnością do ustalonych struktur danych)
Wprawne oko mogło zauważyć, że czas na animacji “prostego zegarka” podlega drganiom podczas animacji rotacji, jest to wynik przyjętego przeze mnie podejścia do obracania elementów - dysponując jedynie metodą obrotu wokół środka ze względów wydajnościowych obracam obraz wokół środka i wyliczam gdzie punkt środka powinien zostać umieszczony po obrocie, a następnie obrazy są łączone - jako, że operacja łączenia obrazów wymaga zaadresowania przestrzeni adresem pikseli wkrada się tutaj “błąd zaokrągleń” powodujące drgania nakładanego obrazu w każdej kolejnej ramce - jest to też powód dla którego Hasler nie używa igły bazującej na zdjęciu. Wstępne oględziny innej biblioteki pyGame - często używana dotworzenia gier 2D - wskazują, że jej wykorzystanie z tym problemem by nie pomogło. Powiększenie obrazu do odpowiednich rozmiarów dające przesunięcie środka daje satysfakcjonujące wyniki, ale czas łączenia obrazów jest większy. (na chwilę obecną trudno mi powiedzieć na ile animacja obracania będzie w przyszłości potrzebna, więc trudno mi stwierdzić czy jest to problem dyskwalifikujący to rozwiązanie - np. żółte diody na Haslerze obracane są w taki sam sposób, ale jako, że kąt obrotu dla każdej jest stały nie mają żadnych problemów tego typu)
Kolejnym słówkiem komentarza, jako że środowisko Pythonowe jest w większym stopniu odseparowane od tego co się dzieje w exe, realizacja ekranów działających na zasadzie “widok z kamery” nie będzie do zrealizowania o ile widok z tych kamer nie zostanie odpowiednio przesłany do programu pythonowego w momencie wywołania funkcji rysującej ekran. (takie przyszłościowe myślenie)
Jako, że ogólna myśl poprawy obsługi ekranów zapewne zostanie ciepło przyjęta tematem dyskusji powinno być czy proponowane podejście technologiczne jest akceptowalne. Ze szczególnym zwróceniem uwagi, że wszystko tak naprawdę mogło by być zrealizowane z poziomu exe (zapewne dużo, dużo większym nakładem pracy), czy za pomocą dynamicznie ładowanych .dll (osobiście w C++ tego nie robiłem, w Delphi działało w miarę bezboleśnie) gdzie spodziewał bym się większej wydajności przy w dalszym ciągu ciut większym nakładzie pracy ale już z możliwością rozwoju niezależnego od exe.
(Podczas testów na Windows XP na maszynie wirtualnej otrzymałem błąd inicjacji tekstury ET22 wraz z ostrzerzeniem o wewnętrznym będzie maszyny wirtualnej, jeśli ktoś jeszcze z takiego windowsa korzysta prosił bym o potwierdzenie lub zaprzeczenie występowaniu takiego zjawiska - starsza wersja tego ekranu działała w tej konfiguracji)
Jako, że nie jest to propozycja idealna zacznę od negatywów tego podejścia:
* zachodzi potrzeba dodania do paczki plików wykonywalnych Pythona (aby nie zachodziła potrzeba instalacji środowiska wykonalnego; około 80MB)
* Python nie jest mistrzem szybkości (problem dotyczy większości języków interpretowalnych) co może powodować spowolnienia symulacji (w tym miejscu trudno mi określić jak duży wpływ na symulację może to być, rozwiązania typu tworzenie tekstury co którąś klatkę potencjalnie mogą wchodzić tutaj do gry jako niwelacja spowolnień)
* tworzenie tekstry sprowadzi się do wykonania praktycznie dowolnego kodu, co oznacza, że w którymś momencie osoby o złych intencjach mogły by w nieoficjalnych dodatkach próbować przemycić tutaj potencjalnie szkodliwy kod (teoretycznie można spróbować ograniczyć środowisko wykonywalne tak aby np. funkcje sieciowe pythona nie były dostępne; z drugiej strony pytanie czy ktoś by się pokusił na taki atak na mimo wszystko stosunkowo małą społeczność)
Na co pozwoliło by wprowadzenie tego pomysłu w życie:
* możliwość tworzenia dowolnie zachowującego się wyświetlacza w lokomotywie bez potrzeby dalszych zmian w exe (“program wyświetlacza” ładowany by był w trakcie procesu inicjacji kabiny) na podstawie wcześniej ustalonego zestawu danych przesyłanego z symulatora
* pełna kontrola nad zachowaniem wyświetlacza - aktualnie wyświetlacz w ET22-2000 jest realizowany przez nakładanie kolejnych tekstur na siebie, co w momencie gdy użytkownik nie włączy podświetlenia instrumentów - co zmienia teksturę wyświetlacza z wyłączonego na włączony - widzi kontrolki nakładane na teksturę wyłączonego wyświetlacza, co wygląda poniekąd komicznie.
Stworzyłem małe demo / proof of concept takiego rozwiązania - kręcący się sześcian teksturowany dynamicznie przez Pythona. Dla zainteresowanych udostępniam do pobrania paczkę ze źródłami programu (i kawałkiem Pythona potrzebnym do kompilacji; przykład dla Visual Studio 2010 (budować w konfiguracji Release); bez kawałka Pythona potrzebnym do uruchomienia) oraz paczkę uruchomieniową zawierającą wszystko co jest potrzebne w momencie uruchomienia.
Kod: ( http://eu07.pl/userfiles/21430/priv-py_screen_src.7z ) (458 KB)
Demo: ( http://eu07.pl/userfiles/21430/priv-py_screen_bin.7z ) (16,5 MB)
(do uruchomienia może być potrzebna paczka bibliotek visual studio 2010 do pobrania tutaj: http://www.microsoft.com/en-us/download/details.aspx?id=5555 )
Demo co minutę zmienia program wykorzystany do generowania tekstury sześcianu:
* prosty zegarek
* interfejs mający symulować ET22-2010 na podstawie
&feature=g-u-u
* Hasler nowego typu (żółte diody chyba się w rzeczywistości tak nie zapalają, ale chciałem pokazać coś więcej)
(naciśnięcie klawisza r włącza i wyłącza rotacje, naciśnięcie klawisza p przełącza tryby odświeżania tekstury przez Pythona)
Trochę dłuży opis proponowanej architektury jest następujący: Symulator podczas ładowania inicjuje klasę Pythona po której wszystkie klasy odpowiadające za rysowanie ekranów dziedziczą. Klasa ta implementuje inicjację identyfikatora tekstury i może zwrócić go do symulatora, z wykorzystaniem wrapperów dla OpenGL wysyła teksturę do środowiska OpenGL - dzięki wykorzystaniu pyOpenGL nie ma potrzeby przesyłania obrazu pomiędzy symulatorem a pythonem gdyż jest to realizowane na poziomie kodu pyOpenGL. Klasy implementujące poszczególne ekrany implenetują dwie funkcje: konstruktor który ma zainicjować teksturę (poprzez wywołanie dziedziczonego konstruktora) oraz załadować do pamięci wszystkie potrzebne obrazy oraz metodę renderującą ekran zwracającą obiekt obrazu (PIL.Image; dziedziczone metody wywołane przez symulator zajmą się resztą - aktualizacją tekstury) przyjmującą jako argument słownik (mapę) z aktualnym stanem symulacji pojazdu.
Do inicjacji klasy potrzebna jest ścieżka do pliku w którym jest zawarta oraz jej nazwa.
Jako, że w przypadku Visual Studio wszystkie opcje kompilacji zaszyte są w plikach konfiguracji, ekwiwalent flag kompilacji dla g++ prezentował by się następująco: -Lpython/lib -Ipython/include -lpython33
W przypadku gdy pomysł zostanie zaakceptowany i wdrożony w życie spodziewam się, że w połączeniu ze skanowaniem torów na potrzeby prowadzenia pojazdów przez AI mogło by to być wyjściem dla stworzenia MaSzynowej sygnalizacji kabinowej. (luźna propozycja)
Kolejnym tematem do rozważenia po integracji Pythona i symulatora może być przekazanie części sterownia maszynami sterowanymi przez mikroprocesory - dla przykładu ET22-2000 i tempomat. W ramach planów wprowadzenia obsługi elektryki lokomotyw przez schematy drabinkowe można rozważyć taką współpracę (nie wiem w jakim stopniu schematy drabinkowe miały by być używane, jak również zdaję sobie sprawę że za ich pomocą można odwzorować sterowanie poprzez mikroprocesory - bo przecież tak je się programuje - ale wykorzystanie tutaj typowego języka programowania wydaje się ciut prostszym rozwiązaniem). (luźna propozycja)
Z mojej strony oferuję się z pomocą przy integracji proponowanego rozwiązania w exe, jak również przygotowania krótkiego kursu tworzenia ekranów na przykładzie tych zawartych w demo. Jako, że nie mam kontaktu z lokomotywami dla tworzenia bardziej rzeczywistych programów ekranów potrzebował bym dodatkowych materiałów i opisów od ludzi którzy mają z nimi styczność na co dzień.
Osobiście uważam, że zastosowanie języka skryptowego może zmobilizować pewną grupę użytkowników (zapewne niewielką) mającą umiejętności programistyczne ale nie wykorzystującą ich do rozwoju symulatora z uwagi na dostępu do kodu exe i przekonanie, że nie mają wystarczająco dużo czasu aby się o taki dostęp starać - w przypadku użycia języków skryptowych rozwój rozszerzenia jest niezależny od exe (z dokładnością do ustalonych struktur danych)
Wprawne oko mogło zauważyć, że czas na animacji “prostego zegarka” podlega drganiom podczas animacji rotacji, jest to wynik przyjętego przeze mnie podejścia do obracania elementów - dysponując jedynie metodą obrotu wokół środka ze względów wydajnościowych obracam obraz wokół środka i wyliczam gdzie punkt środka powinien zostać umieszczony po obrocie, a następnie obrazy są łączone - jako, że operacja łączenia obrazów wymaga zaadresowania przestrzeni adresem pikseli wkrada się tutaj “błąd zaokrągleń” powodujące drgania nakładanego obrazu w każdej kolejnej ramce - jest to też powód dla którego Hasler nie używa igły bazującej na zdjęciu. Wstępne oględziny innej biblioteki pyGame - często używana dotworzenia gier 2D - wskazują, że jej wykorzystanie z tym problemem by nie pomogło. Powiększenie obrazu do odpowiednich rozmiarów dające przesunięcie środka daje satysfakcjonujące wyniki, ale czas łączenia obrazów jest większy. (na chwilę obecną trudno mi powiedzieć na ile animacja obracania będzie w przyszłości potrzebna, więc trudno mi stwierdzić czy jest to problem dyskwalifikujący to rozwiązanie - np. żółte diody na Haslerze obracane są w taki sam sposób, ale jako, że kąt obrotu dla każdej jest stały nie mają żadnych problemów tego typu)
Kolejnym słówkiem komentarza, jako że środowisko Pythonowe jest w większym stopniu odseparowane od tego co się dzieje w exe, realizacja ekranów działających na zasadzie “widok z kamery” nie będzie do zrealizowania o ile widok z tych kamer nie zostanie odpowiednio przesłany do programu pythonowego w momencie wywołania funkcji rysującej ekran. (takie przyszłościowe myślenie)
Jako, że ogólna myśl poprawy obsługi ekranów zapewne zostanie ciepło przyjęta tematem dyskusji powinno być czy proponowane podejście technologiczne jest akceptowalne. Ze szczególnym zwróceniem uwagi, że wszystko tak naprawdę mogło by być zrealizowane z poziomu exe (zapewne dużo, dużo większym nakładem pracy), czy za pomocą dynamicznie ładowanych .dll (osobiście w C++ tego nie robiłem, w Delphi działało w miarę bezboleśnie) gdzie spodziewał bym się większej wydajności przy w dalszym ciągu ciut większym nakładzie pracy ale już z możliwością rozwoju niezależnego od exe.
(Podczas testów na Windows XP na maszynie wirtualnej otrzymałem błąd inicjacji tekstury ET22 wraz z ostrzerzeniem o wewnętrznym będzie maszyny wirtualnej, jeśli ktoś jeszcze z takiego windowsa korzysta prosił bym o potwierdzenie lub zaprzeczenie występowaniu takiego zjawiska - starsza wersja tego ekranu działała w tej konfiguracji)