Beiträge von wurstbrot

Danke für die genaue Ausführung. Ich habe noch garnix im Modell selbst gemacht, nur in der .bus Datei. Mit dem Spiegel rechts war das auch eine Annahme, aber ich habe das Gefühl dass der erste Spiegel, also der linke immer bevorzugt wird und anders verarbeitet wird als der Rest, vor allem im Öko-Modus. Ich habe nämlich vergessen zu erwähnen dass in den Optionen der "normale" Öko-Modus eingestellt ist, und auf den bezieht sich das ganze.

Zu meinem Erstaunen stellte ich aber nun fest dass wenn ich dort vom Öko-Modus auf Voll umstelle, das ganze genau so funktioniert wie ich es möchte: Linker Spiegel rendert sowohl in der Hauptsicht, wo er nur ausschnittsweise zu sehen ist, natürlich dann auch in den Sichten nach links. Kein Frameratenverlust im Vergleich zur vorherigen Einstellung. Bei Verwendung von _2 bei erstem Spiegel und ohne _2 bei den restlichen gab es im Voll-Modus immer massiven Frameratenverlust. Und jetzt kommts: in der "Fahrplansicht", was bei mir so ein Blick nach oben-leicht-rechts" ist werden nun der Fahrgastraum-Spiegel und der rechte Spiegel voll gerendert, mit leichtem Framerateneinbruch. Aber kein Vergleich zum Voll-Modus mit Verwendung von Typ 1 und Typ 2 Kameras. Und der Blick rechts wo nur der Aussenspiegel zu sehen ist, der relevant für mich ist beim Rechtsabbiegen rendert nun auch voll mit leichtem Framerateverlust, was aber nicht schlimm ist. Es ist ein Unterschied wie Tag und Nacht, man nimmt nun weniger Bordsteine mit als bei dem Gezuckel vorher. In der Hauptansicht null Frameratenverlust! Als Bonbon oben drauf habe ich nun auch einen Fahrgastraumspiegel der schön mit voller Rate rendert. Abgesichert ist das ganze für Fälle wo vielleicht doch die Framerate zu niedrig ist mit dynamischem Öko-Modus, der unter 31 fps einschaltet und bei 40 etwa wieder abschaltet.

Die Überwachungskameras lasse ich nun aus, die würden auf jeden Fall das ganze vermasseln wegen des Abstands.

Ja, man muss das wohl feintunen, und die Werte scheinen zumindest für diesen Bus perfekt getroffen zu sein. Andere Busse bedürften dann ebenfalls so eine Behandlung. Aber die Haupterkenntnis ist wohl dass man mit Typ 2 das viel besser hinkriegt als Stumpf die erste Kamera auf Typ 2 zu setzen und die anderen nicht.

Bei Aussenschwenktüren fänd ich das garnicht schlimm dass der ins Sichtfeld kommt und somit bei offenen Türen sich die Lage ändert, denn das passiert ja nur im Stand.

Zum Schluss noch eine Verständnisfrage: ein per CTI abgeschalteter Spiegel ist also auch nicht da und wird in keinem Szenario doch im Hintergrund gerendert?

Moin!

Mein Vorgehen bei den meisten Bussen war es bisher den linken Spiegel auf Typ 2 zu setzen, und die restlichen Spiegel als typ 1 rendern zu lassen. Ziel war es immer dass der linke Spiegel mit voller Framerate refresht, und nur die anderen Spiegel reduziert werden. Nun habe ich aber in Erfahrung gebracht dass das viel geschickter geht, nämlich wenn man nur Typ 2 Reflexionen einsetzt, dort aber geschickt die letzten Zeilen setzt. So sollen die Spiegel auch nur dann voll gerendert werden wenn der Blick auf sie gerichtet wird. Der letzte Wert regelt dann den Toleranzbereich.

Hier mal als Beispiel mein aktueller Test aus dem Solaris Urbino PL:

[add_camera_reflexion_2]
-1.377
5.056
2.285
0
52
175
-25
0.08

[add_camera_reflexion_2]
1.348
5.924
2.353
0
52
205
-10
0.10

[add_camera_reflexion_2]
-0.005
5.2
2.576
0
52
195
-22
0.01

    "reflexion3.bmp":

[add_camera_reflexion_2]
-0.372
0.1
2.793
0
80
45
-40
0.001

    "reflexion4.bmp":

[add_camera_reflexion_2]
-0.294
-3.997
2.828
0
80
45
-40
0.001

    "reflexion5.bmp":

[add_camera_reflexion_2]
1.084
5.882
2.402
0
70
243
-29
0.001

