Beiträge von Stapellurch

Ja moin,
da es die FlipDot Matrizen bereits seit den 80ern gibt und den Arduino erst seit 2005 laut Wiki... wird das wohl im realen Bus anders angesteuert.

Wenn KOMSI in der Lage ist, Haltestellennamen während des Spiels auszulesen und an einen Arduino zu senden, ist das schon mal die halbe Miete. Brauchst dann halt aufm Arduino Code, der die eingehenden Zeichenketten verarbeitet und für ne Matrixanzeige aufbereitet und die Matrix dann auch ansteuert.
Je nachdem, wie groß deine Matrix ist und mit welcher Versorgungsspannung du an die Sache rangehen willst, reicht ein Arduino Uno alle mal. Der Trick hier heißt "Schieberegister". In die Dinger fütterst du einen seriellen Datenstream und kannst ihn dann parallel ausgeben lassen. Da du die Dinger in Reihe schalten kannst, kannst du aus drei Pins des Arduino quasi unendlich viele weitere Pins zur Ansteuerung herausholen. Allerdings brauchst du dann auch noch Treiberschaltkreise, da der Arduino ja nur 5 V liefert. Aber hier wirds dann wirklich bedeutsam, welche Matrix du hast.

Geht es dir darum, in welcher Farbe die Lampen leuchten oder darum, in welcher Farbe Objekte angeleuchtet werden? Das sind in OMSI zwei unterschiedliche Dinge

Moin Celebration,

der Dateipfad sollte sich zwischen Windows 8.1 und Windows 10 nicht unterscheiden. Normalerweise sollte das C:\Programme (oder Programma (x86))\Steam\steamapps\common\OMSI2 sein. Ansonsten kannst du, falls du OMSI über Steam spielst, mal schauen, wo deine Steam Bibliothek auf der Festplatte hinterlegt ist (Steam Einstellungen).

Dann bezüglich Linien: Bei jeder Karte, die du fährst, muss jede Linie bei der Kartenerstellung von Hand erstellt werden. Je nach Karte gibt es dann mehr oder weniger Linien. Falls du mehr Linien fahren willst, wirst du nicht drumherum kommen, dir bestehende Karten selbst zu erweitern oder neue Karten mit neuen Liniennetzen herunterzuladen. Das kannst du zum einen hier im Forum tun (Unterforen "Reale Karten" und "Fiktive Karten") oder in der OMSI-Webdisk. Falls du einfach nur neue Linien einstellen willst, kannst du bei bestehenden Karten die .hof-Dateien anpassen und dort neue Liniennummern hinzufügen. Dann kannst du sie schildern, aber auch nicht viel mehr.

Ich kann dir nur zu deinem ersten Satz Fragen helfen.

Hier die Kurzfassung: In Omsi kannst du jeden Türflügel einzeln steuern. Hat der MAN 3 Türen, so sind door_0 und door_1 die beiden Flügel von Tür 1, door_2 und door_3 von Tür 2 usw. Der Öffnungs- und Schließvorgang läuft in Omsi intern von 0 bis 1 (0 = Start, 1= Ende). Im einfachsten Fall läuft das linear, sprich dass du zur Zeit 0 bei Position 0 bist und z.B. zur Zeit 10 bei Position 1. Du kannst aber Türen auch ungleichmäßig aufgehen lassen, sodass sie z.b. kurz stoppen. Dafür musst du diese Kurve zwischen 0 und 1 um Zwischenpunkte erweitern. Das kann z.B. sein, dass die Tür zwischen 4s und 6s keine Bewegung vollführt. Dann müssen bei t=4 und t=6 die gleichen Zahlen hinsichtlich dessen, wieweit die Tür öffen ist, stehen.

Im gezeigten Codeabschnitt sind jedoch nicht die Positionen der Tür definiert, sondern mit welcher Geschwindigkeit sie wann ihre Bewegung vollführt. Willst du, dass beide Türflügel synchron arbeiten, musst du für beide Flügel einer Tür die Punkte der Kurve, die das Öffnungsverhalten beschreibt, angleichen. Willst du, dass ein Flügel schneller als der andere arbeitet, muss dieser schneller eine hohe Geschwindigkeit erreichen, indem du ihn seine Zielgeschwindigkeit früher erreichen lässt oder diese höher setzt als beim anderen Flügel.

