Erstellen einer Einzel-Buchstaben-Matrix wie in SD200 und SD202

Aus OMSIWiki
Version vom 28. Oktober 2012, 19:54 Uhr von Marcel Kuhnt (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu:Navigation, Suche

Hinweis: Dieser Artikel wurde noch nicht ins Englische übersetzt!

In diesem Artikel wird erklärt, wie man eine Matrix-Anzeige, wie sie in SD200 und SD202 verbaut ist (Typ Annax) in einen eigenen Bus eingebunden wird.

Beschreibung des Matrix-Systems

Dem aufmerksamen Beobachter ist nicht entgangen, das es einen Unterschied gibt zwischen der im SD200 und der im SD202 verbauten Matrix, um genauer zu sein: Die Seiten- und die Heckmatrix sind unterschiedlich.

Beiden gemein ist zunächst die Frontmatrix: Drei Felder à 15x7 Pixel (Font: "Annax Large") sind für die Liniennummer vorhanden und zwei Zeilen mit je 16 Feldern à 7x5 Pixel (Font: "Annax Small") sind für den Zieltext vorgesehen.

Die Seitenmatrix beim SD200 hat für die Liniennummer drei Felder à 11x7 Pixel (Font: "Annax Medium SD") und das Ziel wird nur einzeilig (selber Font, ebenfalls 16 Felder) dargestellt.

Die Seitenmatrix beim SD202 hat bei der Linie einen anderen Font: 11x6 Pixel (Font: "Annax Medium D") und das Ziel wird ebenfalls zweizeilig mit demselben Font, aber wesentlich kleineren Pixeln dargestellt.

Die Heckanzeige entspricht in beiden Fällen der jeweiligen Seitenanzeige.

Modellieren der nötigen Polygone und Mapping

Ich beschreibe hier den Einbau einer SD202-Matrix. Einerseits dürfte das die Interessantere sein (weil moderner), andererseits kann ich dann direkt den Einbau im NG272 zeigen, was mir logistische Vorteile bringt.

Für die drei Anzeigen wird eine o3d-Datei vorgesehen, deren Bau ich im Folgenden beschreibe. Der Vorteil besteht darin, dass die o3d-Datei (übrigens auch in unserem NG272!) dann "ausgebaut" werden kann und eine andere Anzeige hintergeklemmt werden kann, sofern man durch Ausprobieren und Erfragen beim Autor die genaue Position herausbekommen hat. Die Glasscheibe vor der Annax gehört somit nicht zur o3d-Datei, sondern sollte zusammen mit den Fenstern sehr spät, insbesondere nach Innenausstattung und Matrix-Anzeige gerendert werden!

Das, was wir modellieren wollen, soll am Ende also in etwa so aussehen:

2012 1028 01 TutAnnax.jpg

Texturen

Diese o3d-Datei besteht dann aus mindestens zwei Blender-Objekten: Dem von der Beleuchtung angestrahlten "Rahmen", also alles, was grau ist, die selbstleuchtende Lichterleiste unten und den dynamischen grünen (oder gelben, ist wohl Ansichtssache...! ;) ) Pixeln.

An dieser Stelle wird empfohlen, die für solche frei tauschbaren Anzeigen optimierten Textursatz zu verwenden (kann auch für SD200- und SD202-Annax genutzt werden), bei dem die Lichterleiste enthalten ist. Dies ist nämlich bei den in OMSI enthaltenen D- und SD-Texturen nicht der Fall. Daher bitte nun die zwei "Kasten"-Texturen sowie die drei gezeigten Helfer-Texturen herunterladen, die man idealerweise beim Bau der Matrix nutzt. Die beiden Texturen bitte für die Benutzung in OMSI in Bitmaps umwandeln, die drei Helfer können vmtl. png-Dateien bleiben, Blender sollte sie akzeptieren. Aber bitte auf die originalen Dateinamen achten:

  • D_Matrix.bmp
  • D_Matrix LM.bmp
  • MatrixTempl_Z.tga oder .png
  • MatrixTempl_Z2.tga oder .png als Kopie vom vorherigen
  • MatrixTempl_LinL.tga oder .png
  • MatrixTempl_LinS.tga oder .png

