Beiträge von Maik Goltz

Das war aber mal so. Ich arbeite nur mit dem BPE, der erzeugt eh immer beide. Daher kann mir das egal sein

Du musst das in der proxyxml und proxybin Datei ändern. Beide müssen den gleichen Inhalt haben. Also nach der Änderung die proxyxml nochmal über die Serz.exe ziehen, damit die proxybin erzeugt wird. Dann klappt das auch mit .wav. Es gibt aber auch Gründe, warum der BPE kein .wav erzeugt sondern .dav, aber darüber lass ich mich hier nicht aus, denn das glaubt sowieso keiner.

Als Derjenige, der den Mist verzapft hat, möchte ich hier Norweger mal in Schutz nehmen. Er weis sehr genau wie man eine Lok fährt und vor allem wie sie zu funktionieren hat, glaub mir Die 101 und die 189 haben halt noch immer das leidige Problem im Script, dass die Regelung pausiert, wenn der Abstand zwischen ZIst und ZSoll < 5 ist. Dann wartet die Regelung auf mehr Abstand. Das wurde "erfunden" um ein Pendeln zwischen Bremse und Leistung zu verhindern und passiert vornehmlich bei sehr leichten Zügen und Fahrschalter auf Anschlag. Da hatte sich ein kleiner Logikfehler eingeschlichen, bei der Ansteuerung der E-Bremse, der in nachfolgenden Baureihen ja beseitig wurde. Ein Update gab es aus logistischen Gründen leider nie. Die meisten haben davon halt auch nichts gemerkt. Nach etwa 30 Sekunden löst sich das eh auf und die Bremse fängt an zu wirken.

Die Praxis wird zeigen, dass das neu platzieren des Lineals länger dauert als das Maßband anzupacken. Keine Vorsignalbake steht auf den mm genau. Grob und schnell abmessen, hinstellen, gut. Das gibt auch bissel Dynamic da rein und ist nicht so steril akkurat.

Zitat von hansdampff

mit fettem Rollmaterial kann ich aber trotzdem einfachste und sparsamste Strecken zum Absturz bringen

Ja natürlich, aber das liegt nicht am Polycount. Das wollte ich damit sagen.

EDIT: hier mal zum bestaunen. Simpler Test mit Assetblock. ~167Mio Dreiecke und keine Auswirkungen auf die FPS am Ende.

Das Lineal hat mir Kevin damals gebaut weil ich dachte, dass es damit schneller geht. Aber ich hab es am Ende nicht benutzt. Es geht viel schneller mit dem Maßband die Abstände zu ermitteln.

Zitat von tcb262

Ist deren Anzahl (Count) zu hoch, kannst Du aus dem TS eine Dia-Show von Bremen nach Münster machen

Eigentlich nicht. Polygone, bzw. richtiger betitelt Dreiecke (Primitives) in einer GameEngine, sind nicht wirklich relevant bei moderner Hardware. Eine typische großer Bahnhof-Scene im TS hat in der Sichbarkeit einen PrimitivesCount von vll. 5-8Mio Dreiecke und dabei oft einen Vertex-Count von Dreiecke*0,8. Das ist nichts für die Grafikkarten der letzen 5 Jahre. Die können locker 200Mrd. Dreiecke aufn dem Schirm zaubern. Entscheidend ist, wie die Objekte, die ja aus den Dreiecken bestehen, gebaut wurden. Da gibt es dann eben deutliche Unterschiede. Die Anzahl Objekte mit eigenem Material (Textur+Eigenschaften) ist entscheidend. Ein Objekt erzeugt mindestens 1 Drawcall, mit Textur zwei. Dabei spielt die Größe des Objektes keine Rolle soweit. Je größer desto mehr Speicher wird gebraucht, aber nicht proportional mehr Performance. Drawcalls werden von der CPU angehandelt. Das sind quasi Anweisungen des Programms (TS) an die Grafikkarte etwas bestimmtes zu tun (Shader-Instruction zB.). Die CPU limitiert also hier. Denn ab etwa 5000 Draws per Frame wird es langsam eng. Da zählt dann pure SingleCore Leistung. Deswegen ist der TS1 auch so CPU abhängig. Draws einzusparen ist schwer und mit extrem viel Aufwand verbunden. Und leider im TS1 so kaum zu stemmen weil entsprechende Performance Tools fehlen. Aber selbst wenn der ICE da jetzt 1Mio Polys per Wagon haben sollte, spielt das keine Rolle. Hat aber jeder Wagen 200 Texturen drauf, dann hast du bei 12 Wagen 4800 Drawcalls nur für den Zug. Im TS sind die Züge eigentlich stets das kleinste Problem deswegen. Keiner hat meines Wissens 200 Texturen drauf. Maximal vll. 30. Das ist vernachlässigbar. Entscheidend ist eben hier die Masse an Objekten gesamt in der sichtbaren Scene. Hier kommen dann LODs ins spiel, die die Objekte reduzieren wenn sie weiter weg sind. Aber das spart nicht direkt Drawcalls, wenn nur das Mesh reduziert wurde. Ein LOD sollte im Zweifel Objekte zusammenfassen und dadurch Material-Draws sparen. Sonst hilft auch das nicht wirklich. Ich denke das ist einer der größten Fehler bei den Objekten im TS und für dessen teils miese Performance zuständig. Nur gibt es halt eben keine helfenden, bezahlbaren Toolsets um das effizient zu bewerkstelligen. LODs mit reduzierenden Eigenschaften zu erzeugen ist ne mühselige Aufgabe. Der TS hat durchaus moderne Funktionen integriert um dynamisch zu reduzieren. So werden kleine Objekte, wie zb. Isolatoren der OL, dynamisch zusammengefasst, wenn diese nach beieinander platziert sind. Aber diese Funktionen sind unausgereift und greifen kaum ein.

