Standardy tworzenia dodatków

Źródło: tutaj.

Aktualizacja 12.08.2024: Usunięto wymóg wstawiania klauzuli //script;size w plikach .inc modeli statycznych.

Pliki

Wszystkie pliki muszą pasować do obecnie przyjętej struktury katalogowej na repozytorium. Niedozwolone jest tworzenie nowych zbędnych folderów i umieszczanie plików w innym miejscu niż starsze podobnego typu.

Struktura jest mocno niejasna. Wiele plików podobnych typów znajduje się w różnych miejscach. Dlatego póki co nie można ściśle określić co gdzie należy wsadzić. Pewnym wzorcem może być lista umieszczona poniżej poniżej.W razie wątpliwości należy skonsultować się z Wydziałem Repozytorium.

   • Elektryczne – elementy energetyki komunalnej, przemysłowej, sieci przesyłowych. Słupy oświetleniowe.
   • Eng – obiekty inżynieryjne. Mosty, wiadukty, przepusty.
   • Kolejowe – inne kolejowe, nie do zakwalifikowania precyzyjniej.
   • Miejskie – obiekty użyteczności publicznej i detale do krajobrazu miejskiego.
   • Mieszkalne – wszelka zabudowa mieszkaniowa.
   • Nastawnie – nastawnie i inne posterunki PKP.
   • Peronowe – ławki, wiaty, tablice z rozkładami. Do dekorowania peronów.
   • Pkp – wskaźniki z sieci PKP.
   • Plants – roślinność.
   • Pojazdy – pojazdy statyczne. Koparki, dźwigi i.t.p.
   • Posers – ludzie.
   • Przejazdy – elementy przejazdów kolejowych.
   • Przemysl – elementy zakładów przemysłowych, taśmociągi, rury ciepłownicze.
   • Przytorowe – elementy ze szlaków kolejowych. Słupki hektometrowe, rezonatory, czujniki, szafy sterujące automatyką.
   • Stacje – budynki dworców.
   • Tr/tra/trakcja – sieć trakcyjna.
   • Wiejskie – zabudowa gospodarcza, detale polne.

Przykładami złej struktury w obecnej paczce to foldery: otoczenie\budynki, \ip i \szlakowe.

Pliki z nowych paczek nie mogą nadpisywać starszych (wydanych wcześniej) plików. W szczególnych przypadkach, gdy nadpisanie plików jest konieczne należy zapewnić kompatybilność wsteczną.

Nienadpisywanie plików mam nadzieję jest zrozumiałe. Za przykład zachowania kompatybilności wstecznej może posłużyć plik:

scenery\rainsted\lwzmp_l.inc

Dla zgodności z SCSem, autor użył komend zmiany stanu rozjazdu w formacie nazwa:stan. Zostawił jednak zdarzenia dla starego systemu.

event (p1)+ multiple 0 none (p1)_dzwiek (p1)_0 (p1)_Vmax (p1)_suwak0 (p1)_latarnia0 (p1)_walek0 endevent
event (p1)- multiple 0 none (p1)_dzwiek (p1)_1 (p1)_V40 (p1)_suwak1 (p1)_latarnia1 (p1)_walek1 endevent
event (p1):+ multiple 0 none (p1)_dzwiek (p1)_0 (p1)_suwak0 (p1)_latarnia0 (p1)_walek0 endevent
event (p1):- multiple 0 none (p1)_dzwiek (p1)_1 (p1)_suwak1 (p1)_latarnia1 (p1)_walek1 endevent

Wszystkie pliki muszą mieć nazwy zapisane małymi znakami bez spacji i znaków diakrytycznych.

Nie Mój Domek.inc tylko moj_domek.inc. Odnosi się to także do plików tablic relacyjnych. Nie Dąbrowa Górnicza.tga a dabrowa_gornicza.tga.

Pliki tekstowe muszą być zapisywane w formacie ANSI Windows-1250 z windowsowym końcem wiersza \r\n.

Szczególnie dla użytkowników Linuxa. Nie UTF-8, nie samo \n (LF). Wiele narzędzi wymaga takiego formatu i nie trawi linuksowych znaczników. Poniżej te ustawienia w Notepadzie++.

Stosowanym separatorem powinna być spacja.

Maszyna jako separator akceptuje spację, tabulator, znak nowego wiersza, przecinek i średnik, ale preferowana jest spacja dla czytelności pliku przez człowieka. Ewentualnie tabulator lub nowy wiersz dla zwiększenia czytelności kodu. Stare skrypty do 3DS Maxa generują średniki. Warto je zamienić na spacje.

Przecinek jest separatorem, nie symbolem dziesiętnym!

Pliki nie posiadają odniesień do tekstur z jawnymi rozszerzeniami.

Uwaga zwłaszcza dla tworzących scenerie w Rainstedzie. Przy podaniu ścieżki do tekstury podsypki, on lubi zapamiętać rozszerzenie, eksportując potem wpisy:

