Posts by Marcel Kuhnt

The forum is in reduced operation. The Addon and Support forums remain open.
Please note that OMSI is no longer under development. Some of the developers are now working on a new simulator. Further information concerning the LOTUS-Simulator can be found here.

    Heute leider nicht soviel Zeit...


    Hab das Mesh rübergespiegelt und das Mapping auf die andere Seite gelegt. Dort müssen natürlich andere Ausschnitte erstellt werden (insbesondere Klappen statt Tankdeckel usw.). Wichtig war aber natürlich das passgenaue Mapping und zuvor natürlich nicht zu vergessen: Statt der Türen unten zugeblecht und oben noch einen Mittel-Fensterholm eingesetzt, damit alles stimmt!

    :)

    Vorne kommt da natürlich das Fahrerfenster hin, aber da muss ich mir erstmal das Dingen ausm D holen und umbauen (die Niederflurbusse mit tiefer Fensterkante haben ja ein anderes als die Hochflurbusse und die Niederflurer mit hoher Kante, logisch...)


    Zwecks Mapping hab ich die Textur wieder mal neu exportiert, diesmal ohne "Fotofetzen" sondern stattdessen nur mit Kalibrierungsmarkierungen.



    Edit: Achja, noch ein Tipp an dieser Stelle: Für die Feinarbeit hab ich die beiden Hälften Revell-mäßig getrennt! Denn dann besteht nicht die Gefahr, dass man aus Versehen die andere Seite "mitbearbeitet"...!

    ;)

    ah, I understand!

    ;)


    OK, take a look into the "Generic" directory:


    _Rad_ = Wheel
    HL = Hinten Links = Back left
    VR = Vorne Rechts = Front right
    HR and VL = Back right, Front left
    Fahrersitz = Driver's seat
    Frontklappenklickspot = click spot for opening the front door from outside
    Trennscheiben = windows between seats and doors
    Wagennummern = waggon number like 3967
    Panel = Dashboard
    IBIS_... = key ... on IBIS
    schatten = shadow
    schedule = this sheet, you know!

    ;)


    wimpel = the two flags you only see on special days like our birthdays!

    ;)


    Wischwasser = water for cleaning the front window...
    Zahltisch = cash desk
    Drucker = printer
    Ausgabe = output
    Fahrschein = Ticket (ok, you should know that already!

    ;)

    )
    Wechsler = This nice peace of mechanical technique where you just need to push a button and the money comes out!

    ;)


    And in the D92 directory:


    ...hebel = handle
    Blinker... = blinker!

    ;)


    Brems... = beak
    Fahrerfenster = Driver's window
    tuer = door
    Fahrpedal = throttle pedal
    Fenster_ext = all fixed windows, mesh for outside
    Fenster_int = ~ mesh for inside
    haltewunschtaster = this nice red button for the yellow lamp and the red "wagen hält"!

    ;)


    Heizung = heater
    Heizung_... = these levers for the heater
    Innenanzeige = bus stop display inside the bus
    Innenraum = everything "normal" inside the bus!

    ;)


    Innenwaende = inside walls of the bus
    Kinderwagenknopf = this button outside the bus next to the aft door
    Klappfenster = "openable" windows
    Lenkrad = steering wheel
    Hupe = horn
    lenksaeule = this bar where the steering wheel is on top!

    ;)


    leuchten = Lights
    Mikroschalter = switch to "open" the microphone
    Nothahn = red switch over the doors to open them manually (H = hinten = back door, V = vorne = front door)
    Panel_... = dashboard ...
    20h-Schalter = 20 o'clock switch
    Anlasser = starter
    Bremsdruck = brake pressure
    HA/VA = hinterachse = back axle, vorderachse = front axle
    Fahrerleuchte = driver's light
    Feststellbremse = parking brake
    Gangwahl = gear selection
    Geblaese = heating fan
    hour = stunde

    :D


    Hstbremse = bus stop brake
    Kilometer = km counter
    kuelwasser = cooling circuit
    Leuchte_unten_r = light on the [7]!

    ;)


    Motoabstellung = engine switch off switch
    Nebelschluss = fog back light
    Oeldruck = oil pressure
    Raendel_Klimator = adjustment wheel for the front heater fan
    Retarder_direkt = retarder direct!

    ;)


    Schluessel = key switch
    Spiegelheizung = reflector heater
    Standheizung = heater for the cooling circuit if engine is off
    Tachonadel = needle for the km/h's
    Tankuhr = fuel tank level
    Tuer_hand = switch to open the back door manually
    Tuertaster = door button
    Vorratsdruck_HA/VA = pressure in reservoir back/front axle
    Warnblinker = warn blinker
    Rollo = if the sun is too bright, you can pull this thing down!

    ;)


    Rollo_bommel = this tiny peace to get the Rollo back to the highest position!

    ;)


    sitze = seats
    spiegel = reflector (correct word???)
    Tuer = door
    HH = Back-Back (back door, back door wing!

    ;)

    )
    HV = Back-Front (back door, front door wing!)
    and so on
    Tuerbuegel = this kind of elements which hold the door
    Tuerlappen = this small peace of rubber on the floor end of the door which has to be animated seperately
    Wagenkasten = the MAIN MESH!

    ;)


    _dreck = dirt
    Wascher = front window washing system
    Wischer_Drehschalter = this turning switch on the left blinker switch for activating the wiper
    Wischerarm = the arm of the wiper
    Wischerblatt = wiper blade
    LOD = level of detail, detail-reduced meshs


    I hope this will answer your question!

    :D

    [aigroup_depot], letzte Zeile. Da steht der Name der Hof-Datei, die verwendet werden soll. Gibt's die? Oder heißt die anders? "Normal" gibts nicht, die haben alle Namen!!

    Ein bisschen mehr Rechtschreib-/Zeichensetzungs-Disziplin, bitte!


    Wichtig ist, dass die KI-Busse über die nötige Hof-Datei verfügen und in der ailists.cfg und (falls vorhanden) der ailists_#low.cfg auch die korrekte Hof-Datei eingetragen wurde:


    Heute abend gings weiter!


    Es ist nun an der Zeit, sich über die Texturaufteilung Gedanken zu machen. Damit nachher alles möglichst einfach wird - und weil der Nachläufer ohnehin völlig separat gerendert wird - erhalten beide Teile separate Texturen. Da der Hauptwagen aber kürzer als der NL ist, bleiben natürlich Flächen übrig. Die können dann später anderweitig genutzt werden, z.B. fürs Gelenk.


    Ich wählte also folgende Texturaufteilung, welche ich mit Blender-Screenshots auskleidete:



    Wichtig ist dabei, dass selbst bei kleineren Auflösungen (1024, 512, 256) immernoch das Rendern um die Ecken herum präzise möglich ist. Deshalb ist die Aufteilung exakt in vier Höhenteile gewählt. Die roten Linien sind in der 2048er Auflösung 8 Pixel breit, also genau 1 Pixel unter 256. Sie dienen dem genauen Mappen der Ecken, auch unter 256er Auflösung. Eine präzise und durchdachte Planung der Texturaufteilung, wie sie Rüdiger bei den SDs durchgeführt hat, ist es schließlich gewesen, welche das genaue und einfache Mapping der Repaints (allen voran Sander!) ermöglichte! Der Maßstab ist dabei natürlich innerhalb der Texturen des NG272 stets gleich (aber nicht im Vergleich zu den Doppeldeckern!).


    Das wird dann entsprechend aufs Objekt gebracht:



    Die Blender-Screenshots helfen dabei, das Mapping auch genau am Mesh auszurichten, die roten Linien helfen dabei, das Dach und die Seitenwand in Längsrichtung exakt zu "bekleben".


    Nun habe ich begonnen, "Schnipsel" aus zuvor reichlich gemachten Texturfotos wie beim Bau mit Pappmaché auf das Grundgerüst zu kleben. Das ist alles noch recht ungleichmäßig und dient im jetzigen Zustand vor allem dazu, die unregelmäßigeren Formen (insbesondere hier die Radausschnitte), die im Vorfeld nur mit groben Maßen vermessen wurden (Höhe mal Breite) genau zu modellieren. Dennoch können und werden diese Schnipsel später auch in der Textur anwendung finden. Allerdings dann natürlich auf ein etwas gleichmäßigeres und natürlich farblich an die SDs angepasstes Beige:



    Innerhalb der Textur im Texturmaster wird mit verschiedenen Ebenen gearbeitet - für Blender muss natürlich eine einfache Datei erstellt werden (jpg in meinem Fall, es ist ja ohnehin temporär). Wir diese aktualisiert, dann sieht das so aus:



    Wie man sieht, habe ich hier den hinteren Radausschnitt bereits aus einem Circle konstruiert. Wichtig ist natürlich, dabei die gewölbte Ebene der Seitenwand zu berücksichtigen. Hier mal Schritt für Schritt wird das Vorgehen beim Einbauen solcher Details erklärt.


    Schritt 1: Der Radausschnitt der Mittelachse wurde zur Vorderachse kopiert. Bemerkenswert: Die Höhe des Radausschnitts ist hier niedriger!



    Schritt 2: Anpassung der Form an die Vorderachse und Ausrichtung am tatsächlichen Rad! Dann passts zwar nicht mehr genau von der Textur, aber dann muss diese eben später angepasst werden!



    Schritt 3: Löschen der alten Polygone, die nun keine Funktion haben:



    Schritt 4: Erstellen neuer Polygone - diese sind natürlich noch untexturiert:



    Schritt 5: Retexturierung der neuen Polygone. Hierbei hilft es sehr, wenn man die restlichen Polygone markiert - diese sieht man dann im Image-Editor und kann die neuen Polygone millimetergenau platzieren!



    Fertig!



    Die Radausschnitte und auch der Deckel sind nun meshmäßig vorhanden (der Deckel, falls man ihn irgendwann mal benutzen möchte...

    ;)

    ).


    Damit ist die Seitenwand (meshmäßig!) im Grunde fertig - was man hier nicht sieht: Auf dieser Seite sind keine Klappen - die Textur aber stammt von der anderen Seite. Was natürlich doch noch fehlt, ist die Zierleiste, wobei ich noch nicht sicher weiß, ob die auch dreidimensional wird...


    Das nächste Mal kann dann die andere Seite erstellt werden - zwar ohne Türen, dafür aber mit Bodenklappen, die auch vorsorglich schonmal ausmodelliert werden. Und dann muss ich mich mit der Front mal intensiver beschäftigen!

    Ah, now I understand!


    Yes, this curve has to exist! But the answer is just very easy: If you do not have a curve, just make a "horizontal" curve with just a constant value (and only two [pnt]'s). Then you will not use this constant. Else you can also ADD the constant and create a curve without any correct value (but at least one [pnt]-entry!). But you can not add NO curve, then you will get this error message!

    Weiter gehts: Nachdem nun der Bus prinzipell (und mit SD202-Sound!

    ;)

    ) in OMSI funktioniert, besteht genug Motivation, das Mesh mit Leben zu füllen. Dankenswerter Weise hatte Rüdiger bereits vor einigen Monaten Experimente mit der MAN-Stoßstange dieser Generation durchgeführt. Die Scheibe und der Matrix-Kasten können zunächst direkt vom SD202 übernommen werden. Dann sieht das ganze so aus:



    Wenn man dem Bauhaus-Slogan (der auch gut zu OMSI passt!

    ;)

    ) folgen möchte, dann muss man auch die klitzekleinen Details beachten: So zeigte es sich sich auf Fotos, dass die Frontscheibe selbst zwar als "Standard-2-Teil" gleich geformt ist - aber die Wölbung der Außenhaut beim SD202 aber geringer ist als beim NL202, weshalb die Umrahmung ein wenig schmaler ist. Auf diesen Sachverhaltet deuteten aber auch die Maße, die im Innenraum genommen wurden:



    Im nächsten Schritt wurden die Türen vom SD202 importiert (hier kann ich natürlich auf bereits von Rüdiger getane Arbeit zurückgreifen):



    Allerdings mussten die Türen an die neue Wölbung angepasst werden - außerdem mussten die "Brüche" (die für die Wölbung der Außenhaut ja nötig sind) bei den Türen auf die gleiche Höhe gebracht werden wie beim restlichen Mesh: jeweils in die Höhe der beiden Fensterunterkanten sowie auf die Höhe der Zierleiste:



    Außerdem sind die Türen hier etwas höher als beim SD202 und die Türstangen haben ebenfalls eine etwas abweichende Anordnung. Diese beiden Uterschiede wurden auch jetzt schon angepasst, während weitere Änderungen, insbesondere bei der Aufhängung/Türkinematik erst später folgen werden. Auch ist noch nicht entschieden, wie die Flächen dargestellt werden, die hier noch beige sind, später aber schwarz und hinter Glas sein müssen, wie es bei modernen Bustüren üblich ist.


    Mit Hilfe von entsprechenden Maßen und der Türform sowie einem günstigen Foto von vorne wurde nun das vorläufige Profil des Wagens erstellt:



    Aus diesem Profil und der bereit gezeigten Maßzeichnung von der Seite konnten nun die ersten Polygone des Außenmeshs erstellt werden. Insbesondere im Bereich der Räder aber ist das natürlich nur vorläufig. Aber die Fensterstreben sind in diesem Zustand schon praktisch fertig:




    Schließlich wurde der Wagen aus der bestehenden SD202-Textur notdürftig (!!!! Das ist noch keine richtige Textur !!!!) texturiert. Aber immerhin kann man so schonmal ahnen, wie das später mal aussehen wird:




    Beim nächsten Mal wirds dann damit weitergehen, dass der grobe Aufbau der Außenmesh-Textur festgelegt wird... aber soweit bin ich selbst noch nicht!

    ;)

    Sorry, I cannot see your problem... Does this code work or not?


    Functions are possible: If you create a macro which loads or saves values to or from the register (l0, l1, ... s0, s1, ...) then you can bring these values in these registers before the macro starts und you can get them back after the macro quits!

    ;)

    Bitte beachten:


    Die Art und Weise, der Preis und vor allem der Termin einer wie auch immer gearteten Veröffentlichung irgendeiner hier präsentierten Neuheit steht noch nicht fest! Fragen hierzu werden gelöscht.



    Da ich hier ja über ein Projekt berichte, welches von offizieller Seite herkommt, erlaube ich mir mal, dieses Thema anzupinnen!

    :)


    Gelenkbusse. Ein Spezialthema in Hinblick auf OMSI. Wer jemals dreidimensionale Starrkörper-Physik programmiert hat, wird ahnen, dass es kompliziert wird, wenn mehrere Körper miteinander interagieren (und das ist ja beiweitem nicht nur dort der Fall, HAHAHA). Und ein Gelenkbus besteht ja de Facto aus mehreren Körpern.


    Nun also ist es an der Zeit, mal wieder über eine aktuelle Entwicklung von offizieller Seite zu sprechen: Endlich ist es gelungen, die Gelenkphysik zumindest auf einen guten Weg zu bringen. Soll heißen: Es schaut schon wesentlich besser aus als bei den Versuchen, die seitens der Community unternommen wurden (mit den bestehenden, völlig unzureichenden Möglichkeiten). Perfekt ist es leider noch lange nicht, es ist ein einziges Zittern. Aber dazu später mehr.


    Das Versprechen, einen dazugehörigen Bus zu liefern, stand ja von Anfang an im Raum. Und deshalb ist es nun an der Zeit gewesen, die Entwicklung am OMSI-Gelenkbus zu beginnen.


    Und weil wir ja weiterhin in der "sandgelben Ära" der BVG verweilen wollen, gibt es genau drei Kandidaten (wenn man die gebrauchten Hochflur-O405er mal außen vor lässt): Mercedes O405GN, Neoplan N4012NF und MAN NG272. Neoplan-Gelenkbusse der beigen Generation fahren schon länger nicht mehr und uns fehlen sämtliche Unterlagen. Beim O405GN gibt es noch ein ganz anderes Problem, aber ohne Probleme und mit genug Material im Rücken (Soundaufnahmen bewährter OMSI-Qualität, Maßzeichnungen, Fotos) ist der MAN NG272 der (einzige) geeignete Kandidat, auch wenn er gerade für Spandau vieleicht nicht unbedingt der typischste Vertreter war. Aber genauer können das hier die Experten beurteilen!

    :)


    Um gleich mal wieder einige Erläuterungen los zu werden, dann später auch in Hinblick auf die neuartigen Funktionen, die mit der Gelenkbusunterstützung dazukommen werden, werde ich die Gelegenheit nutzen und auch Tagebuch schreiben.


    Den Anfang machte die Auswertung von offiziellen Maßen (LxBxH, Radstand, Einstiegshöhen) sowie natürlich der liebevoll händisch angefertigen Maßzeichnungen. Diese werden erstmal in ein maßstabsgetreues Abbild, bestehend nur aus Linien (Edges) in Blender übertragen:



    Da aber die Gelenkphysik natürlich noch nicht ausgereift ist, hab ich mir zum ausführlichen Testen erstmal ein Fahrgestell gebaut:



    Dem aufmerksamen Beobachter wird nicht verborgen bleiben, dass sich dahinter auch der zugehörige Solowagen befindet (in Berlin allerdings mit "hoher" Fensterkante, im Gegensatz zu dem hier im Forum bereits beschriebenen NL202 der zweiten Generation). Es liegt natürlich nahe, z.B. die Texturaufteilung gleich so zu gestalten, dass beide Fahrzeuge ohne große Umstellungen daraus konstruiert werden können.


    Die Einbindung erfolgt nun so, dass zunächst Hauptwagen und Nachläufer einzeln als separate Bus-Dateien konstruiert werden. Hierzu müssen die Exporte der Meshs auch so erfolgen, dass jeder einzelne Bus-Teil um seinen Mittelpunkt (aktuell muss es der Schwerpunkt sein, kann aber sein, dass wir diesen hierfür nochmal frei konfigurierbar machen) konstruiert wurde. Oder noch besser: Man wählt einen einfachen, definierten Abstand zwischen den beiden Einzelschwerpunkten, in diesem Fall 8,5m, und kann dann den Bus vor- und zurückschieben, bevor man Hauptwagen oder Nachläufer exportiert.



    Schließlich erhält die *.bus-Datei des Hauptwagens folgenden Eintrag:


    Code
    1. [coupling_back]
    2. 0
    3. -4.331
    4. 0.315
    5. [couple_back]
    6. MAN_GN92_trail.bus
    7. false


    [coupling_back] definiert eine Kupplung am Heck des Fahrzeuges,
    [couple_back] kuppelt einen anderen "Bus"/Anhänger oder was auch immer, an der Heckkupplung an, wobei der Eintrag "false" dafür steht, dass dieser Anhänger NICHT "umgedreht" wird (wie es z.B. bei den S-Bahn-Vierteln der Fall ist).


    Der Nachläufer erhält natürlich dementsprechend eine Frontkupplung:


    Code
    1. [coupling_front]
    2. 0
    3. 4.169
    4. 0.315


    Später wird es noch weitere Befehle geben, welche darüber entscheiden, ob sich der Nachläufer eher wie ein Auflieger oder Gelenkbus-Nachläufer verhält oder eher wie ein mehrachsiger Anhänger mit Deichsel. So zumindest unsere bisherige Planung.


    Soweit, so gut - jetzt noch die Meshs exportieren und die Radanimationen wie gewohnt einbauen. Und der erste, wenn auch noch sehr spartanische Gelenkbus kann in OMSI umherfahren:



    Als nächstes gehts dann an die ersten Konstruktionen des Wagenkastens... (nächster Beitrag)

    And you have to move the vehicle with its wheels in such a way that the wheels touch the X-Y-plain but their springs are NOT deflected. Our SDs and Ds have an automatic level adjustment which will be done via script.

    Ah, stimmt, so geht's, klar!

    ;)


    Der auskommentierte Wert dürfte aus der Zeit kommen, wo die Geschwindigkeit und die Traktion noch linear gemessen wurden (m/s und N). Mittlerweile aber ist es Raddrehzahl und Drehmoment, sodass also nur der Wert in der Bus-Datei relevant ist!


    Die Erdbeschleunigung ist bei OMSI stets 9,81 m/s²

    Also, jetzt kommt die richtige Physik ins Spiel!

    ;)


    Zuallererst: Klar, OMSI weiß natürlich intern, wie der Bus steht. Aber ich bezog mich auf die Sensorik, also das, was man im realen Leben hinbekommt.


    Und da hilft ein G-Sensor (also ein Beschleunigungssensor) herzlich wenig, da er alleine nicht unterscheiden kann, ob du Gas gibst ("in den Sitz drücken") oder mit konstanter Geschwindigkeit den Berg hinauffährst ("in den Sitz drücken"). Und einen Neigungswinkel-Sensor - ja, wie soll der physikalisch aussehen? Das einzige, was ich mir vorstellen kann, wär eine Trägheitsplattform, die man ja mittlerweile in jedem IPhone hat - insofern wirds vmtl. so sein... aber die gibts in OMSI leider (noch) nicht so, dass man sie per Script-System abfragen kann.


    A_Trans_Z bedeutet übrigens nichts weiter als A = Beschleunigung, Trans = Translation = geradlinige Bewegung und Z = Z-Achse, sprich: Beschleunigung entlang der Z-Achse. Gemessen aber im fahrzeuginternen Bezugsystem. Im Grunde ist das genau der Wert, den du mitbekommst, wenn du im Busfahrerplatz sitzt und dieser sich auf und abbewegt!

    ;)


    Aber bei aller Theorie: Letztlich willst du ja nen Neigungswinkel-Wert haben. Und diese Bitte muss ich dir eben leider in der aktuellen Version ausschlagen, das geht momentan nicht.

    Nein, das geht aktuell nicht. Ich werde es mal in die Todo-Liste aufnehmen.


    Allerdings frage ich mich, wie die realen Getriebe das berechnen? Denn den Gradienten kann man ja technisch gar nicht direkt bestimmen!


    Das einzige Verfahren, was denkbar ist: Längsbeschleunigung (trägheitsmäßig) mit der Beschleunigung der Räder vergleichen. Dann ergibt sich die Steigung bzw. das Gefälle als "Überschuss" der Längsbeschleunigung. Beispiel: Wenn ich mit konstanter Fahrt einen Berg mit 10% herunterfahre, dann werde ich ja trägheitsmäßig als "Insasse" Richtung Front mit 0,1g beschleunigt. Da ich über die Räder aber merke, dass der Bus nicht schneller wird, weiß ich, dass dieser Anteil nur vom Gefälle herkommt! So könnte man es sogar scripten, weil man ja die Raddrehzahlen bzw. sogar die tatsächliche Geschwindigkeit des Fahrzeuges und auch die Beschleunigungswerte im Innenraum ablesen kann! (Wobei ich jetzt nichtmal genau sagen kann, ob diese auch das Gefälle beinhalten... muss ich direkt mal testen!

    ;)

    )


    Edit: Nein, leider ist es von mir nicht ganz konsequent eingebaut worden: Auch im Gefälle bei konstanter Geschwindigkeit ist der Wert der Beschleunigung 0, d.h. die Hangabtriebskraft taucht nicht auf.


    Insofern geht es zur Zeit leider gar nicht...