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.