NEXT - für Trainsimulator Classic (Railworks)

Zitat von ice

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.

Alles anzeigen

Da hast du grundsätzlich recht: sauber gebackenes AO in Texturen ist natürlich die beste Basis, weil gute Assets dadurch schon von Haus aus mehr Tiefe bekommen.

Aber genau da liegt der Unterschied:

Das, was ich meine, ist kein Ersatz für gebackenes AO und auch nicht einfach das normale TSC-SSAO.

Contact AO Shading arbeitet viel lokaler. Es dunkelt nicht die ganze Szene ab, sondern nur sehr kurze Kontaktbereiche, z.B. wo Rohre am Boden liegen, Schwellen im Schotter sitzen oder Objekte direkt aufeinander/nebeneinander stehen.

Gebaktes AO ist statisch im Asset. Das spielinterne AO ist globaler und gröber.

Contact AO ist ein zusätzlicher, sehr gezielter Kontakt-Schatten im Bild, damit Objekte nicht mehr so „schwebend“ oder flach wirken und hat mit der normalen Umgebungsverdeckung im Spiel absolut nichts zu tun.

Also ja: Wenn ein Author sauber modelliert und AO baked, sieht es schon besser aus. Aber Contact AO hilft besonders bei alten oder einfachen TSC-Assets, die eben keine guten AO-Texturen haben oder im Spiel trotzdem zu flach wirken.

So, auch hier habe ich den Namen geändert.

Und hier seht ihr auch noch ein paar Bilder.

Ich bin aktuell schon sehr weit fortgeschritten, allerdings muss ich jetzt auf die Antwort von DTG warten, da es nicht möglich ist DTG Content auszulesen, da die Geometrie Blobs von einigen Objekten auf den DLC Strecken verschlüsselt sind.

Was geht schon?

Sämtliche Scripts (angefangen von Signalen, Zügen, Waggons etc)
Eigener Dispatcher
Eigenes System zur manuellen Weichenstellung
Eigenes HUD
Sounds, ZZA's, etc
PZB, LZB, AFB, sämtliche Zugsicherungssysteme

Eigentlich bisher alles was man zum Fahren braucht.

Der Editor hat eine Suchleiste bekommen (weil das oft gewünscht wurde)
Und die Favoriten dort werden abgespeichert - auch über den Neustart hinaus.

Funktionsweise des Editors ist exakt die selbe wie beim Original.

Hier ein gutes Beispiel was man mit RELIEF erreichen kann.
Das gesamte Gleisbett wirklich gleich wesentlich realistischer.

Zitat von mikede

Relief is nice, but you should watch out with it, make sure its doesn't contain relief anymore on some distance from the camera, proper lod policy is very important with this.
its also nice if you can introduce instancing on the sleepers and its clips objects , yard full of them can eat you game engine alive.
im actually c++ developer

By the way, the name you use is also used by somebody, Train Simulator NEXT – Virtual Railroading i dont know the status from this sim, but i reminded the name from there.

Its NOT Train Simulator NEXT - its only NEXT. I did the same with OMSI.

And also its not allowed - not even for an Open Source Project to use "Train Simulator" or "Railworks" or anything which contains Stuff or Names from DTG.

And since i work with a lot of Threads - here is a List:

Rendering

• Parallel passes: The frame’s passes (shelter map, shadow cascades, depth prepass, mirror, main pass) are each recorded on their own thread. Recording used to take about 27 ms per frame on one core on the Nordbahn.
• Submit thread: The early command buffers go to the GPU queue on a separate thread. This took about 13 ms of checks off the render thread.
• Main pass split: Without the bindless path, the main pass is recorded in two halves on two threads.
• Parallel culling: Distance culling runs on up to 8 threads once the lists hold more than 4096 instances. It took about 5 ms on one core.
• Helper threads for lists: The material group and the GPU cull plan are built on a helper thread, and the new draw lists are installed only when ready.

Streaming and hitches

• Own tile thread: Tile loading and the GPU build of tiles run on their own thread, with one loader thread.
• Release thread (drop):Tile models are freed on a drop thread, 32 objects plus a 1 ms pause at a time. The world-swap hitches of 58–62 ms fell to under 0.1 ms.
• Terrain layers: The layers upload on a “terrain up” thread.
• Thread priority: All helper threads run below normal priority. That removed the last two hitches during the start-world swap.

Simulation and scripts