Was will der Goltz damit nun sagen? Ganz einfach: Polycount ist egal, Bauweise ist entscheidend.

Immer noch kaputt. Gleisanlage wurde im TS2017/2018 gebaut. Kann man wegschmeißen...

Zitat von Hans Dampf

Gerade DTG gehen unsere Probleme doch am Arsch vorbei. Hauptsache weitere Addons entwickeln, anstatt das Game zu Optimieren. Gerade Leute mit Farbenblindheit habens in Spielen oft nicht leicht, obwohl es heute möglich ist diesen zu helfen. Siehe Bad Company 2, League of Legens usw. Einen Modus für Farbenblinde zu impletieren ist heute keine große Sache mehr.

Ganz sicher nicht, nur ist das kein Team von 2000 Mann wie vll. bei deinen genannten AAA Games. AddOns sichern nun mal die Zukunft des TSW. Ohne diese gäbe es keinen TSW. Von nüscht kommt halt auch nüscht.

Und die Implementation von Bedienhilfen (Barrierefreiheit) ist alles andere als trivial. Allein die Unmengen an Farbschwächen die es gibt, die kann man nicht mal eben so abbilden/abhandeln. Sowas kann sich eine Firma wie DTG gar nicht leisten und andere Entwickler für den TSW schon gar nicht. Klar könnte man die Sichtbarkeit der Signale etwas optimieren, aber nicht barrierefrei gestalten. Der Modus für Farbenblinde wäre dann statt Farben mit Ziffern zu arbeiten Statt gelb-gelb zu sehen als Farbe, stünde dann "gelb-gelb" als Text drauf Auch ne Lösung, ehrlich gesagt.

Zitat von Nickhawk

also ganz ehrlich ich habe foliage.LODDistanceScale auf 4 und r.SkeletalLODBias auf -2 stehen und ich spiele in 3440x1440 mit 60fps. Also ich merk da nichts von "erheblichen performanceeinbrüchen."

Richtig, wir mit unseren dicken Grafikschleudern merken davon (erst mal) nichts. Ich hab mal mit Stat geprüft was da passiert. Und ja, da passiert gewaltig was. Nur 2 Züge mit 146 und 5 Dostos fluppen von ~2Mio SkelMeshTris auf über 8Mio SkelMeshTris. Die Draws steigen nur minimal, was klar ist, da sich die Materialien nicht ändern. Jetzt stell dir das mal mit 10 Zügen vor. Dann bricht auch bei unseren Karten alles zusammen. 20-40Mio Tris is ok, darüber wirds happig und zäh. Da wir nicht nur Züge rumstehen haben, sondern auch viele Personen rumlaufen, die auch Skeletons sind und nicht grad Polygon arm daherwandern, ist da ganz schnell Ende im Gelände.

