Warum kommt der RAM-"blubb" schon bei 3.3 GB Ram-Nutzung und nicht erst bei 4GB-Nutzung?

Hoffentlich musste der nicht zwischendurch raus.
Bekommen die in Blender erstellten Objekte immer eine"externe" Textur?

Blender: andersrum. Um Modelle in den TS zu bekommen, brauchen die eine Textur (vorzugsweise in einem Extra Textur-Ordner). Allerdings Können (sollten) mehrere ähnliche Objekte (z.b. Häuser) auf die selbe Textur (Sammeltextur) zugreifen, spart gewaltig Arbeitsspeicher im TS.
StS

Huhu,

ich muss dieses Thema einfach noch mal aufgreifen, weil es mit doch als sehr wichtig erscheint

In erster Linie geht es darum, eine Textur für ein Objekt zu erstellen, um dementsprechend Berechnungen einzusparen.

Umso niedriger das Verkehrsaufkommen, desto flüssiger der Verkehr auf der Autobahn
Genau so verhät es sich auch mit der TS-Pipline, wo Texturen und Objekt durchmüssen.

Ich habe unten mal ein Besipiel angehangen:

Das erste ist eine Sammeltexur 512x512 (schwarzer Porsche) von mir für das BÜ Signal.
Danach sieht man, wie es größtenteils andere bei dem BÜ Signal machen würden mit 1024x1024 (Kleintransporter) oder 2048x2048 (LKW) Einzeltexturen.
Viele einzelne Berechungen, statt einer.

@StS

Im Prinzip ist es so, egal wie man es auch macht, ganz richtig ist es auf Grund der 32 Bit nie!

Nehme ich eine große 4096x4096 (Schwertransporter) Textur, erstelle auf dieser Texturen für 10 Häuser incklusive einem Dach, so habe ich zwar 9mal ein paar Kbs fürs Dach gespart, allerdings geht der Schuss in dem Moment nach hinten los, wenn ich nur ein Haus davon auf der gesamten Strecke verbaue oder die Häuser einzel über die Kacheln verteile.

Ist übriges auch ein Grund, warum ich bisher noch keine Warstein - Objekte veröffentlicht habe.
Dort macht es teilweise einen Sinn, aber nicht wenn alles wild auf der ganzen Strecke verteilt wird.

Gruss Schmiddi

Eine Frage hab ich Da. Große Textur für mehrere Objekte, aber jedes Objekt auf einer anderen Kachel.
Was mach der TS? Schmeisst der an jeder Kachelgrenze die Textur raus und läd die neu? oder wird die einfach weiterwendet, nichts wird geladen. Dann machen Sammeltexturen Sinn, wenn die Summe der Einzeltexturen größer wäre als die Sammeltextur.
Das ist meiner Meinung nach das KUJU-Prinzip, fast gleiche Häuser auf der ganzen Strecke verteilt, benutzen aber eine gemeinsame Textur.
StS

Das ist ne gute Frage.
Bin eigentlich davon ausgegangen, dass er auch die Texturen nachlädt.
Wenn bei schwachen Rechnern ein Szenrario gestartet wird oder man die Kachel wechselt, so bleibt das Objekt ja erstmal ein wenig weiss.
So habe ich es mit meinem alten Rechner zumindest in Erinnerung.
Würde eigentlich darauf schließen, das auch die Texturen nachgeladen werden.

Wenn natürlich eh alles drin bleibt, wäre es mit einem Dach für ein paar Häuser besser.

Gruss Schmiddi

ich glaube, er verwendet weiter. Zumindest deuten einige Fehlermeldungen, die manchmal in Logmate auftauchen, auf eine entsprechende Reference-Counter Logik hin.

@TailDogRunner1909