• Own sim thread: The simulation runs on its own thread and is now the default.
• Dispatcher: The dispatcher got its own thread, but part of it was rolled back (0.5 s switch cycle, traffic markers) because the system stopped working properly.
• Parallel scripts: AI scripts run in parallel per train, with at most 4 threads.

Loading

• Startup: Track network on 12 threads, start world in parallel, signals in parallel, and train and sound files prefetched. Together these cut the time to the first frame from 34 s cold to about 16 s warm.

Zitat von Kim_olesen1

Already following you on the Railworks Austria thread, very interesting project.

This is ofcourse what DTG ought to have done, but really they probably did not want their legacy simulator to actually be in competition to TSW.

That’s probably part of it. TS Classic still sells well, but every bigger upgrade would compete with TSW, so it’s understandable that DTG keeps it on a maintenance track.

That’s exactly the gap NEXT is trying to fill. It’s a free, open-source rebuild of the TSC engine that reads the existing content as it is: routes, scenarios, rolling stock, Lua scripts. Nothing gets converted or re-released. Your DLC simply runs on a modern renderer with current lighting, weather and performance.

It’s not meant as competition to either product. It just lets the content we’ve all bought over the years keep looking and playing well.

But in my opinion -
I dont see any competition to TSW.

And the main aspect of NEXT is not to have Unreal Graphics 234409873204 - it is functionality, compatiblity and stability.

Und hier zu meiner Erklärung was ich zum Originalen TSC anders mache:

So entlaste ich den Hauptkern

Der Hauptthread ist der Thread, der das Bild fertigmacht und auf den Bildschirm bringt. Ich habe alles, was sich verschieben lässt, von ihm weggenommen:

• Simulation auf eigenem Thread: Physik, Signale, Verkehr und Ton laufen parallel zum Zeichnen. Der Hauptkern bekommt nur das Ergebnis.
• KI-Skripte parallel: Die Skripte der KI-Züge laufen jeweils auf mehreren Threads, nicht nacheinander.
• Bildaufbau aufgeteilt: Ich bereite Schatten, Tiefenvorlauf, Dachkarte, Spiegel und Hauptpass auf getrennten Threads vor und setze sie erst am Ende zusammen.
• Abschicken auf eigenem Thread: Die Befehle gehen auf einem eigenen Thread an die Grafikkarte. Die Prüfungen dabei kosteten vorher auf dem Hauptkern etwa 13 ms.
• Culling auf der Grafikkarte: Welche Objekte sichtbar sind, entscheidet die GPU. Die CPU verteilt nur noch die Arbeit, und der Rest läuft auf bis zu 8 Threads.
• Kachel-Streaming im Hintergrund: Laden, Vorbereiten und Hochladen der Kacheln laufen auf eigenen Threads mit niedrigerer Priorität. Der Hauptkern setzt nur noch fertige Kacheln ein, eine alle 10 Bilder.
• Freigeben im Hintergrund: Nicht mehr gebrauchte Modelle gibt ein eigener Thread frei, in kleinen Stücken. Das kostete vorher bis zu 60 ms im Hauptthread.
• Listen im Hintergrund: Materialgruppen, Zeichenlisten und der Plan für das GPU-Culling baue ich auf einem Hilfsthread.
• Gelände-Texturen: Sie laden auf einem eigenen Thread hoch.
• Dispatcher: Der Fahrplan läuft auf einem eigenen Thread.

Alle Hilfsthreads laufen mit niedrigerer Priorität, damit sie dem Hauptkern keine Rechenzeit wegnehmen.

Was auf dem Hauptkern bleibt, ist das Zusammenbauen und Abschicken des Bildes. Dazu die Messwerte: Der Render-Thread braucht etwa 12 ms pro Bild, die Simulation etwa 10,9 ms parallel dazu.

Danke für die Einordnung. Ein paar Dinge möchte ich trotzdem geraderücken.

Zum Namen: Dass niemand „NEXT“ für sich gepachtet hat, sehe ich genauso. Gerade deshalb verstehe ich nicht ganz, warum du es nötig hattest, dich öffentlich abzugrenzen. Verwechslungen will ich vermeiden, deshalb heißt mein Projekt ausdrücklich „NEXT – für TSC“. Es ist klar als eigenständiges Open-Source-Projekt für Train Simulator Classic gekennzeichnet. Mit deinem Train Simulator NEXT hat es nichts zu tun und will es auch nicht.