node -1 0 none triangles material ambient: 0.0 0.0 0.0 diffuse: 149.94 149.94 149.94 specular: 229.5 229.5 229.5 endmaterial grass.dds
1349.94 0.0 830.446 	0.0 1.0 0.0  550.887 1130.69 end
1668.69 0.0 802.989 	0.0 2.0 0.0  335.016 1116.46 end
1668.69 0.0 273.227 	0.0 1.0 0.0  335.016 841.902 
endtri

Jest to niedopuszczalne. Wszystkie odniesienia do tekstur muszą być pozbawione rozszerzeń. Inne edytory raczej nie robią takich problemów.

W ekranach na Pythonie, większość grafik ma format .png i jest nieużywana w modelu. Są więc otwierane metodą:

Image.open(lookup_path + "image.png")

Tekstury użyte również w modelu, muszą być wczytywaną uniwersalną metodą:

self.openimage(lookup_path + "image")

Dla spójności lepiej stosować wyłącznie drugą metodę.

Modele

Wszystkie modele muszą mieć strukturę hierarchiczną. Jeden obiekt nadrzędny i jego potomne kolejnych stopni. Głębokość hierarchii powinna być możliwie płytka.

Do podglądu można użyć dowolnego edytora 3D lub Rainsteda. W przykładach Rainsted jako najłatwiej dostępny. Podgląd wywołujemy z menu Modele -> Otwórz T3D.

Jako przykład stary model pudła EU20. Jak widać obiektem nadrzędnym jest tu banan. Jest to zwyczajowa nazwa dla handlera geometrii w MaSzynie. Może być to pusty obiekt lub geometria. Istotne jest, by miał największy w modelu zasięg renderowania. Poniżej widzimy jego dziecko - obiekt potomny mocowanie2 a dalej potomne drugiego stopnia w postaci przewodów pneumatycznych w obu stanach. Przykładem zbędnego zagnieżdżania hierarchii jest tutaj pantograf. Animacja wymaga struktury ramię_dolne -> ramię_górne -> ślizg. Optymalnie, ramię dolne powinno być potomnym banana. Podpinanie go pod pudło, podstawę izolatorów, izolatory i mechanizm, to cały stos zbędnych macierzy transformacji do wymnożenia.

Przy braku obiektu nadrzędnego, u góry drzewka byłoby kilka obiektów luzem, nie połączonych przerywanymi liniami.

Wszystkie submodele muszą mieć unikalne nazwy.

Nazwy obiektów w ramach jednego pliku T3D (lub kilku T3D includowanych razem do jednego E3D) muszą być unikalne. Na podstawie nazw tworzona jest hierarchia rodzic-dziecko. Jeśli kilka obiektów ma taką samą nazwę, staje się ona nieokreślona i zależy od kolejności parsowania pliku. Problem ten występował w starych semaforach świetlnych, gdzie soczewka, flara i freespot miały taką samą nazwę.

Za przykład zdublowanych nazw posłuży plik dynamic\pkp\4e_v1\4e-zez-profeta\4e_3]kabina-4en-a.t3d:

Zdublowane nazwy obiektów na podglądzie struktury w Rainstedzie są oznaczane symbolem wykrzyknika. Po zapisie jest on dodawany do nazwy submodelu w celu usunięcia duplikatu.

Plik musi być zapisany zgodnie z hierarchią obiektów. Zawsze rodzic musi występować przed potomnym.

Rodzic zawsze musi się znajdować w pliku T3D przed dzieckiem. Jest to wymuszone liniowym działaniem parsera. Musi on najpierw wczytać rodzica, by mógł podpiąć pod niego dziecko. Jeśli nastąpi próba wczytania dziecka odwołującego się do niewczytanego jeszcze rodzica, zostanie ono wczytane luzem, bez hierarchii.

Jako przykład celowo uszkodzony plik z obiektem nadrzędnym wyrzuconym na koniec pliku T3D. Jak widać, nowym nadrzędnym stał się obiekt kabina_b a obiekty podparentowane wcześniej pod profeta są teraz luzem. Symbolizuje to linia skierowana do góry drzewka hierarchii.

Poszczególne obiekty nie mogą być skalowane transformem.

Macierz transformacji obiektu:

Transform: 
           1.0 0.0 0.0 0.0
           0.0 1.0 0.0 0.0
           0.0 0.0 1.0 0.0
           0.0 0.0 0.0 1.0

nie może zawierać skalowania. Dla macierzy bez obrotu, oznacza to jedynki na przekątnej. Przy obrotach robi się to bardziej skomplikowane i lepiej zawierzyć programom. Rainsted symbolizuje skalowanie wyświetleniem wartości procentowej przy drzewku hierarchii oraz szczegółowym skalowaniem w poszczególnych osiach w polach pod macierzą transformacji.