Der Helfer "MatrixTempl_Z.tga"

D Matrix.bmp.png 2012 1028 03 D Matrix LM.bmp.png 2012 1028 04 MatrixTempl Z.tga.png 2012 1028 05 MatrixTempl LinL.tga.png 2012 1028 06 MatrixTempl LinS.tga.png

Modellieren

Der Bau des Annax-Kastens sollte nicht schwer fallen. Zu beachten ist eben lediglich, dass die Lichtleiste am unteren Rand ein separates Blender-Objekt sein muss. Ansonsten wird immer die Textur D_Matrix.bmp verwendet:

2012 1028 07 TutAnnax.jpg

Im nächsten Schritt muss nun einige Millimeter davor (damit es nicht flimmert) die animierte Schrift gesetzt werden. Hierfür werden wie dargestellt rechteckige Polygone erstellt und diese so mit den gezeigten Hilfs-Texturen gemappt, dass die Pixel genau auf den Untergrund passen:

2012 1028 08 TutAnnax.jpg

Export der o3d-Datei

Für den Export der o3d-Datei muss die Reihenfolge der Objekte stimmen. Daher sollten sie korrekt benannt werden - hierfür wird das gezeigte Feld in Blender 2.49 genutzt:

2012 1028 09 TutAnnax.jpg

Der Name ist grundsätzlich egal, hauptsache die alphabetischer Reihenfolge stimmt. Aber am Besten natürlich, man numeriert die Objekte, z.B.:

  • Beleuchteter Annaxkasten: "ANNAX_01"
  • selbstleuchtende Lichtleiste: "ANNAX_02"
  • animierte grüne Pixel: "ANNAX_03"

Zu beachten ist natürlich auch, dass jedes dieser drei Objekte den jeweiligen Teil der Front-, Seiten- und Heckmatrix enthält! Es werden also alle drei Anzeigen nachher zu einer o3d-Datei exportiert, und es sind trotzdem nur drei Blender-Objekte, die zusammen exportiert werden! (Ich hoffe, es ist jetzt klar....! ;-) )

Einbindung in OMSI

Einbinden der o3d-Datei

Dies geschieht wie immer bei Fahrzeugen in der model.cfg. Zunächst müssen die drei Fonts definiert werden, und zwar wie immer vor dem ersten [mesh]-Befehl und sinnvollerweise nach den bisher bestehenden [texttexture]-Befehlen, damit die Indizes nicht verrutschen:

ANNAX Linie groß:

3 <== ACHTUNG! Hier die richtige laufende Nummer verwenden und vor allem merken, ob sich hier etwas ändert!
[texttexture]
number
Annax Large
128
128
0
210
255
20

4
[texttexture]
number
Annax Medium D
128
64
0
210
255
20


5
[texttexture]
number
Annax Small
512
128
0
210
255
20

Also merken für gleich: In diesem Fall war "Annax Large" Nummer 3, "Annax Medium D" Nummer 4 und "Annax Small" Nummer 5.

Die Einbindung des Matrix-Kastens muss auf jeden Fall vor dem Fenster-Mesh bzw. dem Mesh für die Annax-Glasscheibe kommen. Wir haben es unmittelbar davor platziert, also nach dem Innenraum usw.:

[mesh]
Generic\GN_main_matrix.o3d

[illumination_interior]
-1
-1
-1
-1
---------------

[matl]
D_Matrix.bmp
0
	
[matl_lightmap]
D_Matrix_LM.bmp
lights_stand


---------------

[matl_change]
D_Matrix.bmp
1
lights_stand

[matl_item]

[matl_nightmap]
D_Matrix_LM.bmp

--------------


[matl]
MatrixTempl_LinL.tga
0

[useTextTexture]
3

[matl_alpha]
2

[matl_lightmap]
Matrix_Lin_L_LM.bmp
lights_stand

------------------

[matl]
MatrixTempl_LinS.tga
0

[useTextTexture]
4

[matl_alpha]
2

[matl_lightmap]
Matrix_Lin_M_LM.bmp
lights_stand

------------------

[matl]
MatrixTempl_Z2.tga
0

[useTextTexture]
5

[matl_alpha]
2

