Jo! Mir auch!
Aber die Bögen so dunkel...?
Vielleicht besser im Ton der Streifen.
Micks Werkstatt
-
- TRS 2019
- Freeware
- mick1960
-
-
-
Danke! Aber je weiter ich mit dem Viadukt komme, desto mehr mache ich mir Sorgen ueber die Texturierung. Ich habe keine Idee, wie man ein so grosses Bauwerk sinnvoll mappen kann ohne das es katastrophal ausschaut. Bei einer Laenge von ca. 288 Metern sind das selbst bei einer 2048er Map nur sieben Pixel pro Meter...
Vielleicht kann ich ja auch mal einen Tip geben.
Wie wär's denn , wenn du meine Methode übernimmst , die ich beim OUSE - Viaduct ( das ist im Original noch viel länger ) benutzt habe.
Ich habe ein Anfangs-Stück ( setze ich auch als Endstück , gedreht , ein ) genommen und nur einen Bogen als Spline gemacht.
Damit kann ich jede beliebige Länge erstellen.
Was denkst du ?
-
nur einen Bogen als Spline gemacht
Wie schon einmal erwaehnt, sind Splines ein No-Go fuer mich. Meine Objekte sind ja eh schon keine Polygon-Haenflinge und ich will nun auch keinen Poly-Supergau bauen. Splines sind der Performance-Killer in Trainz, in etwa wie ein Tutu aus Blei...
-
-
Nein, ist mir nicht!
Würde ich dann das oben schreiben...?
Edit:
Zumal ja Spline-Objekte im Trainz seit Anfang her Verwendung finden:
Gleise, Straßen, Brücken, Tunnel, Zäune...
Und selbst die neuen high-poly-3d-Gleise werden als Spline gebaut.
Sind die Nachteile wirklich so erheblich?
-
Ich glaube Dir ist nicht bewusst warum Splines die CPU und GPU belasten...
DAS würde mich auch interessieren.
Wie Jörg schon sagte : Gleise , z.B.
Ausserdem . . . . Eine neue CPU / GPU kann eine ganze Menge.
Alle zwei Jahre rüste ich auf.
-
-
Zumal ja Spline-Objekte im Trainz seit Anfang her Verwendung finden:
Es gibt Objekte, die man eben nicht anders darstellen kann und Gleise sind eigentlich fast die einzigen, welche ich akzeptieren wuerde.
Lest Euch einmal die zugrunde liegende Mathematik durch und dann interpoliert das dort weitgehend fuer Linien geschriebene auf komplexe Meshes samt Texturen und macht Euch klar, dass das nicht beim Speichern als CDP ablaeuft, sondern zur Laufzeit berechnet werden muss:
-
????????? Ach so! ???????
????????
????????Eine Erklärung für Realschulabgänger wäre mir zwar lieber gewesen, denn nun bin ich nur noch verwirrter...
Aber trotzdem danke!
Edit:
Ich habe mich eben auf anderen Seiten belesen, und habe es nun soweit verstanden, dass der PC (CPU / GPU) jeden Knotenpunkt des Splines, und das sind an einem 3-dimensionalen Objekt mehrere, eben alle Eck- und Kantenpunkte, diese komplizierten Berechnungen durchführen muss?
Ich dachte eher, hier wird nur der jeweilige Winkel der Polygone der Knotenpunkte zwischen jedem Spline berechnet, wie an einem Körper allgemein...
-
Gleise sind eigentlich fast die einzigen, welche ich akzeptieren wuerde
In der Theorie eine korrekte Aussage. Objekte stehen in Trainz jedoch immer im Verhältnis zu einer Strecke (wer plaziert schon 2-3 Objekte auf einem Baseboard zum Spass?).
Ein Beispiel aus der aktuellen Praxis:
Ich hatte gestern einen Busch (wäre ja nach deiner Annahme eine Alternative zum Spline) als Einzelobjekt mit 9 MB im CM gefunden. Dieses Objekt hat keine Bibliothek. (kein Einzelfall und selbst heute noch Standard) Wenn ich nun dieses Objekt fleißig in den Bereich des Nachladens von Trainz verbaue, so fahre ich als Alternative mit einem Spline um einiges besser. Warum? Der Lese- / Schreibzugriff (bei Einzelobjekten) ist heute nach wie vor der Flaschenhals, und somit werden die 9 MB x 10 oder realistisch bei einer Strecke mit Gras / Büschen 100x (fast 1GB) fleißig aus dem Speicher (RAM / Platte) gelöscht, geladen, gelöscht, geladen etc... Meist sind hier auch Texturen im Objekt selbst das eigentliche "Problem" (wobei Problem eigentlich das falsche Wort ist...)
Ein Spline geht in der selben Zeit über die CPU / GPU welche im Vergleich zum Schreibe- und Lesezugriff natürlich einen ganz anderen Leistungsumfang besitzt. Natürlich übertreiben es viele mit Splinepunkten. Viele Darstellungen lassen sich auch mit dem Begradigungstool mit wenigen Splinepunkten und fast identischen Ergebnis darstellen. Natürlich ist auch nicht Spline = Spline, auch hier lohnt sich anzuschauen wie hat der CC die Splines erstellt.
Die korrekte Annahme wäre meiner Auffassung nach:
Splines sind nicht ein grundsätzliches Problem, der umfangreiche sowie unüberlegte Einsatz von Splinepunkten kann eine von vielen Ursachen bei Performanceproblemen sein. Auch wenn in der Theroie natürlich ein Spline erstmal das größere Übel ist. Wenn ich mir jedoch (auch BuildIn) Strecken anschaue liegt meist der Hund woanders begraben, in Objekten welche in einem Abschnitt 30x verbaut werden und mit jeweils 30-50 MB verarbeitet werden müssen, (ohne Bibliothek) Autos welche 61 MB haben und 300 Meter (ohne vernünftige LOD, ohne Bibliothek) von der Strecke entfernt sind, Speedtrees welche ohne Bibliothek in 6 verschiedenen Varianten auf die Karte gesetzt werden usw usw...
Dies ist alles kein Vorwurf an die jeweiligen Kollegen Streckenersteller welche sowas verbauen, sondern die Ursache liegt u.a. in der immer noch von vielen gewünschten Abwärtskompatibilität, wo selbst Objekte mit dem dahmaligen Standard noch verbaut werden können, aber heute ganz anderes "verarbeitet" werden. Auch der "gefakte fehlerfreie" BuildIn Content ist mal ein lohnender Blick wert.
Ich möchte (bevor es gerne anders verstanden wird) betonen, dass eine Bibliothek natürlich dann zwingend Sinn macht, wenn das Objekt mehrfacht verbaut wird. (z.b. Straßenlaternen, Büsche, Wohnhäuers, Oberleitungsmasten). Bei Objekten welche z.b. nur sehr selten auf der Strecke vorkommen (Lokschuppen, ein bestimmter Bahnhof, ein Hafengebäude) machen Bibliotheken wenig Sinn, da diese ja bekanntlich komplett geladen / gelöscht wird.Edit:
Sind die Nachteile wirklich so erheblich?Ja und Nein. Solche Bewertungen müssen immer im Kontext gesehen werden, eine Einzelbetrachtung ohne dies im Zusammenhang einer Strecke zu sehen ist wirklich schwer. Auch ist es immer ein Unterschied zwischen Theroie und Praxis. Manche Alternative ist eben leider keine....
-
Das Problem ist, dass alles in seiner Performanceauswirkung stark Zweckabhängig ist.
Libraries sind auch nicht das nonplusultra, welches man nun vermuten könnte.
Libraries sind vorallendingen dann gut, wenn viele Meshes mit gleichen oder zumindest teilweise gleichen Texturen (im Idealfall auf einer oder zwei 1024px Texturen geschickt unterzubringen) häufig zusammen verwendet werden. Ein gutes Beispiel ist dafür ein Oberleitungssystem. Hier haben wir es mit mehrern Arten von Metall, vielleicht einem Betonmast und mehreren Farben Isolatoren zu tun. Können wir relativ bequem auf ein oder zwei Maps unterbringen und haben dann sehr viele Meshes, die diese Texturen und Materials verwenden. Material Sharing ist super, weil diese Oberleitungsmasten können dann alle zusammen geladen und auch von der Grafikkarte in einem Drawcall dargestellt werden.
Erstellen wir aber ein Paket von 20 Stadthäusern welche alle relativ unterschiedlich gebaut sind, so haben wir ein Problem. Wenn wir selbst Objekt und Streckenbauer sind können wir das auf unsere Bedürfnisse anpassen, denn wir werden wahrscheinlich alle 20 Häuser relativ häufig auf vielen Orten der Strecke verbauen und können somit erzwingen, dass diese beim Start bereits geladen und im RAM gehalten werden. Für die meisten Fälle wo ich aber nur Objekte erstelle, verwenden viele Streckenbauer meine Häuser ganz anders als von mir gedacht. Im Extremfall wird nur ein einziges Haus des Sets verbaut, erzwingt aber ein Laden aller Texturen und Meshes der anderen Häuser.
Aus diesem Grund sind und werden viele Einzelobjekte ohne Library gebaut, weil hier vieles Anwenderabhängig ist.
In so einem Fall sollten T:ANE SP3 und TRS19 (theoretisch, ich habe dazu keine eigenen Tests durchgeführt) damit auch performant umgehen, wenn man ein einziges Haus welches ein alleinstehendes Objekt mit eigenen Materials ist, sehr oft auf einer Strecke verbaut. Es sollte dann, wenn immer mindestens ein Haus in der Sichtweite ist dieses auch nicht wieder entladen. Klar, wenn das Haus nur an einem Ende der Strecke steht, wirds nur dort geladen. Eine Meshlibrary sollte sich da aber genau gleich verhalten und entladen werden, wenn kein einziges Asset, dass sie benötigt, mehr in Sichtweite ist. Wir erhöhen nur auf Kosten von RAM die Wahrscheinlichkeit, dass eins in Sichtweite ist.
Dies bitte nicht mit Skriptlibraries verwechseln welche wirklich global für eine Session ein einziges mal geladen werden und danach im RAM verbleiben, wobei lustigerweise die meisten sich selbst so bezeichnenden Skriptlibraries diese Technik gar nicht verwenden (sie ist nicht besonders komfortabel umzusetzen) sondern stattdessen, Asset für Asset, eine eigene Instanz via Script-Include-Table laden.
Das Problem beim Häuserbau ist eher, wenn man nicht gerade wie DTG baut uns auf der ganzen Strecke maximal 6 verschiedene Hausassets einsetzt sondern auf einen realistisch und ansprechend aussehenden Streckenrand setzt, so wird man es nie schaffen, dass wirklich Performant zu bauen.
Zum Mythos "High-Poly-Gleis": Die Gleise haben auch in TRS19 gar nicht so viele Polys, wie sie aussehen. Sie sind vorallendingen Flächen mit Heightmaps drauf. Natürlich ist an Micks Aussagen was dran, die Verbiegungen der Splinemeshes werden in Echtzeit berechnet, deswegen sind sie auch so flexibel. Zu viele Splines können in der Tat die Performance runterreißen, aber wie die Erfahrung zeigt, kann man als Streckenbauer schon sehr stark übertreiben mit den Splinepunkten, bevor das spürbar wird. Und ja, wichtig ist hier auch, gute LODs bereitstellen, bei Splines wie Zäunen die sehr lang und in der Distanz ungenau werden können: große Segmente in den höheren LODs.Sorry für die Textflut. Was ich sagen will ist, dass der Objektbauer es schwer hat, ein Produkt bereitzustellen, welches von Streckenbauern flexibel und trotzdem performant eingesetzt werden kann, wenn nicht über einen genauen Zweck kommuniziert wird oder man selbst Strecken- und Objektbauer ist, denn ein "falscher" Einsatz eines Objektes kann bei einer großen Anzahl zu den angesprochenen Performanceeinbußen führen.
Greets, Mika
-
Libraries sind auch nicht das nonplusultra, welches man nun vermuten könnte.
Sie dienen als Instrument um z.b. Objekte welche häufig im Kontext einer Strecke zum Einsatz kommen sinnvoll sowie Perfomant zur Verfügung zustellen. Besonders bietet sich hier Oberleitungen, Lampen, Bäume und ja auch in Zukunft unter bestimmten Voraussetzungen verschiedene Wohnhäuser an. Ich legte jedoch auch in meinem Posting klar Wert darauf zu vermitteln, dass es oft keine technischen sinnvollen Alternative zu Splines als Streckenersteller gibt. Ebenso, dass man es eben nicht pauschal (in der Praxis) sagen kann: "Splines sind der perfomancekiller schlecht hin". Wir sehen aktuell wie dies unreflektiert von Streckenerstellern fast schon panikartig übernommen wird.
Ich stimme Dir natürlich zu, dass es nichts bringt wenn ein Contentersteller sich Gedanken macht, und eine Streckenersteller aus einem Paket (bleiben wir mal dennoch kurz beim Wohnhaus) nur ein Objekt plaziert. Klar ist ebenfalls, dass gerade in Deutschland sich dieses eigentlich gut nutzbare und sinnvolle Instrument nur dann gänzlich entfalten wird wenn beides aus einer Hand / Team kommt. Aber bei Standardobjekten (Siehe oben) ist es auch unabhängig der Verwendung des Streckenerstellers sinnvoll es in eine Bibliothek zu packen. (Wer verbaut schon nur eine Lampe ?) In meinem obrigen Beitrag bin ich auch ganz klar auf das Beispiel aus der Vegetation eingegangen wo eben ein Spline (sinnvoll eingesetzt) oft Alternativlos ist. (Mangels Alternativen)
Das Beispiel mit DTG kann ich so nicht bestätigen, bei der doch recht in die Tage gekommen Strecken Köln-Koblenz (übrigens noch für 32 Bit erstellt) habe ich z.b über 150 Häusertypen. Da der TrainSimulator jedoch anders arbeitet wie Trainz sollte dies jedoch hier denke ich nicht als Beispiel dienen.So manche Objekte welche wir hier gerne Sorglos einsetzen sind beim TS nicht verwendbar. Dafür hat der TrainSimulator andere technische Stärken (nicht das Spiel an sich, sondern der Motor ist hier gemeint) welche man sich schon lange in Trainz wünscht.
Kurz gesagt:
Wenn alles aus einer Hand kommt wird man den umfangreichen Unterschied sehen und erleben können. Bis dahin bezieht man sich als Streckenersteller auf Erfahrungswerte sowie Kenntnissen welche man im Team über mehr als zehn Jahre gesammelt hat. N3v hat es langsam begriffen und bietet nun schon seit zwei Trainzversionen vermehrt Instrumente an um an technische Standards der Industrie aufzuschließen. Klar ist hier aber auch, mit einem Office PC für 400 EUR kann man in Zukunft einfach nicht mehr mithalten. In diesem und nächsten Jahr wird es mit Trainz sowie Inhalt einen großen Sprung nach vorne geben. Hier wird auch das Thema Perfomance sowie sinnvolle Speicherverwaltung mehr in den Mittelpunkt rücken.
Es ist aber auch an sich ein Drahtseilakt, auf der einen Seite möchte man nicht in einen Perfomance Wahn verfallen oder dieses Image von Dritten aufgedrückt bekommen, auf der anderen Seite jedoch auch den Wunsch äußern, dass ein Dialog zwischen Streckenerstellern und Contenterstellern stattfindet. Am Ende muss es wohl ein lebendes Beispiel sein welches ggf. den passenden Denkanstoß geben wird.
Letztlich aber sehr schön solche Beiträge zu lesen, waren diese früher im alten AuranForum noch täglich vorzufinden sind diese leider zu einem Exoten geworden... -
Oh Mick, jetzt habe ich hier aber was angerollt!
Tut mir sehr leid...
Aber eine Frage habe ich noch:
Dieses Objekt hat keine Bibliothek. (kein Einzelfall und selbst heute noch Standard)
Was meinst Du mit "Bibliothek"?
-
Oh Mick, jetzt habe ich hier aber was angerollt!
Tut mir sehr leid...
Kein Problem! Ich mag's ja, solange es beim Thema bleibt...
Was meinst Du mit "Bibliothek"?
Dies hier: Mesh library
-
Ok, danke!
-
-
Die Bögen erinnern mich an ein Tetrisspiel.
Ich denke du übst dich immer noch an o.g. Problem. Oder?
Grüße
Jürgen
-
Die Bögen erinnern mich an ein Tetrisspiel.
Gespielt wird hier nicht, Tetris is' wech! Hat mir auch nicht gefallen...
Ich moechte nicht vergessen mich herzlich bei @GnatzED und bei Joth zu bedanken. Die beiden haben mich mit tollen Fotos versorgt!