Guzik Resetuj skalowanie wymnoży geometrię przez skalowanie bez pomocy edytorów 3D. Tutaj uwaga, wymnażać należy od góry hierarchii, gdyż wymnożenie skalowanego rodzica, przeniesie jego skalowanie na wszystkie dzieci.

Brak skalowania jest istotny dla kalkulacji wektorów normalnych. Jeśli nie powiedzie się ich normalizacja, to przy przeskalowanej długości, będą przekłamywać oświetlenie obiektu. Dodatkowo jest to problematyczne dla importerów modeli i uniemożliwia manipulacje w modelu z poziomu edytorów tekstowych.

Wszystkie obiekty nieanimowane muszą mieć pivot ustawiony w zerze, zgodnie z orientacją sceny. Wyjątkiem jest tu obiekt nadrzędny kabiny B, gdzie zalecany jest obrót pivotem o 180° po osi Z dla zachowania tożsamości geometrii kabin A i B.

Orientacja pivota ma znaczenie tylko przy animacjach i pozycjonowaniu dźwięku. Jeśli coś nie jest ruchome lub nie jest lampką z głośnym przerzutnikiem, powinno mieć pivot w zerze zgodnie z osiami współrzędnych. Czyli jego macierz transformacji ma być macierzą jednostkową:

Transform: 
           1.0 0.0 0.0 0.0
           0.0 1.0 0.0 0.0
           0.0 0.0 1.0 0.0
           0.0 0.0 0.0 1.0

Macierz obracająca o 180° w osi Z to:

Transform: 
           -1.0  0.0  0.0  0.0
            0.0 -1.0  0.0  0.0
            0.0  0.0  1.0  0.0
            0.0  0.0  0.0  1.0

Wymnożenie kabiny B jest bardziej optymalne pod względem renderowania, ale obrócenie jej obiektem nadrzędnym pozwala współdzielić elementy w kabinach A i B bez żadnych edycji.

Model nie może zawierać zdegenerowanych trójkątów, duplikatów trójkątów, nakładających się płaszczyzn, dziur. Nie powinien zawierać niewidocznej geometrii (w środku innej bryły).

Zdegenerowany trójkąt to taki, którego jeden z wierzchołków leży na przeciwległym boku. Czyli jest linią. Trójkąty są logowane przez EXE symulatora z podaniem numeru wierzchołka, więc można je usunąć edytorem tekstowym.

W narzędziach Mariusza znajduje się skrypt VBA usuwający takie trójkąty. Większość z nich jest usuwana przez edytory 3D podczas spawania wierzchołków z promieniem 1 mm.

Duplikaty trójkątów to dwa fragmenty geometrii leżące w tym samym miejscu z takim samym wektorem normalnym. Również jest skrypt VBA usuwający takie trójkąty.

Chodzi głównie o płaszczyzny znajdujące się w niewielkiej odległości od siebie, z którym bufor głębokości renderera nie daje sobie rady i wyświetla je w losowej kolejności względem kamery. Nakładające się płaszczyzny powstają przez złą topologię modelu w wyniku złej automatycznej triangulacji. Wtedy należy jawnie zdefiniować więcej przekątnych n-gonów celem wymuszenia poprawnej triangulacji. Mogą być również wynikiem błędu modelarza w przypadku luźnej geometrii.

Dziury rozumieją się same przez się. Należy zwrócić również uwagę na krawędzie, gdzie stykają się elementy o różnej gęstości siatki.

Geometrię niewidoczną lub znajdującą się wewnątrz innej bryły należy usuwać. Przykładowo, poręcz wchodząca w bok pojazdu powinna wnikać tylko na kilka milimetrów i nie mieć zasklepionego zakończenia rurki.

Materiał powinien mieć diffuse koloru białego, chyba że zawsze występuje w zacienieniu (tunele, wnętrza pojazdów). Specular koloru zależnego od tworzywa z którego dany element jest w większości wykonany.

Ambient: 255.0 255.0 255.0
Diffuse: 255.0 255.0 255.0
Specular: 100.0 100.0 100.0

Składowe ambient i diffuse (kolor odbity bezkierunkowy) powinny być ustawione na kolor biały (RGB 255 255 255) aby model poprawnie się oświetlał i nie wyróżniał z reszty sceny. Najgorzej wygląda to w przypadku terenu z przyciemnionym diffuse, gdzie smugi reflektorów rozświetlają podsypkę, a na terenie mają mizerny efekt.

Wnętrza tuneli, budynków, kabiny uproszczone lokomotyw powinny mieć ciemniejszy materiał diffuse, dla ukazania zacienienia tych obszarów. Dla wnętrz pojazdów standardowo stosowany jest szary 58% (RGB 150 150 150).