Vorher war nur der erste Spiegel Typ 2 und Rest ohne das _2. Effekt war der gleiche. Aktuell wird der linke Spiegel voll gerendert, die anderen reduziert oder garnicht. Schön udn gut, nur kam ich jetzt mit der Typ 2 Methode auf die Idee auch den linken Aussenspiegel bei Sicht auf diesen auch voll rendern zu lassen, und das klappt leider nicht. Meine Sichten sind so dass in der Standard-Sicht nur der linke Spiegel zum Teil zu sehen sind, beim Blick schräg nach links ebenso, beim ersten Blick richtung rechts ist nur der rechte Spiegel zu sehen, und über die schedule-Sicht habe ich Sicht auf Fahrgastraum-Spiegel, zwei Überwachungskameras und den rechten Spiegel. In der schedule-Sicht hätte ich also sowieso reduziertes Rendern, da hier grundsätzlich mehrere Spiegel sichtbar wären. In der Sicht nach rechts allerdings nur einer. Und egal wie hoch ich da den letzten Wert setze, er rendert beim blick drauf immer reduziert. Hab sogar überprüft ob da nicht der Fahrgastraum-Spiegel aktiv ist, ist er aber definitiv nicht. Bin also etwas ratlos, warum hier das in der Praxis nicht funktioniert.

Der Bus hat noch einen Spiegel: für die Sicht vorne nach unten (weiss nicht wie der sich nennt...) Der ist aber per CTI nicht eingeschaltet und hier bei den Kameras auch eigentlich ausgestellt. Ebenso sind die Überwachungskameras aus, da diese das sowieso unmöglich machen würden aufgrund der nötigen Extremwerte in der letzten Zeile. Kann es sein dass der rechte Spiegel irgendwie doppelt ausgeführt ist und deshalb da eigentlich sich immer zwei Spiegel (mit den gleichen Werten) befinden? Denn in der CTI kann ich für eben diesen einen geteilten Spiegel einstellen, finde aber diesen aber in der Busdatei nicht als Extra-Spiegel. Der hätte aber eine andere Krümmung, aber könnte ja auch durch anderes Mapping entstehen...

Die Frage wäre ob meine Vermutung richtig ist mit dem "Doppelspiegel" und generell. Und ob ich diesen Spiegel irgendwo in der Modeldatei eventuell entfernen kann, da ich ihn für Unnütz halte. Der würde für mich erst Sinn ergeben wenn ich in 4K fahren würde und dann auch noch die Spiegelauflösung von 1024 auf das doppelte oder vierfache hochdrehen würde. So aber definitiv nicht.

Bei den Überwachungskameras habe ich aufgegeben, denn ich bin mir mittlerweile Sicher dass eine Aktivierung auch nur einer davon sofort alle Spiegel (also auch den wichtigsten linken) in den Ökomodus versetzen würde. Einfach aus dem Grund weil man dort nicht die Entfernung zum Bildschirm eintragen muss sondern zur Kamera (!), und diese ist ja Meterweit von mir entfernt. Der Schwellwert liegt hier bei etwa 5-8, eine der Kameras befindet sich ja auch gegenüber Tür 2, was diese Annahme stützt.

Der Standarddepot-Eintrag ist mir bekannt, und ich frage mich immer warum er in 99% der Karten (auch kommerzielle) falsch ist. Dort steht oft einfach nur der Mapname, obwohl das nix mit einem Depot zu tun hat. Dieser Eintrag ist ja essentiell für das Feld mit der Zufallsauswahl und die Bindung der Nummern an dazugehörige Repaints. Leider filtert er aber nicht die Busse selbst;-D

Die AI-Versionen sind ja reduzierter und oft daraufhin optimiert zwar von aussen gut auszusehen, aber ohne alle unnötigen Dinge für den AI-Betrieb. Dazu können auch Scripte zählen, denn die können in der Menge dann zum Teil erheblich auf die Performance drücken. Es gibt zwar den [visible] Flag in den Modelldateien wo man einstellen kann wo was erscheint wenn es sich um ein Spielerfahrzeug handelt oder AI, meiner Erfahrung nach aber wird das Fahrzeug trotzdem immer mit "allem" geladen beim spawnen. Die unsichtbaren Modelle werden also geladen, nur nicht angezeigt. Hat positiven Einfluss auf die Framerate (wieder in der Summe, ein einzelnes Fahrzeug macht selbst als Poly-Schleuder nicht viel aus), beim Nachladen an den Kachelgrenzen ist es aber genauso schlecht wie wenn alles auf visible wäre. Das vermeiden die AI-Versionen, zusätzlich kommt noch die Reduzierung bei den Scripten hinzu.

Also so wie ich es überblicke würde es die besagten Dopplungen dann geben. Nun denn... Dann wäre es also schlau das in Kauf zu nehmen, die drei Höfe auf nach Möglichkeit reinen AI-Betrieb umzustellen, und das gleiche dann nochmal als Spieler-Hof zusammenzufassen und diesen als Standarddepot einzutragen. Die Begegnung mit dem Clon wird mit der Anzahl der Fahrzeug ja zumindest antiproportional.

