REFLECTIVE_NRML_MAP causes crashes/Führt zu Abstürzen

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


  • Deutsch

    Ein Hallo an alle Transport Fever Fans, und vor allem an jene, die sich auch mit dem Modding auskennen. Bisher habe ich noch so gut wie keine Kenntnisse über das Modden in Transport Fever. Lese aber fleissig die hier vorhandenen Tutorials. Habe auch schon nach Lösungen hier in der Modding Sektion gesucht, bin aber nicht fündig geworden. Sollte es auf mein Problem hin einen Thread geben, der eine eindeutige Lösung beinhaltet, so bitte ich, mich darauf aufmerksam zu machen und darüber hinweg zu sehen, dass ich es selbst nicht gefunden habe.


    Die Idee: Ich möchte gerne dem Mesh ''crane_old'' eine neue Textur verpassen, die auch eine Normal-Map beinhaltet. Jedoch zunächst einmal ohne eigenes UV-Mapping, sondern durch Anpassen der vorhandenen Textur ''crane_old.tga''.


    Vorgehensweise: Nach dem Anpassen der Textur habe ich eine vorher nicht vorhandene Normalmap mit Gimp erzeugt. Und auch den dafür notwendigen Eintrag (map_normal) in die entsprechende MTL-Datei hinzugefügt, sowie auch den ''type'' am Ende der MTL-Datei von REFLECTIVE auf REFLECTIVE_NRML_MAP geändert.


    Problem: Es lässt sich ohne Weiteres eine neue Textur aus einem Backup der Originaldatei erzeugen. Doch das Spiel stürzt ab, sobald der Kran ''alt'' geladen wird, und als ''type'' in der MTL-Datei auf REFLECTIVE_NRML_MAP eingetragen ist.


    Lösungsversuche und Erkentnisse: Wird der ''type'' in der MTL-Datei wieder auf REFLECTIVE gestellt, wird der betreffende Kran mit der neuen Textur geladen. Aber eben ohne die Normal-Datei. Beim Import in Blender erscheint der Turm mit 3D Effekt, sobald in der MTL-Datei zusätzlich zu REFLECTIVE_NRML_MAP im Parameter ''two_sided'' der Eintrag ''flipNormal = false'' eingetragen steht, während es im Spiel einen Crash erzeugt.
    Die Dateipfade in der MTL-Datei sind korrekt geschrieben (also kein type-o), und weisen auf den korrekten Pfad hin.


    Fragestellung: Was erzeugt den Crash, während es in Blender geladen und gerendert werden kann? Habe ich einen wichtigen Schritt nicht erkannt?


    Es würde mich sehr freuen, wenn ihr mir in irgendeiner Form weiterhelfen könntet. :)






    STDOUT-Datei/File:


    2 Mal editiert, zuletzt von Vert () aus folgendem Grund: flip_normal zu flipNormal

  • @SD70M: Die NRML-Textur ist eine TGA-Datei. Diese habe ich ohne RLE-Kompression abgespeichert. Der Lexikoneintrag beschäftigt sich mit der Komprimierung von DDS-Dateien. Mal sehen was passiert, wenn ich die NRML-Textur im DDS Format abspeichern würde.


    @MaikC: Äh, ja richtig :D Es steht in der MTL-Datei auch flipNormal=false :) Habe das auch im Eingangspost von mir berichtigt.
    Wie erwähnt führt dieser Eintrag dazu, dass Blender nach einem Import die erzeugte Normalmap darstellen konnte, jedoch nicht ohne diesen Eintrag. Bevor ich die neue Textur ingame prüfe, öffne ich zuvor das Objekt in Blender. Ob das Spiel diesen Eintrag in diesem Falle braucht, oder nicht, wusste ich bis dato gar nicht. Ich fand es nur interessant, dass der Eintrag in Blender die Normalmap erst ''lesbar'' macht.
    An der zugörigen MSH Textdatei habe ich keine Änderung durchgeführt. Nur die Textur an sich (crane_old.tga), sowie die zugehörige MTL-Datei. Liegt dort das Problem? Wie erwähnt, in Blender funktioniert alles genau so, wie es soll.


    Anbei die MTL-Datei, welche zu Abstürzen führt:


  • Nur auf die Schnelle anbei eine mtl mit tga, welche bei mir wunderbar funktioniert.


    Sollte diese, falls du sie testen möchtest, zum Absturz führen, so ist der Fehler definitiv woanders zu suchen.


    LG Enno :)

    Auch ein alter Fuchs schaut gern ein Huhn, selbst wenn er's nicht mehr Reißen kann. ^^

    163393-cpuz-ryzen9-5900-png

  • @Vert Nutzt du für den Import in Blender mein Addon? Ich habe nämlich gerade meinen Code durchgesehen und ich nutze nirgendwo einen Parameter mit dem Namen "flipNormal", also kann es für den Import eigentlich keinen Unterschied machen, ob der vorhanden ist, oder nicht.


    Ansonsten deutet die Fehlermeldung in der stdout eher auf ein Problem mit dem Mesh hin, was aber merkwürdig ist, wenn du selbiges nicht verändert hast. Mal auf das Änderungsdatum geschaut? Vielleicht hast du es, z.B. durch einen Export aus Blender, unbewusst geändert.

  • Deshalb hatte ich auch gefragt :D dieser Fehler tritt normalerweise auf wenn man ein Mesh falsch exportiert so das da die vertexattr Einträge fehlen oder falsch sind.


    Leidet sind die Fehlermeldungen der Stdout zu nichts (nicht viel) zu gebrauchen weil da nach wie vor nicht steht welche Datei den Fehler verursacht. Das kann doch nicht so schwer sein das reinzuprogrammieren.

  • @EAT1963 Feststellung des Sachverhaltes: Zuerst habe ich unsere beiden MTL-Dateien verglichen und habe - abgesehen von den fileName Einträgen - drei Unterschiede ausgemacht: In Deiner ist im map_normal Parameter ''compressionAllowed'' auf true gestellt, bei mir auf false. Im Parameter props ist unter ''coeffs'' der dritte Koeffizient? auf 0.25 und bei mir auf 0.55 gestellt. Der dritte Unterschied (der warscheinlich überhaupt keinen Unterschied macht?) sind Leerzeichen hinter geschweiften Klammern in vanilla und meiner MTL-Datei und keine Leerzeichen in Deiner MTL-Datei.
    Vorgehensweisen: Zuerst habe ich die bei mir abweichenden ''Parameter'' angepasst (manuell). Das führte weiterhin zu einem Crash. Dann habe ich via copy/paste Deine MTL-Datei eins zu eins übertragen und die fileName Parameter angepasst. Das führte auch nachwievor zu einem Crash.
    Schlussfolgerung: Die von Dir und MaikC geäußerte These, dass es am Mesh selbst liegen könnte, könnte stimmen. Ein Fehler der MTL-Dateien also unwahrscheinlich?



    @Merk @MaikC Ja, ich nutze das Addon von Merk. Allerdings habe ich damit bis jetzt noch nicht exportiert. Nur importiert, zur Veranschaulichung der Ergebnisse im 3D-Viewport. Die Mesh-Text-/BLOB-Datei besitzt gegenüber den vanilla Dateien kein abweichendes Datum. Die MSH-Textdatei habe ich mal hinzugefügt, um die vertexattr Einträge zu zeigen, sie müssten identisch mit euren vertexattr Einträgen sein, (sofern sie bei euch vanilla sind).
    Weitere Erkentnisse: Das Nutzen einer x beliebigen Normalmap (FileName Parameter natürlich in der MTL-Datei angepasst), führt ebenfalls zu Abstürzen. Ein Absturz ereignet sich grundsätzlich nur, wenn der Kran auf dem Bildschirm gerendert werden soll. Befindet sich ein Kran nicht auf dem Bildschirm, stürzt das Spiel erst ab, wenn man zu einem Kran in eine Stadt zoomt.


    Der reine vanilla ''crane_old'' besitzt keine Normalmap, und auch der map_normal Parameter fehlt. Der ''type'' ist folglich auf REFLECTIVE eingestellt.


    Ist es also möglich, dass es nicht möglich ist, ''crane_old'' eine Normalmap zu verpassen? Denn es wurde ja schon in der vanilla Version auf eine Normalmap samt MTL Eintrag verzichtet.


    Was passiert denn, wenn ihr kurz eine Normalmap erstellt und sie in die MTL Datei eintragt? (ist zu groß für ein Archiv im Anhang, hätte sonst einfach mal meine hochgeladen).

  • Okay, es sieht so aus, als bräuchten Meshes, die eine Normalmap haben sollen, zwingend Tangentendaten (Block "tangents" bei subMeshes und vertexAttr). Also ja, ohne das Mesh zu ändern, wirst du wohl keine Normalmap hinzufügen können.
    Habe testweise mal bei einem meiner Modelle mit Normalmap den "tangents" Eintrag auskommentiert und das Spiel stürzt dann mit exakt der gleichen Fehlermeldung ab. Kommentiere ich den Eintrag nur bei einem Submesh aus, das keine Normalmap hat, gibt es keine Probleme.

  • Deutsch

    Danke für die Hilfe :) Ich schätze, damit haben wir das Problem gefunden. Habe - als Vergleich - beim Modell ''crane_new'' auch die für das Modell entsprechenden Tangentendaten in der MSH-Datei gefunden.
    Ich danke euch allen.


    Problem aufgeklärt.


    2 Mal editiert, zuletzt von Vert () aus folgendem Grund: Ergänzung, Übersetzung; 'Wrong-Trait'-Satz entfernt, und durch einen Satz ersetzt, den ich besser finde.

BlueBrixx