Specular określa intensywność odbicia bezpośredniego światła do kamery. Obecnie w EXE uwzględniany jest tylko dla pojazdów, przy czym włączone są mnożniki 1/3 dla geometrii nieprzezroczystej i 3/2 dla geometrii półprzezroczystej.

Istnieją wytyczne kolorów dla shaderów PBR. Dla używanego shadera Phong-Blinn wartości trzeba dobrać na oko. Ogólne wytyczne to wysoki specular dla metali i szyb lustrzanych, a niski dla dielektryków. Istotne jest ustawienie specular równego zero dla geometrii udającej cień.

Zaawansowane modele muszą korzystać z techniki LoD (poziomu detali).

Poprzez wartości:

MaxDistance: r2
MinDistance: r1

Należy ustawić zasięg wyświetlania danego obiektu. Obiekty o skomplikowanej geometrii (LoD jest sens robić dla obiektów >1000 trójkątów) powinny być zastępowane przez wersje uproszczone w odległości, gdy detale przestają być widoczne. Zazwyczaj wystarczy jedna-dwie fazy uproszczenia.

Drobne detale, niewidoczne w odległości przejścia w LoD1 mogą nie posiadać wersji uproszczonej i być po prostu renderowane tylko w małej odległości od kamery.

Model powinien posiadać możliwie mało submodeli.

Każdy dodatkowy submodel, to dodatkowy drawcall do karty graficznej, bezpośrednio wpływający na prędkość renderowania. Ich ilość powinna być możliwie mała.

Tekstury należy w miarę możliwości łączyć w duże mapy zawierające wiele obiektów. Optymalnie, model powinien mieć jedną teksturę, czy nawet dzielić ją z modelami często występującymi w jego bliskości (np. różne gatunki drzew na jednej teksturze, tworzące zawsze razem las, bądź różne elementy sieci trakcyjnej).

Dzielenie modeli jest dozwolone, gdy:

• Używają innej tekstury i/lub parametrów materiału.

  Silnik MaSzyny pozwala przypisać tylko jeden materiał do submodelu. Gdy chcemy użyć różnych tekstur, lub różnych wartości diffuse/specular, musimy podzielić model na osobne submodele.

• Mają inny zakres renderowania.

  Poszczególne fazy LoD muszą być osobnymi submodelami. Lepiej jest renderować element z większej odległości, niż dzielić na większą ilość submodeli, by skrócić zasięg renderowania.

  Ukrywane detale powinny być połączone w jeden obiekt, a nie barierki osobno, haki osobno itp.

• Są animowane.

  Silnik MaSzyny obsługuje animacje tylko w formie transformacji submodelu. Z tego powodu, wszystkie animowane elementy muszą być osobnymi submodelami z pivotami ustawionymi w osi animacji. Każde cięgno mechanizmu musi być osobnym obiektem. Również każdy stan lampki musi być osobnym obiektem.

Mapowanie powinno być w miarę możliwości proporcjonalne i pozbawione zniekształceń. Niedopuszczalne jest rzutowanie tekstury pod małym kątem do wektora normalnego płaszczyzny, zwłaszcza w widocznych miejscach.

Przykład czajniczka zmapowanego rzutem Y i rzutem Z na pokrywkę. Wizualizacja w trybie zniekształcenia mapowania. Im większy kąt względem rzutni, tym większe zniekształcenie.

I ten sam czajniczek po rozpłaszczeniu siatki:

Błędy mapowania najczęściej są widoczne jako powierzchnie malowane pojedynczym paskiem pikseli. Powstają wtedy charakterystyczne pasy.

Wszystkie widoczne elementy modelu powinny mieć zbliżoną gęstość tekseli (pikseli tekstury na metr modelu), zwłaszcza przy podziale mapowania jednego obiektu na kilka wysp.

Niewidoczne podwozie może mieć mniej, pulpit przed oczami maszynisty - więcej.

Tekstury

Wszystkie tekstury muszą mieć rozdzielczość 2^n w obu osiach.

Proporcje prostokąta są dowolne. Nie musi być to kwadrat, ale każdy z boków musi mieć długość będący potęgą dwójki. Przykładowo 512, 1024, 2048 px.

Tekstury takie są obsługiwane przez wszystkie karty graficzne. Szybciej się wczytują i pozwalają generować mipmapy o rozdzielczości pierwiastka rozmiaru natywnego. Inne rozmiary i tak są skalowane na karcie graficznej.

Obowiązującym formatem jest TGA z kompresją RLE z originem w lewym dolnym rogu tekstury. Kanały RGB lub RGBA jeśli tekstura zawiera przezroczystości. 8 bitów na kanał.

Kompresja RLE jest bezstratna, a zmniejsza wagę pliku o 20-30%. Spowalnia wczytywanie, ale pliki TGA to wersja źródłowa, więc nie ma to znaczenia. Użytkownicy końcowi korzystają z paczki z teksturami przekonwertowanymi na format DDS.