Edit:

Gutes Beispiel für AI-Versionen sind z.B. die MANs der Stadtbusfamilie. Nutzt man sie nicht und hat viele in der Liste merkt man schon den Unterschied beim Laden finde ich. Nur irgendwie habe ich bei diesen den Eindruck dass die AI-Versionen einen kleinen Bug haben: fährt so ein AI-MAN an mir vorbei, verschwindet irgendwie sein "Hintern" sobald die Mitte des Busses aus meinem Blickfeld ist. Im Rückspiegel ist er aber noch zu sehen. Betrifft glaub ich aber nur die Solobusse.

Zitat von Schleswig-Holstein

Seit OMSI 2 brauchst du das eig nicht mehr, da OMSI sich über die "unsched_trafficdens" selbst definiert, wann WE etc. ist. zu OMSI 1 Zeiten war das noch anders.

Das gilt nur für Verkehr, nicht für das Fahrgastaufkommen. Das ist an jedem Wochentag gleich.

Moin!

Ich lasse in meinen AI Listen gerne AI-Versionen von Fahrzeugen fahren, nutze aber auch gerne die Zufallsauswahl von Fahrzeugen sowie die Beschränkung auf Zuweisung der Nummern für Spielerfahrzeuge auf nur die im Hof zugelassenen. Es ist nicht ganz einfach beides hinzukriegen, da ja AI-Versionen eine andere .bus Einträge benötigen als Spielerfahrzeuge.. Jetzt kam mir die Idee einfach alle Fahrzeuge die zum beispiel für die drei Höfe einer Karte vorgesehen sind zusammenzufassen zu einem "Spieler-Hof" ohne AI-Versionen, und bei den AI-Höfen dann eben die AI-Versionen einzutragen. Diesen Spieler-Hof dann als Standard-Depot festlegen (bei den AI-Höfen werden ja eh die Nummern entsprechend den Einträgen genommen).

Dann hätte man aber theoretisch jede Wagenummer und jedes Kennzeichen zwei mal in der AI-Liste, jeweils in einem der AI-Höfe und einmal im Spieler-Hof. Die Frage wäre nun wie geht OMSI eigentlich damit um wenn ich also zum Beispiel Wagen 200 wähle: eigentlich müsste Wagen 200 bei aktiviertem Häkchen "nur zum Hof zugehörige Nummern" nur auswählbar sein wenn er nicht schon als AI unterwegs ist. Umgekehrt dürfte Wagen 200 nicht spawnen wenn ich schon Wagen 200 fahre, selbst wenn es ein anderer Hof ist? Oder wird das ignoriert und es gibt dann zwei mal den Wagen? Ich denke das Nummernsystem soll doch auch sowas verhindern.

Anderer Grund für diese Aufteilung wäre auch dass ich mir nicht mehrere global.cfg Dateien bereithalten möchte wegen jeweils anderem Standardhof. Ich hab schon mehrere global.cfg wegen unterchiedlichem Fahrgastaufkommen an Wochentagen, das reicht schon... Noch ein Grund wäre dass ich bei manchen Fahrzeugen mit Kopien der .bus Dateien für Spielerbusse arbeiten würde da ich gerade auf halbwegs realen Karten nicht immer den Überblick habe welche Version des Busses nun zu welcher Nummer zugehört, was schnell vorkommt wenn man mit nicht zwischen Euro 4 bis 6 und verschiedenen Motoren samt verschiedenen Getriebetypen wählen kann. Umgekehrt könnte ich bei den AI-Höfen die Varianten dann einschränken.

Aber meinen Clon unterwegs zu treffen würde mich schon nerven;-D

Nein, denn das wäre ja die Skalierung, und die betrifft in OMSI dann das ganze Bild. Leider hat damals keiner daran gedacht dass man die UI-Größe von der sonstigen Darstellung entkoppeln muss. Ein großes Problem bei älteren Spielen.

Der nur geringe fps Verlust wundert mich garnicht. Ich bekomme fast gar keinen Unterschied wenn ich diverse Antialiasing-Geschichten einstelle. Ich glaube nur bei 2x2 Supersampling habe ich was gemerkt, was in etwa der gleichen Pixelmenge dann entspricht. War nicht viel, aber da es "nur" AA war war der kleine fps-Verlust in keinem Verhältnis zum Ertag, da ich mit anderen AA-Modi bei 0% Leistungsverlust ähnlich gute Ergebnisse erzielt habe. Bei nativen 4K ist der Mehrwert am Bild aber höher.

Weiter zum Nachladen:

Wieder habe ich den Framelimiter in OMSI rauf gesetzt, diesmal auf 41 oder gar 45 fps. Je mehr fps, desto erträglicher das Nachladen, da offenbar OMSI dann das gleiche zwischen den Frames geladen kriegt, bei mehr fps sind aber die Abstände natürlich deutlich kürzer. Die Limitierung auf klapp über 30 hat zwar so manchen Frameratensprung verhindert, aber wohl auch das Nachladen ausgebremst. Da ich Gsync einsetze sind aber Frameratensprünge fast irrelevant und nicht wahrnehmbar, ausser sie sind sehr hoch, daher ist glaub ich nun das Limit bei über 40 sinnvoller. Nebenbei fährt es sich mit 40 einfach viel besser als mit um die 30.

Da bei mir auf machen Karten mangels Material leider keine AI-Varianten fahren können: wäre es nicht machbar in diesen Bussen statt z.B. Morphys ZF/Voith Sounds für den AI-Sound aus anderen Bussen Sound-Configs zu verwenden die "Leichter" sind? Ich meine unter sound_ai was einzutragen aus einem anderen Fahrzeug, also auch ohne den ganzen Krempel zu kopieren. Oder muss das immer im gleichen Ordner des Busses sein? Das könnte auch für Entlastung sorgen.

Ich hab aber die Framerate gekappt auf 35, habs aber auch in Gebieten gemerkt wo die 35 stabil waren, also wo theoretisch Luft nach oben noch wär.

Mal wieder zu den Nachladerucklern:

Ich habe mir die Mühe gemacht und und aus vielen Repaints und auch sonst aus vielen Bussen die ganzen PNGs, JPGS und TGAs in DDS konvertiert. Anfangs auch Transparenzen und Scheiben, hab letzteres aber dann doch bei TGA belassen, denn zum Teil wurden hier die Dateien 16 und mehr MB groß im Vergleich zu 1 MB oder wenigen KB, während bei den Repaints selbst meist die Dateien erheblich kleiner wurden (vor allem im Falle von BMPs die zu DXT1-DDS wurden), in EInzelfällen wurden sie einen Tick größer als ursprunglich. Ist aber auch nicht schlimm. in der Summe bliebs gleich und die DDS Daten werden ja komprimiert im Speicher gehalten. Insgesamt gab es auch leichte Besserung beim Nachladen und vor allem seitdem echt keine schwarzen Busse mehr. Übrigens sind die Originaldateien immer noch in den Verzeichnissen der Fahrzeuge und ich habe bisher auch keine einzige Config oder CTI geändert, OMSI zieht sich automatisch vorzugsweise die DDS Texturen, sogar vor BMP.

Mir ist aber aufgefallen, dass anscheinend auch der Bus mit dem man selbst fährt Einfluss auf das Nachladeverhalten hat. Mir ist ja schon klar dass es schwere und leichtere Busse was die Performance angeht gibt, aber ich bin immer davon ausgegangen dass die schweren eben auf die Frameraten drücken und nicht auf das Nachladen. Ich hatte in der gleichen Session bei Fahrt mit dem Citybus i280 schon einige arge Stotterer unterwegs vor allem wieder an den Kachelgrenzen, nach Umstieg dann in einen Solaris bei gleichen OMSI-Settings aber vergleichsweise butterweiche Fahrt. Also eventuell stören manche Scripte das Loading auch, allerdings ist der i280 kein Digitalmonster sondern eher ein alter analoger Bus mit wenig Systemen. Scriptmässig könnten aber die Soundscripts drücken, warum allerdings auf das NAchladen ist mir nicht ganz klar. Bei der Framerate würde ich es verstehen oder solche sekündlichen Stocker wie gewisse DFI-Anzeiger-Scripts verursachen (und keiner sich je deswegen beschwert hat...). Wobei ich die Soundscripts für nicht schwerer als die von Morphy halte.

Ich glaube die Option ist immer da, da man ja in jeder Auflösung skalieren kann. Und Menschen mit Sehschwächen werden je nach Bildschirm vielleicht auch bei 1080p manchmal skalieren wollen auf einem 13" Notebook...

Ich betreibe meinen Bildschrim grundsätzlich mit 2560x1440, hab Skalierung aber global auf 100% eingestellt. Habe aber diese Option trotzdem dort, obwohl ich nicht skaliere.

Zitat von Berlin&Brandenburg

Also bei mir finde ich sie nicht.

Vermutlich braucht man das zweite Fenster und die dort enthaltenen Informationen. Wenn ich nämlich die Vollbildoptimierung bei mir deaktiviere, kann ich in OMSI weder Alt-Menü noch das ESC-Menü aufrufen...

Ich hab die Vollbildoptimierung deaktiviert und die Menüs sind in OMSI da. Da aber OMSI eh kein klassisches Vollbild hat, glaube ich nicht dass die Schaltfläche irgendeinen Unterschied macht.

Zitat von James O'Neill