Das sind halt keine modularen Implementationen. Ich glaube die ZZA auf MSB gibt es nur, weil der Deutsche halt sonst wieder zu viel gemosert hätte. So hat er seine ZZA und gut. Fastfood quasi, damit es stille hält bis der Hauptgang kommt. Dass es die für alle Strecken nun gibt, die da schon erhältlich sind, stand nie irgendwo. Matt sagte mal, dass man sich ein bestimmtes PIS (FIS) vorstellt und es noch nicht an der Zeit ist, dieses umzusetzen, da es wichtigere Dinge gibt. Die jetzige ZZA ist ne simple, in das Fahrzeug fest integrierte Funktion, wie im alten TS. Unflexibel, nicht erweiterbar, hinderlich. Würde ich auch nicht in andere Fahrzeuge bauen wollen Da gibt es bessere Methoden, die aber erst entwickelt werden wollen.

Zitat von Hans Dampf

ach .... 2 Kommentare darüber sagt Du noch "ja aber Vorsicht mit den Werten" und nun stellst Du mich als Deppen hin ?

Hab ja nicht gesagt, dass die Werte für den gesuchten Effekt richtig wären. Hab nur gesagt, dass diese Werte mit Vorsicht angewendet werden sollten, da sie sich auf alles auswirken. Hat ein bissel was davon als wenn man, statt mit der Fliegenklatsche das kleine surrende Ungetier zu entfernen, einfach Giftgas in die ganze Hütte bläst. So unter dem Motto: "Scheiss drauf was noch alles drauf geht, die Fliege wird es schon erwischen". Das gleiche gilt für r.AllowStaticLighting. Das schaltet halt mal eben alle statischen Lichter ab, was absoluter Nonsens ist. Genauso wie r.SkeletalLODBias auf -2 zu stellen, was alle LODs der Objekte mit Skeleton-Meshes (Loks, Wagen, Personen, Autos) die LOD Fähigkeiten quasi wegnimmt und natürlich zu massiven Performanceproblemen führen muss. LOD ist ja nicht zum Spass da. Gilt auch für foliage.LODDistanceScale auf 3. Verschiebt alle LOD0->LOD1 Umschaltentfernungen um Faktor 3 nach hinten und sorgt ebefalls für erhebliche Performanceeinbrüche, wenn man nicht grad die fetteste Grafikkarte im Rechner hat. ViewDistanceScale hat ähnliche Effekte, aber nur auf Objekte die überhaupt eine solche Einstellung haben, was wenige sein dürften im TSW.

Bitte echt nochmal jeden einzelnen Parameter nachgoogeln und versuchen zu verstehen, was er eigentlich wirklich tut. Diese wilden Einstellungen führen nur dazu, dass irgendwann alles schlecht läuft. Die Optimierungen in diesem Spiel haben wirklich nicht auf User-Seite stattzufinden, sondern beim Entwickler.

Zitat von Hans Dampf

zum Glowing hab ich folgendes gefunden ...

Das hat ja mal nun überhaupt nichts damit zu tun. Das ist was ich meine. Die Leute lesen sich irgendwas zusammen und verstehen aber gar nicht, was es wirklich tut. Soweit ich das jetzt sehen konnte, wird das Glow über Emissive mit ScalarParam gesteuert. Da können wir gar nichts dran ändern. Das ist quasi programmiert.

Ja und bitte Vorsicht mit den Werten, denn die wirken sich auf alle Materialien aus und nicht nur auf Signale. Einzige Möglichkeit zur Zeit ist, die Texturen zu suchen und zu bearbeiten. Eventuell wird das Glowing über einen Kanal gesteuert und ließe sich so ausschalten. Auch kann man dann die Farben noch etwas mehr differenzieren. Das Glow allein wegzumachen reicht aber glaube ich aus. Mich stört das auch, weil ich kaum erkennen kann ob das nun Gelb oder Grün sein soll. Es ist einfach nur total überstrahlt bis etwa 10m vor dem Signal, dann erkennt man es einwandfrei.

Zitat von Smokey

Könnten wir vielleicht nochmal auf meine Frage zurück kommen ob es möglich ist Tesslation und eine weite Grasdistanz gleichzeitig zu nutzen ?