Na, denn mach mir mal nen Bahnhof mit 5 Bahnsteigen, je Bahnsteig zwei Aufgängen und einen Tunnelabgang, Rolltreppen, Beleuchtung, Uhren, ZZA, Bahnhofnamen, Bahnsteigabschnittstafeln, großem Empfangsgebäude, Vorplatz und einem Einkaufszentrum mit einer 2048x2048 Texture . Die Texturen dürfen nicht verwaschen sein und mehrere müssen wiederholfähig sein. Aber ich gebe dir natürlich recht, man muss nachdenken. Baue ich das Ding aus vielen Einzelkomponenten zusammen, bekomme ich mehr Draw Calls, als wenn ich ein großes Objekt mit mehreren Texturen bau, da sind es dann nur soviele Draw Calls, wie Texturen... Widerum werden in einer Kachel sich wiederholende Texturen (Dächer, Asphalt, Bürgersteig, Schotter etc etc) schneller in den Speicher geladen als wenn du für jedes Objekt nen eigenen Texturensatz hast. Das Problem ist das Ganze - bei gutem optischen Ergebnis - performat und speicherkompatibel hinzubekommen. Und da gibts sone und sone Vorgehensweisen. Was dein Bü-Signal betrifft, wäre ich anders vorgegangen: weil ich weiß, dass ich den Betonsockel auf der Kachel noch zweihundertmal mal brauche (FL-Masten), bekäme der ne eigene Textur..., die würde auch nur einmal in den Speicher geladen.

Winke, Jan

Habe mal einen Test gemacht:

TS auf bebauten Kachel gestartet: 1,55 GB Verbrauch
TS auf der gleichen Strecke auf einer leeren Kachel gestartet, 1,11 GB Verbrauch
TS auf einer komplett leeren Strecke verbraucht, 0,55 GB Verbrauch.

Wir wissen, Signale und Gleise bleiben beständig im Ram.
Dazu kommt noch dass der Ram sich bei einer Fahrt immer ein wenig aufplustert.
Die Frage nun, kommen die Unterschiede von den verbauten, bzw. nicht verbauten Gleisen?

Könnte man überhaupt lange Strecken bauen, wenn alles im Ram gehalten werden würde?

@bahnjan

Das Problem was ich meine ist ja, das die Leute für eine Uhr gleich ne "048x2048 Textur nehmen.
Für sowas ist ne großes finde eine große Textur oder mehrere vollkommen ok.
Ja, verwaschen und unscharf ist blöd, allerdings besser als Dumps

Gruss Schmiddi

Ich habe jetzt mal folgendes getestet:

Ram1: Strecke erstellt, komplett leer geladen, Provider Düsseldorf_Köln
Ram2: Weitere Provider angehakt: DTG, Kuju, Sad, TDR , RSC, Railsimulator
Ram3: Unterschiedlich Objekte der Provider auf die Kachel gestellt (keine Gleise verwendet)
Ram4: Stecke auf leerer Kachel wieder gestartet.

Für mich sieht es danach aus, dass der TS nicht alles in den Ram schaufelt, sondern nur was er auf einer Kachel benötigt.
Der Ram steigt auch nur leicht an, wenn die Provider aktiviert werden, wobei es sich ja hier um die Schwergewichte handelt.

Theoretisch könnte man also jeden Provider anhaken und die Objekte alle auch benutzen, ohne sich Gedanken zu machen
Bringt eine zu volle Kachel eventuell den TS zum abschmieren und nicht die Gesamtheit

Kleine Schwankungen im Ram sind ja zu beobachten, allerdings kann ich als Laie diese nicht deuten.

Gruss Schmiddi

Wozu sind denn dann die blueprint.pak Dateien, die immer erzeugt werden, wenn der Provider aktiviert ist und die Strecke zum Laden vorbereitet wird.
Komischerweise, wenn man Provider auf das nötigste abmagert und damit kleinere .pak bekommt, kommt der Blubb nicht.
Das war bei der Italienischen Strecke Ferrovia sul confine Italia-Francia die einzige Rettung.
Sollte das jetzt anders sein?
StS

Wäre unheimlich wichtig dieses in Erfahrung zu bringen.
Das wäre revolutionär für den Strecken- und Objektbau.

Vielleicht sind diese Blueprint.pak der Grund für den leichten Anstieg bei der Akktivierung?
Umso größer der Ordner, desto größer der Blueprint.pak?