Kanał alfa należy uciąć, gdy nie jest potrzebny. Co prawda, w pamięci wszystkie tekstury są trzymane jako RGBA 32bpp, ale zmniejsza to rozmiar pliku.

Na granicach wysp mapowania należy stosować marginesy na kilka pikseli. Przy mipmapach i filtrowaniu próbkowane są sąsiednie piksele.

Najlepiej zostawić kilka pikseli przerwy między wyspami. Przy tworzeniu tekstury tło wypełniać kolorem neutralnym lub propagacją sąsiedniego piksela.

Przy obserwacji z większej odległości, używane są mipmapy. Tekstury wykładniczo zeskalowane w dół. Jeśli użyteczny piksel sąsiaduje z kontrastowym, po skalowaniu powstanie piksel o wypadkowej koloru. Stąd pojawiają się na krawędziach modeli białe paski, jeśli tekstura jest klejona na białym tle bez marginesów.

Film autorstwa @Stele pokazujący, jak wygenerować takie marginesy: https://www.youtube.com/watch?v=4JUhVoe6r4Y

Tekstury zawierające pełną przezroczystość powinny mieć wartości RGB na przezroczystych obszarach zbliżone do koloru na krawędzi.

Przyczyna ta sama, co w punkcie poprzednim. Próbkowane są sąsiednie piksele i należy unikać kontrastu.

Przykładowe kwiaty na alfie:

Po usunięciu alfy wyłazi propagacja koloru pod przezroczystością.

Nie powinny być widoczne łączenia kawałków zdjęć na teksturze.

Nie powinny być widoczne różnice w kolorach wynikające ze złego dopasowania odcieni na poszczególnych zdjęciach.

Fizyka

Fizyka musi odzwierciedlać rzeczywistość na stan naszej wiedzy i możliwości symulatora.

Pojazdy z obsługiwanymi typami napędu i hamulców muszą mieć je odwzorowane zgodnie z dostępnymi charakterystykami.

Nie robimy 401Da z silnikiem dumb, obsługując silnik spal-ele.

Nie robimy Skody 754 z silnikiem Fiata, bo nie chce nam się szukać danych.

Robienie pojazdów spalinowych z prądnicą synchroniczną i falownikiem jako prądnicę równoległą z regulatorem Woodwarda jest dozwolone, ponieważ w obecnym stanie EXE nie obsługuje pojazdów z prądnicą synchroniczną i falownikiem.

Wymiary pojazdu, średnice kół, odległości wózków muszą być zgodne z modelem, a dopiero w drugiej kolejności z rzeczywistością.

Jeśli model jest krzywy, należy te krzywe wymiary wpisać w fizykę. Lepiej, by się poprawnie animował, niż był zgodny z książką.

Pojazd musi mieć ustawioną maksymalną dozwoloną flagę sprzęgu, zgodną z występującymi w nim możliwościami połączeń, niezależnie od animacji modelu.

Flagi możliwe do ustawienia w pojeździe. Szczegóły każdej z nich.

BuffCoupl. [...] AllowedFlag=X

Gdzie X jest sumą bitów poszczególnych możliwych połączeń. Domyślna wartość to 3.

Przy błędnych ustawieniach nie będzie można przejść między pojazdami, albo podpinając lokomotywę do składu, podłączy się kabel ukrotnienia, co może doprowadzić do wysypu symulatora.

Nie należy bezmyślnie kopiować parametrów nieobsługiwanych przez symulator.

Część fizyk ma w treści błędy lub wpisy z jakichś starych eksperymentalnych gałęzi EXE. Do niczego nie przydatne. Warto zapoznać się z listą dostępnych parametrów.

Elementy wspólne fizyk powinny być zgrupowane w jeden plik, wykorzystywany przez wszystkie warianty danego pojazdu.

Dla ułatwienia edycji elementów stałych, należy stosować obiektowość plików. Zdefiniować jeden plik ze wszystkimi uniwersalnymi stałymi. Elementy różniące się między wariantami, należy pominąć i zawrzeć daną sekcję w każdym wariancie, lub w miarę możliwości sparametryzować.

Przykładowy plik siodemka.fiz:

Param. Category=train M=80000 Mred=16000 Vmax=(P1) PWR=2000 SandCap=500

Wtedy warianty ograniczają się do plików o treści:

siodemka_na_120.fiz:

include
siodemka.fiz 120
end

siodemka_na_160.fiz:

include
siodemka.fiz 160
end

Ze względu na sposób parsowania plików FIZ, słowa kluczowe składni include muszą znajdować się w osobnych wierszach.

Pliki MMD

Odległości stukotu kół muszą się zgadzać z wymiarami modelu.

Na przykład:

wheel_clatter: 30.0 -9.85 20786]wheel_111a_v2_1.wav -7.35 20786]wheel_111a_v2_2.wav 7.35 20786]wheel_111a_v2_3.wav 9.85 20786]wheel_111a_v2_4.wav end