Nein, nicht wirklich. Da mit dem Parameter der Faktor auf das Weight-Blending gesetzt wird. Da die "dynamische Flora" bisher mit einem weighted Layer-Blend gemacht wird und POM (nicht Tesselation) auch da mit dran hängt, kannst du das nicht separat regeln. Der Effekt, dass die Flora bei niedrigen Material-Qualitäts Werten weiter zu sehen ist, ist schlicht ein unschöner Nebeneffekt. Man nimmt der Bodentextur, die mit einem Layer-Blend aufgetragen wird, die Gewichtung und das reduziert ebenfalls den Einfluss auf die Flora. Null Einfluss = dynamische Flora bis zur Rendergrenze (DistanceViewMax * DistanceViewScale + 1), da das Weighting fehlt. Muss man jetzt nicht direkt verstehen, aber es ist defintiv kein gewollter Effekt und wird hoffentlich bald auch anders gemacht. Diese Proccedural-Flora Funktion in den Materialien ist nämlich bescheiden und maximal für Open-World ARPGs geeignet. Hier gehört schon etwas mehr Hand angelegt als nur einfach per Bodentextur-Layer definierte Flora automatisch hinpinseln zu lassen. Und nur diese Flora wird überhaupt von dem Parameter (negativ) beeinflusst.

Ich hab schon viel gelesen über die ganzen ini-Einstellungsorgien im TSW und kann einfach nur den Kopp schütteln. Wenn überhaupt, verstehen gerade mal 1% überhaupt was sie da genau tun. Deswegen auch meine Befürchtungen dass das alles später nach hinten los geht. Das ist kein zerreißen, sondern auf Fakten und Wissen basierte Schlussfolgerung. Mit den propagierten Einstellungen reicht nicht mal eine Titan RTX aus, um korrekt erstellte Landschaften zu stemmen. Ihr wollte mehr Qualität, aber mit dem Gefummel verhindert ihr es am Ende. Das ist keine Schwarzmalerei. Ich zB muss eben dann abwegen zwischen Spielbarkeit für alle ohne die Einstellungen zu ändern oder dem Gemoser dass es nicht läuft weil die Einstellungen nicht auf Standard stehen. Da nehm ich lieber ersteres und spare mir die immense Arbeit der Optimierung der Sichtweiten etc..

Zitat von ice

Trotz alledem , Wer sein INI File ändern kann ..der kann das auch sicher wieder im umgekehrten Modus abändern.

Und genau da liegt aber mein Problem. Das Spielchen hatten wir doch schon bei der Moselstrecke. Die Leute weigerten sich vehement die Einstellungen an die Strecke anzupassen. Das wird dann wieder passieren. Die Leute werden sich weigern von ihren eigenen ini-Einstellungen abzuweichen. Und dann kommt es eben zu den Problemen. Darauf will ich hinaus. Wenn ich in einer Strecke die Sichtbarkeiten anders umsetze, und dabei Methoden für die Performance-Optimierung ansetze, dann ist es fatal, wenn da wer in der ini-Datei einen Skalierungsfaktor wild hochdreht. Da wird dann aus 1km gleich mal 10km Sichtweite oder LOD-Umschaltpunkt. Wer wird dann dran schuld sein? Natürlich die Strecke, wie immer. Deswegen sehe ich das hier alles sehr kritisch. Aber mir bleibt zumindest immer noch das festnageln der Werte, so dass der User sie nicht per ini ändern kann. Die Hierarchie lautet ja wie folgt: Default-ini-Setting -> Scalability-Setting -> User-ini-Setting -> Console-Command-Settings. Prio steigt von links nach rechts. Wende ich letzteres beim Start an, dann kann man in den Ini Datein rummachen wie man will, da passiert nichts.

Zitat von ice

Für alle die keine Ahnung haben gibt es doch die wie in jeden Spiel voreingestellte Parameter..für Low, Medium und High.
Damit stellt sich dementsprechend auch wieder die Ini Datei ein. Da sind dann für das unwissende Klientel die z.B. LODS & Konsorten Parameter wieder werkseitig neu eingestellt.

Nein, eben nicht. Schau dir das bitte nochmal an. Du hast doch sonst so viel Ahnung von der Materie. Da solltest du das eigentlich wissen und unterscheiden können.

Zitat von ice

