Fragen zum Modden

Solche Fehler wie in Bild 4 entstehen gerne dadurch, daß die UV-Map fehlerhaft ist. Die Oberflächenelemente des 3D-Körpers müssen so abgewickelt werden, daß sie nicht allzu sehr verzerrt werden.

Im UV-Modus in Blender bekommst Du normalerweise sowohl das 3D-Bild als auch die UV-map angezeigt. Klicke die fehlerhafte Fläche im 3D-Modell an, und dann sollte die entsprechende Fläche in der UV-Map ebenfalls markiert sein (mindestens, wenn die Einstellungen entsprechend sind - ich müßte da auch erst mal länger herumfummeln, wenn's nicht klappt). Dann siehst Du, ob die Seitenverhältnisse wenigstens so ungefähr stimmen. Wenn nicht, mußt Du noch mal an die UV-Map ran (und leider auch an alles, was daran hängt).

Mindestens in Blender kann ein Modell auch mehrere UV-Maps haben. Falls das bei Dir der Fall ist, kann irgendeine davon falsch sein oder die Zuordnung Textur - UV-Map stimmt nicht ... es gibt also genug Fehlerquellen.

Wenn Du nicht weißt, was Du mit der mgao-Map tun sollst, ist 0000ff ein guter Startpunkt. Allerdings solltest du die mit der Zeit verstehen lernen.

Ich muß ein wenig ausholen: Sonnenlicht wird - auch bei wolkenlosem Himmel - in der Atmosphäre zum Teil gestreut. Das führt nicht nur zum Abendrot und zum blauen Himmel, sondern auch dazu, daß Du Sachen, die im Schatten liegen, sehen kannst. In Computermodellen gibt es deshalb zwei Lichtquellen, eine direkte für das nicht gestreute Licht und eine diffuse, bei der das Licht keine Information über die Einfallsrichtung enthält.

Diese letztere Lichtquelle ist aber, wie alles im Computer, dumm und kennt nichts von der Umgebung. Wenn Du jetzt also etwas hast, was besonders gut abgeschirmt ist - unter einem Erker, einem Durchgang, in den Vertiefungen von Rauhputz oder in der Achselhöhle des Göoethe-Denkmals zum Beispiel - bekommt es trotzdem genau so viel virtuelles Licht ab wie die einfache Nordseite eines Gebäudes. Das ist dann natürlich zu viel. Deshalb kannst Du solche Partien zusätzlich abdunkeln, indem Du den Blaumilch-, äh, Blaukanal der mgao-map abdunkelst.

Bei den drei unteren kann es sein, daß das richtig ist und durch die Beleuchtung kommt. Oder wenigstens denkt TpF2, daß es richtig sei. Oben kann ich das schlecht abschätzen.

Mit einer zu kleinen Textur für die UV-Map gibt es Möglichkeiten, das in Blender (dürfte daraus nicht exportiert werden) und in der .mtl anzupassen. Bei jedem Map-Block der .mtl hast Du

            wrapS = "REPEAT",
            wrapT = "REPEAT",

wobei das REPEAT auch durch CLAMP_TO_EDGE ersetzt werden kann. Das sagt, ob sich das Muster der Map wiederholt oder bis zum Ende des Bereichs der Farbwert des Randes festgehalten wird. Wenn Du also eine Map mit schwarzen und weißen Quadraten hast, und diese zu klein ist, hast Du im ersten Fall auf der ganzen Fläche ein Karomuster, im zweiten Fall nur da, wo die UV-Werte zwischen 0 und 1 sind, und außerhalb schwarze und weiße Streifen.

Beide Effekte sehe ich in Deinem Bild nicht unbedingt.

Oft sind das einfach nur komische Schattenwürfe im Modelleditor. Probier einmal, die Sonne ein wenig zu bewegen. Strg+linke Maustaste

WTrainy12: Eher unwahrscheinlich. Dazu sind sie nicht scharf genug begrenzt und in sich zu strukturiert. Außerdem brauchst Du natürlich erst einmal eine Textur, die diese Streifen von sich aus mitbringt. Wenn die Sonne hart an einer Kante vorbeistreift, ergeben sich gerne mal Streifen bei TpF2. Das Spiel ist halt in Extremsituationen noch nicht wirklich perfekt, oder es gibt einfach noch Beleuchtungstricks, die dem einfachen Modder wie mir noch nicht bekannt sind. In Deinem Bild von Beitrag #65 hast Du oberhalb des linken roten Kringels ähnliche Streifen, die schräg laufen und von daher sicher keine zu kleine Textur sind (es sei denn, die Fenster liegen in der UV-Map schräg, was ich erst mal nicht annehme).

Ich kann mir vorstellen, daß Du das Bestmögliche getan hast und den Rest einfach nicht mehr verbessern kannst und so hinnehmen mußt wie es ist.

https://www.transportfever.net…77-transformationsmatrix/

Anstatt jeden Schritt umzurechnen, kann man auch einfach direkt eingeben um wieviel Grad sich das ganze drehen soll. Mann muss nur ne andere Transf nehmen.

In den Kopf der ani

local vec3 = require "vec3"
local transf = require "transf"

Für die Schritte

transf = transf.scaleRotZYXTransl(vec3.new( 1.0, 1.0, 1.0), transf.degToRad ( 0, 0, 0), vec3.new(0, 0, 0))

Beispiel

local vec3 = require "vec3"
local transf = require "transf"

function data()
return {
    times = { 0, 1500, },
    transfs = {
        transf.scaleRotZYXTransl(vec3.new( 1.0, 1.0, 1.0), transf.degToRad ( 95, 0, 0), vec3.new(0.0, 0.0, 0.0)),
        transf.scaleRotZYXTransl(vec3.new( 1.0, 1.0, 1.0), transf.degToRad ( 0, 0, 0), vec3.new(0.0, 0.0, 0.0))
    },
}
end

Das ist alles im Wiki beschrieben
https://www.transportfever2.co…ehicletypes#road_vehicles

Die transf die ich oben gepostet habe ist egtl selbsterklärend, wenn man genau hinschaut

scale---RotZYX---Transl
scale---Rotation---Position

In der Reihenfolge stehen dann auch dien Werte in den Klammern.

Wie es eingebunden wird steht hier:

CommonAPI2 Endhaltestellen Anzeige (LINE_DESTINATION)

Es steht in dem Lexikonartikel, wenn der Nutzer kein CommoinApi verwendet dann gibt es einen Ladefehler von TPF2. Daher muss man das entsprechend scripten das es ein Fallback gibt wenn CApi² nicht installiert ist. Wie genau steht nicht da, es wird auf die Moddingwiki verwiesen aber damit kann ich nichts anfangen. darunter steht dann was da rein muss.

Zitat von WTrainy12

wie kann man bei den LabelLists die LINE_DESTINATION CommonAPI implementieren?

Es gibt irgendwo eine Mod welche das bei allen geladenen Fahrzeugen automatisch macht, ich persönlich kontrollierte nur ob die LineDestinations mit besagter Mod an meinem Mod funktionieren. Persönlich hätte ich nur gehandelt wenn es automatisch nicht funktioniert hätte.

Könnt Ihr mal bitte aufhören an jeder Ecke alles schlecht zu machen, und den Wiki Eintrag mal komplett durchlesen, da steht es doch drin:

2.1 Eigene Fahrzeugmodelle nachrüsten (Beispiel Code):

Sobald LINE_DESTINATION eingeschaltet ist, funktioniert in labelList type = "LINE_DESTINATION", ohne CommonAPI2 gibt es einen Ladefehler, daher müsst Ihr eine Code Weiche einbauen:

Siehe dazu auch: https://www.transportfever2.co…ourcetypes:mdl#label_list

In eurer mdl Datei direkt hinter function data() einfügen:

Code

local labelType = "NEXT_STOP"
if (commonapi ~= nil and commonapi.supports and commonapi.supports("LINE_DESTINATION")) then labelType = "LINE_DESTINATION"
end

Danach könnt Ihr in der labelList

Code

type = "LINE_NAME",

durch

Code

type = labelType,

ersetzten.

Code ist da, steht direkt darunter inkl Anleitung...

Alternative Mods zum automatischen Ändern der Fahrzeuge gibt es auch, es gibt auch noch das Ganze als Englische Anleitung hier:

https://commonapi2.bytetransfer.de/#/modding/LabelTypes

Und es wird auch in der Doku auch nach

Verbesserte Linienbezeichnungen  verlinkt...