Das klingt interessant. Magst du dazu vielleicht mal generell ein Tutorial erstellen? Würde sicher viele hier, inkl. mir, interessieren.

Es gibt bei YouTube eins für XPlane, das gilt analog eigentlich auch für OMSI. Da geht es vor allem um die Separierung der Threads auf einzelne Kerne. Hier muss man dann aber im Einzelfall gucken was sinnvoll ist für einen selbst. In meinem Fall macht z.B. Sinn ein Profil anzulegen und die OMSI.exe auf die zweite Hälfte der Kerne zu legen (Threads 8-15, Alle OS-Sachen, Virenscanner und Google Chromes etc auf 0-7 oder gar 0-4 / 0-2 je nach dem...), wobei ich immer noch nicht ganz sicher bin ob nicht gar jeden zweiten ab 8 dann wegen SMT. Dann gibts noch I/O Prioritäten die man festlegen kann, Speicherpriorität, und Prozesspriorität, hat aber meiner Meinung nach kaum bis wenig Auswirkung. Das alles ginge auch ohne Tool, aber wär äußerst mühselig mit dem Taskmanager, gerade für die ganzen im Hintergrund laufenden Prozesse, Hier kann man einfach alle markieren und denen Einstellungen zuweisen.

Hier der Link zum Tutorial:

Die schwarzen Busse sind übrigens doch nicht ganz weg, und ein paar Hänger gabs auch wieder;-D Ich wundere mich trotzdem was da denn passiert dass die OMSI.exe so radikal schrumpft...

OMSI nimmt doch die Auflösung vom Desktop, kann also theoretisch auch in 4K und mehr laufen...

Zitat von Marcel V.

Was mir in den Sinn kommen würde, ist die max. Speicherbedarf der hochauflösenden Texturen auf 8 GB ( 8192MB) hochschrauben oder den Kompatibilitätsmodus von OMSI - falls eine externe .exe angelegt wurde, auf Windows 7 einzustellen

Ein 32 Bit Programm wird alle Speicher zusammengezählt (RAM+Auslagerung+VRAM) nicht mehr als insgesamt 4096 MB nutzen können, auch nicht mit dem 4 GB Patch. Wie der Name schon sagt ermöglicht dieser bis zu 4 GB zu nutzen. Und da müsste man Glück haben, denn die Speicherverwaltung von OMSI ist schon überfordert mit viel weniger. Ich wüsste aber auch keinen Nachteil einer solchen Einstellung in der Praxis, nur bringen wird das nix.

Bei Bahnen jeglicher Art kann es sein dass die generell die Performance drücken, nicht nur dort wo man sie sieht. An vielen orten fällt es nur nicht auf weil die Performance ausreicht. Es scheint auch nicht davon abhängig zu sein wie oft wo eine Bahn fährt, sondern ob überhaupt irgendwann eine fährt. Örtlich sind es dann wiederum die Modelle der Bahnen und dass es Fahrplan-KI ist, also wie bei Bussen.

Möglicherweise hilft es auch den realrail-Eintrag in der Global zu entfernen, dann sollte man aber auch die AI-Liste von Bahnen befreien und dafür sorgen dass keine Bahn-Fahrpläne aktiv sind, in dem Fall also aus dem Fahrplan-Order verschieben.

Ob das grundsätzliche drücken auf die Performance abhängig ist davon ob realrail verwendet wird in der Karte oder nicht kann ich gerade nicht sagen, aber möglicherweise ja.

Die Partikel machen kaum bis garnix aus. Ich finde kann man ruhig bei 1000 lassen und auch für andere Fahrzeuge ankreuzen. Partikel in Reflexionen habe ich noch nicht getestet, aber hier könnte es Unterschiede geben. Einfach bei Regen ausprobieren und an- und ausschalten.

Grundsätzlich ist es so dass Darius zwar mitunter die performantesten KI-PKWs macht, aber seine Busse in der AI leider harte Brocken sind. Bei Problemen würde ich auch testweise andere einsetzen: zum Testen mal Spandau-MANs, auf dauer dann eben schauen was genau man nimmt. Wenn Du Bad Hügelsdorf hast könntest Du für die C2 testweise den dortigen C2 probieren, ich glaube für ihn gibt es auch Hamburger Repaints. Der Volvo ist glaub ich etwas genügsamer, aber sicher auch kein Performance-Wunder. Die Stadtbus-MANs kann man in den AI-Versionen nehmen, ebenso die Stadtbus-Urbinos, was aber beides eher nicht so zu HH passt, zumindest nicht in der Masse. Alters' O530 wäre auch ne Überlegung, aber wenn dann die ungemoddete Fassung, nix Ecomat/Ecolife etc.