Odległości podajemy od czoła pojazdu (wartości ujemne), współrzędnymi uporządkowanymi rosnąco. Muszą być one tożsame położeniu osi pojazdu w osi Y.

Pojazd musi posiadać wpis "animations" bezpośrednio pod wpisem "models".

models: \main/140a.t3d
animations: 5 4 0 4 2 0 -1
lowpolyinterior: low_poly_int/int_140a.t3d
animwheelprefix: wheel0
animdoorprefix: door
endmodels

Wpisy należy umieszczać w kolejności zgodnej z dokumentacją. Szczególnie animations musi być zaraz pod definicją modelu. Określa on ilość animacji określanych poniżej.

Plik nie może posiadać definicji przełączników nieistniejących w modelu. Przełączniki nieobsługiwane można umieścić jako universale bądź komentarze.

brakectrl: hamulec rot 0.0625 -0.0625 0.15
// wylacznik_bezpieczenstwa_pom
// sw-oswietlenie_pulpitu_i_kabiny_potencjometr
alarmchain: bt-hamulec_bezpieczenstwa1 mov -0.003 0 0.15
universal2: { okno_r wip 0.25 0 0.2 soundinc: window_pcv_open.wav sounddec: window_pcv_close.wav }
universal3: { okno_l wip 0.25 0 0.2 soundinc: window_pcv_open.wav sounddec: window_pcv_close.wav }

Wpisywanie nieistniejących w modelu przełączników zaśmieca plik errors.txt i przedłuża wczytywanie. Powyższy przykład zawiera obsługiwane dźwignie, dwie nieobsługiwane - zakomentowane - i dwie dekoracje jako universale. Wszystkie możliwe do animacji elementy najlepiej wypisać od razu z parametrami. To pozwala je w łatwy sposób aktywować przy dodawaniu nowych funkcji do symulatora.

Elementy wspólne plików multimediów powinny być zgrupowane w jeden plik, wykorzystywany przez wszystkie warianty.

Dla ułatwienia edycji elementów stałych, należy stosować obiektowość plików. Zdefiniować jeden plik ze wszystkimi uniwersalnymi stałymi i includować go do danych wariantów.

Przykładowo, dla wagonów różniących się modelem wnętrza, w pliku wspólnym dajemy całą treść pliku MMD, zamieniając części różniące się między wariantami na parametry:

111a_common.mmd:

lowpolyinterior: low_poly_int/(p1)

A w każdym z wariantów określamy tylko ten model:

111a_brazowe_obicia.mmd:

include 111a_common.mmd
int_111a_brazowe_obicia.t3d //model wnętrza
end

111a_tapicerowane_obicia.mmd:

include 111a_common.mmd
int_111a_tapicerowane_obicia.t3d //model wnętrza
end

Dźwięki

Pliki dźwiękowe powinny być normalizowane.

Dźwięk powinien mieć głośność 90% amplitudy maksymalnej. Niedozwolone są przestery, gdy przebieg jest ucięty przekroczeniem maksymalnej amplitudy, jak również ściszanie sampla. Amplitudę zawsze można zmniejszyć w konfiguracji danego dźwięku, a normalizacja ułatwia unifikację głośności i zmianę dźwięków.

Pliki powinny być w formacie PCM WAV 8 bit lub FLAC 16 bit, 48kHz, mono, chyba, że nagranie źródłowe jest gorszej jakości. Format FLAC jest preferowany.

FLAC jest formatem z kompresją bezstratną. Należy go stosować dla plików źródłowych dla ograniczenia wagi paczki. Pliki o niskiej rozdzielczości (8 bit) w formacie FLAC są cięższe niż w formacie WAV, dlatego przy takich plikach należy stosować ten drugi format.

Nie wolno stosować plików stereo. Po pierwsze, czas sampla jest liczony z bitrate dla ścieżki mono. Ścieżka stereo będzie się nakładać lub zapętlać. Po drugie, MaSzyna używa dźwięku przestrzennego i przy wczytaniu taki plik i tak zostanie skonwertowany do mono.

Scenerie i scenariusze

Zawarte wraz ze scenerią modele i scenariusze spełniają osobne wymogi dotyczące wymienionych.

Wymogi estetyczne dla obiektów dedykowanych zazwyczaj są obniżane, ale normy formalne muszą być spełnione. Patrz pliki, include, modele, tekstury.

Sceneria podzielona jest na pliki tematyczne (tory, sieć trakcyjna, zieleń, modele itp.) o odpowiednich rozszerzeniach. SCN dla pliku głównego, SCM dla składowych, CTR dla oskryptowania sterowania ruchem.

Szczegóły: Plik scenerii.