Zu „fast vollständig KI-generiert“: Ja, ich arbeite mit KI-Werkzeugen und mache daraus kein Geheimnis. Das ist ein Werkzeug, so wie Compiler, Engines und Middleware. Entscheidend ist doch, was am Ende herauskommt und ob es funktioniert. Wer pauschal von „AI-Slopware“ spricht und dazu YouTube-Videos verlinkt, ohne sich das Projekt selbst anzusehen, macht es sich ziemlich einfach. Der Code ist offen, jeder kann reinschauen und sich selbst ein Urteil bilden. Das ist mehr Einblick, als du in dein eigenes Projekt geben möchtest. Das ist dein gutes Recht, aber dann ist Kritik an der Arbeitsweise anderer etwas wohlfeil.

Zum Rechtlichen: Die Frage ist berechtigt, und ich nehme sie ernst. NEXT – für TSC liefert keine Inhalte von Dovetail oder anderen Herstellern aus. Es liest nur die Dateien aus der eigenen, rechtmäßig erworbenen Installation des Nutzers. Außerdem habe ich mich bereits direkt an Dovetail Games gewandt, statt im Forum darüber zu spekulieren, was sie vielleicht unterbinden könnten. Wenn von dort eine klare Ansage kommt, richte ich mich danach.

Dir wünsche ich mit Train Simulator NEXT ebenfalls viel Erfolg. Am Ende profitieren wir alle davon, wenn es mehr als eine Idee gibt, wie es mit Train Simulator Classic weitergehen kann.

Oh und btw - das möchte ich noch hinzufügen

Mich interessiert weder deine "eigene Entwicklung" - noch deine "technische Konzeption". - hab mein eigenes Hirn welches ich dafür anstrenge.

Ja es ist halt ein Unterschied ob mit KI alleine oder durch "Unterstützung" der KI.

Wie dumm wäre ich, wenn ich den kompletten Programmcode selbst schreibe, wenn das auch die KI kann.

Und was ich an dem Projekt übernheme ist auch ganz klar

* Fehleranalyse und größtenteils auch - behebung

* rechtliche Überprüfungen
* Konzepterstellung (neue Ideen)
* Korrekturen
* Detailfunktionen - wie - was macht der Dispatcher wann

* Physikalische Berechnungen
* Recherche

Ohne meine Überprüfung wird kein Code umgeschrieben ja nicht mal eine Ziffer ersetzt.

Wenn ihr so wollt - ich bin der Projektleiter, arbeite aber trotzdem komplett mit und die KI Agents sind eben meine Mitarbeiter.
Ich denke daran gibt es nichts verwerfliches.

Ich kann diesen Einwurf deshalb absolut NICHT nachvollziehen.

Es gibt KI und es gibt KI - aber es kommt auf den Menschen an der damit arbeitet.

Danke dir, das trifft es ziemlich genau.

„Bau mir einen TSC-Klon“ eintippen und abwarten, das funktioniert nicht und hat auch nie funktioniert. Hinter NEXT – für TSC steckt Arbeit, wie man sie aus jedem normalen Softwareprojekt kennt:

• Aufteilung: Das Projekt ist in klar getrennte Bereiche zerlegt: Grafik und Shader, Modelle und Animationen, Lua-Skripte und Signale, Fahrphysik, Sound, KI-Fahrdienstleiter, Editor. Jeder Bereich hat feste Zuständigkeiten und Regeln, wer welche Dateien anfasst.
• Nachvollziehbar statt erfunden: Werte kommen aus den Original-Blueprints und Dateien, nicht aus Schätzungen. Wo etwas eine Annahme ist, wird es als solche markiert und später überprüft.
• Prüfung von außen: Signale, Lokskripte, Shader, Sound, Physik, Kupplungen, Gelände und Dispatcher werden regelmäßig von einem zweiten, unabhängigen System gegengeprüft. Die Fehlerlisten werden dann Punkt für Punkt abgearbeitet.
• Ein Build, feste Tests: Gebaut wird zentral, mit automatischen Tests bei jedem Schritt. Was dort scheitert, geht zurück, bevor es überhaupt jemand startet.
• Abnahme im Spiel: Am Ende sitze ich selbst im Führerstand und prüfe, ob sich Signale, Bremsen, Anzeigen, Licht und KI-Verkehr so verhalten wie im Original. Erst dann gilt etwas als erledigt.

Die KI schreibt den Code, ja. Aber was gebaut wird, wie es aufgeteilt ist, ob es stimmt und was rausgeht, entscheide ich. Wer das „Vibe Coding“ nennt, hat es entweder nie selbst versucht oder das Ergebnis nicht angeschaut.