In anderen Spielen sind die UE4 Grafik und Spiel Einstellungsmöglichkeiten wesentlich mehr vorhanden als im TSW. Und die Einstellungen anderer Spiele greifen auch nach Justierung in die Ini Dateien ein.

Ja, das ist so, aber all diese Einstellungen aus dem in-Game-Menü sind auch wohl selektiert und ranged. Es macht schlicht keinen Sinn wild an LOD oder MaterialQuality rumzuspielen, ohne die Basis zu kennen, auf die diese "Offset-Parameter" aufsummiert werden. DTG nutzt standard LOD und Foliage Einstellungen, deswegen funktioniert das mit den ini-Dateien einigermaßen gut. Ich würde aber zB eben nicht diese Standards nutzen, da diese zu schlecht sind. Ich wähle also eigenen LOD Einstellungen für meine Strecken und dann geht es schief, wenn in der ini ein LOD Skalierungsfaktor von 10 und mehr drin steht. Das würde die geschaffene Struktur zum schonen der Performance zerstören und schon wäre in den Augen der User die Strecke "nicht optimiert". Darauf will ich hinaus. Dass unbekannte Parameter nicht angenommen werden ist klar, spielt aber auch keine Rolle. Es geht ja um die bekannten Parameter die aber mit unsinnigen Werten gefüttert werden. Die Shader-Quality auf 0 zu setzen ist bekloppt, nur um die prozedurale Flora weiter sichtbar zu haben. Das ist zwar möglich, aber es eliminiert eben andere Effekte. Das ist auch der Grund warum die Performance nicht einbricht. Das Gras ist zwar deutlich weiter zu sehen, aber dafür wird POM und Heigh/Weight-Blend ausgeschaltet. Das führt zu hässlichen und aus Sicht der Entwickler falsch dargestellten Terrain-Texturen und im Falle des TSW eben des Gleissystems.

Ich weis es jetzt schon. Wenn die User aufgefordert werden würden, die ini-Einstellungen für jede Strecke zu ändern, was ja nun mal sogar mehr Arbeit macht als im TS1 die Einstellungen zu ändern, werden die rummosern und die Schuld auf die Strecken schieben, die das verlangen. Die verbogenen ini-Settings sind dann eben längst "falscher" Standard geworden. Bleibt dem Entwickler nur noch übrig, die ini-Settings zu sperren und festzunageln, das natürlich auch geht, aber dem User sämtliche Kontrolle darüber entzieht.

Es muss keine 4.21 erst installiert werden. Man kann auch direkt nur die 4.16 installieren. Und nicht vergessen, der TSW-Editor ist nachher eh eine ganz eigene und zusätzliche Engine-Version, so wie die anderen Mod-Kits auch.

Auch wenn ich weis, dass meine Einwände kaum Gehör finden werden, sage ich dennoch mal was ich denke zu dem Gefummel in den .ini Dateien. Einfach um in Erinnerung zu rufen, dass das auch negative, unerwünschte Effekte hervorrufen wird. Nämlich genau dann, wenn die ersten Strecken, die nicht von DTG gebaut wurden, erscheinen. Dann nämlich fliegt euch der ganze ini-Fummelkram um die Ohren und das Geschrei wird wieder sehr laut sein. Am Ende sind dann die Strecken und Fahrzeuge wieder Schuld. Dass DTG nicht auf Maximum Qualität aus ist, sollte ja mittlerweile klar sein. Diese überall propagierten ini-Einstellungen sollte kein Standard werden. Das würde verhindern, dass andere Anbieter vernünftige Qualität erzeugen können, da sie gegen einen etablierten Standard antreten müssten. Ihr schneidet euch wieder ins eigene Fleisch damit. An Material- und LOD-Einstellungen rumzufummeln ist schlicht eine beschissene Idee. Zumal die meisten ja nicht mal wissen was es damit auf sich hat. Klar, momentan ist einiges wenig zufriedenstellend und das wird noch ne Weile so bleiben, aber das wird sich auch irgendwann ändern und dann stehen euch diese Einstellungen im Weg, weil keiner mehr gewillt sein wird, andere Einstellungen für jede Strecke anwenden zu müssen. Das Problem haben wir im TS10xx ja leider auch schon gehabt.

Nur ne meine Meinung dazu.

Einfach aus dem Laucher installieren. Du kannst jede Version parallel installieren, wenn du genügend Platz hast.