Plik główny SCN musi zawierać definicję skyboxa, pogody, czasu i składów do jazdy. Cała reszta powinna być wydzielona do podzielonych tematycznie i obszarowo plików składowych SCM. Całe oskryptowanie powinno się natomiast znaleźć w plikach o rozszerzeniu CTR.

W paczce zawarte są wszystkie pliki niezbędne do działania scenerii, które nie są wersjonowane na repozytorium. Sceneria nie może dublować plików istniejących już pod innymi nazwami lub w innych lokalizacjach ani przywracać plików marnej jakości, zastąpionych masowo innymi.

Średni czas powstawania scenerii w maszynie to około dekady. Paczka całościowa zmienia się dużo szybciej. Należy śledzić zmiany na repozytorium i dostosowywać się do zmian w assetach i strukturze katalogowej.

Sceneria nie generuje błędów do pliku errors.txt.

Czyli nie zawiera odwołań do nieistniejących eventów, duplikatów nazw bądź zdegenerowanych trójkątów terenu.

Sieć trakcyjna nie powoduje łamania się pantografu.

Czyli jest wszędzie tam, gdzie porusza się tabor trakcji elektrycznej. Nie wykracza za płaszczyznę pracy ślizgu. Nie zawiera gwałtownych załomów profilu pionowego.

Sygnalizacja, wskaźniki, profile toru spełniają normy budownictwa kolejowego. Chodzi o spełnienie dróg ochronnych. Dopuszczalnych pochyleń, skrajni itp.

Podstawowe informacje w treściwej formie można znaleźć na stronie Paula.

Pełne dane są dostępne w instrukcjach PLK.

Wszystkie obsługiwane semafory i wskaźniki są przypisane do torów. Sygnały powinny mieć zunifikowane nazwy, zawierające nazwę posterunku i oznaczenie zgodne z tabliczką na obiekcie. W miarę możliwości tory i rozjazdy stacyjne również powinny być ponazywane zgodnie z normami.

KAŻDY semafor, tarcza, wskaźnik musi być przypisany do toru.

Koncepcja nazewnictwa elementów dostępna jest na stronie Ra.

Na scenerii realistycznej, nazwy te powinny być zgodne z nazewnictwem na schematach stacji.

Wszystkie odcinki torów posiadają unikalne nazwy.

Każdy tor ma unikalną nazwę w obrębie scenerii. Pozwala to odwoływać się do nich poprzez eventy bez ingerencji w tory oraz umieszczać na nich tabor.

