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.