Programista, pomysł na nowy brand... WAŻNE

[janek32]

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.

[Krzysiek626]

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.

[pkp.]

Radeon hd7850 2Gb.

Równoważnik należy zakończyć kropką.
Benek

[janek32]

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.

[pkp.]

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.

[Krzysiek626]

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.

[piotrek-]

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

[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.

[piotrek-]

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 :)

[Ra]

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), 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), 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ę.

[piotrek-]

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.

[Ra]

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?

[piotrek-]

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 :)

[Ra]

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.

[piotrek-]

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

[Ra]

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ą.

[piotrek-]

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.

[Ra]

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.

[piotrek-]

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.

[youBy]

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.

[Ra]

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.