Nachbarkacheln auf HH würde ich auf 1 belassen. So schlimm ist es nicht und bringt einiges. Der Öko-Modus mit dem Umschalten funktioniert meiner Meinung nach nicht zufriedenstellend, und kann Dir nach einem Wechsel der Sicht manchmal zurückfallen in mehr Kacheln, obwohl es beim Fahren schon auf 1 zurückgesprungen ist.

Und in einer dicht bebauten Stadt wie HH bei Bedarf maximale Objektentfernung runterschrauben. Das hat erheblichen Einfluss (weil es zählt nicht nur die Sicht nach vorne sondern auch nach hinten und in die Seitenstraßen. Hier liegt viel Einsparpotential was abgerufen werden kann.

Zu guter letzt: in Hamburg scheint mir alles was mit Bahn, Zügen, U-Bahnen etc zu tun hat enormen Einfluss auf die Performance der ganzen Karte zu haben. Das sollte das erste sein was man reduziert. Bin mir nicht sicher ob diese Dinge auf der letzten Fahrplanpriorität liegen sodass man nur eine Stufe runterschalten müsste, kann man sich aber so editieren.

Editier am Besten im Titel den Namen des Busses. "i280" nennt man eigentlich die Citybus i260/i280 Reihe von Bustrainz (Payware). Mich hat der Titel auch etwas irritiert, da ich zufälligerweise gerade auch mit den "Rollbändern" dort kämpfe, aber eben vom i260/i280 ;-D Ich meine dass die Freeware-Ikarusse sich einfach "Ikarus 260/280" nennen ohne das behelfsmässige kleine "i".

Schon bei den Repaints wird das immer durcheinandergewürfelt, und man weiss nie so recht für welche Version genau was ist, manchmal sieht man es erst an der der Ordnerstruktur nach dem Download.

Nachtrag 2:

Dass die Speicherverwaltung von OMSI sagen wir mal seltsam ist war mir ja bekannt. Dass es ohne virtuellen Speicher abschmiert auch (hatte das vor Jahren mal probiert). Gestern aber doch was sonderbares entdeckt: ich bin zur HVZ in Fikcyjny Szczecin gefahren, hatte mir dort nach X10 Vorbild die Verkehrsdichte in Lastrichtung erhöht mit separater AI-Klasse und wollte das ausprobieren. Nun ist vor allem meine Bus-AI da nicht gerade optimal, denn es scheint üblich zu sein für jeden Wagen ein separates Repaint zu machen, da sonst nicht mal die Kennzeichen angezeigt werden. Dann gibt es natürlich keine AI-Versionen der Busse sondern mit Morphy-Sounds und Getrieben versehene Busse, die als Spielerbus toll sind, in der AI allerdings suboptimal, und natürlich PNGs zu hauf. Ein schwarzer Solaris kam also relativ oft vor wenn viel unterwegs war. Ich habe aber während der Fahrt etwas in Process Lasso rumgedoktort (ein Tool welches in jedem wärmstens empfehlen kann, nicht nur für OMSI) und hab spaßeshalber bei OMSI.exe auf "Virtuellen Arbeitssepicher trimmen" geklickt. Eine Funktion die ich nie genutzt habe bisher, da ich das Tool eigentlich nur zum klaren separieren von Prozessen auf einzelne CPU-Kerne nutze, damit Spiel und Rest (OS etc) wirklich getrennt laufen. Ergebnis: OMSI.exe schrumpfte von etwa 1,4 GB auf etwa 150 MB (!), und ich erwartete sofort eigentlich einen Absturz. Aber nix, lief astrein weiter und wuchs dann erneut, aber vielleicht auf nur 600 MB. Irgendwann das Spielchen nochmal wiederholt. Im Spiel selbst nix negatives bemerkt, nur immer mal geguckt im Debug Fenster viele KI-Busse so aktuell rumfahren, es waren knapp 200. In dieser Spielsession kam mir danach kein einziger schwarzer Bus entgegen, völlig unnormal wo ich ja weiss wie suboptimal das eingesetzte Fahrzeugmaterial ist. Noch überraschender war aber dass an den Kachelgrenzen die Nachladeverzögerungen deutlichst geringer waren und eigentlich nur zu spüren waren in den Bereichen wo es vorher auch mal Freezes gab, aber dort war es auch nur noch minimal. Ich kam aus dem Staunen echt nicht raus, zumal ich glaube dass die Größe der Exe sich deshalb reduziert hat, weil das Tool Teile in den virtuellen Arbeitsspeicher verfrachtet hat, oder zumindest in einen Cache im RAM. Aber offenbar hat es Tante OMSI sehr gut getan. Selbst bei OMSI 1 hatte ich noch nie gesehen dass die exe so klein war.

Jetzt beobachte ich das mal längerfristig bevor ich mir wirklich die Mühe mache alle PNGs and TGAs anzugehen, oder es dann halt mache wenn ich richtig viel Zeit habe. Unabhängig davon lege ich jedem ans Herz das besagte Tool mal zu testen, gerade auf Systemen mit deutlich mehr als vier Kernen. Bei Ryzen 8-Kernern der ersten zwei Generationen zum Beispiel kann man so auch vermeiden dass OMSI (und auch Lotus) seine Threads auf beide CCX verteilt, aber alleine die Trennung beim Spielbetrieb bringt einiges. In GTA 5 habe ich so jeden verbliebenen Mikroruckler eliminiert, bei Xplane stabilere Frameraten und in OMSI auch paar FPS rausgekratzt vor allem in Momenten wo das Betriebssystem halt trotzdem meint irgendwas rumwurschteln zu müssen. Vor allem auf guten, vielkernigen Systemen bringts was, könnnte aber auch durch ähnliche Maßnahmen bei kleineren helfen.

Nachtrag:

Also die Große macht echt nix. Hab bei zwei bussen von 4096x1475 auf 4096x2048 hochskalliert, was mir sehr weh tat, aber auf 1024 runter wollte ich dann auch nicht. So viel Pixelverschwendung;-D Problem beim Skallieren war dass mir der Alpha der PNG erstmal flöten ging. Hab das per IrfanView gemacht und war mir nicht sicher welche Einstellung ich brauche beim Abspeichern des Zwischenstandes. Überhaupt sind PNGs mit Transparenzen für mich noch seltsam. Bei TGAs sehe ich in Photoshop zumindest den Alphakanal, bei PNGs kann ich manchmal nur raten. Dann hatte der Bus auf einmal keine Scheiben mehr;-D

Ich bräuchte also ein Tool bei dem ich direkt klipp und klar sehe ob da eine Alpha drin ist oder nicht, auch bei PNGs. DXTbmp hat ja einige Möglichkeiten, aber es skaliert automatisch runter, hätte also ohne zu fragen aus der Textur 4096x1024 gemacht, was ich nicht wollte.

Und dann gibt es ja noch bei den Alphas Unterschiede, ob die nur 1 bittig sind oder mit Abstufungen. Ist mir auch nicht ganz klar wie ich das erkennen soll.

Beim Zielformat würde ich natürlich gerne die kleinste Dateigröße vorziehen, aber da gibt es unterschiede. Ich denke für Häuser etc reicht DXT1 ohne Alpha, bei Bussen wäre es auch für Dinge aus dem Innenraum sinnvoll anstatt stur DXT3 oder DXT5 anzuwenden. Das wichtigste wäre aber die Außentextur: mach ich eigentlich DXT5, aber ist das nötig?

Ich glaube nicht dass dds bevorzugt wird aufgrund der Stellung im Alphabet. Hat man nämlich das gleiche mit bmp und dds, Verweis auf bmp in Modell und Config, nimmt sich OMSI trotzdem die dds. Also offenbar ist es das erste wonach es sucht, danach die anderen Sachen.

Und komischerweise reicht es nicht nur die benötigten Repaints zu bearbeiten. Wenn beim Ausgewählten Busmodell andere Repaints drin sind die aber aktiv nicht genutzt werden weder vom Spieler noch der AI Liste, lädt OMSI diese trotzdem gerne rein. Ich hatte auf Grunddorf einen Bus getestet bei dem ich die Bearbeitungen testen wollte und als ich mir die geladenen Texturen auflisten ließ kamen da Dateien zum Vorschein die garnicht relevant waren.

Zitat von Einsamer_Wolf86

Servus zusammen,

jetzt hab ich mich auch mal getraut Bad Hügelsdorf anzutesten, gleich zu Beginn mal den Linienwechsler 301/316, an nem Werktag um 7:22 ab Hildegardplatz mit dem A40. 3 volle Runden hab ich absolviert und kann mich folgender Passage anschließen:

Zitat von wurstbrot

Der 301 hat genug Fahrgastaufkommen um mit einem Gelenkzug bedient zu werden, da waren es hingegen beim 316 nur maximal 20, 25 Fahrgäste zeitgleich.

Die Ehrenrunde in Malg würde ich weiterhin dem 314 zuschlagen, welcher bei geraden Fahrten (2, 4, 6 etc.) über Malg, und bei ungeraden Fahrten (1, 3, 5 etc.) über den Wanderweg verkehrt. Anschluss vom Hbf kann man herstellen indem der 314 am Klinikum 2 Minuten nach dem 316 fahrt, und Richtung Stadttheater 2 Minuten vor dem 316 am Klinikum ankommt um einen Anschluss an den Hauptbahnhof zu gewährleisten.

Die Steigungen sind hinter Malg zum Schloß hoch auch nicht von schlechten Eltern, da musste ich den Karrn ordentlich treten bis ich dann mal oben angekommen bin, das ist maximalst etwas für einen gut motorisieren Solobus, aber nichts wo ich freiwillig nen Gelenkzug hochjagen würde...

Vor allem find ich ja das alte Schloß echt niedlich Das würd ich auf jeden Fall gegen etwas größeres austauschen dass auch 150 Stellplätze auf dem angrenzenden Parkplatz verdient, wobei das fast schon zu schade ist wenn es gänzlich im Nirvana verschwindet wenn es denn erstzt werden sollte.

Alles anzeigen

Ich beziehe mich nicht auf das Fahrgastaufkommen in OMSI selbst, denn das kann man ja steuern und einstellen wie man lustig ist. Mir geht es bei der Überlegung eher darum ob es zu einer Stadt wie "Bad Hügelsdorf" und den Gegebenheiten dort passt. Es ist und bleibt eine Klein- bis Mittelstadt mit Dörfern drumherum. Jetzt schau Dir mal die Fahrpläne in solchen Gegegenden an und den Fahrzeugeinsatz, auch in Touristengegenden. Sowas wie "Schloß" wird meist nicht mal mit einer einzigen Linie bedient, die Touris werden eher mit Reisebussen geshuttelt, und abends beim Ausgehen werden Taxen genommen und keine Linienbusse. Dennoch würde ich das Schloß mit einer Linie bedienen, nur eben dünner. Und an besonderen Tagen kann man Shuttles fahren lassen ohne Umwege. Ein dünnerer Takt heisst ja nicht weniger Fahrspaß, und komplett auf Gelenkbusse muss man ja auch nicht verzichten.

Die letzten Änderungen sind prima, vor allem die separate parklist und Überarbeitung der Privatauto-AI. Wenns weiterhin an bestimmten Stellen hackt im Laden (der große Kreisel vor dem Hauptbahnhof war ja auch so eine Stelle) könnte man auch hier überlegen zu separieren: für diesen Bereich könnte es helfen nie NormalCars auszuschalten und eine spezielle Klasse einführen, die in der AI List separat wäre und dünner belegt sein kann (oder auch nicht, kann man ja dann anpassen). Das würde auf manchen Systemen enorm dazu beitragen dass sich OMSI nicht verschluckt, ohne an anderen unkritischen Stellen die Vielfalt einzuschränken. Außerhalb der Stadt macht es nämlich überhaupt nix aus wenn einem ganz verschiedene Autos entgegen kommen, selbst aus den Halycon AI-Packs, was super Modelle sind, aber leider in kritischen Bereichen zu den Problemen erheblich beitragen würden.

Zitat von Lµkas

Das Problem beim Größen verändern ist halt auch, dass das Mapping verloren geht - oder man verzerrt die Textur, was Nachbearbeitungen schwieriger macht.

An sich kein Problem, denn gemappt aufs Modell wird sie wieder entzerrt. In Einzelfällen kann es aber tatsächlich problematisch sein. Dummerweise zerhaut mein Konverter jede Textur die mit "krummen" Auflösungen nach DDS exportiert wird. Würde eigentlich auch dazu neigen sie krumm zu belassen, daher geh ich auch lieber eine Stufe rauf um die Auflösung quadratisch zu machen, und runter nur wenn der Unterschied wenige Pixel sind.

Der Unterschied BMP - DDS ist eigentlich nur dass DDS komprimiert ist, und auch komprimiert im Speicher gehalten wird. BMP macht auch keine Probleme, verursacht nur überproportional große Datenmengen beim Laden, was bei den heute üblichen Texturgrößen eine Rolle spielt.

Es ist sogar noch einfacher: Ist eine gleichnamige DDS Datei im Verzeichnis vorhanden, nimmt OMSi diese bevorzugt, egal welche Endung in der Config eingetragen ist, im repaint oder im Modell. Man brauchts nicht mal löschen, außer man möchte den Speicherplatz nicht verschwenden... Sauberer wäre es dennoch wenn direkt DDS genommen werden würde und auch eingetragen. In OMSI 1 hat das zumindest paar Milli/Nanosekündchen ausgemacht und sich in der Masse bemerkbar gemacht. Eventuell erübrigt sich das aber mit Abschaltung des Loggens.

Ich hab ja Tools um sowas zu bearbeiten, kostet halt viel Zeit, da man doch immer gucken muss zum Beispiel ob die Texturen im Quadratischen Format sind. Konvertiere ich also direkt eine PNG mit 2048x1475 bekomme ich eine kaputte Textur. Die muss ich entweder auf 2048x1024 oder 2048x2048 wandeln. Und wie oft übersieht man da einen Alpha-Kanal, weshalb ich bei TGAs sehr vorsichtig bin. Mit viel Mühe geht das aber. Bei so Sachen wie Matrix würde ich mir das dann sparen.

Ähm ich könnte also `Texturen aus den Vehicles in den Textur-Ordner schmeißen wenn sie sich gleichen? Noch nie probiert;-D