Beiträge von Marcel Kuhnt

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.

    Die Hauptarbeit besteht momentan einfach darin, die verschiedenen Flächen erst zu mappen und dann eine entsprechende Textur aus den vielen Fotos zu erzeugen. Das ist meistens eine ziemliche Flickerei. Die Fahrerrückwand ist z.B. auf Basis einer homogenen, fotorealen braunen Fläche entstanden, die dann entsprechend schattiert und mit Details belegt wurde. Andere Bauteile, wie das große Plastikteil über der Frontscheibe, kann man aber in einem Stück aus den Fotos extrahieren. Diese Teile sehen dementsprechend natürlich besonders realistisch aus!

    ;)


    Nach reiflicher Überlegung habe ich mich doch dazu entschieden, die Gummieckleisten meshseitig abzutrennen, damit sie in einer höheren Auflösung dargestellt werden können. Nachdem dies komplett geschehen ist, habe ich außerdem die Seitenwände sowie die Vorderachskästen texturiert:


    (Der dunkle Fleck auf dem ersten Screenshot ist übrigens nur ein Test, wie man am Besten diffuse Schatten einarbeiten kann...)



    Jetzt geht's ans Texturieren! Die Aufteilung der Textur richtet sich wieder ein bisschen danach, dass man auch einen NL202 bauen kann, ohne dass man zu viel neu mappen muss.


    Zuerst wurden die Böden und die Oberseiten der Podeste gemappt. Die Texturaufteilung wurde dann per Screenshot festgehalten, sodass man bei den Arbeiten an der Textur wieder eine möglichst genaue Vorlage hat:



    Lustig sieht es aus, wenn man die so erzeugte Textur wieder anwendet:

    ;)



    Auf die Textur kann man jetzt nach belieben solange fotoreale Flicken arangieren, bis man zufrieden ist. Ich habe schonmal mit dem hellen und dem dunklen Boden angefangen (die wiederum von Rüdigers D "geklaut" sind) und ein paar fotoreale Nähte und die erste Gummilippe platziert:



    Was dann so aussieht:


    So, die Innenverkleidungen sind fertig modelliert! Es fehlen natürlich noch sämtliche Einbauten, angefangen bei den Sitzen, dann die zahllosen Griffe und Griffstangen bis hin zu den noch fehlenden Teilen am Fahrerarbeitsplatz. Aber die werden separat texturiert.


    Das heißt also, jetzt kann ich mit dem Mapping und den Texturen für die Innenverkleidungen anfangen! Mal sehen, wie schnell ich da vorankomme - wir haben ja ne schöne Summe an Fotos und verschiedene Texturen werden ich auch wieder aus dem D verwenden können, vermute ich mal...


    Weiter geht's mit dem Mesh... viele kleine Ecken waren ja immer noch nicht fertig: Dieses Plastikteil über der Mittelachse auf der linken Seite, die Fahrerrückwand (aber von der Fahrerseite aus gesehen) oder - noch nicht fertig - das große Plastikteil über der Frontscheibe mit den Vertiefungen für die Rückspiegel...




    Und weiter geht's mit dem Innenraum-Mesh. Heute habe ich mich bis zum Gelenk vorgekämpft! Langsam wirds also spannend. Noch aber ist das Gelenk nur sehr theoretisch ein Kreis und die Podeste schmiegen sich schonmal an.


    So langsam sind auch alle Maße vom Innenraum-Mesh für den Hauptwagen "verbaut", es fehlen nur noch wenige... außerdem weiß ich noch nicht recht, ob ich zuerst den Nachläufer auf denselben Stand bringe oder erst die Texturen anlege...




    Hab vorhin die bereits exportierten (aber nun verschobenen) Panel-Bauteile erneut exportiert. Dabei wollte ich gleich nochmal auf eine Vereinfachung hinweisen:


    Wenn man mehrere Bauteile exportieren möchte, die allesamt in der Form vorliegen, dass EIN Blender-Objekt zu jeweils EINER o3d-Datei werden soll (hier: Zeiger und km-Zähler-Röllchen), dann gibts dafür eine spezielle Funktion im o3d-Exporter.


    Wichtig ist, dass alle o3d-Dateien mit "GN92_Panel" beginnen und dann die einzelnen Objekte "_hour.o3d", "_tachondel.o3d" usw. heißen sollen. Man kann in so einem Fall den Objekten die Namen "hour", "tachonadel" usw. geben und dann alles zusammen als EINE x-Datei exportieren, die dann den Namen "GN92_Panel.x" erhält.



    (Im Bild wurde das Km-Zähler-Röllchen für die Zehntausender-Stelle markiert, welches in Blender "kilometer_10000" heißt)


    Nun konvertiert man die o3d-Datei mit aktiver Option "Separate Files":



    Automatisch legt der Konverter für jedes Blender-Objekt in der X-Datei "GN92_Panel.x" wie gewünscht die o3d-Dateien an! Somit konnte ich das Panel mit nur zwei Export- und zwei Konvertierungsvorgängen komplett nach OMSI transferieren (einmal Panel-Träger, welcher ja mehrere Objekte beinhaltet, die zu einer o3d-Datei werden sollten und dann die ganzen animierten Einzelteile).


    Nachdem nun die Türausschnitte am Original begutachtet werden konnten (und ausgemessen), gehts nun mit dem Innenraum weiter. Bei der Gelegenheit habe ich festgestellt, dass der gesamte Fahrerarbeitsplatz samt Instrumententräger nochmal 3cm nach vorne verschoben werden musste. Früher oder später also müssen die bereits exportierten Instrumententräger, Zeiger, Leuchtmelder und seit heute auch km-Zähler-Röllchen nochmal exportiert werden. Nun ja, was solls...


    Man beachte beim Screenshot vor allem die Schutz-Plastikteile, die beim NG272 um die "Türhebelstangen" herum angeordnet sind.



    Als nächstes kommen die Podeste rund um die Mittelachse dran und so langsam auch die Verkleidungen rund um das Gelenk. Bevor das Gelenk selbst kommt, werden ich aber wohl erst noch den Innenraum vom Nachläufer bauen. Und irgendwann zwischendurch muss das Zeug noch texturiert werden. Arbeit, Arbeit, Arbeit!

    :)

    Eine kurz Nachreiche für heute:


    Tachonadel und Uhr im Tacho sind jetzt auch vom D92 importiert worden und stehen zur Verfügung. Diese Bauteile wurden bereits von Rüdiger so erstellt, dass die X-Achse die Rotationsachse ist, sodass ein simpler o3d-Export (hier natürlich aufgrund der Animation eine o3d-Datei pro Zeiger) mit den entsprechenden Einbindungsbefehlen gereicht hat, die auch die nächtliche Beleuchtung ermöglichen.


    Der zugehörige Quelltext für die Interessierten:



    Besonders lustig beim Screenshot: Der Leuchtmelder "Zentralschmierung" leuchtet ja abhängig vom Kilometerstand, aber mehr oder weniger zufällig aber vor allem sehr selten auf. Aber just bei meiner zweiten Testfahrt gerade eben mit Leuchtmeldern und jetzt ja auch Tacho ging sie an! Super, konnte man gleich sehen, dass auch sie funktioniert!

    ;)


    Da ich mich generell mit der Vorgehensweise an Rüdigers SD202 orientiere, baue ich demzufolge auch das Panel so, wie er es getan hat.


    Der Instrumententräger, den ich gestern schon vom D92 importiert habe, gehört zur o3d-Datei GN92_Panel.o3d. Diese Datei enthalt außerdem das Mikrophon, den Rollo-Halter und die Pedal-Halter sowie Funkgerät, IBIS und auch die ganzen Leuchtmelder. Allerdings müssen diverse Bauteile wie die Zeigerinstrumente beleuchtet werden und weitere Bauteile wie die Leuchtmelder und das Display vom IBIS müssen selbst leuchten. Dazu kommt die Schrift auf dem IBIS. Die Einbindung nach OMSI ist also hier etwas komplizierter, aber dennoch systematisch möglich, wenn man erstmal weiß, wie der Hase läuft!

    ;)


    Aber erstmal mussten die Zeigerinstrumente zurechtgerückt werden und die entsprechenden Leuchtmelder ergänzt (der GN hat ja doch noch ein paar mehr Funktionen). Das Ergebnis:



    Für die Funktionen ist nun folgendes wichtig:


    * Die Glasabdeckungen wurden mit der Textur "Fenster.tga" belegt, die IBIS-Schrift mit vier individuellen Texturen (aufgrund der Verspätungsanzeige war das beim IBIS-2 schon beim D92 nötig). Auf die IBIS-Schrift soll hier aber weniger eingegangen werden.
    * Alle anderen Teile werden mit der Textur G92_Panel.bmp belegt, außerdem gibt es die Lightmap ("einfarbig", dienen der Aufhellung, also Beleuchtung der Texturen) G92_Panel_LM.bmp und die Nightmap (für Selbstleuchtendes wie Leuchtmelder) G92_N.bmp


    Wär nun alles in Blender nur ein Objekt, dann hätte man das Problem, dass man nur sämtlichen Polygonen (also sämtlichen Leuchtmeldern) gleichzeitig die Nightmap zuweisen kann. Sie könnten also alle nur gleichzeitig an oder aus sein, aber nicht individuell verschiedene Zustände annehmen.


    Aus diesem Grunde werden die genannten Bauteile, insbesondere Instrumententräger, jeder Leuchtmelder für sich und die IBIS-Front (mit der Displayzeile) in einzelne Blender-Objekte aufgeteilt! (Taste [P]) Werden sie nun alle markiert und in eine o3d-Datei exportiert, dann bleiben sie dennoch getrennt ansteuerbar. Und hier kommt dann die ominöse Zahl, die immer nach dem Texturnamen im [matl]-Befehl folgt, ins Spiel!


    Die Objekte bekommen nämlich eine bestimmte Namensgebung und damit eine bestimmte Reihenfolge für den Export (ist übrigens auch die Renderreihenfolge innerhalb der o3d-Datei):
    Panel_00_GN92: Instrumententräger
    Panel_01_GN92: Zeigerinstrumentenskalen (werden nachts beleuchtet)
    Panel_02_GN92: IBIS-Gerät (nachts leuchtet die Displayzeile)
    Panel_03_GN92: Leuchtmelder Störung
    Panel_04_GN92: Leuchtmelder Kühlwasser
    usw.


    Die restlichen Objekte (Textzeilen, Glasabdeckungen) werden zwar unabhängig davon benannt, spielen aber keine wichtige Rolle in der obigen Numerierung, weil sie ohnehin nicht die GN92_Panel.bmp enthalten.


    In der model.cfg kann nun gezielt mit


    Code
    1. [matl]
    2. GN92_Panel.bmp
    3. 0 - 1 - 2 - 3 - ...


    auf die einzelnen Bauteile zugegriffen werden.


    Außerdem muss zum Verständnis noch die Funktionsweise von [matl_change], [matl_item] und [viewpoint] eingegangen werden.


    [viewpoint] steuert die Sichtbarkeit. 0 = immer, 1 = draußen, 2 = drinnen, 4 = nicht aktiver Bus (verlassener Userbus, KI-Busse, mit denen man nicht mitfährt usw.) Entweder man verwendet "0" oder man addiert die gewünschten Bedingungen. In diesem Fall soll das Panel von innen und außen sichtbar sein, jedoch nicht bei anderen Fahrzeugen. Daher die 1 + 2 = 3.


    [matl_change] arbeitet zunächst wie [matl], er setzt den "Fokus" auf eine bestimmte Textur im Objekt, sodass man dann weitere Eigenschaften festlegen kann. Zusätzlich definiert man aber eine Script-Variable, die mit Hilfe der [matl_item]-Befehle die Materialeigenschaften beeinflussen kann. Ist die Variable 0 oder hat sie einen zu großen Wert, dann werden die Eigenschaften angewendet, welche unmittelbar auf den [matl_change]-Befehl folgen. Dann aber folgt ein [matl_item]-Befehl, auf den alle Eigenschaften folgen, die bei Var = 1 aktiv sein sollen. Folgt ein weiterer [matl_item]-Befehl mit weiteren Eigenschaften, dann gelten die bei Var = 2 usw.


    Der typische Aufbau für die Leuchtmelder ist also:



    Zuerst wird der Fokus auf die Polygone gelegt, welche mit GN92_Panel.bmp in der dritten "Gruppe" liegen, das ist der Leuchtmelder "Störung". Dazu kommt die Variable "cockpit_light_masterfailure", die im Script-System zur Ansteuerung des Leuchtmelders definiert wurde.


    Da dann gleich ein [matl_item]-Befehl folgt, beginnt sofort die Definition für den Fall, dass die Variable den Wert 1 hat. Dann kommt der Befehl [matl_nightmap], welcher für eben diesen Fall die Nightmap "GN92_N.bmp" zuweist. Also: Ist die Variable 1, wird die Nightmap angewendet, sonst nicht, genau das, was wir wollten!

    ;)


    Und der ganze Anfang für die GN92_Panel.o3d ist hier nochmal nachzulesen - die restlichen Leuchtmelder hab ich mir erstmal gespart!

    ;)



    Und: Es funktioniert!

    :D


    Heute hab ich im Innenraum weitergemacht. Die fehlenden Maße betreffen ja die Türbereiche, also hab ich mich intensiv mit der Fahrerkabine beschäftigt: Zunächst die Rückwand, dann den "Dachquerträger" (wo später die Haltestellenanzeige sitzt) und schließlich die entsprechenden Bleche am, vorm, neben dem und unterm Fahrer!

    ;)

    Bei der Gelegenheit und zum Test hab ich auch schon das D92-Panel importiert und auch schon leicht modifiziert (Haltewunschlampe, Motortaster und Schloss sitzen anders und auch die Schalterreihen sind etwas nach außen verrückt). Exportiert wurde das Panel auch gleich - und eingebunden, denn der Aufwand ist ja ohnehin beim Panel recht hoch: Sehr viele Einzelteile und diverse Effekte (Beleuchtung und Reflexionen), sodass es nicht schaden kann, frühzeitig mit der Einbindung zu beginnen!

    ;)


    Solange der Innenraum noch mangels exakter Maße warten muss, hab ich heute mal den Unterboden fertig gemacht (naja, abgesehen vom Gelenk, natürlich!

    ;)

    ).


    Hab mich dabei beim SD/D bedient, sowohl was die Textur angeht (die ich aber zurechtretouschiert habe) und auch das Modell. Es ist ja ohnehin nur für den seltenen Fall, dass man den Bus umschmeißt und damit man ein bisschen Gerödel unterm Bus sieht, wenn man sich duckt!

    ;)





    Hallo Andy!


    - Wie oft wird sie aufgerufen? Im aktuellen OMSI schlicht in jedem Frame. Das kann sich aber künftig ändern, falls wir dazu übergehen sollten, Bilddarstellung und Scriptverarbeitung zu desynchronisieren...


    - Die Uhrzeit kann man leider nicht abfragen - das ist natürlich ne dumme Sache, aber es ist nunmal keine Fahrzeugvariable. Man könnte aber dem jeweiligen (!!) Bus ein Scriptupdate verpassen, was die Variablen rüberkopiert. Ist aber natürlich seehr umständlich. Kommt in die Todolist.


    - C++: Keine Ahnung! Ob das Gegenstück von "var" in Delphi bei C++ ein Zeiget ist, vermag ich nicht zu sagen...!


    Marcel

    Faszinierend - in diesem Thread stehen 36 Kommata. 34 davon stehen in der Titelleiste der jeweiligen Beiträge ("Sonntag, 8. Januar 2012, 18:04"). Die anderen beiden sind von Foob!


    Sagt mal, luckysunyblue und philipp99, ihr habt beim Registrieren hier im Forum die Forenregeln akzeptiert - würdet ihr euch bitte auch an Regel 4.5 halten? Bitte verwendet auch Kommata und Punkte! Euer Schreibstil ist grausam! Alleine der Titel "sitze einsetzen wie?"


    Erstens: "Sitze" GROSSSCHREIBEN Die stehen (in deiner Variante der Überschrift) einerseits am Satzanfang und andererseits sind es Substantive! Sitze kann man anfassen, also schreibt man sie groß!!
    Zweitens: Die Frage lautet korrekt "Wie setzt man Sitze ein?"


    Um es mit dem Dicken zu sagen: "Wo haben Sie eigentlich schreiben gelernt, Junger Mann?? Man, man, man!!"

    *Kopfschüttel* Zugegeben, die Fehlermeldungen sind oft unverständlich. Es ist aber auch klar, dass ein sauberes und genaues Arbeiten Schritt für Schritt ohne Probleme möglich ist. Man muss aber natürlich alle Dateinamen richtig schreiben usw.! D.h. wenn eine Fehlermeldung kommt, hat man irgendwas falsch gemacht. Um herauszufinden, was, muss man einfach nochmal alles prüfen, was man geändert hat!

    Jetzt geht's los mit dem INNENRAUM!


    Während es bei der äußeren Schale vor allem auf die perfekten Proportionen und die perfekte Textuierung ankommt, warten im Innenraum ganz andere Herausforderungen: Unzählige von kleinen, verwinkelten Ecken, deren geometrie meist nur schwer festgehalten werden kann und man somit immer irgendwas vergessen hat zu vermessen. Dann muss der Innenraum nahtlos an das Außenmesh "passen" (was vor allem bei den Türen ziemlich kompliziert ist) und dann muss bei der Textuierung noch in Betracht gezogen werden, wie der Bus nachher beleuchtet wird.


    Begonnen hatte ich ja vor längerer Zeit bereits mit den Bodenteilen vom NL202, dann habe ich erstmal mit den Fensterstreben und den relativ einfachen Verkleidungen über den Fenstern begonnen. Der Übergang zur Tür war dann der nächste Schritt, aber da fehlen mir noch einige Maße/Proportionen, die man nur sehr schwer aus den Fotos herleiten kann.



    Dadurch, dass die Form der Radkästen im Innenraum nun feststeht, konnte ich die Radkästen auch fürs Außenmesh bauen (erstmal nur die Vorderachse):




    Ein typischer Trick, den wir sehr oft anwenden: Das gezielte Verschieben von Objekten um einfache Werte (z.B. exakt 5m) erlaubt ein einfacheres Arbeiten, aber auch ein sauberes zurückschieben für den Export! Zwischendurch sieht es dann z.B. so aus:



    Schließlich habe ich den Boden und die Podeste weiter verfeinert:



    Ziemlich schwierig, weil weder zwecks Ausmessen erreichbar noch anständig fotografierbar sind die Dachaufbauten. Deshalb wurden die Sicken / Kerben / wasweeßickdenn synthetisch aus "Fotoresten" hergestellt, ebenso die Umrandung für die Dachluken, welche ja ohnehin nur dann wirklich sichtbar ist, wenn die jeweilige Luke offen ist. Auch diese Lüfterdinger am Heck waren nur anhand eines von weitem aufgenommenen Fotos einigermaßen präzise nachbaubar!

    ;)

    Dennoch macht die Topansicht gleich was her mit den nötigen Details:



    Die Lüfterdinger sind außerdem getrennt vom Dach und jeweils separat gemappt. Man kann nach belieben das Dach gelb und die Lüfter blau anstreichen oder aber auf den rechten Lüfter ein "L" und auf den linken ein "R" raufschreiben, je nach Lust und Laune!

    :)

    Spiegel (funktionierend natürlich, siehe insbesondere: http://www.omnibussimulator.de…ug-SDK#Reflexionstexturen ) und auch die am Hauptwagen angepassten Lichtquellen waren heute der nächste Schritt.


    Allerdings muss ich gerade heute ganz klar sagen, dass ich (nachdem die Außenhaut erstmal stand) vor allem deshalb so schnell vorankomme, weil ich mich großzügigerweise der Guttenberg- ääh Copy'n'Paste-Methode bedienen kann: Z.B. sind die Spiegel völlig identisch zum SD202 und brauchten nur ein wenig zurechtgerückt werden, auch die Textur hatte Rüdiger ja einst schon erstellt. Ebenso die Lichtquellen: Die Ähnlichkeit der Blinker und vor allem der Scheinwerfer erlaubte es mir, auf die bereits fein justierten Lichtquellen-Eigenschaften und die rechteckigen Scheinwerfer-Texturen vom SD202 zurückzugreifen. Nur die Koordinaten mussten ermittelt und neu eingefügt werden. Rüdigers Beitrag zu dieser Arbeit ist also (obwohl er zur Zeit nicht aktiv am Bus mitarbeitet) dennoch nicht zu unterschätzen! Außerdem baue ich auf einer Menge Know-How auf, welches er in Pionierarbeit erstmal selbst erarbeiten musste, z.B. wie das mit der Annax-Beleuchtung funktioniert oder das Prinzip, mit dem die dynamischen Nummern idealerweise aufgebracht werden.


    Hier nun aber das Resultat von heute bis jetzt: