- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Bieżące Symulatorowe => Wątek zaczęty przez: Technik w 01 Czerwca 2014, 01:19:59
-
Witajcie!
Może na początku się przedstawię. Mam na imię Szymon, jestem z zawodu programistą aplikacji mobilnych, pasjonuje się elektroniką, szczególnie programowalną.
Mam trzy sprawy:
1. Czemu kod źródłowy MaSzyny nie jest na GPLu?? Ogólnie jestem ogromnym zwolennikiem wolnego oprogramowania, moim zdaniem otwarcie MaSzyny przyniosłoby same korzyści.
2. Czemu MaSzyna jest tylko na przestarzałą architekturę x86? Dlaczego nie jest dostosowana do ekranów dotykowych?
3. Z uwagi na moją pasję, mógłbym zacząć produkować coś w rodzaju pulpitu do podpięcia do kompa. Słyszałem, że powstaje jakaś nowa MaSzyna pod nową marką, może zrobilibyśmy sklep.maszyna.pl lub coś takiego, tam możnaby było kupić gotowe pulpity maszynisty do podpięcia do kompa. Dochód z tego szedł by na dalszy developing MaSzyny. Dodatkowo mógłbym pomóc w portowaniu tej nowej MaSzyny na Androida.
Co o tym sądzicie?
W ogóle koncept tych paneli maszynisty jest taki:
- Jako przełączniki dajemy zwykłe "pstryczki hebelkowe", podłączone pod jakiś expander I2C, który to z kolei podłączony jest do AtMegi8, wersji z wbudowanym kontrolerem USB.
- Jako te wskaźniki ciśnień damy zwykłe woltomierze analogowe, oczywiście z wymienioną "karteczką", podpięte pod PWMy.
- Jako nastawnik... O właśnie - oto jest pytanie. Ja myślałem o jakiejś starej metalowej kierownicy ze złomu, przypiętej do enkodera cyfrowego, który jest też wpięty do naszego mikroprocka.
- z kontrolkami nie ma problemu, zwykłe ledy/małe żaróweczki
- Jako główna płyta do której wszystkie komponenty będą przymocowane będzie paminat epoksydowo-szklany, oklejony odpowiednim materiałem.
-
Słyszałem, że powstaje jakaś nowa MaSzyna pod nową marką, może zrobilibyśmy sklep.maszyna.pl lub coś takiego, tam możnaby było kupić gotowe pulpity maszynisty do podpięcia do kompa. Dochód z tego szedł by na dalszy developing MaSzyny. Dodatkowo mógłbym pomóc w portowaniu tej nowej MaSzyny na Androida.
Ta nowa MaSzyna to coś w ten deseń:
-
Nic z tych rzeczy, to pulpit zrobiony na oryginalnych częściach podpięty do obecnej maszyny.
-
1. Kod maszyny nigdy nie był dla każdego, odpowiedź jest na tym forum, trzeba tylko zapoznać się z historią MaSzyny.
2. Ekrany dotykowe są stosunkowo nową technologią w monitorach do PC i laptopów. Systemy operacyjne obsługujące tę technologię również powstały dużo później niż MaSzyna. .Jesteś pierwszą osobą która o to pyta. Nie jest priorytetem wykonanie takiej wersji symulatora, uważam że przydatność z tej funkcji jest żadna! Priorytetem jest poprawienie błędów, także wprowadzenie nowych funkcji taboru, także infrastruktury kolejowej.
3. Należałoby skwitować to milczeniem, ale... Od ręki widać, że nie przeczytałeś wątków dotyczących pulpitu. Takie pulpity powstają, mają konkretne rozwiązania i to bardziej zaawansowane, niż to co proponujesz. Pomysł ze sklepem jest nietrafiony kompletnie, miejsca gdzie można zakupić potrzebne elementy, są znane. Budowa struktury dystrybucji tych elementów dodatkowo podniesie ich koszty.
Co sądzę o tym? Jestem przeciwnikiem przystosowania MaSzyny do obsługi ekranów dotykowych, także tworzenia przez Ciebie pulpitu, kto chciałby kupić od Ciebie coś takiego? Sądząc po propozycjach "konceptu" nie będzie to pulpit udany (stara kierownica ze złomu). Kod exe ma taką licencję jaką ma. Jeśli ktoś zasługuje, wykaże się odpowiednią wiedzą zawsze dostaje dostęp do źródeł. Nie ma potrzeby zmieniać licencji.
@marczi-arczi, znów wprowadzasz zamieszanie. Wartość Twojego postu to tylko link gdzie pokazałeś koledze że pulpity i to zaawansowane powstają. Natomiast, to nie jest żadna nowa MaSzyna. Nowy projekt symulatora jest, powstaje w działach niewidocznych na forum dla przeciętnego użytkownika. Nie ma także żadnych materiałów pokazujących działanie nowego elementu.
-
Dobra, rozumiem, ekran dotykowy nie jest faktycznie prioryretem.
Przejrzałem posty o pulpicie. Po pierwsze, są to posty dość stare, oparte na przestarzałych komponentach. (Atmel AT89x? to mówi samo za siebie)... Po drugie, chodzi o to, że te pulpity nie są dostępne dla przeciętnego użytkownika MaSzyny. Po trzecie...
@Krzysiek626 - Nie przeczytałeś chyba dokładnie mojego postu. Napisałem tam, że w środku dajemy enkoder, a nie wiem czym na zewnątrz zakończyć ten "nastawnik".W wielu pulpitach z forum jest jako nastawnik jakaś zabawkowa kierownica, wycofuje pomysł o klawiaturze ze złomu. Myślę, że najlepiej byłoby wydrukować ORYGINALNY model nastawnika na drukarce 3D.
Tak sobie myślę, taki sklep mógłby zacząć działalność razem z wypuszczeniem "nowej MaSzyny", SPT...
-
Do meritum odniosę się w późniejszym czasie, na teraz tylko kilka zdań.
Przejrzałem posty o pulpicie. Po pierwsze, są to posty dość stare, oparte na przestarzałych komponentach. (Atmel AT89x? to mówi samo za siebie)
Mówisz o pulpicie Mariusza? Obecnie puplpity są budowane z układem Pokeys jako wejście–wyjście, mikrokontrolery z reguły pełnią funkcje dodatkowe i nie są konieczne.
Po drugie, chodzi o to, że te pulpity nie są dostępne dla przeciętnego użytkownika MaSzyny.
Nie wiem, czy patrzenia na przeciętnego użytkownika MaSzyny jest dobre. Tylko pełnowymiarowy pulpit jest w stanie zapewnić wystarczające wrażenia. Powstaje pytanie, czy przeciętny użytkownik będzie chciał inwestować trochę pieniędzy i miejsce w domu na taką zabawkę.
W wielu pulpitach z forum jest jako nastawnik jakaś zabawkowa kierownica
Wg moich informacji:
– liczba pulpitów z zabawkową kierownicą — 1,
– liczba pulpitów z rzeczywistym kołem nastawnika (EU07, ET22) — 4 5,
– liczba pulpitów z nastawnikiem w postaci dźwigni (EN57) — 3.
EDYCJA: Okazało się, że ta zabawkowa kierownica już została wymieniona.
Myślę, że najlepiej byłoby wydrukować ORYGINALNY model nastawnika na drukarce 3D.
Chyba prościej, szybciej i taniej będzie jednak kupić kierownicę od żuka. Przykładowo, koło nastawnika w EP09 ma ok. 40 cm średnicy. Osobiście nie do końca widzę drukowanie czegoś tak dużego, ale nie siedzę w tej branży i mogę się mylić.
Tak sobie myślę, taki sklep mógłby zacząć działalność razem z wypuszczeniem "nowej MaSzyny", SPT...
Ostatnia aktywność w temacie SPT wskazuje, że go jednak nie będzie.
-
Z całym szacunkiem, ale myślę, że mierzysz za wysoko.
[...]Po drugie, chodzi o to, że te pulpity nie są dostępne dla przeciętnego użytkownika MaSzyny.[...]
Nie sądzę, żeby przeciętny użytkownik MaSzyny byłby zainteresowany posiadaniem takiego osprzętu. Poza oczywistym aspektem kosztu takiego urządzenia dochodzą jeszcze problemy natury logistycznej i ze znalezieniem miejsca w swoim mieszkaniu. Kto natomiast wyraża chęć posiadania tego typu pulpitu może go skonstruować sam, jak np. pulpit @mechatronika czy w/w symulator w Sosnowcu. Ze strony @Ra, z tego co się orientuję mamy już wsparcie dla PoKeys55/56: http://rainsted.com/pl/Symulator/MaSzyna/Informacje_zwrotne/PoKeys55 (http://rainsted.com/pl/Symulator/MaSzyna/Informacje_zwrotne/PoKeys55). Poza tym powątpiewam w opłacalność konstrukcji. Jednocześnie jednak nalegam do nie zniechęcania się, bo każda para rąk się przyda. Wszystko jest kwestią czasu, a obecnie jesteśmy skupieni raczej na poprawianiu scenerii pod nowe EXE i łatanie innych błędów.
Pozdrawiam!
Edit: @youBy mnie uprzedził. W razie potrzeby proszę na bocznicę.
-
PoKeys to zwykła AtMega z USB właśnie, proponowana przeze mnie, tylko ze specjalnym wsadem...
Ja taki pełnowymiarowy pulpit wyceniam (jak ja bym miał go sprzedawać) na 250 zł.
-
Ad.1. Virtual Bus jest niby GPL, a jakoś nie widać samych korzyści ani ogromu chętnych do poprawiania kodu. Użytkownicy preferują nowszy i komercyjny OMSI. Poza tym, problemem nie jest licencja kodu źródłowego, tylko brak nowych scenerii, czy raczej brak materiałów do ich tworzenia (wymiarowe rozjazdy, wysięgniki, znaki drogowe, modele skrzyżowań dróg, profile pionowe linii kolejowych, modele budynków, tekstury podsypek).
Ad.2. Bo tak wyszło i nikt nie czuje potrzeby, aby to zmieniać. Co do ekranu dotykowego, to faktycznie jesteś pierwszym, który o to pyta. Pomijając już, że trzeba by opracować całą koncepcję sterowania ekranem dotykowym, to obecne działanie kabiny jest mocno uzależnione od klawiatury typu RT i trzeba je wymienić w całości.
Ad.3. Mi nic nie wiadomo o "nowej marce", może masz na myśli symulator dla Kolei Mazowieckich? Obecnie wykonanie pulpitu to jest koszt rzędu 2000 zł. Swego czasu był jeden wystawiony na aukcji z ceną minimalną 3500 zł, ale jakoś chętnych chyba nie było.
-
Ja taki pełnowymiarowy pulpit wyceniam (jak ja bym miał go sprzedawać) na 250 zł.
Proszę napisz co w tym zestawie by się znalazło.
-
"Nowa marka" - SPT, rzekomy następca MaSzyny.
2000 zł? Laminat/pleksa to koszt może 15zł, pstryczki hebelkowe jakieś 0,10gr za pstryczek, woltomierze analogowe jakieś 5zł za jeden, wykonanie PCB w profesjonalnej firmie (nie potrafię sam wytrawiać, zawsze nadtrawiam) to jakieś 35zł. AtMega 8zł. Enkoder(y) 1zł. Diody to w sumie jakieś 2zł. Wychodzi jakieś 110, robocizna 50 zł, zysk 80zł na panelu zostaje na developing maszyny.
@Ra - gdzie Ty tu widzisz 2000 zł ???
-
Łeee to Ty chcesz robić protezy, a nie pulpity do MaSzyny.
-
Możesz rozwinąć myśl?
-
@mechatronik chyba miał na myśli w pełni wymiarowy ze szczegółami wiernie oddający oryginalność pulpit lokomotywy.
-
@szy_mat jeśli Ciebie satysfakcjonowałby taki "pulpit" no to ok. W chwili obecnej podejrzewam, że większości użytkowników to by nie zadowalało. Proponujesz zrobienie płytki z paroma LEDami, kilkoma przełącznikami i badziewnymi miernikami z plastikową wskazówką za 5zł. Ludzie głowią się i troją żeby zdobyć oryginalne części z lokomotywy -zastanów się po co. Nie mówię, że nie znalazłbyś parę osób, które by coś takiego chciały ale jeśli to ma być ta Twoja "nowa marka MaSzyny" to gratuluję. Chcesz tworzyć nową markę to idź w kierunku symulatora w TK w Sosnowcu, a nie takich tworów. Z resztą. Jeśli jesteś przekonany co do projektu to czemu go nie zrealizujesz? Co stoi na przeszkodzie żebyś wykonał taką płytkę z przełącznikami i zobaczył czy jest jakiekolwiek zainteresowanie? To jest góra dzień, dwa pracy. Pozwolenia nie potrzebujesz, a błogosławieństwa raczej nikt tu nie da.
-
Będzie pełnowymiarowy, będzie bardzo szczegółowy - laminat będzie oklejony okleiną drukowaną na mojej drukarce fotograficznej wielkoformatowej. Nastawnik też będzie szczegółowy bo drukowany na drukarce 3D (koszt materiału wliczony w robociznę). Jedyna różnica między prawdziwą lokomotywą będzie taka, że mój pulpit będzie również w wersji z zawiasami, że pulpit będzie można złożyć na 4, że będzie dość komfortowy do przechowywania.
-
No to czekamy z niecierpliwością na prototyp :) Za ile możemy się go spodziewać?
Jedyna różnica między prawdziwą lokomotywą będzie taka, że mój pulpit…
Bardzo śmiałe podejście do tematu :)
-
Dobra, mechatronik:
MÓWIĘ PO RAZ 100 ŻE "NOWA MARKA" TO NIE JEST MOJE OKREŚLENIE NA PULPITY, A PO PROSTU SPT, RZEKOMY NASTĘPCA MASZYNY...
Nie zdobędziesz oryginalnych części z lokomotywy na taką skalę i za taką cenę!
Zrobię model 3D jak taki pulpit by wyglądał w jakimś programie, i pokaże tutaj. Na razie z tego co widzę 99% osób opiera się na jakichś swoich wyobrażeniach...
-
Nie no, niektórzy mają za sobą jakąś tam praktykę w budowie pulpitów.
-
Za jakieś 2h wrzucę model pulpitu "kibelka".
-
@Krzysiek626 - Nie przeczytałeś chyba dokładnie mojego postu. Napisałem tam, że w środku dajemy enkoder, a nie wiem czym na zewnątrz zakończyć ten "nastawnik".W wielu pulpitach z forum jest jako nastawnik jakaś zabawkowa kierownica, wycofuje pomysł o klawiaturze ze złomu. Myślę, że najlepiej byłoby wydrukować ORYGINALNY model nastawnika na drukarce 3D.
Tak sobie myślę, taki sklep mógłby zacząć działalność razem z wypuszczeniem "nowej MaSzyny", SPT...
Nic nie napisałeś, to nie doczytałem. Twój pomysł jest pozbawiony szczegółów, jakieś ogólniki które nie dają żadnego wyobrażenia i szansy rzetelnej oceny. Ja chcę zobaczyć Twój zbudowany pulpit, jego estetykę, funkcjonalność i atrakcyjność. Najpierw niech powstanie SPT, zdaje się nie doczytałeś co @youBy napisał w tej sprawie, dopiero myśl o sklepie. Tak widzę, że chcesz uzyskać informację czy warto pakować się w taki interes. Nie warto, widać to po wszystkich postach w tym wątku i tej wiadomości nie chcesz przyjąć. Twoją rzetelność już widać, z 2 godzin zrobiło się już 8.
-
Już wysyłam wizualizację, miałem problemy z netem. Uzgadniałem szczegóły z Ra. On byłby zainteresowany współpracą, tak samo jak zacząłem dostawać PW o chęci kupna pulpitu. Wszystkich informuję, że dwa pulpity "Kibla" powstaną, bo mam zapewnionych kupców. Zrobię zdjęcia, nakręce filmy jak to działa, i zobaczymy.
Oto prosta wizualizacja 2D panelu, tak na szybko. Wszystkie rzeczy to REAL FOTO części, które mam na warsztacie. Oczywiście wskaźniki zostaną "przekarteczkowane", aby pokazywały właściwą jednostkę (bar, amper), a nie volty. Kontrolki mam na warsztacie, niemalże identyczne jak w oryginalnym kiblu, tu wstawiłem takie "poglądówki". Znalazłem w necie zdjęcie kibli po modernizacji, tam zamiast kwadratowych, dużych kontrolek są po prostu diodki. (hasło "en57 pulpit" w google). Może to jest lepsze wyjście?
Część z hebelkami nie jest tu ujęta. W miejscu amperomierzy "papierowych" są znaki zapytania, nie wiem co tam wstawić aby było w miarę podobne. Aha, przepraszam za "Woltomierz NN" :)
-
2. Czemu MaSzyna jest tylko na przestarzałą architekturę x86? Dlaczego nie jest dostosowana do ekranów dotykowych?
Ja się zastanawiam czemu nikt nie odpowiedział na pierwszą części pytania tylko każdy skupił się na ekranie dotykowym.
Po za tym na twoim miejscu postawił bym jeszcze pytanie " Dlaczego maszyna nie obsługuje wielordzeniowych procesorów?".
-
Wielordzeniówki, zgadza się. To samo z architekturą x86-64. Teraz wszystkie procesory są wielordzeniowe i mają 64 bitową szynę danych. A potem wszyscy narzekają że MaSzyna wolno działa. Wolno działa bo wykorzystuje jakieś 30% mocy przeciętnego procesora... A wersja na ARM to już szczyt marzeń.
-
Nie jesteś pierwszy który narzeka na MaSzyne jaka to ona przestarzała, a w dodatku chcesz sobie urządzać komercje czym jest sprzedaż pulpitów i to moim zdaniem tandetnych... z resztą wole swoją klawiaturę. Ale żebym nie było że kogoś tu karcę za swoje wizję, może się pomylę ale skoro MaSzyna jest projektem nie komercyjnym to niech taki pozostanie, a podczepianie pod to sprzedaży pulpitów czy czegoś innego to przynajmniej moim zdaniem zarabianie na bezpłatnym symulatorze a co za tym idzie zarabianie na czyjejś pracy społecznej dla innych miłośników kolei. Czyli po prostu wiele osób którzy poświęcają swój wolny czas na rozwój MaSzyny bez pobierania jakiś opłat oddają swoją prace również bezpłatnie dla nas wszystkich abyśmy się tym cieszyli nie wydając ani grosza, to ktoś będzie na tym w jakiś sposób zarabiał, nawet jeśli pieniążki miały by iść na rozwój MaSzyny to nie wiem czy by to przyspieszyło pracę nad symulatorem, lepiej niech już będzie MaSzyna niekomercyjna i dostępna dla wszystkich niż nagle miała by się stać mniej dostępna bo nie każdego jest stać na kupno czy też wydatek rzędu 200 - 300 zł za oryginał, dlaczego to napisałem? Uważam że zaczyna się od takiego czegoś a w którymś momencie staje się wszystko komercją łącznie z samym symulatorem, który na obecną chwile jest jednym jeśli nie jedynym symulatorem nie komercyjnym o tak zaawansowanej fizyce jazdy.
-
Po za tym na twoim miejscu postawił bym jeszcze pytanie " Dlaczego maszyna nie obsługuje wielordzeniowych procesorów?".
Zaproponuj, w jakim zakresie ma to działać oraz kwotę wynagrodzenia, jaką przelejesz na moje konto, a ja odpowiem, czy biorę tę robotę, czy nie. Póki nikt nie popiera swoich oczekiwań konkretnymi kwotami i nie ma większych narzekań na wydajność (nie licząc użytkowników kart graficznych firmy Intel® oraz innych kilkuletnich), to ja wolę pracować np. nad rozwojem scenerii realistycznych, czy poprawą zachowania AI, niż żeby ktoś miał 60 FPS zamiast 30. Możesz też sam siebie zapytać, dlaczego jeszcze tego nie zrobiłeś sam, skoro uważasz to za najważniejsze?
skoro MaSzyna jest projektem nie komercyjnym to niech taki pozostanie, a podczepianie pod to sprzedaży pulpitów czy czegoś innego to przynajmniej moim zdaniem zarabianie na bezpłatnym symulatorze a co za tym idzie zarabianie na czyjejś pracy społecznej dla innych miłośników kolei. Czyli po prostu wiele osób którzy poświęcają swój wolny czas na rozwój MaSzyny bez pobierania jakiś opłat oddają swoją prace również bezpłatnie dla nas wszystkich abyśmy się tym cieszyli nie wydając ani grosza, to ktoś będzie na tym w jakiś sposób zarabiał, nawet jeśli pieniążki miały by iść na rozwój MaSzyny to nie wiem czy by to przyspieszyło pracę nad symulatorem, lepiej niech już będzie MaSzyna niekomercyjna i dostępna dla wszystkich niż nagle miała by się stać mniej dostępna bo nie każdego jest stać na kupno czy też wydatek rzędu 200 - 300 zł za oryginał,
Póki co, licencja jest jaka jest, a przez 7 lat mojej obecności na forum nie zauważyłem żadnej inicjatywy, mającej na celu zmianę w tym zakresie (było kilka zapytań o możliwość wydania MaSzyny — zakończyły się odpowiedzią, że skontaktowanie się z wszystkimi autorami w celu uzgodnienia innych warunków licencji jest praktycznie niemożliwe). Oznacza to (na ile rozumiem licencję), że kopie MaSzyny mogą być udostępniane jedynie bezpłatnie. Więc nie wiem, skąd się bierze lament "bo nie każdego jest stać na kupno czy też wydatek rzędu 200 - 300 zł za oryginał" — chyba z nieprzeczytania licencji.
Licencja dotyczy programu w sensie plików i nie reguluje kwestii innych sposobów zarabiania (niż dystrybucja kopii), np. sprzedaży pulpitów, gadżetów, czy zbudowania pulpitu, który będzie następnie odpłatnie udostępniany chętnym. Licencja nie ogranicza też kwestii zlecenia komuś odpłatnego wykonania jakiegoś dzieła, które następnie zostanie dołączone do MaSzyny i będzie rozpowszechniane zgodnie z licencją (czyli bezpłatnie). Jest wiele projektów, przy których ludzie normalnie zarabiają, a mimo to dla użytkowników są one bezpłatne (np. Wikipedia, Linux). Obecna licencja prac nad symulatorem nie przyspiesza. Wręcz przeciwnie, obserwując forum widzę, że wiele osób — po kilku latach zdobywania wiedzy o MaSzynie oraz umiejętności modyfikowania plików — przepada bez wieści.
-
2. Czemu MaSzyna jest tylko na przestarzałą architekturę x86? Dlaczego nie jest dostosowana do ekranów dotykowych?
Ja się zastanawiam czemu nikt nie odpowiedział na pierwszą części pytania tylko każdy skupił się na ekranie dotykowym.
Po za tym na twoim miejscu postawił bym jeszcze pytanie " Dlaczego maszyna nie obsługuje wielordzeniowych procesorów?".
Pisałem, że są ważniejsze priorytety niż zmiana architektury x86. Dodatkowo x86 nadal nie jest w pełni wykorzystana ze względu na brak pełnej optymalizacji modeli, infrastruktury i samego exe. Optymalizacja wyznacza priorytety, odpowiedź padła. Co do obsługi wielu rdzeni, u mnie w czasie symulacji obciążenie procesora rozkłada się na wszystkie rdzenie, pisałem już o tym wiele lat temu. Narzekanie w tym temacie na jakość jest idiotyzmem, SPT miało rozwiązać wszystkie poruszone przez Was zarzuty, nic tylko dołączyć i wspomóc nowy projekt. Odniosę się jeszcze do załącznika mającego przedstawiać pulpit EN 57 - żenada, brak podobieństwa, estetyki. Nie widać ani pomysłu, ani umiejętności i tyle.
-
... to ktoś będzie na tym w jakiś sposób zarabiał, nawet jeśli pieniążki miały by iść na rozwój MaSzyny to nie wiem czy by to przyspieszyło pracę nad symulatorem...
Skoro teraz zasiadam i coś robię, to jakbym dostawał za to pieniądze, to zasiadałbym częściej. To jest chyba logiczne? Jak dla mnie to mógłbym tworzyć MaSzynę do końca życia, jeśli dostawałbym comiesięczną wypłatę, oczywiście nie 1500 zł, bo to żadne pieniądze, zwłaszcza dla osoby która musi nauczyć się programowania, obróbki grafiki, dźwięku i modelowania. Teraz nawet jak chcę tworzyć scenerię realistyczną, to nie mogę, bo muszę iść do pracy.
-
Wielordzeniówki, zgadza się. To samo z architekturą x86-64. Teraz wszystkie procesory są wielordzeniowe i mają 64 bitową szynę danych. A potem wszyscy narzekają że MaSzyna wolno działa. Wolno działa bo wykorzystuje jakieś 30% mocy przeciętnego procesora... A wersja na ARM to już szczyt marzeń.
Żeby jeszcze pomyśleć nad natywnymi 64-bitami to rozumiem. Ale na co Ci MaSzyna działająca na ARMie? Jeżeli ta architektura w ogóle będzie w stanie kiedykolwiek zastąpić x86 w komputerach, to jeszcze bardzo daleka droga do tego, więc po sobie zawracać głowę?
Natomiast co do wolnego działania - w przypadku MaSzyny najwięcej zależy od karty graficznej, nie procesora. Swego czasu miałem komputer na Athlonie 1200 z GeForcem 2 MX 200. Na linii 61 jakieś 8 FPS na stacjach i 15 na szlaku było szczytem wydajności. Po wymianie na GeForce 6200A nagle okazało się, że na stacjach może być 26-28 FPS, a na szlaku nawet 60 przy tym samym procku i karcie graficznej podłączonej pod APG 4x.
W obecnej chwili, mając Phenoma II X4 955 i GeForce GTS 450, nawet na Całkowie (sceneria z najbardziej rozbudowanym otoczeniem) mam rezerwy FPS.
-
Co do obsługi wielu rdzeni, u mnie w czasie symulacji obciążenie procesora rozkłada się na wszystkie rdzenie, pisałem już o tym wiele lat temu.
Ciekawa teoria ale ja ci powiadam że to tylko teoria albo twoje tezy wyssane z palca. Odpalam maszynę na windows 7 procesor amd fx-8350 i jak że inną prawdę od twojej wskazuje menadżer zadań dowody poniżej.
Ra dziękuje za szczerą odpowiedź.
-
Co do obsługi wielu rdzeni, u mnie w czasie symulacji obciążenie procesora rozkłada się na wszystkie rdzenie, pisałem już o tym wiele lat temu.
Ciekawa teoria ale ja ci powiadam że to tylko teoria albo twoje tezy wyssane z palca.
Jakie macie karty graficzne? Z tego co wiem w sterownikach NVIDII jest jakaś opcja równomiernego obciążania procesora, nawet jeżeli program nie został napisany pod obsługę wielu rdzeni. Ja mam GeFroce i rzeczywiście obciąża wszystkie 4 rdzenie, ale jeżeli masz np. Radeona, to ZTCW w sterownikach czegoś takiego tam nie ma.
-
Odsyłam niedowiarków do: http://eu07.pl/forum/index.php/topic,18639.msg212409.html#msg212409
Teraz mam inną kartę, jest GF9600 i nie mam żadnego kłopotu z FPS. Procesor 2 rdzenie intel E6600. Nie wyssałem tego z palca - tak mam, symek obciąża oba rdzenie. Inna sprawa, że od czasu athlona xp2500 (barton, ostatni sensowny procek tej firmy), nie tykam AMD, bo to kit jest i tyle. Tak samo jak ich radeony.
-
Radeon hd7850 2Gb.
Równoważnik należy zakończyć kropką.
Benek
-
Czyli jest tak jak pisałem. Tylko w takim razie pytanie, czy masz problem z płynnością działania? Przy tej karcie graficznej wszystko powinno być w porządku, nawet używając tylko jeden rdzeń procesora.
-
Płynnie działa pomijając fakt że jeden rdzeń mi się gotuje. I raczej będę musiał zainwestować w chłodzenie cieczą bo wiatrak zaczyna tłuc się w niebo głosy.
Fakt uruchamiając symulator na ubuntu przez wine sytuacja wygląda trochę lepiej bo większość rdzeni zaczyna chodzić ale wydajność raczej spada. Jedno ale gdyby każdy kto chciałby wykorzystać wielordzeniowca musiał instalować linuxa a później uruchamiać symulator przez niego to chyba coś nie teges oczywiście ubuntu osobiście używam i sobie chwale.
-
Nawet jeśli na jednym rdzeniu procek się gotuje, oznacza to źle nałożoną pastę pod radiator z wentylatorem. Procesor wykorzystany nawet w 100%, nie ma prawa przekroczyć dozwolonej temperatury i gotować się. Temat przerabiałem i nie jest z tym łatwo.
Zboczyliśmy z tematu.
-
Ad.1. Virtual Bus jest niby GPL, a jakoś nie widać samych korzyści ani ogromu chętnych do poprawiania kodu. Użytkownicy preferują nowszy i komercyjny OMSI. Poza tym, problemem nie jest licencja kodu źródłowego, tylko brak nowych scenerii, czy raczej brak materiałów do ich tworzenia (wymiarowe rozjazdy, wysięgniki, znaki drogowe, modele skrzyżowań dróg, profile pionowe linii kolejowych, modele budynków, tekstury podsypek).
Gdyby symulator oferował cokolwiek twórcom dodatków toby tacy się pojawiali. Niestety zazwyczaj ci zainteresowani tworzeniem realistycznych modeli/scenerii zdecydowanie bardziej sobie cenią realistyczną grafikę i wygodne narzędzia niż realizm jazdy, co łatwo zrozumieć bo tworząc dodatki to 90% czasu spędza się na oglądaniu i testowaniu a na jazdę nie ma już czasu.
Jakiś czas temu sam chciałem zrobić symulator kolejowy, który miał zapewniać min. użycie danych z najpopularniejszych gier tego typu,
Usunąłem grafikę.
ale porzuciłem ten projekt bo właśnie dzisiaj jak nie zrobisz niesamowitej grafiki czy rozbudowanych narzędzi to nikogo nie zainteresujesz.
Co do źródeł maszyny to dostałem kiedyś jakieś na GPL v2, w dodatku nie problem znaleźć je na necie. Więc jak to jest z tą licencją?
Reg. obowiązki 2.
Proszę wstawić grafikę jako załącznik.
Benek
-
Gdyby symulator oferował cokolwiek twórcom dodatków toby tacy się pojawiali. Niestety zazwyczaj ci zainteresowani tworzeniem realistycznych modeli/scenerii zdecydowanie bardziej sobie cenią realistyczną grafikę i wygodne narzędzia niż realizm jazdy, co łatwo zrozumieć bo tworząc dodatki to 90% czasu spędza się na oglądaniu i testowaniu a na jazdę nie ma już czasu.
To ja bym nie chciał, by tacy twórcy tu przychodzili. Co to za deweloper, który stawia tylko na fajny wygląd? Właśnie tym się wyróżnia MaSzyna od pozostałych projektów, że najpierw stawia się na realizm, a potem dopracowuje się wygląd. Poza tym zauważ, że prawdziwych miłośników kolei, którzy mają wiedzę techniczną o taborze i infrastrukturze jest niewielu. A spróbować wyłonić z nich dobrych informatyków, którzy mają czas, by poświęcać go na MaSzynę, to już jest wyczyn.
ale porzuciłem ten projekt bo właśnie dzisiaj jak nie zrobisz niesamowitej grafiki czy rozbudowanych narzędzi to nikogo nie zainteresujesz.
Nie zainteresujesz dzieciaków, ale użytkowników, którzy wiedzą co dobre. Oczywiście tych drugich jest mniej, ale jeśli cierpliwie będzie się tworzyć ten projekt, to w końcu dojdzie się i do ulepszania grafiki.
Ja swego czasu zapytałem Ra, co trzeba zrobić, by zaimplementować wreszcie tekstury przejściowe w MaSzynie. Odpisał, że trzeba przygotować paczkę tekstur, wybrać jednostkową komórkę i spojrzeć do literatury, jak ten model powinien działać. Po prostu jak Ci zależy, to zacznij coś robić, a nie wynajdować koło od nowa. Ra spędził kilka lat nad MaSzyną i najrozsądniejszym krokiem jest dołączenie do niego. Jeśli stwierdzisz, że coś zrobił niepoprawnie, a Ty zaproponujesz lepsze rozwiązanie i je uzasadnisz, to wiem, że zostanie to zmienione w exe. Od samego biadolenia nic się nie zmieni.
Co do źródeł maszyny to dostałem kiedyś jakieś na GPL v2, w dodatku nie problem znaleźć je na necie. Więc jak to jest z tą licencją?
Jak nie problem, to znaczy, że licencja działa. Zapewne się pomyliłeś i chodziło Ci, że nie ma źródeł. Exe jest na bieżąco udoskonalane, więc nie dziwię się, że Ra co chwilę nie wypuszcza źródeł. Szkoda jego czasu.
-
To ja bym nie chciał, by tacy twórcy tu przychodzili. Co to za deweloper, który stawia tylko na fajny wygląd? Właśnie tym się wyróżnia MaSzyna od pozostałych projektów, że najpierw stawia się na realizm, a potem dopracowuje się wygląd.
Podstawowa zasada jest taka, że jest podział zadań. Ktoś robi realistycznie wyglądające scenerie, kto inny kodzi symulacje. Nie da się znaleźć ludzi od wszystkiego na raz :)
-
Ktoś robi realistycznie wyglądające scenerie, kto inny kodzi symulacje.
Ja zacząłem od robienia realistycznych scenerii. Okazało się, że jest (między innymi) problem z tym, żeby scenerie były zgodne z mapą (błędy dochodziły do 5km). Zacząłem więc robić własny edytor, którym mogłem ustawiać tory z dokładnością do kilkunastu metrów (na początku, teraz to jest 0.1m). Po 3 latach pracy nad edytorem okazało się, że MaSzyna nie daje rady sceneriom eksportowanym z edytora, między innymi są problemy z AI, czasem wczytywania scenerii oraz wydajnością przy dużej liczbie trójkątów terenu. Ograniczyłem rozwój edytora i przez kolejne 3 lata poprawiałem kod MaSzyny, aby usunąć błędy i dostosować do możliwości edytora. Po drodze również programowałem mikrokontroler do pulpitu i zrobiłem komunikację z PoKeys, bo z elektroniką mikroprocesorową też sobie dobrze radzę. W fizykę symulacji też się zagłębiałem, aczkolwiek skoro ktoś ma spore doświadczenie w termodynamice, to ja nie czuję potrzeby się angażować w hamulce czy silniki spalinowe (za to zrobiłem spadki napięć na sieci trakcyjnej). Oczywiście zamiast tego mógłbym się zająć jedynie usprawnianiem silnika graficznego, być może coś by wyglądało ładniej. Ale biorąc pod uwagę, że generatorów ładnie wyglądających widoczków jest dość dużo (np. Outerra (http://www.outerra.com/)), to pewnie znajdą się ludzie, którzy będą potrafili zrobić grafikę lepiej niż ja. Staram się robić to, czego nikt inny nie chce. Wracając do realistycznych scenerii, to teraz byłbym już w stanie modelować średnio jedną stację miesięcznie (do stanu surowego, czyli wykorzystując wyłącznie dostępne obiekty, bez robienia np. charakterystycznych modeli z indywidualnymi teksturami, czy zastanawiania się, jak by należało zrealizować przejazd pod skosem).
Co do źródeł MaSzyny, to ostatnio znalazłem wersję wywieszoną publicznie przez kolegę Q. Jest to wersja z 2005 roku, być może też są jakieś jego późniejsze modyfikacje. W kodzie jest informacja o GPL, ale są to martwe zapisy, jako że nigdy kod źródłowy nie był dołączany do wersji wykonywalnej.
Jeśli masz gotowe rozwiązania, jak należy konstruować grafikę, aby wyglądała ona realistycznie(j), to ja jestem zainteresowany wdrożeniem. Silnik graficzny MaSzyny jest jaki jest i w krótkim czasie (bez nakładu pracy) nie będzie diametralnie inny. Jeśli będzie ktoś chętny do dostosowania jakiegoś gotowego silnika graficznego (np. OSG (http://www.openscenegraph.org/)), to moim zdaniem optymalna jest architektura klient-serwer. Czyli symulacja będzie udostępniać pakiety danych, na podstawie których osobny program będzie tworzył wizualizację.
-
Co do źródeł MaSzyny, to ostatnio znalazłem wersję wywieszoną publicznie przez kolegę Q. Jest to wersja z 2005 roku, być może też są jakieś jego późniejsze modyfikacje. W kodzie jest informacja o GPL, ale są to martwe zapisy, jako że nigdy kod źródłowy nie był dołączany do wersji wykonywalnej.
Dołączanie kodu nie jest wymogiem GPL, można go w ogóle nigdy nie dołączać. GPL wymaga jedynie tego, żeby na życzenie udostępnić kod bez żadnych dodatkowych warunków, oczywiście na licencji GPL. Do ważności GPL wystarczy że raz upubliczniony zostanie skompilowany plik wykonywalny (w przypadku AGPL dla ważności licencji wystarczy już udostępnienie wyniku pracy programu).
Jedyny sposób aby pozbyć się GPL to zgoda wszystkich dotychczasowych autorów na wydanie kodu na innej licencji na której kod będzie dalej rozwijany lub pozbycie się kodu tych którzy się na to nie zgadzają. Chyba, że kod od początku rozwijany był na dwóch licencjach wtedy problemu nie ma. Ale chyba żadna z tych sytuacji nie miała tutaj miejsca?
Jeśli będzie ktoś chętny do dostosowania jakiegoś gotowego silnika graficznego (np. OSG), to moim zdaniem optymalna jest architektura klient-serwer. Czyli symulacja będzie udostępniać pakiety danych, na podstawie których osobny program będzie tworzył wizualizację.
Osobny program do wizualizacji jest bez sensu ze względów wydajnościowych i praktycznych. Pomijając to że do renderowania dobrej grafiki potrzebna jest odpowiednia struktura danych (kanał alpha w maszynie działa? :) ), to jeśli chcemy tworzyć scenerie na setki kilometrów i miliony obiektów to musi być odpowiednio zrobione zarządzanie danymi w całej aplikacji.
Możliwa jest opcja w drugą stronę: serwer symulacji poszczególnych obiektów.
Ja może byłbym chętny coś zrobić, ale właśnie jakby kod był dostępny to może po cichu bym coś tam podłubał a tak nie chcę obiecywać gruszek na wierzbie devom by dostać dostęp a ostatecznie stwierdzić ze nic się nie udało. Bo chociaż zrobiłem silnik graficzny który pod wieloma względami znacznie przewyższa maszynę (nieskończonych rozmiarów scenerie, nieskończona liczba obiektów, lod, działa na linuksach i wszędzie, wielowątkowy, wczytywanie scenerii czas 1s, itp), to wygląda równie ohydnie, no może poza tym że alpha wyświetla się 10x poprawniej :) Nie jest to proste zagadnienie.
biorąc pod uwagę, że generatorów ładnie wyglądających widoczków jest dość dużo (np. Outerra)
Żadne w miarę darmowe nie nadają się do szczegółowej symulacji bardzo dużych scenerii.
Wracając do realistycznych scenerii, to teraz byłbym już w stanie modelować średnio jedną stację miesięcznie (do stanu surowego, czyli wykorzystując wyłącznie dostępne obiekty, bez robienia np. charakterystycznych modeli z indywidualnymi teksturami, czy zastanawiania się, jak by należało zrealizować przejazd pod skosem).
No właśnie, i to nie są niestety realistyczne scenerie a realistyczne wizualizacje układów torowych :) W konkurencyjnych narzędziach w miesiąc niedoświadczony użytkownik zamodeluje cały szlak i tu nie ma porównania do jednej stacji w miesiąc przez najbardziej doświadczonego użytkownika.
-
GPL wymaga jedynie tego, żeby na życzenie udostępnić kod bez żadnych dodatkowych warunków, oczywiście na licencji GPL.
O ile wiem, to tak nigdy nie było. Przykład:
http://eu07.pl/forum/index.php/topic,6339.msg63946.html#msg63946
Osobny program do wizualizacji jest bez sensu ze względów wydajnościowych i praktycznych.
Mam odrębne zdanie. Jeśli będzie symulacja, do której będzie podłączonych wielu użytkowników, do tego dyżurny, czy chociażby podgląd z lusterek na osobnym komputerze, to inaczej się tego zrobić nie da.
jeśli chcemy tworzyć scenerie na setki kilometrów i miliony obiektów to musi być odpowiednio zrobione zarządzanie danymi w całej aplikacji.
Też się nie zgadzam. Nie ma sensu wczytywać i wykonywać symulacji na ogromnym obszarze, można to podzielić na komórki o wielkości kilkunastu kilometrów i obsługiwać tylko te potrzebne. Gdyby jednak było to za dużo na jeden komputer, to można każdą komórkę symulować na osobnym serwerze. Wtedy może być dowolna liczba użytkowników, którzy się będą podłączali do kilku osobnych serwerów, zależnie od tego, gdzie będą się znajdować.
Ja może byłbym chętny coś zrobić, ale właśnie jakby kod był dostępny to może po cichu bym coś tam podłubał a tak nie chcę obiecywać gruszek na wierzbie devom by dostać dostęp a ostatecznie stwierdzić ze nic się nie udało.
Wielu ludzi sobie po cichu dłubało, a od niektórych wydłubanych rzeczy włos się jeży na głowie (np. fragmenty fizyki umieszczone w wyświetlaniu, przez co pojazd renderowany zachowuje się inaczej niż niewyświetlany). Na ile się orientuję, to w kodzie nadal jest niezły syf, nawet pomimo 3 lat mojego sprzątania. Tyle, że się teraz prawie nie sypie, a niedokończone koncepcje zostały naprawione. Jednak w wielu miejscach brakuje elegancji czy nawet sensowności rozwiązań i wstyd by to było pokazywać wszystkim. Z drugiej strony, poprawianie tego wymaga czasu, a nawet syfiasty kod, który działa, ma zasadniczą przewagę nad kodem, który nie działa (albo którego jeszcze nie ma). Dość powiedzieć, że integracja trzech linii rozwojowych (tzw. baterie i SPKS) wraz z przerobieniem działania pantografów trwa już 18 miesięcy, a rezultat jeszcze nie jest zadowalający.
alpha wyświetla się 10x poprawniej :)
Co dokładnie masz na myśli?
Dodano: 06 Czerwca 2014, 19:49:46
W konkurencyjnych narzędziach w miesiąc niedoświadczony użytkownik zamodeluje cały szlak i tu nie ma porównania do jednej stacji w miesiąc przez najbardziej doświadczonego użytkownika.
Niedoświadczony użytkownik nie ma pojęcia o krzywych przejściowych, profilach i łukach pionowych, zasadach ustalania rozstawu torów, odcinkach izolowanych, nie mówiąc o budowie sieci trakcyjnej czy wielu innych rzeczach. Skoro te konkurencyjne narzędzia są takie wspaniałe, to może skupić się na masowym konwertowaniu do MaSzyny tego ogromu scenerii, wykonanych przez niedoświadczonych użytkowników za pomocą konkurencyjnych narzędzi?
-
Mam odrębne zdanie. Jeśli będzie symulacja, do której będzie podłączonych wielu użytkowników, do tego dyżurny, czy chociażby podgląd z lusterek na osobnym komputerze, to inaczej się tego zrobić nie da.
No czyli serwer symulacji + klienty które robią całą resztę a nie serwer co robi wszystko + klienty co tylko wyświetlają.
Da się zrobić też inaczej, czyli tak jak wszyscy to robią zazwyczaj - wymiana danych pomiędzy oddzielnie uruchomionymi symulacjami.
Też się nie zgadzam. Nie ma sensu wczytywać i wykonywać symulacji na ogromnym obszarze, można to podzielić na komórki o wielkości kilkunastu kilometrów i obsługiwać tylko te potrzebne.
Ale ja właśnie napisałem, ze niezbędny jest podział symulacji a nie tylko silnika graficznego więc tu się zgadzamy. Tylko podział kilometrowy symulacji jest wyjątkowo niepraktyczny. Tylko i wyłącznie logiczny na poszczególne obiekty.
Wielu ludzi sobie po cichu dłubało, a od niektórych wydłubanych rzeczy włos się jeży na głowie.
No takie rzeczy wymagają zatwierdzenia przed dołączeniem do głównego kodu.
Jednak w wielu miejscach brakuje elegancji czy nawet sensowności rozwiązań i wstyd by to było pokazywać wszystkim. Z drugiej strony, poprawianie tego wymaga czasu, a nawet syfiasty kod, który działa, ma zasadniczą przewagę nad kodem, który nie działa (albo którego jeszcze nie ma).
To rozumiem, z tego samego powodu sam nie lobię udostępniać kodu. Fajne rzeczy robią zdecydowanie większe wrażenie dopóki nie widzi się jak zostały zrobione.
alpha wyświetla się 10x poprawniej :)
Co dokładnie masz na myśli?
No przez długi czas alpha była w ogóle w maszynie zakazana bo nic nie było widać przez tekstury. Widziałem że duże poprawki wprowadziłeś w tej kwestii ale nadal nie działa to jak powinno?
Niedoświadczony użytkownik nie ma pojęcia o krzywych przejściowych, profilach i łukach pionowych, zasadach ustalania rozstawu torów, odcinkach izolowanych, nie mówiąc o budowie sieci trakcyjnej czy wielu innych rzeczach.
Profile łuków mogą się robić automatycznie. Reszta to jest problem dla niedoświadczonego użytkownika no ale w praktyce takie rzeczy robi się w kilka osób.
Skoro te konkurencyjne narzędzia są takie wspaniałe, to może skupić się na masowym konwertowaniu do MaSzyny tego ogromu scenerii, wykonanych przez niedoświadczonych użytkowników za pomocą konkurencyjnych narzędzi?
Myślałem o tym. Ale właśnie Maszyna w życiu nie uciągnie takiej trasy jak Warszawa - Kraków. Ile czasu by w ogóle trwało wczytanie 4 GB skompresowanych danych? Robi takie rzeczy Maszyna dynamicznie? Bo oczywiście po zdekompresowaniu trzeba by mieć z 16 GB RAM aby wszystko pomieścić więc wczytywanie jednorazowe odpada.
Zacząłem więc robić własny edytor, którym mogłem ustawiać tory z dokładnością do kilkunastu metrów (na początku, teraz to jest 0.1m).
Wiesz, że dokładność z mapą 0.1m nie ma nic wspólnego z rzeczywistością ze względu na projekcje mapy i krzywiznę Ziemi. Ma się wybór albo dokładnie z projektem ale nijak nie będzie to pasować do mapy w nawet średnich sceneriach, albo dokładnie z mapą ale nie będzie pasować w rzeczywisty projekt.
Oczywiście nie ma się co tym przejmować, wg. mnie zdecydowanie lepiej robić z mapą i pogodzić się z tym że łuki mają r=1010m zamiast 1000m czy prosta ma 1010m zamiast 1000 m a w zamian mieć nieocenioną pomoc w postaci zdjęć satelitarnych i możliwość robienia wielkich scenerii. Ale na pewno nie jest to dokładność 0.1 m :)
-
No czyli serwer symulacji + klienty które robią całą resztę a nie serwer co robi wszystko + klienty co tylko wyświetlają.
No tak, klient ma dostawać głównie informacje o aktualnym stanie obiektów. Ewentualnie, jeśli przełączasz przełącznik w kabinie, to on może być animowany lokalnie, zanim jeszcze informacja o zmianie stanu trafi do serwera.
Da się zrobić też inaczej, czyli tak jak wszyscy to robią zazwyczaj - wymiana danych pomiędzy oddzielnie uruchomionymi symulacjami.
Teoretycznie też by tak można. Ale to wymaga zintegrowania symulacji z wizualizacją, a obecnie bardziej prawdopodobnym scenariuszem jest rozwód (tzn. pozostawienie szczątkowej grafiki na obecnym poziomie).
Tylko podział kilometrowy symulacji jest wyjątkowo niepraktyczny. Tylko i wyłącznie logiczny na poszczególne obiekty.
Tylko po co symulować Kraków, jeśli wszyscy użytkownicy znajdują się pod Warszawą? Podział geograficzny umożliwi również uruchamianie symulacji na rozproszonych serwerach. Chyba że coś innego rozumiesz przez obiekty.
No takie rzeczy wymagają zatwierdzenia przed dołączeniem do głównego kodu.
Tylko kto by miał to robić? Ja ogarniam ok. 70% kodu i jeśli np. youBy zmienia coś w hamulcach, to ja na dobrą sprawę nie wiem, co zrobił i dlaczego właśnie tak. Jeśli np. ktoś dorzuci do kodu obsługę Pythona albo shaderów, to ja nie jestem w stanie tego zweryfikować, zwłaszcza gdy aktualnie przerabiam całkiem inną część i staram się zachować ciągłość poprawności działania. Dobra praktyka mówi, że albo zmieniasz i testujesz jedną rzecz na raz, albo tracisz jakikolwiek wpływ na to, co się dzieje.
No przez długi czas alpha była w ogóle w maszynie zakazana bo nic nie było widać przez tekstury. Widziałem że duże poprawki wprowadziłeś w tej kwestii ale nadal nie działa to jak powinno?
Nie wiem, być może się nie znam. Moim zdaniem wypadało by jeszcze zrobić sortowanie obiektów względem odległości od kamery. Na razie są zastosowane pewne półśrodki i jesteśmy na etapie dostosowania modeli. Powstały już pierwsze modele z wnętrzem widocznym z zewnątrz.
Profile łuków mogą się robić automatycznie. Reszta to jest problem dla niedoświadczonego użytkownika no ale w praktyce takie rzeczy robi się w kilka osób.
Żeby coś się robiło automatycznie, to wcześniej ktoś musi opracować algorytm. Chociażby w przypadku przechyłki na łuku, są wzory na jej skrajne wartości, ale jej wybór zależy np. od kategorii linii, natężenia i typu przewozów (pasażerskie, towarowe, czy mieszane). Dopuszczalne są też wyjątki, uzależnione od warunków miejscowych. Niedoświadczony użytkownik być może zrobi, ale nie będzie umiał ocenić, czy zrobił dobrze. W praktyce do MaSzyny daną scenerię robi jedna osoba i zwykle nie jest inżynierem budownictwa kolejowego.
Myślałem o tym. Ale właśnie Maszyna w życiu nie uciągnie takiej trasy jak Warszawa - Kraków. Ile czasu by w ogóle trwało wczytanie 4 GB skompresowanych danych? Robi takie rzeczy Maszyna dynamicznie? Bo oczywiście po zdekompresowaniu trzeba mieć z 16 GB RAM aby wszystko pomieścić więc wczytywanie jednorazowe odpada.
Dlatego ja od 6 lat pracuję nad podziałem scenerii na komórki, żeby nie wczytywać wszystkiego jednorazowo. Na razie udało mi się utworzyć dwie funkcjonalne komórki (mają poprawne układy torowe i zdefiniowane przebiegi, przy czym nie są idealnie płaskie). Trzeba by teraz odejść od formatu tekstowego na rzecz binarnego (aby nie czekać na wczytanie) i doprowadzić do tego, aby komórka mogła być wczytana i usunięta z pamięci w razie potrzeby.
Mnie interesuje to, co można by na teraz zrobić lepiej. Wiadomo, że nie zrobi się wszystkiego od razu.
Dodano: 06 Czerwca 2014, 21:47:03
Wiesz, że dokładność z mapą 0.1m nie ma nic wspólnego z rzeczywistością ze względu na projekcje mapy i krzywiznę Ziemi.
Mam na myśli ortofotomapy. Obecnie używam tych z Geoportalu, o rozdzielczości 4px/m (czasem mniej). Dostępne są też ortofotomapy niektórych gmin o rozdzielczości 20px/m (ale mają inny układ współrzędnych). Nawet na tych z Geoportalu przesunięcie toru o te 10cm robi widoczną różnicę (tzn. bez żadnego problemu da się odróżnić rozstaw torów 4.75m od 5m). Zwłaszcza dotyczy to obiektów "długich i prostych", bo precyzja wstawienia latarni jest rzędu 0.5m. Oczywiście same ortofotomapy mają własną niedokładność, której wartość nawet trudno oszacować, szczególnie jeśli się nic nie mierzy w terenie.
-
Tylko po co symulować Kraków, jeśli wszyscy użytkownicy znajdują się pod Warszawą? Podział geograficzny umożliwi również uruchamianie symulacji na rozproszonych serwerach. Chyba że coś innego rozumiesz przez obiekty.
Oczywiście obiektów znajdujących się poza zasięgiem symulacji nie wczytujemy w ogóle. Podział danych scenerii można robić jak najbardziej kilometrowo, właściwie jest to jedyne praktyczne rozwiązanie. Ja pisałem o danych symulacji: składy itp.
Dlatego ja od 6 lat pracuję nad podziałem scenerii na komórki, żeby nie wczytywać wszystkiego jednorazowo. Na razie udało mi się utworzyć dwie funkcjonalne komórki (mają poprawne układy torowe i zdefiniowane przebiegi, przy czym nie są idealnie płaskie). Trzeba by teraz odejść od formatu tekstowego na rzecz binarnego (aby nie czekać na wczytanie) i doprowadzić do tego, aby komórka mogła być wczytana i usunięta z pamięci w razie potrzeby.
Mnie dziwi wolne wczytywanie danych tekstowych w MaSzynie. Z moich doświadczeń w C++ nie ma takiej tragedii między tekstem a binarną. W Javie jest różnica, dlatego zrobiłem wczytywanie wielowątkowe. Swój silnik oparłem na dane z msts i tam jest w użyciu bardzo dużo danych tekstowych np: http://koniec.org/trainsim/ts/routes/bbb/world/w-005308+014961.w
-
Mnie dziwi wolne wczytywanie danych tekstowych w MaSzynie. Z moich doświadczeń w C++ nie ma takiej tragedii między tekstem a binarną.
Hm, chyba coś w tym jest. W pewnym momencie pojawiły się uwagi, że się scenerie wolniej wczytują niż wcześniej. Ponieważ z pierwszej ankiety wyszło, że tematem najbardziej wymagającym poprawienia jest wolne wczytywanie, zrobiłem binarny zapis modeli do plików E3D. Normalnie wczytywały się one z tekstowych T3D, po czym były liczone wektory normalne. Mimo iż zoptymalizowałem liczenie wektorów normalnych, to i tak czas wczytania E3D jest znikomy w porównaniu do T3D, a do tego pliki E3D są na ogół mniejsze (można by jeszcze zrobić indeksowanie wierzchołków i były by jeszcze mniejsze o 40%).
Przy ostatniej ankiecie nikt nie podnosił kwestii prędkości wczytywania, więc prawie w ogóle się nią nie zajmowałem (usunąłem tylko przecinki z listy separatorów — były używane raptem w trzech plikach). Obecnie najczęściej wskazywanym brakiem jest zapis stanu symulacji — jeśli będę coś robił, to raczej albo zapis struktur wewnętrznych z perspektywą natychmiastowego wczytania albo wczytywanie z plików RSF, co powinno też dać możliwość podglądu 3D z edytora 2D. Jednak podstawowy do rozwiązania pozostaje temat doczytywania komórek i pozbywania się ich z pamięci — trzeba mieć to wszystko razem na uwadze. Gdy będzie już dobrze działająca koncepcja zarządzania pamięcią, będzie można to przerobić na wątki, bo testowania nie ułatwią.
-
Ponieważ z pierwszej ankiety wyszło, że tematem najbardziej wymagającym poprawienia jest wolne wczytywanie, zrobiłem binarny zapis modeli do plików E3D. Normalnie wczytywały się one z tekstowych T3D, po czym były liczone wektory normalne. Mimo iż zoptymalizowałem liczenie wektorów normalnych, to i tak czas wczytania E3D jest znikomy w porównaniu do T3D, a do tego pliki E3D są na ogół mniejsze (można by jeszcze zrobić indeksowanie wierzchołków i były by jeszcze mniejsze o 40%).
W e3d normalne są już policzone? Mi się zawsze liczenie normalnych wydawało b. długie aby to robić za każdym razem od nowa.
Jednak podstawowy do rozwiązania pozostaje temat doczytywania komórek i pozbywania się ich z pamięci — trzeba mieć to wszystko razem na uwadze. Gdy będzie już dobrze działająca koncepcja zarządzania pamięcią, będzie można to przerobić na wątki, bo testowania nie ułatwią.
Wg mnie format scenerii powinien być podzielony na regiony tak jak to jest np: tutaj i problem co wczytywać i co usuwać z głowy.
http://koniec.org/trainsim/ts/routes/cmk/world/
Tam jest to tak zrobione że tylko dane nie biorące udziału w symulacji są podzielone. Wszystkie dane interaktywne są razem dzięki czemu z głowy problem integralności symulacji.
A najwięcej zasobów właśnie zajmują te nieistotne dane: modele, tekstury, teren itp.
-
W E3D normalne są policzone, ich liczenie było szczególnie uciążliwe powyżej 5000 trójkątów. Ostatnio dorobiłem też możliwość podawania normalnych w T3D, ale wątpię, żeby się to cieszyło dużą popularnością.
To wygląda jak zorganizowane w kwadraty kilometrowe. Moim zdaniem zbyt drobny podział w sensie ogólnym (chociaż do terenu właśnie taki zastosowałem, np. do zapisu terenu w E3D). Poza torami i terenem dochodzą takie rzeczy jak logika sterująca stacjami (definicje przebiegów obejmują całą stację), więc mi bardziej odpowiadają obszary funkcjonalne o średnicy 8÷16km. Ponadto, póki nie ma automatu wczytującego w miarę potrzeby, łatwiej jest zbudować scenerię z części, gdy potrzeba ich kilka(naście) niż kilkaset.
-
To wygląda jak zorganizowane w kwadraty kilometrowe. Moim zdaniem zbyt drobny podział w sensie ogólnym (chociaż do terenu właśnie taki zastosowałem, np. do zapisu terenu w E3D).
Dokładnie tak jest, podział 2048 x 2048 m. Wg mnie drobny podział obiektów statycznych i terenu jest bardzo dobry jeśli chcemy mieć setki/tysiące obiektów na km. Oczywiście nie może być z kolei za mały bo to też jest jakiś narzut na wydajność.
Poza torami i terenem dochodzą takie rzeczy jak logika sterująca stacjami (definicje przebiegów obejmują całą stację), więc mi bardziej odpowiadają obszary funkcjonalne o średnicy 8÷16km. Ponadto, póki nie ma automatu wczytującego w miarę potrzeby, łatwiej jest zbudować scenerię z części, gdy potrzeba ich kilka(naście) niż kilkaset.
Wg mnie bez sensu dzielić takie rzeczy bo raczej chcemy by w całej scenerii się coś działo, więc i tak wszystko powinno być wczytane co bierze udział w symulacji. Poza tym co jak ci stacja wypadnie na skraju kilku obszarów? Druga rzecz to prawda, ale po to się robi te rzeczy by było doczytywanie.
-
Poza tym co jak ci stacja wypadnie na skraju kilku obszarów?
Nie wypadnie. Po pierwsze, granica obszaru ma być przyjmowana dowolnie, to nie będzie ścisła siatka. Po drugie, Tarnowskie Góry mają z 8 km, więc każda stacja w Polsce zmieści się na w ramach jednego obszaru.
-
Granice obszarów ustalam ręcznie, w miarę potrzeby i sensu. Takie było pierwotne założenie. Na razie nie ma automatu i na razie jestem jedynym, który dzieli duże scenerie na osobne pliki (obszarowo). Co z tego wyjdzie, to trudno powiedzieć. Niektóre koncepcje sprawdzają się w praktyce, inne po kilku testach trzeba wymyślić na nowo. Jak na razie moja koncepcja zapisu modeli do E3D się sprawdza dobrze, zapis scenerii w RSF też wytrzymuje próbę czasu. Ale czy koncepcja komórek się utrzyma w takim kształcie, to jeszcze za wcześnie oceniać. Jednak od czegoś trzeba zacząć, biorąc za podstawę to, że dysponuję działającą MaSzyną taką, jaka jest teraz, a na robienie czegoś zupełnie od zera nie mam ambicji.
Jakbym miał trochę więcej luźnego czasu, to bym próbował wczytać podane przez Ciebie pliki do edytora w Rainsted... Ale muszę to odłożyć na później.