Kommentarthread zu "Doppelgelenkbus AGG 300"

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.
  • Meiner (Laien-)Meinung nach sind die Spiegel hier zwar durchaus ein Grund, dass die Performance abnehmen mag, allerdings habe ich zunehmend die Vermutung, dass die Scripts tatsächlich Schuld am "Hüpfen" des AGG sind. Habe mir zu Testzwecken das AddOn wieder nach dem Patch über Steam geholt und habe das ganze einmal unter Rheinhausen getestet (die bekannterweise als relativ performancesparende Karte gilt). Selbst in Randgebieten, ohne dazugeladene AI Busse, fing das Ding an zu "zuckeln", sobald eine Haltestelle über den Drucker weitergeschalten wurde. (das Trampolinhüpfen blieb aus, aber der Bus erfuhr eben einen "Schlag", wie als hätte jemand die Kiste mit dem Hammer von oben getroffen) Soetwas habe ich persönlich so reproduzierbar bei noch keinem anderen Bus vernehmen können, weder beim C2, noch sonst irgendeinem. (lediglich bei sehr niedriger Performance <10 FPS, aber das war hier ja nicht der Fall) In Hamburg 2015 bietet sich mir exakt dasselbe Bild, auch wieder (meiner Beobachtung nach) bedingt durch das Eingreifen des Ticketprinters/IBIS Systems. Der Bus (bezogen auf den AGG) ist mittlerweile zwar bedingt auf einigen Maps fahrbar, aber dort wo ich ihn eigentlich einsetzen wollen würde (e.g. Hamburg, AH-LZ...) ist es mir aufgrund eines drohenden Hüpfkonzertes leider nicht möglich. Interessant ist ebenso, dass der Bus performancemäßig sonst bei mir nicht einmal großartig zu Buche schlägt. Auf der Innovationslinie hatte ich im Bereich des Hauptbahnhofs tatsächlich mit dem AGG teilweise so hohe FPS Zahlen wie mit keinem anderen Bus bisher. Also wie ich schon zu Anfang schrieb scheinen - zumindest bei mir - der ausschlaggebende Grund für jenes extreme Hüpfen in Schlangenlinien reproduzierbar die Scripts zu sein und nicht die Spiegel, Texturgrößen o.a.. (ich schließe aber hierbei nicht aus, dass ich meine Beobachtungen inkorrekt geschlussfolgert habe. Ich bin bei OMSI eher Konsument und Repainter, als jemand der sich mit dem Fahrzeugbau per se auseinandersetzt, also sorry dafür, sollte es der Fall sein)

  • Schon interessant, wie viele Probleme mit der Performance haben. Ich selbst habe auch nur eine GTX660 und ne AMD FX8350 und es reicht vollkommen aus. Allerdings spiele ich ohne Stencil Shadows, denn das sind absolute Framerate-Killer. Bei OMSI empfehle ich so wieso grundsätzlich ohne diese ohnehin verbuggten Schatten zu fahren.

  • Also es muss an den Spiegeln liegen!!


    Die Spiegel kann man doch auskommentieren. Schaumal in die Busdatei, da sind die Einträge für die Reflexionen. Der letzte sollte der Innenspoiegel sein. Diesen einfach auskommentieren (Hochstrich am Zeilenanfang oder TAB-Taste) und damit rausnehmen. Dann suchst du den Reflexionseintrag in der model.cfg und kommentierst für den Innenspiegel ebenfalls die Reflexionszugehörigkeit aus. Damit zeigt der Innenspiegel automatisch nur die gemappte Fläche aus der Textur. Der Innenspiegel ansich kann ja bleiben.


    Du könntest mal so nett sein und einen einfachen Test machen:
    - Stelle den Bus auf einer einfachen kleinen Map (Bsp. Grundorf) und schau, was die FPS durchschnittlich ausgibt.
    - Teste dann mal den GSÜH von iTram, bei dem du auch den linken Spiegel siehst und gleichzeitig den Innenspiegel.
    Dann müßte deine FPS genauso einbrechen. Denn beide Busse sind mit ihren Polygonen sparsam gebaut worden.


    Das tut er übrigens in allen Ansichten inkl. F3. Das läßt mich vermuten, daß nicht der Spiegel der Übeltäter ist, da der ja in der F3 Ansicht irrelevant ist?!? Da lasse ich mich aber gerne eines besseren belehren.


    Das erkennst du wenn du deine Spiegel anschaust. In der Außenansich siehst du die Grund-Textur der Spiegel, aber keine Reflexionen. Egal bei welchem Bus.

  • Tatra danke für die ganzen Überlegungen!
    Könntest du mir genau sagen, was man beim innenspiegel tun muss und wo? Ich nutze den so gut wie nie und er raubt dem linken Spiegel die Performance.
    Gruß Michael

  • Schon interessant, wie viele Probleme mit der Performance haben. Ich selbst habe auch nur eine GTX660 und ne AMD FX8350 und es reicht vollkommen aus. Allerdings spiele ich ohne Stencil Shadows, denn das sind absolute Framerate-Killer. Bei OMSI empfehle ich so wieso grundsätzlich ohne diese ohnehin verbuggten Schatten zu fahren.


    Was meinst du mit Stencil Shadows ?


    Gruß

  • In den Grafikoptionen kann man unter Stencil Buffer die Schatten deaktivieren.


    Michael: Bitte lies auch meine Antworten, damit ich nicht alles mehrfach erklären muss: Der Spiegel wird nur gerendert, wenn er im Sichtfeld ist. Also wenn ihr in der Fahrersicht geradeaus fahrt, nur der linke Außenspiegel.
    Die Spiegel auszukommentieren, ist übrigens überflüssig, da man diese in den OMSI-Optionen auf ökonomisch oder komplett aus stellen kann.



    Bei den Stringabfragen der Hofdatei. Da ist wieder das übliche Chaos drin. Blöderweise fragt Omsi aber die anderen Strings mit ab und erstellt dann die richtige Anzeige. Also auch auf der Hamburger Map mit der Hamburger Hofdatei, werden blöderweise die Strings 1-4 abgefragt. Bei dem Van Hool hast du scheinbar auf den letzten String verzichtet, weil hier nur die Strings 0-3 oder (auf Fremd-Maps) 1-3 abgefragt werden.


    Deine Ausführungen verstehe ich nicht, da sie technisch nicht nachvollziehbar sind. Die Abfragen im Matrixskript sind in if-Schleifen gestaffelt, sodass die jeweils nicht zutreffenden Inhalte nicht abgefragt werden. So wird z.B. erst geprüft, ob es sich um Hamburg handelt, dann, ob Großschrift eingetragen ist. Ist dies nicht der Fall, werden die folgenden Schritte übersprungen.


    Zur Performance von Skripten hatte ich ja bereits einiges geschrieben. Diese sind im Gegensatz zu Systemmakros und Texttexturen unkritisch. Problematisch sind also z.B. aufwendige moderne Cockpits mit Touchscreen-Druckern, VDV-Display usw., da deren funktionsfähige Umsetzung nicht so effektiv möglich ist, wie z.B. ein alter Bus mit Analoganzeigen. Grund ist hierfür u.a. die Anzahl der zu aktualisierenden Texttexturen und die Komplexität der model.cfg.

  • Hi Darius, vielleicht um etwas Licht in´s Dunkel zu bringen: wie hast Du es geschafft, die Performance im Patch zu verbessern? Vielleicht kriegen wir dann einige Ursachen raus bzw. wissen, was evtl. die Gründe hierfür sind.
    In meinem Beispiel war der Solo sogar nicht spielbar, bis er gepatcht wurde. Nun geht er eigentlich ganz gut (von ein paar Aufstoßern mal abgesehen). Es muß ja Unterschiede zwischen Deinem C2Ü zum A330 geben. Den Citaro C2, den C2G oder den Ü kann ich problemlos nachts auf Rheinhausen fahren, der A330 solo fährt phasenweise "unrund". Hat dieser so viel mehr Funktionen als die C2-Familie oder sind die Texturen um so viel größer?


    Ich fahre Omsi auf recht niedrigen Einstellungen, von daher gibt es eigentlich so gut wie keine "Hüpfprobleme", weder bei den MAN-Stadtbussen noch bei O305ern oder O405ern. Dass der AGG ziemlich frisst, ist mir klar, der C2-Doppelgelenker funktioniert hingegen bei mir aber (mit seinen Einschränkungen

    ;)

    ).


    Das mit den Spiegeln kann ich ebenfalls bestätigen. Bei dem AGG muß man sie nutzen und sobald ich einen Außenspiegel in´s Blickfeld kriegen muß, ist Gummiball angesagt (auch wenn KI-Fahrzeuge nachgeladen werden).


    Klar, über Einstellungen kann man einiges drehen und die Prüfung von irgendwelchen im Hintergrund laufenden Programmen ist bestimmt nicht schlecht, wenn aber Omsi ohne Nutzung der Van Hool´s problemlos läuft, mit diesen aber Probleme bereitet (die massiv sind), wird diese mit den angesprochenen Maßnahmen nicht lösbar sein. Die Ursache ist daher klar, nun muß man nur versuchen, etwaige Fehlerquellen auszumerzen.


    Vielleicht kriegen wir ja eine Lösung hin. Ist doch ziemlicher Quark, wenn Dein (gut gelungenes) Addon aufgrund der Kritik der Erfolg fehlen wird. Je schneller wir da was hinkriegen, desto besser auch für Dich.

  • Darius, aber in den Videos, die ich bislang gesehen habe, bewegt sich auch der Hintergrund im großen Innenspiegel. Es würde mich sehr wundern, wenn ich mich da irre.
    Mein Download ist noch nicht freigeschaltet, aber ich meine es in den Videos so zu sehen!


    https://youtu.be/LaUSyrl7Qg8


    Hier ist definitiv der Innenspiegel mitgeladen!
    Gruß Michael

  • Der Spiegel wird nur gerendert, wenn er im Sichtfeld ist. Also wenn ihr in der Fahrersicht geradeaus fahrt, nur der linke Außenspiegel.


    Darf ich dir auch da widersprechen? Bei mir wird bei der Sicht geradeaus, auch der Innenspiegel komplett gerendert. Ich sehe die Leute einsteigen. Ohne das ich die Sicht zum Spiegel hin verändere.
    Eigentlich nutzt man doch den Befehl [add_camera_reflection] damit der Spiegel nur rendert, wenn man direkt reinschaut (siehe MAN SD). Du hast im Van Hool aber alle Spiegelsichten mit _2 gesetzt und dazu die Sichtwinkel geschrieben. Den Linken und rechten Außenspiegel auf 20 cm und den Innenspiegel auf 50cm. Während der Fahrt werden mir aber im VanHool beide Spiegel (also links und innen) sauber gerendert. Und meine Spiegeleinstellungen stehen auf ökonomisch ... Verstehe mich nicht falsch, ich habe keine Probleme mit der Performance (bei mir schaucket der ganze Bus nur). Und ich fahre Omsi mit recht hohen Einstellungen, weil mir viel Verkehr recht wichtig ist.


    Michael, versuche dein Glück, aber lösche bitte nicht's. Nur auskommentieren.
    - In der Busdatei "AGG300_main.bus" den gesamten Abschnitt unter 2.Innenspiegel mit jeweils einen Tab am Zeilenanfang belegen. Siehe weitere Spiegel-/Kameraeinstellungen.
    - in der Model.cfg brauchst du nichts ändern.


    Wahlweise kannst du auch in der Bus-Datei den letzten Wert verringern. Also statt 0.5 mal testweise auf 0.05 setzen. Damit sollte der Innenspiegel nichtmehr rendern, solange du nicht direkt reinschaust. Der Innenraum wird aber trotzdem angezeigt. Die andere Variante ist beim Befehl in der Busdatei das _2 zu entfernen.


    Vielleicht kriegen wir ja eine Lösung hin.


    Das wäre ja mal ne richtig interessante Sache. Einerseits lehrreich für uns und Hilfe für Darius. Und damit ein Gewinn für alle.

  • Also mit den Spiegeln hat das Gewackel nichts zu tun. Und, wenn ich mich recht entsinne, waren beim letzten Kandidaten der so vor sich hin wackelte, allerdings nicht so wie der Doppelgelenkbus auch im Stand, die Bremsen-Skripte für die Hüpferei hauptverantwortlich. Das Problem muß auch in den Skripten zu finden sein, denn egal welchen Bus man verwendet, sie hüpfen alle, wenn eine entsprechende Auslastung der Map, falsches Wetter und physikalische Inanspruchnahme zusammen kommen. Ich habe mir auch probehalber einen AG300 zusammengestellt, denn, wenn es nur daran liegt, daß der XXL performencelastiger wäre, würde sich das Problem ja erledigt haben. Erledigt ist bei der kurzen Gelenkvariante tatsächlich aber nur das Wackeln im Stand. Die Hüpferei geht auch los, sobald der Verkehr und die Bebauung dichter werden. Gleiches gilt auch für den A330.

  • Guten Morgen,


    danke für das Addon.
    Das Fahrzeug lässt sich wunderbar auf Hamburg fahren, die FPS bewegen sich zwischen guten 70 FPS am U-Alsterdorf und zwischen 30-50 FPS am Rathausmarkt und Hbf.

  • Ich kann mir aber auch vorstellen, das hier beim letzten OMSI Update an sich etwas an der Gelenkphysik "verschlimmbesserter" wurde, kann aber auch nur Zufall sein... Mir ist eben auch beim MAN Stadtbus aufgefallen, wenn ich auf dem Stellplatz Adenauerallee stehe, das sich der Nachläufer langsam aber sicher nach Rechts verschiebt...


    Bei mir läuft allerdings gerade ne Steamprüfung, weil ich seit einem Absturz eben beim Start die Fehlermeldung "Ungültiges Argument zum Codieren des Datums" bekomme und die Logfile unauffällig ist.

    8|
  • Dass das Hüpfen mit der Gelenkphysk zusammenhängt könnte ich mir auch gut vorstellen, ich konnte dazu gerade eben folgendes beobachten:
    Ich fuhr in Gehrten auf der Linie 1 von Gehrten ICE Ri. Hallenberg, an der Hst. Angerplatz (der ersten Hst. mit Kopfsteinpflaster) begann der Bus beim Einfahren in die Hst. zu hüpfen. Nach der Ausfahrt aus der Hst. gabs keine Probleme mehr. Offenbar verträgt die Physik die kleinen Bodenwellen des Kopfsteinpflasters nicht bzw. kann diese nicht korrekt verarbeiten...

  • Ich habe mal an den Einstellungen geschraubt: den Texturspeicher auf 2.000 MB gesetzt, eine Kachel Sichtweite. Den Solo auf Rheinhausen Hbf nachts gesetzt --> 43+ fps. In den Bus eingestiegen, alles eingeschaltet, Motor gestartet--> 24 - 28 fps. Losgefahren --> 21-24 fps, hinter der Haltestelle Hauptbahnhof --> 11-14 fps Hüpforgie, -30 fps auf 100 m. Das ohne ein KI-Fahrzeug in der Nähe ist.


    Den AGG konnte ich auch fahren (bis zum Domshof), dann ging es auf's Pflaster und das war's wieder.

  • Ich habe mir das Addon jetzt nach dem 1. Patch auch mal zugelegt und eine erste Runde auf der Innovationslinie 109 gedreht. Zur Performance muss ich sagen, dass es auf meinem Rechner recht gut lief. Ich habe die Stencil-Buffer-Effekte vorab deaktiviert, weil sie schon bei normalen Bussen auf der Map Probleme machen. Einen Hüpfer machte der Bus nur ein einziges Mal am Anfang bei der Anfahrt zur Starthaltestelle am Hbf. Ich muss sagen ich bin überrascht, wie gut er lief. Natürlich bin ich tagsüber bei Standardwetter (Sonne, 15°C, keine Wolken, kein Niederschlag) unterwegs gewesen, bei anderen Bedingungen kann es wieder anders aussehen. Meine Einstellungen sind allgemein eher hoch.
    Das seitliche Gewackel ist mir nur einmal an der Haltestelle Stephansplatz bei meiner Rückfahrt Richtung Hauptbahnhof aufgefallen. Da geht es ja auf den besonders performancekritischen Gänsemarkt zu, ich schiebe es also mal darauf.
    Am Jungfernstieg wurde dann der Touchscreen weiß und es traten zunehmend weiße Objekte auf, bis sich hinter dem Gerhart-Hauptmann-Platz OMSI verabschiedete. Da war wohl wieder zu wenig Speicher übrig. Mit den normalen Gelenkbussen reicht er aus, aber der AGG300 braucht offenbar noch etwas mehr. Das kann man dem Addon jedoch nicht unbedingt anlasten.


    Ein paar Kritikpunkte habe ich aber:

    • Der schwerwiegendste betrifft das Fahrverhalten. Mich wundert es etwas, dass das hier kaum ein Thema war. Der AGG300 hat nach meinen Informationen die Eigenschaft, dass die Nachläufer ziemlich präzise der Spur des Vorderwagens folgen. Daher soll er lt. Aussage eines Aachener Busfahrers sogar einfacher um Kurven zu bewegen sein als ein normaler Gelenkbus. Hier ist das nicht gegeben. Ich habe gleich zu Beginn bei der Ausfahrt aus dem Überliegeplatz deswegen die Ampel mitgenommen und später nochmal das ein oder andere Objekt. Das sollte unbedingt nachgebessert werden, weil das Fahrverhalten doch ein Kernstück der Simulation darstellt. Jemand erwähnte hier ja schon einmal, dass die Achsen nicht an den Stellen definiert seien, wo sie sich optisch befinden. Das würde es natürlich erklären.
    • Beim Runterschalten in einen bestimmten Gang macht das Getriebe einen heftigen Ruck. Das ist mir schon bei den 3Gen-Bussen, jedenfalls beim O405GN2, negativ aufgefallen. So verhält sich das Getriebe ganz sicher nicht, weil der Fahrkomfort damit gegen Null geht.
    • Die schwebende letzte Achse wurde ja schon erwähnt. Ist auch nach dem Update noch vorhanden und stört auch den optischen Eindruck.


    Insgesamt ein gelungenes Addon, wenn die Fehler mal behoben sind. Das Modell gefällt mir sehr gut und die Sounds haben mich positiv überrascht! In den Vorabvideos hatte ich noch den Eindruck, sie würden völlig daneben liegen.


    Bei OMSI empfehle ich so wieso grundsätzlich ohne diese ohnehin verbuggten Schatten zu fahren.


    Hierzu stelle ich fest, dass die Fehler meistens bei den Objektkonstrukteuren liegen. Kein Wunder, wenn niemand mit Schatten testet. Jüngste Beispiele: Scania CityWide, LC von V3D und die Aachener Citaros haben alle drei denselben Fehler bei der Schattendarstellung in der Innenansicht. Beliebt sind auch die "unendlichen" Schatten, die von bestimmten Hinweisschildern verursacht werden, welche auf so ziemlich jeder Freeware-Map stehen. Liegt auch nicht an OMSI, sondern bekommt man bei einer fehlerhaften model.cfg.


    Edit: Eine Sache hab ich noch vergessen. Wenn ich den AGG300 in der Busauswahl wähle (also nur aus der Liste auswähle), verabschiedet sich bei mir anscheinend immer das Direct3D-Device. Jedenfalls wird der Hintergrund schwarz und ich sehe nur noch das Auswahlfenster. Nach Klick auf OK ist die 3D-Ansicht wieder da, aber die rote Schrift (Statuszeile) wird in OMSI nicht mehr angezeigt. Strg-Alt-Entf und dann Abbrechen bringt sie wieder zurück, jedoch nimmt OMSI dann für einige Zeit nicht mehr die Tastenkommandos (P für Pause) entgegen. So war es nicht nur bei Hamburg, sondern auch auf Grundorf, wo die Auslastung ja eigentlich noch in Ordnung sein sollte.
    Konnte das jemand anderer schon beobachten?

  • Zu Deinem Nachtrag: Habe ich auch desöfteren. Da ich allerdings selten mit dem Busauswahl-Menü arbeite, habe ich bisher nicht an einen Zusammenhang damit gedacht, weil ich habe es auf allen Maps und bei unterschiedlichen Bussen. Meist nachdem die Map auch schon eine ganze Weile gelaufen ist. Aber ein Zusammenhang mit dem Menü fällt mir jetzt auch auf, denn zuweilen kommt man auf das Menü durch einen versehentlichen Fehlklick und dann kann ich die rote Schrift auch nicht mehr sehen (ich probiere das dann beim nächsten Mal mit Deiner Methode, wenn es sich wiederherstellen läßt, umso besser).

  • Ich hätte noch ein kleinen Fehler zu Melden


    Das sind die Lichtpunkte (Lichtquellen) der Innenleuchten, die da etwas durchscheinen. Hängt man diese zu tief, beleuchten diese die Fahrzeugdecke von Innen. Was bei den Strahlern etwas unreal wirkt. Hängt man diese zu hoch, sieht man das was du siehst. Wenn die Fahrzeugedecke bis zum Dach (der Zwischenraum) zu gering ist, wird es schwer das zu berichtigen.