[matl_lightmap]
Matrix_Ziel_font_LM02.bmp
lights_stand


[matl]
MatrixTempl_Z.tga
0

[useTextTexture]
5

[matl_alpha]
2

[matl_lightmap]
Matrix_Ziel_font_LM01.bmp
lights_stand

Zur Erläuterung:

Zunächst erkennt man den Aufruf der o3d-Datei, gefolgt von der Angabe, dass hier keine Lichtquelle wirksam ist (sonst wird das Mesh womöglich von der Innenbleuchtung beschienen).

Nun wird D_matrix.bmp betrachtet, und zwar im ersten Objekt ("0"): Es wird die vorbereitete Beleuchtungs-Textur als "Lightmap" hinzugefügt (erhellt nur, stellt kein Selbstleuchten dar), und zwar in Abhängigkeit von "lights_stand", das ist das Standlicht.

Als nächstes wird D_matrix.bmp im zweiten Objekt ("1") betrachtet, das ist die Lichtleiste. Hier kommt ebenfalls dieselbe Beleuchtungstextur zur Anwendung, diesmal aber als "Nightmap", aber ebenfalls in Abhängigkeit von "lights_stand".

Nun folgen die vier Hilfstexturen. Hier muss einerseits darauf geachtet werden, dass die korrekte Endung verwendet wird! Im Beispiel war es .tga, je nachdem, wie oben verfahren wurde, kann es aber auch .png sein. Dann folgt der jeweilige [useTextTexture]-Befehl, wobei hier der Index stimmen muss! Die Reihenfolge ist aber dieselbe wie zuvor bei der Definition der Texttexturen, die letzte kommt zweimal vor. Der Hintergund ist hierbei, dass unterschiedliche Beleuchtungstexturen genutzt werden. Die Beleuchtungstexturen finden sich im SD202-Texturordner und sind unverändert. Sie werden anschließend eingebunden, ebenso wie die Transparenz mit [matl_alpha].

Einbinden des Scripts

Damit die Matrix-Anzeige funktioniert, muss sowohl das Matrix-Script als auch das IBIS-Script für die Ansteuerung eingebunden werden. Wenn ohnehin die Basis für den eigenen Bus ein SD202 ist, dann sind die folgenden Schritte nicht mehr nötig, da ohnehin intern eine Annax simuliert wird.

Ansonsten sind folgende Dateien nötig, welche vom SD202 hinüberkopiert werden müssen:

  • IBIS.osc oder IBIS-2.osc
  • IBIS_constfile.txt
  • IBIS_stringvarlist.txt
  • IBIS_varlist.txt
  • matrix_D.osc
  • matrix_constfile.txt
  • matrix_stringvarlist.txt
  • matrix_varlist.txt

Diese müssen natürlich wie üblich in die bus/ovh-Datei eingebunden werden:

[varnamelist]
###
...
script\IBIS_varlist.txt
script\matrix_varlist.txt
...

[stringvarnamelist]
###
...
script\IBIS_stringvarlist.txt
script\matrix_stringvarlist.txt
...

[script]
###
...
script\IBIS.osc oder script\IBIS-2.osc
script\matrix.osc
...

[constfile]
###
...
script\IBIS_constfile.txt
script\matrix_constfile.txt
...

Und zuletzt muss in der Haupt-Scriptdatei (z.B. MAN_D92_main.osc) sichergestellt werden, dass im {init}-Block die Einträge

{init}
...
	(M.L.Matrix_init)
	(M.L.IBIS_init)
...
{end}

und im {frame}-Block die Einträge

{frame}
...
	(M.L.IBIS_frame)
	(M.L.Matrix_frame)
...
{end}

vorhanden sind.

Einbinden des Sounds

Das Umschildern macht im SD200/SD202 bekanntlich einen Sound; dieser hat folgende Definition, welche also auch in der eigenen Sounddatei vorhanden sein sollte:

###################################################
Matrixanzeige
###################################################

[sound]
Matrix_Ziel.wav
1

[3d]
0.77
5.14
2.72
0.5

[trigger]
ev_Matrix_Terminus_change

[sound]
Matrix_Linie.wav
1

[3d]
0.77
5.14
2.72
0.5

[trigger]
ev_Matrix_Line_change