Zawiera orientację modelu względem pivota (np. //wzrastająca oś X przód budynku).

Standardowy przód modelu to oś -Y. Przy innej orientacji, czy pivocie nie na środku, tylko w jakimś punkcie ułatwiającym wstawianie, należy to zaznaczyć:

// Kolano rurociagu
// (p1) none (p2)(p3) (p4) wspolrzedne (p5) rotacja
//
// ^ os Y
//
// |
// \
// * \__ -> X
//
// Punkt 0,0 (gwiazdka na "rysunku") ustawiony 3m od jednego konca, na linii drugiego

Przy zmiennej teksturze w pliku INC jako komentarz znajduje się informacja o ścieżkach dostępu do tekstur dostarczanych przez autora modelu.

Wypisać wszystkie pasujące tekstury wymienne, do podstawienia za parametr:

// Fragment dwóch równoległych rur CO prowadzonych poziomo o długości 20m +Y. Pivot w osi rur na krańcu -Y.
// Tekstura wymienna P1: mpec, grafiti.

Obrót modelu przy znakach i wskaźnikach we wszystkich trzech osiach, przy reszcie tylko w osi Z. Translacja jako parametry 2-4, rotacja 5-Z 6-X 7-Y.

Kolejność parametrów jest standaryzowana.

• P1: nazwa node model lub tekstura wymienna; przy braku nieużywany
• P2: translacja -X (X współrzędne OpenGL)
• P3: Translacja Z (Y współrzędne OpenGL)
• P4: Translacja Y (Z współrzędne OpenGL)
• P5: Rotacja Z
• P6: Rotacja X lub tekstura wymienna
• P7: Rotacja Y

origin (p2) (p3) (p4)
rotate (p6) (p5) (p7)

Wszystkie składy w ruchu, zwłaszcza pasażerskie, posiadają rozkład jazdy.

Dzięki temu działają im tablice relacyjne, stają w peronach, przeładowują pasażerów. Wiedzą gdzie jadą i mogą być odpytywane o rozkład przez skrypt sterujący ruchem.

Składy pasażerskie posiadają pliki tablic relacyjnych dla użytego w nich taboru. Opcjonalnie dla innego taboru pod podmianki użytkownika.

Pojazdy nieposiadające skryptów generujących tablice relacyjne muszą mieć je zrobione ręcznie zgodnie z szablonem danego pojazdu i umieszczone w jego folderze dynamic jako plik nazwa_pociagu.tga, pamiętając przy tym o zastąpieniu spacji znakami podkreślenia oraz nie używaniu polskich znaków.

Wszystkie składy są sensownie zestawione z taboru eksploatowanego przez danego przewoźnika, odwzorowują możliwie spójny okres historyczny. Mają założone (w ruchu) lub nie (stojące na torach bocznych) sygnały SKP. Ładunek i sprzęgi zgadzają się z przeznaczeniem składu.

W znalezieniu pasującego taboru, pomocny jest katalog tekstur, sortujący na podstawie metadanych pojazdów.

Tarcze SKP na pojeździe determinuje jego flaga sprzęgu. Jeśli jest zerowa, pojazd dostaje SKP od C1 (tylny sprzęg). Jeśli jest różna od zera, nie. Dlatego zestawione składy kończymy sprzęgiem 0 w trainsecie, a luźne wagony - różnym od 0 (zazwyczaj 3).

Nie wozimy węgla do kopalni ani pustych wagonów do elektrowni. Nie wstawiamy wagonów załadowanych ludźmi w krzaki.

Tabor

Kabiny powinny mieć wszystkie odwzorowane przełączniki przygotowane do animacji, czyli wydzielone do osobnego obiektu z ustawionym pivotem w osi ruchu, nawet, jeśli nie są obsługiwane przez symulator.

Wszystkie przełączniki, hebelki, pedały, okienka, szafki należy wypisać w pliku MMD. Dla modelarza to mały wysiłek na etapie robienia kabiny. Dla dostosowującego pod nowe funkcje w przyszłości - zdecydowanie większy, gdy musi importować i kroić cudzy model.

Koła kręcą się w odpowiednią stronę.

Czyli pomijając transformację wózka i ewentualnych innych rodziców, mają transformację zestawu kołowego obróconą o 180° w osi Z względem układu sceny.

Światła mają ustawione ID zgodnie z położeniem na modelu. Mają ustawioną emisyjność i skojarzone źródło punktowe FreeSpotLight o kolorze zgodnym z barwą reflektora.

Czyli zgodnie z poniższym schematem:

Kolor światła punktowego FreeSpotLight najlepiej określić, próbkując średnią środka tekstury zapalonego reflektora. Pozwoli to uniknąć widoczności kropki źródła światła i przeskoku, gdy przesłania teksturę.

Pudło i ładunek przechyla się prawidłowo.

Czyli pojazd ma prawidłową hierarchię. Ładunek ma jednostkowy transform. Błędy w tym miejscu objawiają się złą animacją na przechyłce.

Rozstaw kół pasuje do prześwitu szyn, koła dotykają szyn.

Koła pasują do rozstawu normalnego 1435mm (bądź innego, stosownego do typu danego pojazdu). Między wewnętrzną krawędzią główki szyny a obrzeżem koła zostaje margines na wpasowanie się zestawu w łuk. Wysokość styku toru z kołem jest zerem modelu.

Sprzęgi i węże mają standaryzowane punkty łączeń, pojazd łączy się prawidłowo z podobnymi i innymi.

Czyli spełnione są wymiary z poniższego rysunku. Dla połączeń skośnych przewidziana jest inna wysokość położenia główek. Rysunek w przyszłości będzie uzupełniony.

Pojazd posiada plik mini w formacie BMP, 24 bity, bez palety w nagłówku.

Zapis z innymi opcjami powoduje, że Rainsted nie potrafi wyświetlić miniaturek na niektórych systemach operacyjnych.

Pojazd posiada plik/wpis do pliku textures.txt z komentarzem w zadanym formacie.

Dla tekstur taboru, umieszczamy we wpisie do textures.txt komentarz z opisem pojazdu wg klucza:

• Znacznik wersji opisu
• Oznaczenie eksploatacyjne
• Identyfikator literowy (fragment numeru EVN)
• Stację macierzystą, lokalizację bazy przewoźnika prywatnego
• Datę rewizji w formacie dd.mm.rrrr; Dla nieznanej daty wstawiamy ?; Dla nieznanej częściowo xx.xx.2000
• Zakład dokonujący rewizji lub cyfry/litery po REV., aby później osobie która będzie te dane uzupełniać, łatwo było odszukać dany kod i dopisać dane
• Autora tekstury
• Autora zdjęć

Każdą z tych wartości rozdzielamy przecinkami, na przykład:

303E-TV-477_HIST.TGA=303E-TV,EU07,EU07-477_HIST//v2,EU07-477,PKPC,Wrocław,10.11.2006,Zakład_Taboru_w_Krakowie,Lelek&Ziutek,darek71wrc

W miejsce nieznanych tokenów wstawiamy pytajniki ?, by parser dobrze to łapał.

Jeśli w którymś polu chcemy dać kilku autorów, oddzielamy ich znakiem &. Między mini a komentarzem nie stawiamy spacji.