Welche Dateitypen sind für Texturen in OMSI sinvoll?

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    Disclaimer: könnte Meinung enthalten!

    Ich nehme für 4k-Texturen dds, für 2k und kleiner TGA. Dann hab ich bei kleineren Texturen keine Verschmierungen (bei 4k fallen die eh nicht so auf wegen der größe) und große texturen werden nicht schwarz (eine 4k-Textur mit vielen Farben in .tga ist diesbezüglich schon sehr kritisch).

    Ausnahme sind z.B. .trans-Dateien, wenn die nicht allzu voll ist dann nehm ich auch in 4k noch .tga.

    Ich sehe kein Problem darin, dds und tga zu mischen, Lazarus. Bereiche, die im Blickfeld sind, also der Fahrerplatz z.B. in tga, anderes, wie der sonstige Innenraum in dds ist für mich die erste Wahl. Letztenendes probiere ich immer bei jeder Textur aus, ob dds akzeptabel aussieht. Wenn nicht, bleibt es eine tga. Hier gilt, wie überall, die Regel von Marcel: So wenig, wie möglich, so viel, wie nötig.


    Eine komprimierte tga bringt, soweit ich weiß, nur Ersparnis beim Speicherplatz auf der Festplatte, nicht aber im Grafikspeicher, weil OMSI die wieder dekomprimiert.

    Zitat von Perotinus

    Ich habe vorhin, nachdem ich mit paint.net nochmal schlechte Ergebinsse hatte, einen Versuch mit DXTBMP gestartet, das ich aus dem TS-Modding kenne. Da kam tatsächlich ein brauchbarereres Ergbnis raus, das zumindest diese Farbveränderungen bei eigentlichen Graustufen verringert hat.

    Hey, das Tool ist ja wirklich noch brauchbar. Es scheint wirklich eine geringere Kompression als Paint.net zu verwenden. Die Dateien sind zwar etwas grösser, dafür aber nicht so verwaschen.:thumbup:


    mfg

    Daniel

    Zitat von Perotinus

    Ich sehe kein Problem darin, dds und tga zu mischen

    Sagte ja schon - persönliche Präferenz. Ich mag Konsistenz, aber TGA und DDS mischen ist noch in Ordnung. Ich krieg dann doch eher die Krätze, wenn man einen wilden Mix aus PNG, JPG, BMP und ab und an noch ne TGA und DDS hat. Citaro und Co. sind solche Kandidaten, finde das grausam.

    Zitat von fOcUs04

    Hey, das Tool ist ja wirklich noch brauchbar. Es scheint wirklich eine geringere Kompression als Paint.net zu verwenden. Die Dateien sind zwar etwas grösser, dafür aber nicht so verwaschen.:thumbup:


    mfg

    Daniel

    Eigentlich sollten die Dateien die gleiche Größe behalten, außer du aktivierst die MipMaps oder änderst das Format.BC1 aka DXT1 ist das Kleinste der Formate und weißt die meisten Artefakte auf und stellt Alpha überhaupt nicht da, BC2 aka DXT2 und DXT3 unterstützt 4-bit Alpha und hat weniger Artefakte, aber ist dafür doppelt so groß. Mit neuen DDS Formaten kommt Omsi teilweise überhaupt nicht mehr klar.


    Vom DXT10 Header ist Omsi überhaupt nicht begeistert, weshalb der aktuelle Nvidia Texture Tools Exporter für Omsi lange unbrauchbar war.

    Grundsätzlich muss man hier aber anmerken, dass wir uns in einem 10 Jahre alten Spiel bewegen. Bei neueren Engines, vorallem mit 64-bit unterstützung sind größere Dateien kein Problem mehr, in OMSI geht das allerdings nicht. Bei einem M&R Wagen ist es vermutlich egal, welches Dateiformat verwendet wird - bei so wenig und so niedrig aufgelösten Texturen ist der Texturspeicher auch noch nicht großartig überfordert. Wir wollen ja immer mehr Qualität, immer mehr Texturschärfe - das geht aber irgendwann einfach nicht mehr. Bei großen Texturen ist die Verwendung von DDS fast schon unumgänglich, weil diese "as-is" in den Speicher geladen werden. Da wird auch nix entpackt oder dekomprimiert, eine 600kb DDS ist auch im Texturspeicher 600kb groß. Es ist auch völlig egal, ob eine Komprimierte 8k TGA auf der Platte nur 100kb belegt weil sie kaum Bildinformationen enthält - die ist im Speicher selbst dann trotzdem so groß wie eine 0815 Bitmap.
    Wenn ich mich richtig erinnere, werden bei einer DDS Textur die Informationen aus 4 nebeneinanderliegenden Pixeln zusammengefasst und in ein 565 RGB Format umgewandelt. Das ergibt eine Komprimierungsrate von 6:1. Farbinformationen werden in 5 bits für Rot, 6 bits für Grün, 5 bits für Blau gespeichert. das ergibt eine 16 bit Farbtiefe und damit 216 Farbabstufungen - ~65.000 Farben. Gerade in Graustufen führt das zu den bekannten, sichtbaren Artefakten, vorallem dann wenn es aus einer True-Color Datei (24 bit Farbtiefe oder mehr) umgewandelt wurde. Würde man allerdings 24 bit Farbtiefe nutzen, hätte man über 16 Millionen Farbabstufungen aber damit auch eine wesentlich größere Dateigröße.
    Es gibt keinen Mittelweg zwischen Dateigröße/Texturspeicher und der Qualität der Texturen. verringert man den einen Faktor, verringert sich auch immer der andere. Durch unterschiedliche Komprimierungsmethoden und Einstellungen lassen sich natürlich auch unterschiedliche Ergebnisse erzielen. die DXTBMP Software, welche Perotinus hier angesprochen hat liefert eventuell bessere Ergebnisse bei Graustufen, hat aber eventuell auch mehr Artefakte an anderen stellen. Irgendwo muss man immer Abstriche machen.
    Ich nutze Grundsätzlich DDS für alle meine Texturen. Ausnahmen sind kontrastreiche Texturen wie die VDV-Displaytexturen meiner Fahrzeuge.

    • Hilfreichster Beitrag

    Sehr schön, nach 10 Jahren wird nicht mehr mehr jpg und png ins Spiel gebracht sondern es geht nur noch darum wann tga und wann dds. Wir sind also weitergekommen;-D Und in der Tat ist diese letzte übrig gebliebene Frage gar nicht so einfach, und insbesondere was die Qualität betrifft gibts wohl erhebliche Unterschiede welches Tool man dafür verwendet. Nutzt eigentlich jemand dieses dds-Plugin von Intel für Photoshop? Das ist jahrelang an mir vorbei gegangen aber mittlerweile nutze ich das fast ausschließlich, auch in Kombination mit der Batch-Funktion in Photoshop. DXTBMP stürzt gerne mal ab, das nicht. Qualitativ kann ich das aber nicht beurteilen, ich sehe zumindest keine Unterschiede. Jemand der aber jeden Pixel seines Busses kennt wird da sicher mehr zu sagen können.


    Über TGA würde ich auch fast nur in Zusammenhang mit Bussen oder Fahrzeugen nachdenken, für Häuser etc grundsätzlich dds nehmen. Sogar die Bäume habe ich alle mittlerweile in dds und sehe keinen Unterschied.


    Der Punkt bei dds ist ja auch dass OMSI es einfach bevorzugt behandelt. Nimmt mal einen Bus der TGA oder sonstwas in den Configs und Meshes verwendet, platziert aber eine gleichnamige dds-Datei neben der originalen Textur. OMSI wird trotzdem die dds nehmen.


    Die Dateigröße auf dem Datenträger ist mittlerweile nicht mehr so entscheidend. der Flaschenhals von OMSI ist ja das Problem, nicht mehr die Geschwindigkeit des Datenträgers, eine SSD mal vorausgesetzt. Hatte aber auch oft den Fall gesehen dass die dds deutlich größer war als die TGA nach der Wandlung, vermutlich weil ich eben nicht das optimale Format gewählt habe, und trotzdem hat im Ladefluss die dds einfach besser "geflutscht". Ein weiterer Vorteil wäre noch dass es im VRAM komprimiert gehalten wird, während alle anderen Formate zunächst entpackt werden und im Speicher dann wie eine BMP Pixel für Pixel gehalten werden. VRAM ist aber immer noch ein Problem, auch bei heutigen Grafikkarten, denn OMSI kann nicht den kompletten VRAM adressieren. Auch mit dem 4GB Patch ist der Adressraum stark beschränkt, und der VRAM muss dabei immer mitberücksichtigt werden, was oft vergessen wird. Irgendwann ist halt Sense und dann fliegen die Texturen als erstes einem über die Ohren.


    Ein Nachteil von TGA wäre auch noch zu nennen: es kann wie bei PNG und Co auch passieren dass die Texturen plötzlich durchknallen, allerdings bei weitem nicht so häufig. Und anscheinend spielt dabei auch die Einstellungen "maximale Größe in Reflexionen" in den OMSI-Optionen eine Rolle. Setzt man die auf 0 ist man ganz gut dagegen gesichert.


    Und grundsätzlich sollte man halt auch gucken dass man wirklich das Format und die entsprechende Variante davon nimmt die man wirklich braucht. Ein stumpfes Konvertieren wird unnötig große Dateien erzeugen. Zum Beispiel ist eine dds ohne Alpha nur halb (oder ein viertel?) so groß wie mit Alpha...

    Zitat von wurstbrot

    es kann wie bei PNG und Co auch passieren dass die Texturen plötzlich durchknallen, allerdings bei weitem nicht so häufig

    Da fällt mir gerade noch ein Schuss in ne andere Richtung ein: Kann man das "Durchknallen" der Texturen evtl. durch low-res-Kopien verhindern? Das heißt TGA-Texturen für Texturen, bei denen Komprimierung nicht gewünscht ist, als Ausweichmöglichkeit aber eine _#low-Textur im DDS-Format, die OMSI dann stattdessen lädt, wenn der eingestellte max-Speicher für hochauflösende Texturen zur Neige geht (an anderer Stelle wurde ja schon geklärt, dass die Texturen immer dann schwarz werden, wenn der Speicher nicht mehr ausreicht - was widerum teilweise(!) auch Einstellungssache ist - sind z.B. 500MB eingestellt, werden natürlich trotzdem mehr Texturen geladen, nur nicht mehr hochauflösend).

    Zitat von Lµkas

    Da fällt mir gerade noch ein Schuss in ne andere Richtung ein: Kann man das "Durchknallen" der Texturen evtl. durch low-res-Kopien verhindern? Das heißt TGA-Texturen für Texturen, bei denen Komprimierung nicht gewünscht ist, als Ausweichmöglichkeit aber eine _#low-Textur im DDS-Format, die OMSI dann stattdessen lädt, wenn der eingestellte max-Speicher für hochauflösende Texturen zur Neige geht (an anderer Stelle wurde ja schon geklärt, dass die Texturen immer dann schwarz werden, wenn der Speicher nicht mehr ausreicht - was widerum teilweise(!) auch Einstellungssache ist - sind z.B. 500MB eingestellt, werden natürlich trotzdem mehr Texturen geladen, nur nicht mehr hochauflösend).

    Ich bin nicht sicher ob das funktionieren würde. Meines Wissens nach greifen die _#low-Varianten wenn man die Option LowRes Texturen verwenden aktiviert hat. Und dann nimmt OMSI immer diese, sofern vorhanden (man kann den Spieß auch umdrehen und sich unter _#low besonders hoch aufgelöste bereitstellen...)


    Was anderes ist wiederum "alle Texturen auf 256 Pixel reduzieren": hier lädt offenbar OMSI die Texturen (auch normale, _#low nur wenn das auch aktiviert ist) und reduziert diese intern. Sieht natürlich furchtbar aus;-)


    Was nun passiert wenn man den maximalen Speicher niedrig eingestellt hat weiss ich nicht genau. Entweder aktiviert sich dann die Variante mit _#low oder halt die Reduzierung auf 256x256. Probiers mal aus, ich denke im Debug-Fenster siehst Du dann anhand der Texturnamen was passiert.

    wurstbrot tatsächlich bin ich gerade im hochoffiziellen OMSI1 Handbuch fündig geworden (Seite 102f.)

    Es ist wirklich verrückt. Da liegt die Antwort vermutlich auf der Hand, und wir diskutieren hier lange herum... zumindest würde ich nicht glauben, dass das Handbuch lügt. :P