Es wird vermutlich nur die .pak geladen + die Objekte komplett die auch auf der Kachel stehen.

Jo,

wäre dem nicht so, würde die Strecke bei der Anzahl der großen Provider wohl gar nicht mehr gestartet.
Da reichen ja schon zwei Haken bei Düsseldorf und Hamburg für einen Dump

Würde zumindest in der Theorie bedeuten:

- hohe Anzahl an unterschiedliche Objekten auf der gesamten Strecke verteilt
- größerer Texturen (zumindest für mich, die anderen haben ja schon vorgelegt )
- auf den Ramverbrauch der einzelnen Kacheln achten

Ich hyperventiliere

Ich kann nur aus eigener Erfahrung berichten. Ich bastel immer ein wenig an Hamburg - Hannover rum und platziere hier und dort eine Werbetafel, ne Sparkasse oder ein Kino für mehr Realismus. Auch an der Vegetation habe ich einiges gemacht. Im Zuge dessen habe ich unglaublich viele Provider freigeschaltet und es hat bisher keinen EInfluss auf die Strecke und ich kann alle Szenarien normal fahren.
Da habe ich mir auch schon gedacht: Freischalten scheint nicht das Problem zu sein, wenn man nur hier und da was plaziert. Falls es jemanden interessiert: Freischgeschalten habe ich (mal so aus dem Kopf) Diverse DTG Strecken, SAD, pawerybs, News, Icepack und noch einige Kleinigkeiten. Das scheint den TS nicht zu jucken...

Also verursacht der Blueprints.pak irgendwann den Dump, weshalb es nicht möglich ist unendlich viele Objekte zu bauen?
Groß ist der pak. allerdings nicht, so dass ich meine, da geht einiges, oder?

Gruss Schmiddi

Ich bin eher auch der Überzeugung dass es auf die Vielzahl, aber letztendlich eben doch auch die physikalische Größe der verbauten Assets auf EINER Kachel ankommt. Ich hab da bei meinem Stahlwerk in Dillingen eben dummerweise auf einer Kachel das meiste Zeug stehen und die Böller von "Massilion, Ohio Steel" - auch wenn es nur MSTS Konvertiten sind- sind halt Kalorienbomben (Provider sind da sicher auch 15-20 an), Gleise/Signale alles schön und gut, aber in den großen Gleisfeldern mit vielen Signalen machen dann die aufzustellenden Züge wohl eher das Problem, aber klar es ist die Summe von allem ... also weitere "Selbsttests sind angesagt Schmiddi!"

@[1247]DetPhelps: Der Flaschenhals ist der TS. Da kann er auch auf 512 GB RAM aufrüsten. Es wird nicht besser laufen, da sein Betriebssystem mit Anhang wohl kaum mehr als 4,2GB verbrauchen wird.

Grüße

[anmerkung]Die RAM-Diskussion aus dem Moseltal-Thread wurde hierher verschoben.[/anmerkung]

Zitat von [1247]DetPhelps

Der Flaschenhals ist aber der RAM, mit 8GB eindeutig zu wenig. Hier solltest du aufrüsten auf 16/32GB und dann nochmal testen.

Etwas OT hier, aber klärt mich mal auf. Bisher war hier immer zu lesen, dass der TS ohnehin nicht mehr als 4 GB nutzen kann, man aber trotzdem mehr haben sollte, weil ja noch einige andere Programme laufen (müssen), aber 8 auf jeden Fall ausreichen, und nun sind inzwischen 8 GB "eindeutig zu wenig" ?

Nein, 8GB reichen locker aus wenn nicht noch eine virtuelle Maschine oder Folding@Home nebenbei läuft. Der TS kann nur knapp 4 GB adressieren, fertig. Wenn man auf 16 GB aufrüstet, dann für andere Spiele, nicht den TS.
Der RAM ist hier nicht der Flaschenhals. Nicht für den Train Simulator. Für den Train Simulator ist ab 8 GB alleine der Train Simulator selbst der Flaschenhals.

Grüße