Distant Terrain im TS ab TS2014

    • Distant Terrain im TS ab TS2014

      Nachdem ich wegen der unbefriedigenden Berg-Darstellung mittlerweile einige Experimente auf meinen eigenen Strecken und auf der (simtrain) SBB Route gemacht habe, hier eine kleine Zusammenfassung der Ergebnisse.

      Zunächst: die Funktion ist keineswegs ganz neu im TS2014. Hier ein Zitat aus der Ankündigung von Railworks 2:
      RailWorks currently renders 4km x 4km of high resolution textured terrain plus a further 6km of lower resolution 'distant mountain' terrain. In other words, when exploring your surroundings at the moment, only the nearest 4km are recreated in high detail which moves along continuously with you. By utilizing improvements in PC specs and refining the underlying code, we will be extending the draw distance further so that a much greater amount of the surrounding area is highly detailed, increasing the visual realism of the simulator.
      Die Funktion war wohl längere Zeit wegen Bugs deaktiviert, aber z.B. die SBB Route 1 enthält noch Distant Terrain (ja, der berühmte Spalt im Berg ..).

      Was macht die Funktion:
      Sie erzeugt niedrig aufgelöstes Gelände aus den bereits in die Strecke importierten DEM-Kacheln (in Terrain/DistantPatches.bin), sowie die zugehörigen Texturen (in terrain/textures/tile_xx_yy) . Dabei berücksichtigt sie die Texturierung, die man dem Gelände bereits verpasst hat. Diese Texturierung kann man, während die Funktion arbeitet, gut in dem Quadrat rechts oben beobachten, das die gerade bearbeitete "Makro-Kachel" darstellt. Wenn das Gelände noch nicht texturiert wurde, besteht die Distant Terrain Textur nur aus den Farben der unterschiedlichen Höhenzonen aus dem Textur-Blueprint.

      Dieses niedrig aufgelöste Gelände wird angezeigt, wenn man weiter davon weg ist, als die Sichtbarkeitsgrenze für "normales" Gelände.
      Wenn man Distant Terrain benutzt, kann (und sollte) man auch die Fog-Entfernungen in den ToD Dateien vergrössern, da der Fog in den Standard-ToDs meist so eingestellt ist, dass die Sichtbarkeitsgrenze des normalen Geländes bereits im Nebel verschwimmt.

      Experiment mit der SBB Route 1:
      1. vorhandene DistantPatches.bin entfernen --> die Berge am Horizont sind weg.
      2. "Distant Terrain" Tool benutzen - (man braucht etwas Geduld, bei so 'ner großen Strecke gibts ein paar Phasen, in denen sich nichts sichtbares tut)
      Ergebnis: neues Distant Terrain mit Texturierung (das Original hat gar keine Texturierung, das ging damals wohl noch nicht) - das sieht ingame doch schon mal ganz anders aus :) (der Zyklopenspalt im Berg ist nebenbei auch verschwunden)

      Für die Benutzung des Distant Terrain Tools ist also folgende Reihenfolge sinnvoll (sofern es für die Gegend überhaupt von Bedeutung ist):
      1. DEM importieren, soweit das Gelände sichtbar sein könnte (man muss evtl ein paar mal "nachlegen", weil man das im Welteditor nicht direkt beurteilen kann)
      2. Gelände texturieren (auch das entfernte)
      3. Distant Terrain erzeugen. wichtig dabei:
      3.1 Beim Start des Tools sollte man am Route Origin sein
      3.2 die DEM-Kacheln sollten keine Lücken haben, d.h. wenn horizontal oder vertikal Kachel 1 und 3 importiert wurden, sollte auch Kachel 2 importiert werden.

      Es ist auch kein Problem das Distant Terrain wiederholt zu erneuern, oder gar auf einer fertigen Strecke zu benutzen.
      Abstürze hatte ich bisher nur, wenn die oben erwähnten Punkte 3.1 bzw (vor allem) 3.2 nicht erfüllt waren.
      (edit: 3.1 scheint wichtiger zu sein als 3.2 - die SBB Route1 hat einige Lücken, die aber nicht zu Problemen führen, wenn man am Origin ist)

      edit:

      1.) Ergänzung zum DEM-Import:
      da muss man iterativ vorgehen. Durch den ersten Distant Terrain Lauf werden (bei entsprechenden ToD Daten) weit entfernte Berge sichtbar, und damit möglicherweise auch abgeschnittene Berge, wenn man noch nicht ausreichend DEM importiert hat. Also hinfliegen, mehr DEM importieren, DistantTerrain nochmal generieren ...
      In der fertigen Strecke könnte man, wenn man Speicher (und Ladezeit) sparen will, die DEM-Kacheln jenseits der Sichtbarkeit des "normalen" Geländes wieder löschen - sie sind ja im DistantTerrain enthalten.

      2.) Beispiel-Screenshots aus der SBB Route 1 (Standort: Mühlehorn)
      Bild 1: Originalzustand der Strecke, d.h. mit DistantTerrain, aber mit der alten (fehlerhaften) Version generiert (der berühmte Zyklopenspalt...)
      Bild 2: so siehts ohne Distant Terrain aus
      Bild 3: Distant Terrain neu mit TS2014 auf der fertigen Strecke generiert (die Texturierung des TS2014-Distant Terrain kommt hier nicht zur Wirkung; wenn man den Fog noch ändern würde, würde man aber auch in den entfernten Bergen noch etwas Strukturen sehen können)

      3.) Wintertexturen
      einfach Distant Terrain generieren, während im Editor Winter ist. Es werden dann die entsprechenden Wintertexturen (terrain/textures/tile_xx_yy_Wi) erzeugt. Mehr ist nicht zu tun, da das Terrain (terrain/DistantPatches.bin) selbst keine Textur-Referenzen enthält.

      Wunsch
      Durch die DistantTerain Generierung erhält man ja eine komplette texturierte "Landkarte" der Strecke. Du wünsch ich mir noch eine Option, diese auch ingame unter der 2D-Map anzeigen zu können :) ...
      Bilder
      • 2013-12-01_00001.jpg

        40,03 kB, 800×450, 639 mal angesehen
      • 2013-12-01_00002.jpg

        43,28 kB, 800×450, 627 mal angesehen
      • 2013-12-01_00003.jpg

        41,03 kB, 800×450, 666 mal angesehen
      Werbung

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von nobsi ()

    • Danke für deine ausführlichen Erkenntnisse in dieser Thematik.
      Doch will sich mir irgendwie noch nicht so richtig der Nutzen erschließen.

      Ich bin etwas verwirrt, ob es nun Form oder Farbe oder sogar beides manipuliert.
      Bislang war ich der Auffassung, dass diese Funktion lediglich eine Texturierung vornimmt, was mir in deinem 3. Edit auch so bestätigt wird: Erstellung von entfernten Wintertexturen für weit entfernte Berge.
      In deinem 2. Edit jedoch scheint aber auch die Form manipuliert zu werden, sonst würden nicht zuerst Berge auf der SBB-Route fehlen (Bild 2) und auch nicht der bekannte fehlerhafte Spalt plötzlich repariert sein (Bild 3).

      Was die eigentliche Form betrifft ist mir also noch nicht ganz bewusst, welchen Vorteil das gegenüber einem DEM-Import haben soll, außer dass etwaige Risse repariert werden, die ich aber auf noch keiner Route habe antreffen können.
      Irgendwie habe ich da wohl noch einen Knoten im Kopf und missverstehe wohl die korrekte Funktionsweise.

      Und was bedeutet dies alles für jemanden, der eine Strecke baut?
      Macht es Unterschiede, ob man davor oder danach noch das gelände manipuliert, indem man z.B. am Gleisbett rumzupft? Werden Bodentexturen beeinflusst? Wieviel DEM-gelände muss importiert werden, um gute Ergebnisse zu erzielen? Und können überflüssige DEM-Kacheln anschließend gelöscht werden um Nachladeruckler zu vermindern?

      Das alles sind noch Fragen, die ich sehr gerne beantwortet hätte, weil mir vielleicht dann eher ein Licht aufgeht, welchen Zweck, welchen Vorteil und welche Funktionsweise das Ganze haben soll.

      Danke
      Ist es denn wirklich so schwer, das "DASS" und das "DAS" richtig einzusetzen? das-dass.de/
    • Doch will sich mir irgendwie noch nicht so richtig der Nutzen erschließen.
      Der Nutzen?
      der ist sicher nicht vorhanden, solange man in der Ebene oder in "lieblichen Hügellandschaften" baut. In der Eifel oder auch auf meiner Almetalbahn ist der nächste Hügel nicht weit weg, der übernächste auch nicht, und der vierte ist meist nicht hoch genug, um (aus Zugperspektive) über den ersten hinaus zu ragen.

      Ganz anders in den Alpen. Wenn ich z.B. von Murnau über Farchant Richtung Garmisch-Partenkirchen fahre, sehe ich in der Realität die Alpspitze schon lange bevor ich Farchant erreiche. Im TS nicht, weil sie zu weit weg ist. Das Bild 2 oben zeigt ja, wie der Walensee ohne Distant Terrain aussieht: eher wie die "grauen Anfurten" als wie ein See der mitten in den Bergen liegt: die Berge um den Alvier fehlen. Das DEM-Gelände um den Alvier ist in der SBB-Route ja richtig vorhanden, es wird nur vom TS nicht angezeigt, weil der TS nicht nur für Szenerie-Objekte eine maximale Darstellungsentfernung hat, sondern auch für DEM-Gelände. Der Alvier ist von Mühlehorn ca. 18 km weit weg, DEM-Gelände wird über diese Entfernung vom TS nicht gerendert.

      Da kommt das Distant Terrain ins Spiel. Distant Terrain manipuliert weder Form noch Farbe des existierenden Geländes, sondern ist eine zusätzliche Kulisse, die sichtbar werden kann, wenn der echte Horizont weiter entfernt ist, als der TS das DEM-Gelände rendert.
      Was die eigentliche Form betrifft ist mir also noch nicht ganz bewusst, welchen Vorteil das gegenüber einem DEM-Import haben soll, außer dass etwaige Risse repariert werden, die ich aber auf noch keiner Route habe antreffen können.
      Von Vor- oder Nachteilen gegenüber DEM-Import kann man nicht reden, weil DEM in keiner Weise ersetzt wird, aber auch umgekehrt nicht das liefern kann, was Distant Terrain liefert. Die "Riss-Reparatur" oben war nur ein Nebeneffekt, weil ich das Distant Terrain im TS2014 neu generiert habe, wohingegen JAW das DistantTerrain möglicherweise nicht mehr nachgenerieren konnte, weil RSC diese Funktion irgendwann in (ich glaube) 2011 einfach mal stillschweigend entfernt hat (hierzu gibts Indizien auf railworks-america).
      Der gespaltene Berg auf der (simtrain)SBB-Route 1 liegt nur im Distant Terrain vor, das DEM-Gelände selbst ist ok, aber man kommt ja meist nicht nah genug ran, dass letzteres angezeigt wird. Dass es auch in normalem Gelände auf Kachelgrenzen beim Rendern schonmal schmale Spalte gibt, ist nochmal eine andere Sache.
      Macht es Unterschiede, ob man davor oder danach noch das gelände manipuliert, indem man z.B. am Gleisbett rumzupft? Werden Bodentexturen beeinflusst?
      Nein, weil es keinen Einfluss auf Gelände oder Texturen hat, sondern zusätzliches (low resolution) Gelände jenseits des TS-Horizonts für Standard-(DEM-)Gelände schafft.
      Wieviel DEM-gelände muss importiert werden, um gute Ergebnisse zu erzielen?
      Wenn Spalte im Berg sind, fehlt noch was ;)
      Und können überflüssige DEM-Kacheln anschließend gelöscht werden um Nachladeruckler zu vermindern?
      ja - ist natürlich Interpretationssache, der Spieler könnte ja von der Strecke wegfliegen und dann plötzlich den Boden unter den Füssen verlieren ;)

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von nobsi ()

    • Hey nobsi,
      erstmal danke für die super Erklärung :thumbup:
      Dann kann man sich das Distant Terrain also quasi als eine aus bereits bestehenden DEM-Kacheln generierte Fassade bezeichnen, ähnlich einer Fototapete die in großer Entfernung aufgestellt wird und nur den Anschein von Bergen erwecken soll? Ähnlich wie die Fototapete bei Modellbahnen?
      Ist das so vergleichbar?

      ich hatte immer gedacht, dass das Distant Terrain die Farbe/Texturen ferner DEM-berge beeinflussen würde. Daher war ich jetzt sehr vwerwirrt und verstand den Zusammenhang überhaupt nicht.
      Ist es denn wirklich so schwer, das "DASS" und das "DAS" richtig einzusetzen? das-dass.de/
    • Hallo Nobsi,
      ich möchte Dir recht herzlich danken. Ich muß zugeben, darauf wäre ich momentan nicht gekommen (ich hatte ja auch einmal meinen Kommentar zu dem Spalt in der SBB1 geschrieben, aber das war noch zu RW4-Zeiten).
      Das ist mit nur noch nicht klar:
      Kann es Nachteile haben, wenn man das Distant Terrain nach Terrainerweiterung nochmals erstellt ?
      In welchen Dateien wird das Distant Terrain gespeichert ?
      Kris
      Alte Rechtschreibung - na und ? Wenigstens richtig ! (außer ein paar spezial-120er-Worte ;) )
    • Prelli schrieb:

      Dann kann man sich das Distant Terrain also quasi als eine aus bereits bestehenden DEM-Kacheln generierte Fassade bezeichnen, ähnlich einer Fototapete .....
      genau das ist es. (edit: "Fototapete" ist irreführend, siehe unten, Beitrag 11)

      Das DEM-Gelände selbst (und dessen Texturen) wird nicht beeinflusst.
      Im Übergangsbereich zwischen der "normalen" Geländedarstellung des TS und der Anzeige des Distant Terrains kann es durch die Überblendung natürlich optisch eine Änderung geben (z.B. wenn man im Distant Terrain noch keine Wintertexturen erzeugt hat, aber ein Szenario im Winter fährt .. und das Gelände so ist, dass man quasi seitlich die Hügel/Berge über eine große Strecke sehen kann, und man auch entsprechende Fog-Einstellungen hat).

      Was mich noch etwas irritiert, ist, dass Kris sagte, die Funktion hätte ihm das Gelände überschrieben. Das kann ich mir bisher überhaupt nicht vorstellen - und ich hab schon einige Experimente mit meiner Almetalbahn, Berner Oberland, Werdenfelser Land und Gesäuse gemacht. Vielleicht betraf Kris' Beobachtung ja auch nur die Texturen in der Überblendungs-Entfernung.

      @thenilsman
      3CCR werd ich sicher demnächst auch mal in dieser Hinsicht testen. Aber seit meinem HD-Crash hab ich außer dem Steam/RSC Kram noch nicht sehr viel wieder installiert - dauert also noch.

      @120
      ich sehe da keine Nachteile. Das Distant Terrain wird ausschließlich in der <route-id>/terrain/DistantPatches.bin gespeichert (da stehen die Höhendaten als blobs drin) und die Texturen in <route-id>/terrain/textures - jeweils 8x8 "normale" Kacheln in einer Textur, Jahreszeiten mit den üblichen Endungen.

      Ich habe in meinem "Werdenfelser Land" (Murnau-Garmisch) mehrfach DEM im Bereich Alpspitze/Zugspitze nach importiert, weil im DT noch Schnitte sichtbar waren. Gelegentlich gab es Abstürze, vermutlich weil ich gleich an Ort und Stelle des Imports die DT-Funktion gestartet habe. Nachdem ich in diesen Fällen den Editor neu am Route Origin gestartet habe, ging die Generierung aber sauber durch.

      Wenn man Distant Terrain wiederholt erstellt, wird einfach (sobald man mit F2 abspeichert) die existierende DistantPatches.bin überschrieben, und die Texturen entsprechend der aktuellen Jahreszeit im Welteditor neu generiert. In der DistantPatches.bin steht das komplette Höhenmodell der gesamten Strecke - in gegenüber dem DEM-Terrain stark reduzierter Auflösung. Zur Laufzeit wird das dann als Kulisse "hinter" dem normalen Gelände gerendert (falls der Fog aus den ToD Dateien entsprechende Sichtweite zulässt).


      Wie immer beim Bau ist es von Vorteil, im Fenstermodus zu arbeiten - da sieht man besser was gerade läuft.

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von nobsi ()

    • Verstehe...
      Wie muss man das mit den Texturen verstehen? Muss man diesen Vorgang für jede Jahreszeit einzeln vornehmen?

      Und woher weiß der TS, dass es sich um ein entferntes ("distant") Terrain handelt? Denn nur weil es an dieser Stelle entfernt ist, muss es ja nicht generell entfernt sein, wenn die Strecke dort zufällig entlang geht. Kann man das irgendwie durch den derzeit eingestellten kamerawinkel oder die momentane Position im Editor beeinflussen, oder wie muss man sich das vorstellen?
      Oder anders gefragt: Muss man diesen Vorgang an mehreren Stellen der Strecke wiederholen oder wird für die Gesamtstrecke eine solche "Fototapete" erstellt?

      Also so ganz werde ich noch nicht ganz schlau und das Quadrat rechts oben irritiert mich mehr, als dass es mir nützliche Infos gibt.
      Ist es denn wirklich so schwer, das "DASS" und das "DAS" richtig einzusetzen? das-dass.de/
      Werbung
    • Texturen:
      die DT-Funktion guckt sich quasi das Gelände was gerade im World Editor zu sehen ist aus großer Höhe an. Wenn man in Standard-Jahreszeit editiert, wird automatisch ne Standard-Textur erstellt. Wenn man z.B. ein Szenario im Winter startet, daraus den Welt-Editor aufruft, und da dann die DT-Funktion werden die Texturen so wie Gelände gerade aussieht erzeugt, und automatisch mit _Wi Postfix gespeichert (im Anhang Beispiel direkt aus dem textures Verzeichnis der SBB-Route nach meiner Neugenerierung - einmal Standard, einmal im Winter - konvertiert nach jpg, tatsächlich generiert wird dds und tgpcdx)

      woher weiß ...

      Das gesamte Terrain liegt mehrfach "übereinander" vor.
      Einmal ein "normales" Gelände in voller Auflösung:
      - die DEM Kacheln in <routeid>/terrain/+xxxxxx+yyyyyy.bin
      - und die zugehörigen Texturen in der Mixmap

      Zum zweiten das low resolution Distant Terrain (die Vorstellung einer topografischen Landkarte niedriger Auflösung ist hier wohl besser als die einer Fototapete):
      - Höhenwerte des Geländes zusammengefasst in einer einzigen Datei <routeid>/terrain/DistantPatches.bin
      - Texturen in den Textur-Kacheln in <routeid>/terrain/textures - jeweil 8x8 "normale" Kacheln in einer Texturkachel zusammengefasst. (Wenn man das textures Verzeichnis mal mit 'nem Viewer betrachtet, der dds anzeigen kann (z.B.xnview), hat man die Landkarte schon vor der Nase.)

      Zur Laufzeit zeigt der TS immer abhängig von der aktuellen Kamera-Position an
      - Szenerie nur die ersten 1 oder 2 km
      - DEM .. hmm .. irgendwas um 8 oder 10 km, weiß ich nicht genau
      - danach nur noch Distant Terrain

      also auf jeden Fall: DT muss nur einmal erzeugt werden - es wird das komplette Streckengelände abgebildet.
      das aber evtl mehrfach für verschiedene Jahresszeiten,
      und es kann beliebig oft wiederholt werden, wenn man mehr DEM importiert oder größere Gelände-Texturierungen macht (aber DT wird ja nur in großen Entfernungen angezeigt, daher wäre es unsinnig bei kleineren Texturierungen neu zu generieren)


      p.s.:
      das Thema ist durchaus nicht nur in den Alpen von Bedeutung.
      z.B. gibts auch im Rheintal Abschnitte wo man so weit geradeaus sehen kann, dass man im TS an die Sichtbarkeitsgrenze des normalen Geländes kommt (z.B. Remagen Richtung Andernach)
      Bilder
      • tile_32_-16.jpg

        15,36 kB, 256×256, 369 mal angesehen
      • tile_32_-16_Wi.jpg

        15,23 kB, 256×256, 264 mal angesehen

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von nobsi ()

    • Ok
      Das bedeutet also, dass dieser Vorgang nur 1x je jahreszeit gemacht werden muss, solange man kein neues DEM-gelände hinzufügt.
      Ist das so korrekt?

      Das würde weiterhin bedeuten, dass man zu diesem Zweck einen sehr großzügigen DEM-Import machen sollte von 10km oder besser mehr rechts/links vom Gleis, damit die DT-Funktion brauchbare Ergebnisse liefern kann, SOFERN in der Ferne überhaupt Bergketten und Hügel zu erwarten sind.
      Anschließend kann man die DEM-Kacheln wieder löschen, die man nicht benötigt, also die, die weiter weg als etwa 5 km sind.

      Hab ich das so korrekt verstanden?
      Ist es denn wirklich so schwer, das "DASS" und das "DAS" richtig einzusetzen? das-dass.de/
    • ja, korrekt.
      Bei den Jahreszeiten sollte man bedenken, dass DT ja nur in großer Entfernung angezeigt wird. Frühlung- und Herbst-Variante werden sich da vermutlich nur selten sichtbar von der Sommer-Variante unterscheiden.
      Ergänzung: die Überblendung auf die DT-Texturen erfolgt teilweise viel früher (näher), als ich ursprünglich gesehen habe. Das scheint von den Fog-Entfernungswerten der Strecke abzuhängen (was ja auch sehr sinnvoll ist).

      Ich muss noch mal auf die Vorstellung einer "Fototapete" zurückkommen - rückblickend erscheint mir das eher irreführend, auch wenn es den optischen Eindruck beschreibt. DT ist ja keine feststehende, vertikale Kulisse wie z.B. die Wald- und Hauszeilen-Lofts, die oft zur Begrenzung der Sichtweite verwendet werden ("Schlauchlevel", z.B. auf Köln-Düsseldorf), sondern eine Möglichkeit zur Erweiterung der Sichtweite. Eine komplette, deckungsgleiche Kopie des Geländes, in stark reduzierter Auflösung, für die Anzeige in großer Entfernung. Also eine Mipmap / LoD-Variante für Gelände.

      Dieses zusätzliche Gelände kostet natürlich Performance, aber bei weitem nicht soviel, wie es kosten würde, wenn der TS einfach die maximale Render-Distanz für das Standard-Gelände auf 25 oder mehr Kilometer erhöhen würde.

      Man kann DT versuchsweise erzeugen, und wenn man feststellt, dass es auf der Strecke nichts wesentliches bringt, einfach die DistantPatches.bin (und, der Ordnung halber, auch die erzeugten Texturen) wieder löschen, und damit ist auch die Performance wieder wie vorher. Das könnte auch jeder Benutzer individuell machen, da es keine weiteren Abhängigkeiten zur Strecke gibt.

      -----

      hab mal eben DT für die 3CCR generiert (Dauer ca. 5 Minuten für einen Durchlauf).
      Blick von Lindau (Start im Szenario "Von Hafen zu Hafen") grob Richtung Süden
      Bild 1: original
      Bild 2: mit DT
      na, wen das nicht überzeugt ... :D

      man erkennt auch schon, wo man noch etwas DEM importieren müsste (etwas rechts von der Bildmitte Bild 2)
      Bilder
      • 3CCR-1.jpg

        51,62 kB, 800×450, 399 mal angesehen
      • 3CCR-2.jpg

        51,09 kB, 800×450, 397 mal angesehen

      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von nobsi ()

    • Hallo Nobsi,
      Ich rückblickend kann ich nicht mehr sagen, ob bei mir wirklich etwas überschrieben wurde. Nach Deinen Ausführungen hier vermutlich nicht.
      Als ich das Tool anwendete zeigten sich die Berge mehr oder weniger halb durchsichtig, was vermutlich erstmal die Folie war, die generiert wurde. Darüber war ich so erschrocken, daß ich sofort wieder alles rückgängig machte. Damit darfst Du meine damalige Aussage getrost vergessen.
      Einen weiteren Versuch werde ich demnächst machen und berichten.
      Kris
      Alte Rechtschreibung - na und ? Wenigstens richtig ! (außer ein paar spezial-120er-Worte ;) )
    • thenilsman schrieb:

      Hm, bei mir ist er mit nem Vertex Error ausgestiegen, könntest du viel leicht die DT Daten hochladen/mir schicken?
      Vielleicht warst du nicht am Route Origin. Wenn du in der aktuellen 3CCR Version gleich den Welt-Editor startest, stehst du nicht am Origin, sondern in Rorschach.
      Am sichersten ist: neues Freeroam-Szenario (z.B. "DT Generierung Sommer") erstellen, dabei Route Origin als Startposition wählen, im Szenario-Editor sofort speichern. (Für Wintergenerierung vor dem Speichern nur noch die Jahreszeit ändern). Dann kannst du jederzeit das Generierungsszenario starten, da dann sofort in den Welteditor und generieren.

      Ich hab als Demo mal Distant Terrain mit Sommer und Wintertexturen für die 3CCR angehängt. Das Paket überschreibt keinerlei Dateien der 3CCR, kann also problemlos wieder deinstalliert werden.
      --> sorry, Anhang enthält nur Sommertexturen, sonst wärs zu groß geworden.

      120 schrieb:

      Als ich das Tool anwendete zeigten sich die Berge mehr oder weniger halb durchsichtig, was vermutlich erstmal die Folie war, die generiert wurde.
      Gut möglich, während der Generierung wechselt der Boden vor einem gelegentlich die Farbe :)

      ---

      Bei der Generierung von Frühlingstexturen für das DistantTerrain der 3CCR gabs ein Problem:
      - Bild 1: Ansicht des Preview-Fensters während der Generierung
      - Bild 2: so siehts dann ingame aus.
      Ursache:
      In der Strecke wurden in der Bauzeit Texturen verwendet, die aktuell nicht mehr vorhanden sind. Das stört normalerweise nicht, weil die Texturen beim Bau der Strecke aus dem verwendeten Texturset (in diesem Fall Kuju) in die Strecke kopiert werden (in den Mixmap-Ordner). Bei der Generierung des DT greift der TS aber wieder auf den ursprünglichen Texturset zu, und da fehlen seit irgendeinem TS-Update ein paar Texturen; Hinweise dazu auch in railworksamerica.com/forum/viewtopic.php?f=34&t=9583
      Hier müsste man also erst mal das Kuju-Texturset flicken, bevor man DT mit sauberen Frühlingstexturen für die 3CCR erstellen kann.

      edit:
      Die genaue Fehlerursache ist unklar. Da in Wiederholungsversuchen auf der selben Strecke ohne Texturänderungen einige DT-Läufe komplett fehlerfrei waren, andere aber diesen Fehler hatten, kann es eigentlich nicht am Texturset der Strecke liegen. Mögliche Ursachen:
      - Reste von alten DT-Läufen im Terrain-Ordner
      - geringfügige Abweichungen vom Route-Origin beim DT-Lauf.
      - ???
      Bilder
      • missing-1.jpg

        16,75 kB, 324×285, 311 mal angesehen
      • missing-2.jpg

        32,3 kB, 1.014×466, 311 mal angesehen
      Dateien

      Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von nobsi ()

    • Danke mal für die interessanten Ausführungen hier die mich als Landschaftsbauer natürlich brennen interessieren und in die Alpen komm ich sicher auch noch. Ja die Performance Frage würde mich schon leider auch interessieren, die Sichtweiten lassen sich ja in den Einstellungen runtersetzten, die Frage wäre also ob man hier sogar etwas reduzieren könnte und schon "früher" DT einschalten kann um so umgekehrt sogar Performance zu sparen (ist halt dann die Frage wie das aussieht - aber sicher alle male besser 3 km hochdetailliert zu haben und dahinter zumindest ein "Kulisse" eine Lod-Stufe für das Gelände und das ev. performanceschonender also 7 km hochdetailliert und keine weitere DT. Auch wenn es alphanumerisch keinen großen Unterschied größenmäig machen sollte (die Rastergröße bleibt ja gleich) bin ich auch immer interessiert SRTM und ASTER zu vergleichen (aber gegenüber Rollmaterial ist der Performanceverlust des Geländers eher klein) und auch zu "mischen" denn ich kann in kleinen "Kacheln" etwa 3x3 ja streckennah oder für besonders schöne Felspartien/Strukturen besser ASTER verwenden (mir graut es ehrlich gesagt etwa für die Moselstrecke schon vor SRTM, das sieht dann aus wie MSTS Gelände). Das was man Mehraufwand für das Planieren und Korrigieren mit ASTER2 Daten hat das bekommt man einfach durch besser Qualität gerade im Nahbereich von 1 km zu spüren. Darüber hionaus würde SRTM vollkommen reichen und eben ab 3-4 km so ein entschlacktes DT.
      Werbung
    • Ich möchte gerne hier nochmal was nachfragen...

      Wie siehtn das aus, wenn man nachträglich Gelände verändert?
      Beißt sich dass dann nicht mit dem vormals generierten -ich nenne es mal- Fassaden-Gelände?
      Wenn ich nun das Distant Terrain erstelle, aber dann feststelle, dass ich 390 Meter tiefe Krater im Bodensee habe, die Darstellungsfehler verursachen könnten, und diese repariere, müsste ich dann nicht den ganzen Generierungsvorgang wiederholen?
      Was passiert, wenn ich in Gleisnähe das gelände zurechtzupfe?

      Oder kurz: Wann wäre der beste Zeitpunkt, das Distant Terrain zu generieren? Wenn man die Strecke fertig hat als letzter Job vor dem Veröffentlichen?

      Und:
      In welchem Abstand zum Gleis wäre es ratsam, die "echten" Terrain-Kacheln wieder zu löschen, um Performance/Ladezeiten zu sparen?
      Hintergrund ist der, dass ich bei meiner SWB einen ca. 20 km breiten Terrainstreifen entlang der Strecke aus DEM importiert habe, damit man auch fernere Berge sehen kann. Vermutlich muss ich auf 30 km oder sogar noch breiter werden.
      Wieviel Breite rechts und links von der Strecke wäre zu empfehlen, was man als echtes Terrain stehen lassen sollte und was nicht?

      Fragen über Fragen... aber es wär schon cool, wenn man die derzeit 3900 Dateien (=km²) an Geländekacheln irgendwie eindampfen könnte, denn man kann schon merken, dass der Kram nachgeladen und vor allem aufgebaut werden muss. Wäre schon toll, wenn man das beschleunigen könnte, ohne Abstriche bei fernen Gebrirgsketten in Kauf nehmen zu müssen.
      Ist es denn wirklich so schwer, das "DASS" und das "DAS" richtig einzusetzen? das-dass.de/
    • zunächst:
      der TS zeigt das "richtige" DEM Gelände bis zu einer
      Entfernung von etwa 11 km an (d.h. in dieser Entfernung poppen die Berge
      auf). Alles was weiter von der aktuellen Position weg ist, bekommt man
      nicht zu sehen - bzw. bekommt man nur zu sehen, wenn man es in DistantTerrain gießt.

      DEM
      Gelände, das weiter als 10 km von den Gleisen weg ist, kann man also
      sicherlich löschen, vermutlich kann man da auch bis 5 km runter gehen.
      Das muss man aber sicher im Einzelfall klären, hängt ja auch davon ab,
      in welchem Winkel man auf die Bergflanken guckt, und ob das Gelände eher
      schroff oder sanft gerundet ist.

      Da das DistantTerrain nicht zur
      Anzeige vor der Nase benutzt wird, hat "rumzupfen" am Gelände keine
      wahrnehmbaren Auswirkungen, in Gleisnähe schon gar nicht - wobei man
      sicher Fälle konstruieren kann, in denen man einen Unterschied sieht
      (ich denke da an steile Felswände einseitig außen direkt neben einem
      Gleis mit großem Krümmungsradius, ohne irgendwelche Büsche oder Bäume,
      die die Sicht behindern) .

      Für optimale Ergebnisse sollte das
      Gelände aber texturiert sein, wenn man das DT erzeugt. DT macht ja kein
      "Foto" der ausgestalteten Strecke, sondern basiert nur auf dem nackten,
      texturierten DEM-Gelände. Wenn man einen Hügel bewaldet, aber den Boden
      unter den Bäumen nicht texturiert, sieht der Hügel aus der Entfernung
      eben nach hellgrüner Wiese statt dunkelgrünem Wald aus. Deshalb
      erweitere ich grade meine Textursets um solche "Untergrundtexturen"
      (Wald, Wasser, Wohn- und Industriebebauung .. ) . Stichwort Wasser:
      Wasserfolien sind keine Texturen ;) - der Bodensee in der 3CCR sieht im
      DistantTerrain wie grüne Wiese aus, weil der Boden unter der Folie
      untexturiert ist. Die Seen auf der Albula-Strecke sehen auch im DT nach
      See aus, weil sie eine Bodentextur haben.

      Der Zeitpunkt der DT-Generierung ist eigentlich total unabhängig vom eigentlichen Streckenbau. Es geht auch komplett unabhängig:
      - neue Strecke mit selbem Origin wie die richtige Strecke anlegen
      - DEM importieren (großräumig)
      - Gelände texturieren (z.B. mit dem Google-Overlay als Orientierung)
      - DT erzeugen
      - der "richtigen" Strecke die DT-Datei und die DT-Texturen unterschieben

      (hab ich kürzlich testweise mit Teilen der SBB-Route so gemacht)
    • Ich hab eben auch mal paar Tests gemacht und habe herausgefunden, dass das Distant-Terrain bis maximal 50 km Entfernung angezeigt wird, egal ob man dahinter noch was berechnet hat oder nicht.
      Das konnte ich durch ein 50km langes gerades Gleis feststellen.
      Für meine Schwarzwaldbahn bedeutet das, dass man von Konstanz aus nicht die Alpen sehen kann. Das ist im TS nicht möglich.
      Von Offenburg aus könnte es aber sein, dass man einen kleinen Teil der französischen Vogesen (ist das richtig? Erdkunde ist lange her) auf der anderen Rheintalseite sehen kann.
      Ich werde also einiges an Gelände importieren müssen *stöhn*

      Beim Distant-Terrain-Berechnen bekam ich einen DirectX3D-Error auf dem Windows-Desktop bei vom TS geöffneter CMD-DosBox. Scheinbar hatte dieser Fehler aber keinen Einfluss auf das Ergebnis. Das testgebirge wurde jede nfalls ordnungsgemäß dargestellt, obwohl ich nach der Berechnung alle Terrain-Kacheln löschte.

      Alles in allem finde ich dieses neue Feature jedenfalls sehr gut, weil es Performance spart, weil ja weniger Terrain-Kacheln in der Ferne aufgebaut werden müssen, bei gleichzeitig erheblich gesteigerter Sichtweite. Mir ist grad nicht bekannt, wie weit das normale Terrain dargestellt wird, aber ich denke, bei allerallerhöchstens 10 km ist "Ende Gelände" (Nomen est Omen), die effektive Sichtweite des Geländes hat sich also verfünffacht, was wirklich eine enorme Verbesserung darstellt bei weniger Performanceverbrauch und Plattenplatz.

      Mit ist noch nicht ganz klar, ob es notwendig ist, die Berge in >20 km Entfernung mit Bodentexturen zu bepinseln. So wie ich nobsi verstand, werden diese in die Berechnung des DT ja einbezogen, so dass man damit auch eine Schneegrenze und Wälder simulieren könnte.
      Aber ab einer gewissen Entfernung ist das vermutlich Nonsens, weil es im atmosphärischen Azurblau in der Realität wahrscheinlich untergehen würde, so dass eine Simulation dessen im TS unnötig wäre. Weitere Experimente tun Not...
      Ist es denn wirklich so schwer, das "DASS" und das "DAS" richtig einzusetzen? das-dass.de/