Angepasst auf den Codeabschnitt steht da, dass die Tür zum Zeitpunkt 0 mit einer Geschwindigkeit von 0,2 öffnen soll, nach 0,3 Sekunden soll die Geschwindigkeit jedoch bei 1 liegen.
Für den Schließvorgang wird von Zeitpunkt 0 bis 0,7 bis 1 eine Geschwindigkeit von 0,75 vorgegeben, danach nur noch von 0,1.

(Anmerkung: Ich weiß nicht, ob OMSI zwischen einzelnen Datenpunkten interpoliert oder nicht, kann auch sein, dass du zwischen 0,7 und 1 eine Interpolation von 0,75 Geschwindigkeit auf 0,1 hast.)

Nachdem ich letzte Woche den SG 321 NF von außen gezeigt habe, hier ein paar Bilder vom Innenraum

Da es momentan einigen Wirbel um den Fortbestand dieses Forums und in welcher Form es weiterexistieren wird, gibt, werde ich Neuigkeiten zum Bus sowohl in diesem Thread, als auch in der OMSI Webdisk posten. Affektgetriebene Handlungen führen manchmal zu lustigen Ergebnissen und ich fänds schade, wenn als Resultat dessen dieser Thread geschlossen würde.

Das von mir vor knapp einer Woche gezeigte Gelenk ist dann nun auch eingebaut. Hier zu sehen: Der Grund, weswegen momentan nix beim S 315 NF passiert.

Bus: Setra SG 321 NF (fiktiv)
Blender Cycles Rendering

Blender-Rendering eines Hübner Niederflurgelenks für ein noch in der Arbeit befindliches Busprojekt

Moin zusammen,

diese Woche gibts das Update schon samstags, weil mir danach ist. Der Innenraum ist jetzt komplett mit Sitzen, Haltegriffen und Notsitzen ausgestattet. Bilder wie üblich unten.

Viele Grüße

der Stapellurch

Moin zusammen,

in den letzten Wochen sind die Fahrertür samt Anschlag, die Rückwand hinterm Fahrerarbeitsplatz, der Kasten unter der Feststellbremse, das Fahrgastpendel samt Halterung und der Kabelkanal hinterm Fahrersitz entstanden. Die Arbeiten an den Sitzen haben begonnen, sind aber noch nicht in vorzeigbarem Zustand. Bilder wie üblich unten.

Viele Grüße

der Stapellurch

Hmm, hast du beim Export den Haken bei "Selection only" gesetzt?

Wenn ich deine usrpüngliche Frage richtig verstehe, geht es dir darum, warum eine .obj Datei kleinder ist, als eine .x Datei, die die gleichen Modelle beinhaltet, wie die .x, richtig? Das liegt daran, dass beide Formate unterschiedliche Spezifikationen haben, wie sie 3D Flächenmodelle definieren. Als einfachen Test kannst du in Blender mal den normalen Standardwüfel als .x und als .ojb exportieren und dir die Ergebnisse im normalen Editor anschauen. Da beides ASCII-Formate sind, geht das. Du wirst sehen, dass die .obj Datei die gleiche Information enthält, aber einfach weniger Zeichen benötigt.
Grob interpretiert hast du in der .obj Datei folgende Ordnung (nicht durch irgendwelche Dateispezifikationen überprüft, sondern einfach interpretiert):

• Pfad zur Datei, die die verfügbaren Materialien enthält
• Objektdefinition
  • Liste der im Objekt enthaltenen Gitterpunkte
  • Liste der Normalenvektoren
  • Materialienzuweisung
  • Definition der Flächen

In der .x-Datei hast du hingegen:

