TSC Visual Framework

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).
    • Projektname: TSC VISUAL FRAMEWORK
    • Projekttyp: Ein Allgemeines Tool - welches analysiert und korrigiert (Kantenglättung, MipMap Fehler, Darstellung der Spielwelt, etc)
    • Projektform: Payware
    • Beschreibung des Arbeitsfortschritts: Das meiste funktioniert bereits - es geht momentan um die sogenannte Wire Reconstruction Methode - also das, was ihr als flimmern seht im Bild bei Oberleitungen, etc



    TSC VISUAL FRAMEWORK

    Zitat
    Zitat Das TSC Visual Framework erweitert Train Simulator Classic um moderne Bildverarbeitungstechnologien, die speziell auf die Anforderungen der Eisenbahnsimulation abgestimmt wurden.
    Der Fokus liegt auf Bildstabilität, Tiefenwirkung und einer natürlicheren Darstellung der Spielwelt. Statt den Charakter des Spiels zu verändern, verfolgt das Framework das Ziel, die bestehende Grafikengine gezielt zu modernisieren und bekannte Schwächen zu reduzieren.
    Entwickelt für Spieler, die das Maximum aus Train Simulator Classic herausholen möchten.


    SCREENSHOT 2

    ADAPTIVE BELICHTUNG

    Zitat
    Zitat Wechselnde Lichtverhältnisse gehören zu den größten Herausforderungen älterer Grafikengines. Besonders in Tunneln, Bahnhöfen oder bei Nachtfahrten wirken Szenen häufig zu dunkel oder verlieren wichtige Bilddetails.
    Die adaptive Belichtung analysiert die aktuelle Szene in Echtzeit und passt die Helligkeit dynamisch an. Dadurch entstehen natürlichere Übergänge zwischen hellen und dunklen Bereichen sowie eine angenehmere Wahrnehmung der Umgebung.
    Das Ergebnis ist ein deutlich stimmigeres Fahrerlebnis bei allen Lichtverhältnissen.


    SCREENSHOT 3

    WIRE RECONSTRUCTION

    Zitat
    Zitat Fahrdrähte, Tragseile und andere dünne Strukturen gehören zu den anspruchsvollsten Elementen moderner Bildverarbeitung.
    Die Wire-Reconstruction-Technologie erkennt diese Strukturen gezielt und nutzt die gewonnenen Informationen, um deren Stabilität und Sichtbarkeit zu verbessern. Besonders auf größere Entfernungen können dadurch störende Flimmereffekte reduziert werden.
    Die dargestellte Debugansicht zeigt die Echtzeiterkennung von Oberleitungen innerhalb des Frameworks.


    SCREENSHOT 4

    TEMPORAL ANTI-ALIASING (TAA)

    Zitat
    Zitat Das integrierte Temporal Anti-Aliasing analysiert Bildinformationen über mehrere aufeinanderfolgende Frames hinweg.
    Durch die Nutzung von Bildhistorie und Bewegungsinformationen können feine Details rekonstruiert und störendes Flimmern deutlich reduziert werden. Besonders Vegetation, Oberleitungen, Gleisanlagen und entfernte Objekte profitieren von einer ruhigeren und stabileren Darstellung.
    Die Debugansicht visualisiert die Bereiche, die für die temporale Bildstabilisierung ausgewertet werden.


    SCREENSHOT 5

    TECHNISCHER EINBLICK

    Zitat
    Zitat Das TSC Visual Framework basiert auf einer mehrstufigen Analyse der dargestellten Spielwelt.
    Hierzu werden verschiedene Bildinformationen wie Kanten, Tiefendaten und Oberflächennormalen ausgewertet. Diese Daten bilden die Grundlage für zahlreiche Funktionen des Frameworks, darunter Bildstabilisierung, Tiefenverbesserung und die Analyse feiner Strukturen.
    Die gezeigten Debugansichten ermöglichen einen Einblick in die internen Prozesse und zeigen, wie das Framework die Spielwelt in Echtzeit analysiert.

    Anbei noch ein paar Screenshots aus dem Menü:


    Kostet das FPS?

    Gemessen wurde ein Maximalverlust von 2-3 Frames, da alles über einen Dx9 Hook läuft und das meiste schon über die Engine selbst gesteuert wird.


    Kostet es Geld?

    Ja es wird etwas kosten, aber momentan bin ich eher bei der Vorstellung des Tools da es noch einige Baustellen gibt.

    Ich wollte es euch aber dennoch nicht vorenthalten.

  • DaTeddyx3

    Hat das Thema freigeschaltet.
  • Wunderbare Sache! :)


    Ich finde den TSC immer noch in Hinblick auf Streckenvielfalt, Anzahl der Loks und dem Edtior, als Spitzenreiter unter den Eisenbahnsimulationen.

    Schön das durch dein Tool daher die Grafik, das Ambiente und technische Möglichkeiten angehoben werden.


    LG

  • Klingt sehr interessant. :thumbup:

    Eine Frage dazu. Wird es auch mit Vulkan (DXVK) funktionieren? Ich habe eine AMD Karte und da bringt mir Vulkan gegenüber DirectX ca. 25-50% mehr FPS. Auf diese FPS will ich nur ungern verzichten.

    Ja, es läuft mit DX9 und mit Vulkan. Da ich selbst auch mit dem RW Enhancer normalerweise über Vulkan gehe.


    Ja, das ist richtig und genau das ist meine Intention. So viel breiten Content wie hier hast du in keinem TSW.

  • Der TSc ist eigentlich ein DirectX9.0 Spiel. Es wurde nachträglich auf DX12 möglich gemacht.

    Man kann sowohl als DX9 bzw. Vulkan oder DX12 starten. Mit der jeweiligen EXE Startversion versteht sich.

  • Bei mir sieht nichts matschig aus, matschig sieht es nur aus wenn es nur mit schwachen Einstellungen genutzt wird. Meistens reicht die Hardware nicht.

    Selbst mit einer 4080 kann es unter Umständen schlecht aussehen, wenn entweder die andere HardwareUmgebung nicht stimmt oder die Spielengine nsich nicht verträgt.

    Deswegen gibt es auch Leute mit kleineneren 3D Beschleunigern, die damit dann schonmal schneller laufen...obwohl sie unter einer 4080 rangieren.

    Vulkan gibt mir im TSc 10-15 Frames mehr als DX12.

  • Warum Vulkan/DXVK für TSC sinnvoller ist als DX9 oder der experimentelle DX12-Modus

    Train Simulator Classic basiert technisch weiterhin auf einer sehr alten DirectX-9-Renderpipeline. Genau dort liegen viele der typischen Probleme: CPU-Limit, alte Render-State-Logik, schwaches Ressourcenmanagement, instabile Frametimes und Probleme mit modernen Treibern. Der experimentelle DX12-Modus von TSC war laut Dovetail selbst nicht vollständig optimiert und sollte Feedback sammeln; bei Problemen wurde weiterhin empfohlen, auf der normalen 64-bit-Version zu spielen.

    Vulkan über DXVK ist für TSC deshalb interessant, weil es nicht versucht, TSC intern zu einer modernen DX12-Engine umzubauen, sondern die vorhandenen D3D9-Aufrufe in eine moderne Vulkan-Ausgabe übersetzt. DXVK ist genau dafür gebaut: Es ist eine Vulkan-basierte Implementierung für Direct3D 8/9/10/11.

    Für unser Framework bedeutet das:

    TSC bleibt logisch D3D9, aber die Ausgabe läuft moderner über Vulkan. Dadurch können wir alte TSC-Hooks, D3D9-States und Shader-Pfade weiter nutzen, aber trotzdem von DXVK/Vulkan bei Frametimes, Backend-Stabilität und modernen GPU-Treibern profitieren.

    DirectX 9 im TSC

    Vorteile

    • Originaler Renderpfad von TSC
    • höchste Kompatibilität mit alten Strecken, Assets und Shadern
    • funktioniert ohne zusätzliche Wrapper
    • unser d3d9.dll-Proxy kann direkt in den D3D9-Pfad eingreifen
    • RenderStates wie SetRenderState, SetSamplerState, DrawPrimitive, DrawIndexedPrimitive sind direkt abfangbar
    • ideal für Debugging, Shader-Hooks und klassische D3D9-Modding-Techniken

    Nachteile

    • sehr alte API
    • stark CPU-/Drawcall-limitiert
    • moderne Treiber optimieren D3D9 oft nicht mehr so aggressiv wie moderne APIs
    • Framepacing kann unruhig sein
    • viele Probleme entstehen aus alter Render-State-Logik
    • schlechte Kontrolle über moderne GPU-Features
    • Z-Fighting, Alpha-Test-Flimmern und MIP-Shimmering bleiben enginebedingt bestehen
    • Downsampling/AA löst nicht alle alten TSC-Probleme

    Kurz gesagt

    DX9 ist der stabilste und kompatibelste Originalpfad, aber technisch auch der limitierendste.

    DirectX 12 Experimental im TSC

    Vorteile

    • theoretisch moderneres Backend
    • kann auf bestimmten Systemen oder Szenarien bessere GPU-Auslastung bringen
    • langfristig wäre DX12 als nativer Renderpfad moderner als DX9
    • potentiell besseres Ressourcenmanagement, wenn vollständig sauber implementiert

    Nachteile

    • in TSC offiziell als experimental eingeführt
    • Dovetail schrieb selbst, dass der DX12-Build noch nicht vollständig optimiert war und Feedback gesammelt werden sollte
    • kann je nach Strecke, Asset, System und Treiber instabiler sein
    • für Modding schwieriger, weil klassische D3D9-Hooks nicht mehr direkt greifen
    • unsere bestehenden d3d9.dll-Hooks, RenderState-Hooks und Shader-Override-Ansätze passen dort nicht sauber
    • bringt nicht automatisch bessere Bildqualität
    • löst Z-Fighting/enge Mesh-Überlagerungen nicht grundsätzlich
    • für alte TSC-Inhalte kann DX12 sogar mehr neue Probleme erzeugen, weil die Engine ursprünglich nicht dafür gebaut wurde

    Kurz gesagt

    DX12 Experimental ist interessant, aber für ein tiefes TSC-Framework aktuell weniger kontrollierbar und weniger vorhersehbar als D3D9/DXVK.

    Vulkan über DXVK

    Vorteile

    • nutzt den bestehenden D3D9-Pfad von TSC, gibt ihn aber über Vulkan aus
    • DXVK ist speziell eine Übersetzungsschicht von Direct3D 8/9/10/11 zu Vulkan
    • unser Proxy kann weiterhin als RailWorks\d3d9.dll arbeiten
    • DXVK kann als Backend aus RailWorks\dxvk\d3d9.dll geladen werden
    • moderne Vulkan-Treiber können oft bessere Frametimes liefern als alter nativer DX9-Treiberpfad
    • DXVK bietet zusätzliche Konfigurationsmöglichkeiten über dxvk.conf; die Datei wird üblicherweise im Arbeitsverzeichnis beziehungsweise beim Spiel-Exe-Pfad gesucht
    • Optionen wie d3d9.alphaToCoverage, d3d9.maxFrameLatency und LOD-/Sampler-Einstellungen können gezielt getestet werden
    • guter Mittelweg: alte TSC-Kompatibilität behalten, aber moderneres Backend nutzen
    • ideal für unser Framework, weil wir D3D9-Hooks behalten und trotzdem Vulkan als Ausgabe verwenden können

    Nachteile

    • zusätzliche Übersetzungsschicht
    • nicht jede D3D9-Spezialität verhält sich exakt wie beim nativen DX9-Pfad
    • manche alte Fixed-Function- oder Shader-Edge-Cases können anders reagieren
    • DXVK-Konfiguration muss manuell angelegt werden; DXVK erzeugt die dxvk.conf nicht automatisch
    • Debugging wird komplexer, weil man TSC → Proxy → DXVK → Vulkan betrachtet
    • nicht jedes Flimmerproblem wird gelöst, besonders nicht echtes Z-Fighting durch Mesh-auf-Mesh
    • kann je nach GPU/Treiber/Strecke eigene Nebenwirkungen haben

    Kurz gesagt

    Vulkan/DXVK ist für TSC aktuell der beste Kompromiss:

    mehr Modernität als DX9, aber deutlich mehr Kontrolle und Kompatibilität als der experimentelle DX12-Pfad.

    Mein Fazit

    Für TSC ist Vulkan über DXVK aktuell der sinnvollste Weg, weil wir damit drei Dinge kombinieren:

    1. D3D9-Kompatibilität

      TSC läuft weiterhin über seinen bekannten Renderpfad.
    2. Framework-Kontrolle

      Unser d3d9.dll-Proxy kann weiterhin RenderStates, Shader, SamplerStates, Depth und Postprocessing kontrollieren.
    3. Modernes Backend

      Die eigentliche Ausgabe läuft über Vulkan/DXVK statt über den alten nativen DX9-Treiberpfad.

    Deshalb ist Vulkan/DXVK für unser TSC Visual Framework besser geeignet als nativer DX9 oder der experimentelle DX12-Modus. DX9 ist zu alt und limitiert, DX12 Experimental ist zu unkontrollierbar, aber Vulkan/DXVK gibt uns genau den Mittelweg: alte Engine behalten, modernes Backend nutzen, Framework-Hooks weiter verwenden.


    Und das ist eine Zusammenfassung aus all meinen recherchierten Quellen.


    Der TSc ist eigentlich ein DirectX9.0 Spiel. Es wurde nachträglich auf DX12 möglich gemacht.

    Man kann sowohl als DX9 bzw. Vulkan oder DX12 starten. Mit der jeweiligen EXE Startversion versteht sich.

    Und nein kann man nicht. Bei sehr vielen Usern startet TSC im DX12 Modus überhaupt nicht.

  • Bei sehr vielen Usern startet TSC im DX12 Modus überhaupt nicht

    Eben weil es nur angepasstes exp. DX12 ist und nicht alle haben auch eine DX12 fähige Karte. Viele spielen noch mit DX11 Karten.

    Vulkan reduziert mit dxvk eben den Shaderoverhead, bzw. vereinfacht damit die Shadersprache...die Befehlskette wird kleiner..allerdings ist daß limitiert auf zwei C.Kerne.

  • Nein hat weniger mit der Karte zu tun. Ich hab ne 5080 und bei mir läuft es gar nicht mit DX12.

    Vulkan über DXVK macht TSC nicht „modern“, aber es verlagert die alte D3D9-Ausgabe auf einen effizienteren Vulkan-Pfad. Dadurch sinkt oft der CPU- und Treiber-Overhead bei Drawcalls und Pipeline-Verwaltung. Shader und Renderstates werden von DXVK in Vulkan-Pipelines übersetzt und gecacht, wodurch Shader-Stutter reduziert werden kann. Die Engine selbst bleibt aber alt und meist auf wenige CPU-Threads begrenzt; Vulkan hebt diese Engine-Limitierung nicht vollständig auf.


    Also: Ja, DXVK kann den Overhead reduzieren. Nein, Vulkan/DXVK ist nicht grundsätzlich auf zwei Kerne limitiert.

  • Nein, Vulkan/DXVK ist nicht grundsätzlich auf zwei Kerne limitiert.

    Da hast Du Recht und ich habe mich falsch ausgedrückt, die zwei Kerne sind auf den TSc gemünzt ...eigentlich läuft alles auf einen Kern,einwenig Berechnungen laufen auf einen zweiten Kern mit.

    Es gibt aber auch Spiele die trotzdem nicht besser laufen. Auch Spiele mit Anticheat können Probleme machen.

    Da nützt dann auch die beste Karte nichts.

  • Da hast Du Recht und ich habe mich falsch ausgedrückt, die zwei Kerne sind auf den TSc gemünzt ...eigentlich läuft alles auf einen Kern,einwenig Berechnungen laufen auf einen zweiten Kern mit.

    Es gibt aber auch Spiele die trotzdem nicht besser laufen. Auch Spiele mit Anticheat können Probleme machen.

    Da nützt dann auch die beste Karte nichts.

    Vulkan/DXVK macht aus TSC keine moderne Multi-Core-Engine. Der Train Simulator Classic bleibt stark auf einen Hauptkern limitiert, mit etwas Arbeit auf einem zweiten Kern.

    Der Vorteil von DXVK liegt eher darin, den alten DX9-Pfad zu entlasten: weniger Treiber-Overhead, effizientere Drawcalls und ein modernerer Vulkan-Unterbau.

    Aber Vulkan ist kein Wundermittel. Wenn ein Spiel selbst schlecht optimiert, stark CPU-limitiert oder durch Anti-Cheat eingeschränkt ist, bringt auch DXVK nicht immer Vorteile. Eine starke Grafikkarte hilft wenig, wenn die Engine am Hauptthread hängt.

    Für das TSC Visual Framework ist Vulkan deshalb kein reiner FPS-Trick, sondern eine modernere Basis, um den alten Renderpfad sauberer und effizienter zu behandeln.


    Aktuell arbeite ich an sogenannten "Contact AO Shading"

    Hier eine kurze und knappe Erklärung was es macht:


    Contact AO Shading ist eine sehr kurze, lokale Abdunklung dort, wo Objekte optisch Kontakt zur Umgebung haben.

    Also z.B.:

    • Mastfuß am Boden
    • Zaunpfosten im Gras
    • Schwellen im Schotter
    • Räder/Objekte nahe am Untergrund
    • Vegetation unten am Boden

    Es ist kein großes SSAO, das die ganze Szene dunkler macht, sondern eher ein feiner „Objekt-klebt-am-Boden“-Effekt.

    Kurz gesagt:

    Contact AO gibt Objekten Gewicht und Tiefe, indem es nur die direkten Kontaktbereiche leicht abdunkelt. Dadurch wirkt TSC weniger flach und weniger „schwebend“, ohne das komplette Bild zu verdrecken.


    Hier ein Bild ohne "Contact AO Shading"

    Hier ein Bild mit "Contact AO Shading"


    Es verleiht der gesamten Umgebung wesentlich mehr Tiefe - es geht nur noch um Feinabstimmungen.

    2 Mal editiert, zuletzt von FreD () aus folgendem Grund: Ein Beitrag von FreD mit diesem Beitrag zusammengefügt.

  • Das habe ich doch schon alles oben geschrieben..also für mich nichts Neues.

    Der Geschwindigkeitsvorteil von Vulkan ensteht maßgeblich durch die reduzierte Shaderlanguage im Vergleich zu DX9.0.

    TSc:,

    Das Spiel hat ja auch eine "Umgebungsverdeckung" die 1 oder 2 Stufen in den Einstallungen dazu schaltbar ist. Das ist nichts anderes als "Ambient Occlusion...also "AO".

    Da werden Ecken Spalten, Übergänge zwischen Objekten mit Schatten belegt. Das wird über alle Objekte der Scenery angewand(eingeschalttet).


    Wer saubere Arbeit als Author macht, der backt bei Texturerstellung in Modeller den Licht-Schatten gleich mit in die Textur. Das gibt nacher den Tiefen-Effekt.


    In den ersten Bild oben sind keine Texturen mit AO gebacken...deswegen sehen die auch fade und fast kontourlos aus.