Mercedes Benz O309D Kleinbus

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


    Hui, die Passagiere drücken den Tri-Count gut nach oben xD 5600 knapp... Für so ein kleines Büssle schon beachtlich *duck* Dabei hab ich scho immer das Gefühl, dass ich so sparsam und grob wie möglich arbeite >< Naja, seis drum - wofür gibts das LoD1 mit mageren 84 Tris (falls ich die Räder doch mit ins Lod1 nehm, werdens halt ~400).


    Zu den Bilderchens: Zuerst wurde Heinz platziert. Der Faulheithalber hat er sein schickes Blaues Hemd behalten ^^ Hoffe es wirkt nicht ZU uniformiert :P Danach mal ein Gruppenbild unserer Gewerkschaftsmitglieder, wie sie gerade zum Streiken fahren wollen - ich muss mich beeilen, das noch fertig zu bekommen! Und anschließend wieder Export-Vorbeireitungen. Mesh auswählen, mit Tab in den Editmode, mit A alle Flächen markieren und mittels Strg+T die Flächen triangulieren - weil n-gons (Vielecke, Polygone mit n (also 5 und mehr, mit 4en fällts für mich noch unter Quads ^^ ) Vertices) mag der Exporter nicht. Und auch OpenGL mag meinem Wissensstand nach nur noch Tris. Nachdem wir alles durch haben, können wir auch schon ans Exportieren denken. Der erste Schritt des "Rausschreibens".



    Dazu wählen wir unser "Model"-Objekt aus, stellen vorsichtshalber sicher, dass alle Meshes sichtbar sind (nicht wie hier bei mir aufm Bild mit dem Fenster ^^) - geht zwar glaube auch so, aber es schadet ja nix - und hangeln uns im Menü wie gezeigt vor. Nun kommen wir zu folgender Ansicht:



    Ganz wichtig! Unten müssen wir "Bus" statt "Train" auswählen. Vergisst man das, hat man plötzlich nen Zug für TF gebaut ^^ Kann man zwar händisch alles wieder zurecht biegen, aber das ist arge Fummelarbeit (nix gegens Fummeln, aber nuja :P ). Mit "Hidden Faces" können wir glaube auch so ausgeblendete Sachen wie mein Fensterchen da mit exportieren, ich haks immer mal mit an, viel hilft viel! Merk bekommt sicher nen Schock beim lesen :P "Select ngons" - joa, wie das funzt, das habsch au noch ned rausgefunden. Wenn ich ma was vergessen hatte, war da nie irgendwas selektiert ^^ Oder ich habs einfach übersehn *schulterzuck* Nuja, Erklärungen gibts ja eigentlich auch im Lexikon und im Tooltip auch son bissl. Haben wir alles eingestellt, klicken wir hart auf "Export TF-Object" (nicht im Bild, wäre dann oben rechts) und hoffen, das alles klappt. Wenn er irgendwas wegen camera not found nölt, dann den Haken bei UI Files rausnehmen und nochmal machen. Am besten in so einem Falle alles, was im Kauf/Vorschau-Bild zu sehen sein soll markieren, zusammenfügen und kopieren. Dann (ohne speichern!) ein neues Projekt öffnen, den Würfel mit x killen und euer Machwerk einfügen. Nun wieder Model und Lod tüdeln, dem Model nen gescheiten Namen geben (oder halt eurem Bildchen nachm Exportieren nen anständigen Namen verpassen) und exportieren - mit UI Files bla, oder auch nur damit. Dann sollte das eigentlich klappen. Meins sah am Ende so aus:


    Joa, und dann geht die wilde Text-Editiererei los >< Das mach ich dann in nem seperaten Posting :D Also schreibt fleissig irgendwas, zum Bsp dass die Männeken blöd aussehn xD

    Soha, es ist dreiviertel 6, mal ein wenig anfangen ^^ Eventuell schaff ichs sogar bis zum Abendbrot :P


    Wir haben also exportiert. Was nun? Standardmäßig wird das gute Stück dorthin exportiert, wo ihr euer .blend-File auch gespeichert habt. Bei mir also in meinem Projekt-Ordner. Dort hineingeschaut, finden wir 2 neue Ordner: models und textures. In textures gibt es wieder einen ordner models, in dem die Texturen für unseren Bus gespeichert sind. Neben diesem Ordner gibt es noch den ui-Ordner - hier ist das Vorschau-Symbol gespeichert, das man bspw. im Kaufmenü sieht. Das war es bei den Texturen. Zurück zum models Ordner (also nich den innerhalb von textures ^^ ). Hier wird unsere Hauptarbeit liegen. Hier gibt es je nach Modell-Aufbau verschiedene Ordner. Das "wichtigste" File ist die .mdl - ohne diese könnt ihr die anderen Dateien da reinschmeissen, wie ihr lustig seid. Keine .mdl - kein Fahrzeug ingame. Die .mdl gibt an, wann ein Fahrzeug erscheint, dessen Leistungsdaten usw usf - und eben auch, aus welchen Meshes das Modell besteht, welche LoD's zum einsatz kommen... Sie befindet sich im Unterordner model. Nutzt man Groups, so gibt es auch einen group-Ordner. Hierrin befinden sich die .grp-Dateien, welche ähnlich der .mdl auf die Meshes verweist, aus denen die Group besteht. Auch weitere Gruppen können hierrin vorhanden sein (Verschachtelung bla). Keine Groups, kein group-Ordner. Generell gibt es aber einen mesh-Ordner. Hier sind eure Meshes gespeichert. Dies geschieht in zwei Formaten: Einmal in .msh-Dateien, welche Metadaten beinhalten (Anzahl von Vertices und sowas und auch welche Materialien genutzt werden sollen) und andererseits die .blob-Dateien, welche die tatsächlichen Meshdaten beinhalten. Diese könnt ihr nicht einfach im Texteditor öffnen, ihr seht dann nur Kauderwelsch. So, schlussendlich gibt es noch den material-Ordner und hierrin sind - wie unschwer zu erraten - unsere Dateien mit der Endung .mtl für die Materialien.


    Das Ganze noch einmal im tabellarischen Versuch:

    Code
    models
    \group\vehicle\bus
    \material\vehicle\bus
    \mesh\vehicle\bus\O309D
    \model\vehicle\bus
    		- alle Modelldaten
    -- alle Gruppen für euren Modelltyp
    -- alle Materialien für euren Modelltyp
    -- eure Meshes für euren Modeltyp mit einem Unterordner mit der Modellbezeichnung
    -- euer .mdl-File für euren Modelltyp
    Code
    textures
    \models\vehicle\bus
    \ui\models_small\vehicle\bus
    		- alle Bilddateien
    -- die Fahrzeugtexturen für euren Modelltyp
    -- das Vorschaubildchen für euren Modelltyp



    Überall, wo hier vehicle steht, kann natürlich unter Umständen auch ein depot oder station stehen, je nachdem, was ihr so bauen wollt ^^





    Soweit zur Einführung. Ich zäume das Pferd gerne von hinten auf, also bei den Materialien. Wieso von hinten? Nunja, die mdl verweist auf die Groups und Meshes, die Groups auf die Meshes und die Meshes auf die Materials. Die Materials sind die Endstation ^^ Also ran da! Was da alles so dran hängt, habe ich im folgenden Lexikon-Eintrag mal versucht zu erörtern (den ich auch noch irgendwann fertig übersetzen wollte ^^ ): Materialien . Bei mir gibt es hier drei Dateien: O309D.mtl, O309D_glass.mtl und O309D_ppl.mtl. Die erste ist die "Grundtextur" und soll ein reflektierendes Material sein. In Blender hab ich der Textur daher den namen "map_color_reflect" gegeben. Das Material bekam den Namen, den nun die .mtl-Datei trägt. Diesem hab ich die schon genannte Textur zugewiesen und die Textur bekam das .tga-File zugewiesen, dass nun in textures/models... gelandet ist ^^ Das ist für O309D.mtl und =309D_glass.mtl die gleiche Datei btw. Gut, hoffe das war jetzt nicht zu verwirrend. Hmm, hab mal ein Bild gemalt:

    So schaut das dann im Outliner in Blender aus, wenn mans alles expandiert. Der Body hat als Material O309D erhalten, also wird dieses .msh-File auf O309D.mtl verweisen. In dieser mtl wird es den texturtyp map_color_reflect geben welche als Quelldatei/Textur die hier angegebene O309D.tga angeben wird. Body_glass wird hingegen auf die O309_glass.mtl verweisen, in welcher nun ein map_color_alpha Texturtyp zu finden ist, der ebenfalls auf die O309D.tga verweist. Bei den Passagier-Meshes sieht es so aus:

    Als mtl wird hier auf die O309D_ppl.mtl verwiesen welche ein map_color_reflec (ohne t! das müssen wir also dann noch ändern, sonst raucht TF ab. Hab das so gemacht, da man in Blender nicht zwei verschiedene Texturen mit gleichem Namen anlegen kann und diese Variante den wenigsten Arbeitsaufwand verspricht) Texturtyp verweist und diesmal wird hier auf eine andere Textur verwiesen, nämlich auf O309D_ppl.tga (ppl wie people ^^ ).



    Gut, soviel zu den Zusammenhängen. Jetzt muss ich erstmal nach der Family schauen, bis später. Sind wir ja schon weit gekommen xD


    Und weiter gehts. Wie gesagt, öffne ich erstmal die mtl-Dateien und schaue nach dem Rechten. Nutze dazu Notepad++ *anmerk* Bei den ersten beiden Dateien (O309D und O309D_glass) ist alles wie erwartet erstmal in Ordnung, bei der O309D_ppl fehlt wie schon erwartet das t:
    map_color_reflec = { -> map_color_reflect = {. Das wars auch schon fürs Erste :) Später werd ich hier nochmal Hand anlegen müssen, wenn ich die Normalmaps baue.


    Gut, weiter gehts mit den Meshes. Das sind jetzt jede Menge Dateien. Allerdings gibts hier eigentlich auch kaum was zu tun. Wichtig sind eigentlich nur die Animationen, also werde ich mich auf die Blinker-Meshes sowie die Tür samt Glaseinfassung und dem dranhängenden Spiegel beschränken. Grundlegende Informationen gibts in folgendem Lexikon-Eintrag: Türen animieren . So, theoretisch sehen die Animationen relativ simpel aus. Die Blinker müssen an und für sich nur immer um 180° gedreht werden und fertig. Beim Agg hab ich die Drehung innerhalb einer ms realisiert und diesen Zustand 200ms so gelassen, dann zurück gedreht und wieder so gelassen - und das Ganze 3mal. Die Tür werde ich einfach in etwa der selben Zeit aufgehen lassen, ich probiers erstmal mit 80°. Tür und Ihr Glas-Mesh haben den selben Drehpunkt (Mesh-Ursprung in Blender), also sind beide gleich zu behandeln. Der Spiegel wird nur halb soviel gedreht, in Blender sah das Versuchsweise ganz gut aus.



    Hier einmal alle Drehpunkte im Bild, die Tür samt Spiegel nochmal etwas detaillierter. Die Scheibe der Tür ist hier nicht gedreht, die Tür um 80° und der Spiegel um 40:



    Also ab in die Dateien! Ich öffne meinen rückwärtigen linken Blinker und finde fast ganz oben den Animationsteil:

    Code: O309D_Lod_0_blinker_back_left.msh
    animations = {
	},

    Hab ich schon erwähnt, dass ich das Forenupdate klasse find xD Hier werde ich nun also unsere Animation für den Blinker reintüdeln. Das Grundgerüst schaut nun so aus (das kopier ich mir auch gleich in die anderen Meshes *rödel*):

    Mit blink_bl geben wir unserer Animation einen Namen - am besten erhält jede ihren eigenen, bild mir ein mal gelesen zu haben, dass das besser sei ^^ danach folgt eine type-Angabe, hier kenne ich als Wert bisher nur KEYFRAME, sowie die param(eter)s für diesen type. Diese beinhalten den origin/Ursprung (wäre meine Tür bei den globalen Koordinaten 0|0|0, müsste ich hier den Drehpunkt entsprechend anpassen. Da ich den Objektursprung aber schon so gelegt hab, dass er dem Drehpunkt entspricht, reicht hier die Angabe 0,0,0) sowie die einzelnen keyframes - Schlüsselpositionen könnte man sagen. Zu einem Keyframe gehören die hier gezeigten paramter. time gibt die Zeit in Millisekunden (ms) an - also zumindest bei dem von mir gewählten Auslöse-Event. Beim Event drive wäre das eher eine Art Prozentangabe. 0 entspricht einer Bewegung des fahrenden Objekts um 0m und 1000 um den zurückgelegten Weg, der einer Radumdrehung entspräche. Gott, das ist schwer zu erklären ^^ Nehmen wir ein Rad, das hat einen Radius von 1. time 0 entspricht nun also dem Ausgangszustand von 0° Drehung. Bewegt sich das Fahrzeug, so dreht ich auch das Rad. Der Umfang des Rades mit dem Radius 1 beträgt 6.283 (wenn man http://www.schulminator.com/mathematik/kreisberechnung glauben schenken mag :P ). Bewegt sich das Fahrzeug also genau 6,283 Meter, dann hat das Rad exakt eine Drehung um 360° gemacht. Dieser Zustand entspricht nun time = 1000. Für dieses Rad fürde also time 1000 immer dann auftreten, wenn das Fahrzeug 6m irgendwas gerollt ist. Bei unserer Türanimation zählt das aber eben wie gesagt als Milisekundenangabe.





    Ooooookay. Ein Name ist vorhanden (soll blinker-back-left bedeuten) und ein Keyframe. Nun soll der Blinker ja möglichst unbemerkt von "dunkel" auf "hell" wechseln, also wähle ich die kleinstmögliche Zeiteinheit: 1 ^^ Ich füge nun also einen zweiten Keyframe ein mit der angabe time = 1. Das kann aber natürlich nicht alles sein. Wie bereits angekündigt, hab ich das so gebaut, dass eine Drehung um 180° den gewünschten Effekt erzielt. Die gewünschte Achse ist die Z-Achse, könnte aber theoretisch glaube auch die Y-Achse sein. egal, ich möchts mit der Z-Achse machen. also schaut das nun wie folgt aus:


    Ich möchte eine ROTation (Drehung) und keine TRANSLation (Verschiebung) erreichen, also wird bei rot der Z-Wert geändert. Da dies aber ne ziemlich doofe Blinkeranimation wäre, müssen wir noch mehr machen. Jetzt kommt die Zeit, in der das gute Stück "leuchten" soll. Ich habe hier mit 200ms eine gute Erfahrung gemacht, also werd ichs hier auch wieder probieren. Also wieder einen Keyframe einfügen, bei dem nur der Zeitwert geändert wird. Da unser Mesh bei 180° gedreht bleiben soll, bleibt dieser Wert stehen. haben wir nun also folgenden Stand:

    Nun schalten wir den Blinker wieder um auf dunkel, also wieder time um 1 erhöhen und die 180° wieder zur 0 ändern. Dann wieder 200ms so halten, dann wieder wechseln - bis das Teil 3mal geblinkt hat. Wenn ich mich nicht vertan hab, kommt an Ende sowas bei raus:



    Rein theoretisch kann ich diesen Code nun in alle 4 Blinker-Meshes einfach kopieren und muss nur die Animations-Namen anpassen *rödel* Gut, für die Tür (und das Glas) gestaltet sich das alles etwas einfacher:


    Ganz simpel wird hier innerhalb einer Sekund die Tür geöffnet und dabei um 80° um die Z-Achse rotiert - fertig. Das gleiche passiert bei dem Glas-Mesh und beim Spiegel (hier allerdings nur mit 40°). Jo, dann sollten wir auch "schon" mit den Meshes durch sein. Fehlt nur noch die mdl...




    Uuuund weiter gehts mit der mdl. Wieder öffne ich sie in Notepad++ und im Moment interessiert mich vordergründig die Reihenfolge der children Einträge. Die Problematik, auf die ich zu sprechen kommen möchte, habe ich in folgendem Lexikon-Eintrag ausführlich geschildert: loadIndicators und LoD's . In aller Kürze sei soviel gesagt, dass die Passagiermeshes ganz oben stehen sollten. Das gestaltet sich bei dem Bus ohne Gruppen noch recht simpel. Da ich hier keinen Textflood verursachen möchte, kontrolliere ich die Reihenfolge mit anton95's kleinem ID-Counter-Tool und poste die dortige Liste. Dazu lade ich die mdl mit besagtem Tool und sehe folgende Auflistung:


    Wie schön zu sehen ist, haben meine Passagiermeshes in LoD0 die ID's 15, 16 und 17 und in LoD1 2, 3 und 4 - dat geht so nich! In allen LoD's müssen die ID's übereinstimmen. Also kopiere ich die Einträge in der mdl einfach nach ganz oben und wir erhalten folgendes Bild *rödel rödel*:


    Soho! (... liegt in Manhatten, äh ja) Wie schön zu sehen ist, passen nun die ID's. Was muss noch getan werden? Da wir schon dabei sind, die loadIndicators! Die ID's stehen fest, also ab nach ziemlich weit unten in der mdl und die loadIndicators reinfriemeln. Ahja, die exportierten metadaten waren etwas rudimentär, also kopier ich erstmal das vom Agg (is noch im Editor offen grad ^^). Nehm ich das als Grundlage, da sind sogar schon die Indikatoren drin. Supi. Hab ich nun wie folgt reingemogelt:

    Er soll 16 Leute transportieren können was in TF glaub ich auf 4 runtergebrochen wird. Und zwar Passagiere und nicht Bratwürste. Dazu DISCRETE levels mit unseren 3 ID's die wir so schön ermittelt haben. loadSpeed ist bei 1 - hat ja auch nur eine Tür. Weiterhin ist er zu Testzwecken ab 1850 verfügbar, hat ne Lebensdauer von 30 Jahren und Anschaffungskosten von rund 108.000 Credits bei ca 10k laufenden Kosten. Als Gewicht hab ich 5,4 Tonnen angegeben, topSpeed mit 80km/h, power bei 200 kW und tractiveEffort mit 10. Das sind jetzt alles eher Platzebo-Werte, falls hier irgendwer was genaueres weiß, bitte Bescheid geben :)


    Sollte soweit alles an Metwadaten drin sein. Name hab ich auch schon reingemeiselt, nur die Beschreibung ist noch Platzhalter. Kann ich also rein theoretisch das Ganze mal rüberkopieren und dann in TF schauen, welche Fehlermeldung er mir schmeisst ^^ Bis hoffentlich gleich xD

    Büffeln is nich so meins, ich bin da eher der Ornithologe...

    DarkMo's YouTube-Kanal

    2 Mal editiert, zuletzt von DarkMo () aus folgendem Grund: weiter gehts...²

    Hmm, aufgrund der Länge durch die editiererei des letzten Posts mach ich mal einen neuen auf, ich hoffe man vergibt mir. Ich bin fasziniert! Er konnte fehlerfrei geladen werden :) Also ohne TF-Fehler. Fehler an sich fielen mir schon ganz gut welche auf ^^ Hier erstmal fix die ersten Bilder *Spannung*:


    - Steam gestartet
    - es updated -.-
    - fertsch, TF startet
    - meine Test-Map laden, 15%, 25... 65... 100! Es lüppt noch
    - Depot anklicken, keine Fehlermeldung, der bus ist im Menü und auswählbar :D

    - auch kaufen geht, keine Fehler
    - dann Pause weg, das kleinod kommt heraus gerollt
    ... und sieht total mies aus xD

    - wie wir sehen - LoD1 funktioniert schonmal lol
    - auch die Lenkung funzt:



    Soweit also alles tutti. Was muss also noch getan werden? Einerseits Distanzen für die LoD's angeben, damit man auch den schönen Bus sieht. Dann funktioniert zwar die Lenkung, aber der Dauerfehler, den ich eigentlich gleich mit erwähnt haben wollte uum ihn zu korrigieren, den habsch natürlich och vergessen. Auch wenn das rechte Rad nach dem Kopieren mit Strg+A (apply->rotation&scale) bearbeitet wurde, dreht das irgendwie GENERELL nach hinten (rückwärts). Also muss man hier als Lösung in der mdl den Childreneintrag bearbeiten, indem man aus der 1.0 fürs x ne -1.0 macht. Weiterhin fehlen die ganzen Animationen. Wir haben sie zwar in den Meshes angelegt, steuern sie aber nicht über die mdl an.


    Also: Ab zurück ans Reisbrett!
    Erstmal das Rad. Wir machen aus

    Code: O309D.mdl
    }, {
					id = "vehicle/bus/O309D/O309D_Lod_0_wheel_right.msh",
					transf = {
						1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2.27485, -0.86052, 0.36859, 1.0, 
					},
					type = "MESH",
				},

    ein

    Code: O309D.mdl
    }, {
					id = "vehicle/bus/O309D/O309D_Lod_0_wheel_right.msh",
					transf = {
						-1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2.27485, -0.86052, 0.36859, 1.0, 
					},
					type = "MESH",
				},

    (man beachte in Zeile 151 die erste Zahl - farbig was editieren geht bei code-Tags nicht :( ).



    Als nächstes die LoD-Distanzen. Aus:

    Code: O309D.mdl
    visibleFrom = 0,
			visibleTo = 2500,

    für LoD0 wird:

    Code: O309D.mdl
    visibleFrom = 0,
			visibleTo = 200,


    und aus:

    Code: O309D.mdl
    visibleFrom = 0,
			visibleTo = 2500,

    für LoD1 wird:

    Code: O309D.mdl
    visibleFrom = 200,
			visibleTo = 1000,



    Fehlen ja nur noch die Animationen, dazu müssen wir in diesem events-Block rumpfuschen:

    Code: O309D.mdl
    events = {
			},


    Die Grundlagen lassen sich auch im schon Verlinkten Lexikon-Eintrag nachlesen: Türen animieren .
    Ich möchte die Animationen beim Türen öffnen/schließen ablaufen lassen. Die Tür öffnet sich natürlich (bzw schließt sich wieder) und beim öffnen soll die Warnblinkanlage loslegen, beim Türen schließen der linke Blinker gesetzt werden - so der grobe Plan.


    Hmm, habs jetzt mal eingepflegt und schaut wie folgt aus:


    Als Events hab ich die öffnen und schließ Methoden für alle Türen verwendet - ist beim Bus ja wumps. In den Eckigen Klammern ist die ID der Meshes drin (erinnert euch an das ID-Counter Tool), forward false bei close bedeudet, das die Animation nicht vorwärts (sondern eben rückwärts) abgespielt wird und als name hab ich hier die von mir gewählten Animationsnamen (was wir in den .msh Dateien bearbeitet hatten) gewählt.



    Nun also auf zu Test nummero 2...


    Auch wieder problemlos ladbar, aber das ist alles wieder komisch ^^ Das "gefixte Rad" hat einerseits einen Schattenfehler, andererseits dreht es beim Lenken in die falsche Richtung... grr. Und die Animationen drehen auch um die falschen Achsen -.- is das wieder ätzend - jetzt wirds Fummelarbeit. Aber erstmal hier noch fix die Bilder dazu:



    Auf zu Test nummero 3...



    Änderungen:
    - door, door_glass und mirror .msh auf 1300ms animationsdauer erhöht, Rotations-Achse auf X geändert
    - blinker .msh'es ebenfalls auf Rotations-Achse X geändert und die Blinkdauer von 200 auf 250ms hochgesetzt (insgesamt 1251ms)
    -> Animationen passen endlich

    (beim Schließen)
    - noch einen Fehler enddeckt (doofes copy-paste ^^): Beim Türschließen haben auch alle Blinker geblinkt. Hab hier also die ID's 6 und 8 rausgelöscht.
    - wenn ich den Negativ-Wert für das Rad von X zu Z änder, dann dreht das Rad vorwärts und lenkt korrekt, hat aber immernoch den Schattenfehler...




    Ich probiere jetzt mal in Blender das linke Rad erneut zu kopieren und das Rad im Edit-Mode um -1 zu skalieren - eventuell klappt das so. Muss ichs halt neu extrahieren, aber nuja.





    ... Nope, keine Chance. Sieht zwar ordentlich aus, aber dreht halt rückwärts :/ Was soll denn das nur *grml*







    AAAAAH! Ich hab das Rad jetzt in zig Variationen neu exportiert, am Ende funzte folgende Vorgehensweise: Das linke Rad kopieren, um 180° (Z) rotieren und NICHT die Rotation anpassen. Anschließend in der mdl die Werte für X und Y auf -1 setzen:
    transf = { -1.0, -0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2.27485, -0.86052, 0.36859, 1.0, },





    Juhu! Damit will ich für heute Feierabend machen. Die Tage werden dann die Texturen vereinert (Transparenzen und Normal-Maps hab ich mir vorgenommen :D ). Also dann, bald ist der kleine soweit *jubel*

    Der Schattenfehler tritt bei gespiegelten Teilnen manchmal auf, was ihn genau verursacht konnte ich noch nicht rausfinden. Einzige mir bisher bekannte Lösung: Das Teil kopieren, spiegeln und dann über apply -> rotation and scale so anpassen, dass in der entsprechenden *.mdl bzw. *.grp keine negativen Werte auftauchen. Dann hast du zwar 2 unterschiedliche meshs, aber dafür siehts wieder gut aus ;) Das nur als Hintergrundinformation, du hast ja bereits eine etwas andere Lösung gefunden.


    Ansonsten bin ich von dem Detailgrad echt fasziniert - fast schon eine Verschwendung diesen Bus nur in TF einzusetzen.


    Fred

    @BILLYxx20xx: Bei dem Dingen hält sichs eigentlich noch in Grenzen, der AGG war 10mal schlimmer durch die Faltenbälge xD Und: Vielleicht animiert meine Erklärerei ja den ein oder anderen, sich auch mal zu versuchen :) Ich gehe zwar nicht davon aus, das ich hier alles "wasserdicht" und allgemeingültig erklärt hab, aber die Grundzüge für einfache Modelle sollten durchaus nachvollziehbar sein *denk*. Dann darf sich gerne nachwuchs einfinden :P


    @fred1690: Joa, das Phänomen kenn ich ja (vermute dass da irgendwas mit Normals im argen liegt). Bei den Wheels mach ich mittlerweile eigentlich eh immer 2 Meshes, damit das eben NICHT auftritt ^^ Aber siehst ja, das Rad (trotz korrektem apply bla) dreht rückwärts. Mir kommts so vor, dass das rechte Rad wirklich einfach falschrum gedreht wird von TF und eben die Drehung OHNE apply die Lösung ist. Weil der Fehler war jetzt bei jedem Bus bisher bei mir und hier hab ichs erste mal ne ordentliche Lösung gefunden ^^


    Ach edit: Für den Fall dass jemand den langen Text ned lesen wollte aber denoch was weiß: Ich suche noch anständige Daten fürs Datenblatt ^^ Also sowas wie Gewicht, Leistungsdaten usw usf.

    Jop, habs mal übernommen. Erscheinungsdatum wird bei dem hier aber 75, ne 68er (kurze) Variante hatte ich aber auch überlegt. 10 Passagiere sind ok?


    Hab btw nun auch mal einen Alpha-Kanal getüdelt, sieht schon sehr viel schicker aus so! Fehlt im groben nur noch die Normal-Mpa, aber da brauch ich irgendwie immer bissl Überwindung xD



    Edit: So, Normal-Map ist hinzugefügt! Musste ich natürlich nochmal in das Material-File und den Normal-Map-Eintrag hinzufügen und den Type passend ändern. Leider ists mit aktiviertem HDR kaum bis garnicht sichtbar, da das Dach zu sehr strahlt - ohne kommts aber gut. Da ich aber sowieso noch nen Alpha-Kanal für die Normal-Map bauen will, wird sich das geglänze hoffentlich noch einränken ^^ Die Türklinken kommen leider jetzt nich so dolle rüber, aber nuja. Ach apropos Türklinke: Hab den Türen (also an den Textur-Positionen bla) auch innen nen kleinen Türgriff angepinselt. Sah ohne doch etwas seltsam aus. Im übrigen kann man eventuell den rechten Blinker leuchten sehn ^^ Sieht in Bewegtbildern natürlich besser aus ><



    Edit2: Oha! Smoothnes-Faktor (nutze xNormal) reduzieren und schon tritt der Effekt stärker hervor :) Hier jetzt mit aktiviertem HDR:

    10 Paxe finde ich ok, das ist ein guter Abstand zu den Standard-Linienbussen (z. B. O305, Citaro etc.), die ja Platz für 15 - 17 Paxe haben.

    Grüsse aus der Schbätzles-Diaspora,
    - petrolhead -


    nachts isch kälter wie draussen... :P

    Zur Historie von irgendwas brauchst du mich garnich fragen ^^ Sowas hat mich schlicht nie interessiert xD Was ich noch so an Versionen geplant hatte, war der Bus in kürzer ab '68 und vllt noch ne "LKW" Variante, muss ich guggn wie ich die Lust und Zeit zu finde.


    Im Moment beschäftigt mich aber eher der Alpha-Kanal der Normal-Map. Hab dem Dingen nun mal aufm Dach und an der Seite zum Texten schwarze transparente Vierecke gegeben. Zuerst mit voller Transparenz, dann bissl weniger. Bei voller Transparenz sah man einfach einen untexturierten grauen Flatschen - total hässlich, und beim 2. versuch sieht man schlicht und ergreifend garnix >< Es glänzt überall gleich dolle irgendwie.

    @'BILLYxx20xx: ein wenig zur Historie hatte ich schon in meinem Mod-Request (link: klickst du hier) geschrieben. Im Prinzip hast du Recht, der DüDo ist allerdings der Vor-Vorgänger vom Vario. Vario hiess das Ding ab 96, als Daimler mit dem Schwachsinn angefangen hat, Nutzfahrzeugen Namen zu geben.
    Der Vorgänger vom Sprinter ist die Transporterbaureihe 601 aka T1.

    Grüsse aus der Schbätzles-Diaspora,
    - petrolhead -


    nachts isch kälter wie draussen... :P

BlueBrixx