• eine Frame Transform Matrix (wofür auch immer)
• Objektdefinition
  • Frame Transform Matrix
  • Definition der Gitterpunkte
  • Definition der Flächen
  • Definition der Normalenvektoren
  • Liste der Materialien mit Materialdefinition

Ich vermute stark, dass ich weiß, um welche Bodentextur es geht. Die habe ich gestern sowohl in 1024x1024 als auch 4096x4096 gefertigt. Da ich die von Blender generieren lasse, bin ich was die Auflösung angeht nur beim RAM meines Rechners begrenzt. Je höher die Auflösung, desto unwahrscheinlicher ist es aber, dass OMSI damit klarkommt.

Moin zusammen,

die vergangene Woche ist viel beim Setra passiert. Der Innenraum ist jetzt mit Haltestangen und den Trennwänden an den Türen ausgestattet. Auch sind die Türstangen jetzt auch oben befestigt. Weiterhin sind der Kasten oberhalb des Fahrerplatzes, die Wagen hält-Anzeige und die Uhr entstanden. Bilder wie üblich unten.

Viele Grüße

der Stapellurch

Schau dir die Flächennormalen deiner Sitze an. Die müssen alle nach außen zeigen, sodass du die Vorderseite der Fläche siehst. Tun sie das nicht, siehst du quasi die Rückseite und das wird von Omsi nicht dargestellt. Du kannst sowas beheben, indem du die fraglichen Flächen markierst und dann darauf "Flip Normals" ausführst.

Moin zusammen,

nach längerer Zeit gibts auch mal wieder was neues. Die Scheibenwischer, Kleiderhaken, Nothämmer, Haltewunschtaster, Türrahmen und Infrarotbake sind jetzt verbaut. Auch sind einige fehlerhafte Überlappungen beseitigt worden. Inzwischen bin ich auch bei unter 1 Million Gitterpunkten angelangt. Als nächstes kommen die Haltestangen im Innenraum.

Viele Grüße

der Stapellurch

Can you provide us some more information? How many vertices do your objects have in total? How large is the .x file? Do you get a resulting .o3d file in the directory where your .x file is located?

Moin zusammen,

die Reduktion geht weiter. Die Türstangen innerhalb des Fahrzeugs sind inzwischen eingebaut, die Deckenleuchten und Leuchten über der Tür auch, bei weiß auf weiß sieht man die aber nicht. Weiterhin sind die Matrixkästen verbaut und im Heckbereich oben die Abschlusselemente. Dann sind die Klappfenster samt Halterungen hinzugekommen und die Dachluken. Beweisbilder wie üblich unten.

Citaro C2 Hybrid: Die Kennzeichen sind notiert und kommen wieder dran, wenns wieder um die Texturen geht.

Viele Grüße

der Stapellurch

Moin zusammen,

über die Zeit zwischen den Jahren ging es mit der Detailreduktion im Innenraum weiter. Das Ergebnis sind untexturierte Wände, Fensterbänke und -rahmen, Radiatoren, Türmotorkästen, Dachkanäle und erste Deckenelemente. Beweisbilder wie üblich unten.

Die nächste Zeit werd ich mit weiteren Objekten und deren Reduktion verbringen, Texturen kommen erst danach. Den Grund dafür liefert unter anderem BusfahrerP. Wenn ich die Vereinfachung um 98 % im Schnitt über das gesamte Modell beibehalte, lande ich am Ende bei ~80000 Dreiecken, was immer noch viel ist. Auf der anderen Seite habe ich die Tage gelesen, dass einige andere Freeware-Busse teilweise auf über 400000 Dreiecke kommen. Ergo möchte ich erst mal alles runterreduzieren und dann schauen, wo mehr Details vonnöten wären bzw. ob überhaupt, damit ich die Texturen möglichst nur ein mal erstellen muss.

Damit noch einen schönen Sonntag

der Stapellurch

Wenn ich Fotos mit Maßangaben bekomme, kann ich Teile des Armaturenbretts bauen. Ich kann auch mal bl00dy_rAiN fragen, eventuell kann er einzelne Bauteile für mich ausmessen.