Unerklärliche Abstürze in LokSim

    lukash  JakobF  KlausN


    Hallöle.


    Ich habe noch ein wenig weiter getestet:


    Auch wenn in den ersten 17 Km keine Signale von Klaus aufgestellt sind, und diese erst danach kommen, wirken sich diese negativ auf die Framerate vom Start ab aus.

    Ich habe gestestet von Frankfurt Hauptbahnhof über Frankfurt Stadion nach Goddlau.

    1. Versuch Grüne Welle, auf den ersten 17 Km waren keine Signale von Klaus aufgestellt, erst danach kamen sie. Negative Auswirkung auf die Framerate ab Startpunkt.

    2. Versuch Grüne Welle,die 2 Module mit den Signalen von Klaus, welche nach den 17 Km kamen abgeschnitten, Erolg, Die Framerate war hervorragend gut.


    Gruß

    Martin

    lukash  JakobF  KlausN


    Hallöle


    Heute habe einen neuen Test gefahren. Ich habe das "Mehrabschnittssignal_720.l3dgrp" genommen und habe alle .dae Objekte durch ein .l3dobj ersetzt. Dieses Signal hat dann alle anderen Signale von Klaus in der Strecke ersetzt.


    Herausgekommen ist folgendes:


    Eine hervorragende Framerate, die sich gegenüber der Rate mit mit den nicht umgebauten Signalen verdreifacht hat und im Normalbereich liegt.

    Somit handelt es sich wohl um die .dae Objekte, mit denen Loksim nicht umgehen kann.


    Dieses war ja auch schon der grund, warum ich aus der Schmalspurstrecke die .dae Menschen rausgenommen habe.


    Gruß

    Martin

    Hallo,

    wie gesagt, eine Teststrecke die nur aus Signalen besteht wäre sehr hilfreich für uns. Zumindest würde es Analyse wohl um einiges schneller gehen. Bevor wir das nicht gemacht haben, würde ich mir sagen trauen woran das ganze liegt :)


    Was man auch probieren könnte: Loksim3D mit /renderstats:1 starten, also zb  .\Loksim3D.exe /renderstats:1

    Damit könnte man grob Unterschiede in der Komplexität der 3D Darstellung sehen (es werden zusätzlich zu den fps die Anzahl der Draw-Calls und gezeichnete Dreiecke angezeigt)


    lg

    Lukas

    Hallo,


    dank Martins Hinweis auf die Variablen bin ich jetzt auch weiter gekommen. Zuerst habe ich versucht, die Strecke noch mal mehr zu optimieren. Hat auch geklappt, die Bildrate ging auf der Strecke um etwa 10 fps rauf. Die Überraschung kam in Köln Hbf: Wo sonst der Absturz kam lief die Simulation mit 1 bis 2 fps ohne Absturz weiter.



    Das hatte den Vorteil, dass ich mich besser umsehen konnte und da kam die Erinnerung an Martins Verdacht zu den Variablen. Es gibt auf den Bahnsteigen etliche Uhren mit Echtzeitanzeige und das führte schon nach der Einführung dieser Möglichkeit zu Problemen mit der Bildrate, wenn zu viele dieser Uhren eingebaut wurden.

    Nach dem Halt musste ich doch noch die Videoaufzeichnung starten, die Himmelsdarstellung wechselte im Sekundentakt zwischen normal und schwarz.



    Jedenfalls scheinen wirklich nur Unzulänglichkeiten an den Strecken die Ursache für die Abstürze zu sein, nicht das Loksimprogramm.


    Gruß

    Gerd

    Ein Kluger bemerkt alles. Ein Dummer macht über alles eine Bemerkung. Heinrich Heine

    lukash  JakobF  KlausN


    Hallo Lukas.


    Die Teststrecke hat Jakob.


    Ich habe mal mit meiner Frankfurter Strecke getestet:


    1. Alles mit den Signalen von Klaus, Grüne Welle

    FPS 10,75 Draw Calls 6786 Triangles 102960


    2. Alles mit den Signalen von Klaus, Alles geht schief

    FPS 24,75 Draw Calls 6623 Triangles 99242


    3. Umgebautes Signal von Klaus, .dae Objekte mit .l3d Objekte ersetzt, Grüne Welle

    FPS 29,71 Draw Calls 6364 Triangles 77876


    Ich hoffe ich konnte helfen. interessant ist dabei, wieviel Dreiecke weniger dargestellt werden, nachdem die .dae Objekte raus sind.


    Gruß

    Martin

    Moin,

    ich saß bisher nicht wieder am Rechner.

    Es ist aber nur ein Gleis ohne Landschaft, und die Signaleinträge lassen sich mithilfe eines Texteditors schnell kopieren. Also ich kann nacher gern mal versuchen euch das zu schicken, sollte aber nicht an mir scheitern.

    Zitat von JakobF

    Es ist aber nur ein Gleis ohne Landschaft,

    Genau das ist das gute ;) Wenn Du mit dieser Strecke schon Unterschiede zw. grüner Welle und "nicht grüner Welle" feststellen kannst, dann ist das genau das was wir brauchen. Sind zuviele andere Objekte etc darauf, dann ist es viel umständlicher für uns


    Und auch wenn man glaubt so etwas lässt sich schnell nachbauen: Ja, wenn man regelmäßig an etwas baut und die verwendeten Signale halbwegs im Kopf hat. Ich baue aber so gut wie nie (ernsthaft) irgendwelche Strecken, oder Fahrpläne ;) Da hilft es ungemein, wenn man auf etwas Fertiges zurückgreifen kann, wo das Problem auftritt :)


    lg und Danke,

    Lukas

    Wegen den Triangles bei Dae Objekten.

    Eventuell lohnt sich mal ein Blick auf den Detailgrad der Bauteile von Klaus.
    Natürlich sind da mehr Dreiecke vorhanden, das wäre bei einem Objekt aus dem Editor mit dem selben Detailgrad nicht anders.
    Es würde sich eventuell mal lohnen ein solches Objekt mit "Loksimedit -convert Quelle Ziel" zu konvertieren.
    Damit man erstmal sieht, was Loksim leisten muss um das darzustellen.

    Sicherlich wird die assimp Schnittstelle nicht der Performance günstigste Weg sein, derartige Dateien zu integrieren.


    Ich hab mal einen Zylinder als Dae, als konvertiertes und als mit dem Objektcreator erstelltes einfaches Objekt auf eine jeweilige Strecke gestellt.
    Muß ich dann mal testen in wie weit es da Unterschiede gibt.

    ofenrohrtest.zip



    Gruß André

    Martin noch mal damit auch du Sachlich verstehts wo der Unterschied einer DAE Datei zu einer L3dobj Datei besteht.

    Loksim macht bei einer solchen Datei aus einem Würfel den du mit 4 Punkten und 6 Flächen erstellst das hier..


    Eventuell kannst du ja jetzt nachvollziehen warum es kein Wunder ist, das Loksim bei Dae Dateien mehr Dreiecke braucht.
    Würde aber verlangen das du deine Persönlichen Differenzen mit mir mal da lässt wo sie hingehören. Nämlich raus aus diesem Bereich.

    Denn dieser Beitrag bezog sich auf diesen Satz von dir....

    Zitat
    Ich hoffe ich konnte helfen. interessant ist dabei, wieviel Dreiecke weniger dargestellt werden, nachdem die .dae Objekte raus sind.

    Interessant ist jedenfalls das es plötzlich nicht mehr interessant ist wenn ich sachlich etwas dazu schreibe...

    Gruß André

    Erst einmal meinen Dank an Jakob für die Teststrecken, ich habe sie mir nur mit einer LZB und Hektometertafeln ergänzt. Sie haben mir jetzt mehr Durchblick gebracht.


    Ein Blick in die Loksimdoku hilft weiter:


    Sichtweite
    Entfernung, bis zu der die Darstellung der Objekte erfolgt
    Sichtweite Berge
    Entfernung, bis zu der die Darstellung der Landschaft und weit sichtbarer Objekte erfolgt


    Dazu noch ein Rückblick auf die frühere Zeit der Loksimentwicklung: Es wurde immer wieder bemängelt, dass die Berechnungen der Objekte durch die CPU und nicht durch die Grafikkarte erfolgt. Das dürfte doch auch heute noch so sein und erklärt das Dilemma mit den Variablen bei den Signalen von Klaus. Die innerhalb der Sichtweiteneinstellungen liegenden Variablen werden anscheinend ständig berechnet und belasten die CPU stark. Bei der Strecke mit den Signalen im Abstand von 100 m liegt die Bildrate bei mir nach dem Berechnen der Landschaft bei 30 fps. Schalten die Signale auf grün durch sinkt sie auf konstant 25 fps. Jetzt kam mir die Idee, nicht zur Abfahrzeit loszufahren und mal zu warten; könnte ja sein, dass mal alles berechnet ist und die CPU wieder frei wird. Typischer Fall von "Denkste!", da kann man ewig stehen und warten. Den Zugkraftsteller der AFB bediene ich normalerweise mit dem Mausrad, während der Variablenberechnung reagiert das Programm nur auf Tastatureingaben und nicht auf das Rad. Und während der Fahrt kommt die Überraschung: Die Bildrate steigt langsam an und erreicht nach knapp 3 km der Fahrt die 30 fps, die auch bis zum Ende stabil stehenbleiben.



    Anscheinend hat das Programm gemerkt, dass durch die Verwendung der selben Signale immer die gleichen Variablen kommen und sich darauf einstellen können. Bei Verwendung verschiedener Signale würde die Sache wohl anders aussehen.


    Ein anderes Beispiel von der erwähnten Strecke Frankfurt - Köln. Ich starte in Frankfurt Flughafen, die Landschaft ist berechnet, die Bildrate stabil. Plötzlich geht sie immer weiter runter, wie kann das sein? Dann geht sie wieder langsam auf den Normalwert hoch und um die Ecke kommt der Versuchs-ICE von Ulrich zur Darstellung bewegter Gegenzüge. Er ruckelt sich in den Bahnhof rein, meine Bildrate hat aber wieder den stabilen Anfangswert. Mit dem Sichtbarwerden des Zuges wurde die Berechnung also von der CPU an die Grafikkarte übergeben, aber auch die kam wohl mit dem Problem der Variablen nicht klar, der Zug fuhr nur ruckweise ein. Es mag zwar auch um die Berechnung von Dreiecken in der Grafikkarte gehen, das Ergebnis sehe ich ja an Ulrichs variablengesteuertem ICE und dürfte eine andere Baustelle sein.


    Ich sehe das mit den Variablen jetzt so:

    Wird im ZZA eine bestimmte Anzeige gewünscht, so wird sie einmalig aus dem Fahrplan berechnet und unveränderlich dargestellt, keine Auswirkungen auf die Simulation. Bei den Echtzeituhren sieht das schon anders aus, eine größere Anzahl derselben in einem Bahnhof drückt durch ständige Variablenberechnungen die Bildrate. Bei der Strecke mit dem Signalabstand von 1000 m läuft die Fahrt wegen der Seltenheit der Signalobjekte bei mir vom Anfang bis zum Ende konstant mit 30 fps.


    Man kann Klaus N. für das Experiment mit den universal einsetzbaren Signalen dankbar sein, für den praktischen Einsatz sind sie leider nur mit Einschränkungen nutzbar. Das ganze Variablenwesen im Loksim scheint also nur für einmalige Berechnungen und konstante Darstellungen sinnvoll zu sein.


    Schönen Sonntag

    Gerd

    Ein Kluger bemerkt alles. Ein Dummer macht über alles eine Bemerkung. Heinrich Heine

    2 Mal editiert, zuletzt von Nemo ()

    Hallo zusammen.

    Danke an Nemo und MartinF für eure zahlreichen Tests. Wir haben jetzt nachgewiesen, dass die Variablensteuerung ein Problem ist. Ursprünglich wollte der Themenverfasser aber wissen, wie die Abstürze zustande kommen. Jetzt bleibt halt die Frage: Sind von diesen Abstürzen nur Strecken betroffen, die mit rechenintensive Signalen ausgestattet sind? Dann wäre es ja eine Idee, auf eben jenen Strecken die Signale komplett (mittels Texteditor) zu entfernen und bis zum Umfallen zu Testen.


    Lg, Jakob

    Moin,


    ich hab den Thread bisher passiv verfolgt, da ich durch andere Themen derzeit schon ausgelastet war und noch bin. und finde die Ergebnisse interessant. Bei der Variablensteuerung gibt es im Objekteditor eine Option, mit der man einstellen kann, ob die Berechnung der Variablen weiterhin mit jedem Frame erfolgen soll, wenn sich das Objekt in Sichtweite befindet.

    Dass die Berechnung für Objekte, die ihren Zustand ändern, notwendig ist, ist klar. Bei den Signalen ist das nicht der Fall (Dinge wie Mastschilder oder die Ausstattung mit Zusatzsignalen ändern sich ja nicht). Daher ist diese Option bei meinen Signalen in allen Objekten aktiviert. Was mit Euren Tests aus meiner Sicht auch bewiesen wurde, ist, dass diese Option offensichtlich unwirksam ist, was den Stopp der Berechnung bei Sichtbarwerden des Objekts angeht. Diese Befürchtung hatte ich schon länger. Wenn das Programm, wie bei den Objekten eingestellt, die Berechnungen nicht mehr durchführen würde, dürfte der Einfluss auf die Framerate deutlich geringer ausfallen.


    Möglich ist natürlich auch, dass die Berechnung der Objekte, die noch nicht in Sichtweite sind, permanent erfolgt. Das war m.W. aber auch nicht beabsichtigt. Die Berechnung soll bei aktivierter Option nur einmalig erfolgen - wenn das Objekt die Sichtbarkeitsgrenze erreicht.


    Gruß, Klaus

    Hallo


    Auch ich habe den Beitrag bisher nur passiv verfolgt und mir "Sorgen" um die Signalausstattung (weil Signale und Signalteile von Klaus benutzt werden) beim Bau der ETB (Ermstalbahn) gemacht.


    Allerdings scheine ich potente Hardware zu besitzen, denn bisher ist mir kein Simulationsabbruch bei keiner befahrenen Strecke wiederfahren, noch konnte ich ein "reinruckeln" nach Köln Hbf beobachten, selbst wenn ich in FFM Hbf gestartet und über die Rennbahn gallopiert bin.

    Das die Framerate eventuell stark runtergeht, kann ich dort momentan noch nicht sagen, weil ich sie noch nicht aktiv beobachten habe seit Eröffnung dieses Beitrags.


    Somit scheint auch die verwendete Hardware an "Herausforderungen" und Abstürzen während einer Simulatorfahrt beteiligt zu sein, weil auf der Teststrecke "Versuch_Signale_1000" von JakobF sogar nach einiger Zeit die Framerate bei mir hochgeht, statt geringer zu werden, siehe hier nach dem passieren etlicher Kombisignale:


    Meine Simulationsoptionen sehen so dazu aus:

    Und kurz vorm Ende bei einer weiteren Fahrt mit anderen Wetterbedingungen:


    Aus diesen Tests würde ich sagen, dass das hier nicht zutrifft:

    Zitat von KlausN

    dass diese Option offensichtlich unwirksam ist, was den Stopp der Berechnung bei Sichtbarwerden des Objekts angeht.

    Aber? :/


    Grüße Andre

    Hallo Jakob,


    dann noch mal zum Anfang zurück.

    Zitat von JakobF

    Jetzt bleibt halt die Frage: Sind von diesen Abstürzen nur Strecken betroffen, die mit rechenintensive Signalen ausgestattet sind?

    Die von mir zum Testen genutzte Strecke Frankfurt - Köln hat noch keine Signale von Klaus. Die Abstürze kamen mitten auf der Strecke und bei der Einfahrt Köln, allerdings nur mit den Einstellungsoptionen des Programms. Da ich einen Uraltrechner nutze und aus diesem möglichst noch das Beste rausholen möchte, habe ich endlich mal die Software des Chipherstellers AMD installiert und eingerichtet, seitdem blieben die Abstürze aus.


    Verblüfft hat mich die Anzahl der Bäume auf der Strecke ohne Signale, 100000 Objekte auf 10 km Streckenlänge. Da auch diese alle vom gleichen Typ sind, ist die Berechnung noch nicht so umfangreich, trotzdem erreichte ich keine höhere Bildrate als 17 fps. Natürlich habe ich dann mal in die Strecke reingeschaut, die Objekte wurden nur in der normalen Sichtweite eingelesen und dargestellt. Also habe ich alle Objekte auf "weit sichtbar" eingestellt und die Fahrt wiederholt. Jetzt kam die "Sichtweite Berge" für die Berechnung hinzu und die Bildrate sank auf 15 fps. Die Abstürze auf der Köln - Frankfurt dürften also bei der Strecke, und bei der aus gleicher Quelle stammenden anderen, aus der sehr großen Anzahl verbauter Objekte die zur gleichen Zeit berechnet werden müssen, resultieren. Da dürften wohl auch die moderneren Rechner an ihre Grenzen gestoßen sein.


    Den gleichen Darstellungseffekt der Bäume als Sichtblende auf der Strecke ohne Signale erreiche ich nun auch mit 20000 Bäumen, alle auf "weit sichtbar" gesetzt. Und die Bildrate geht dementsprechend auf die bei mir optimalen 30 fps hoch.



    Neben den eingestellten Sichtweiten sind eben auch die Anzahl der gleichzeitig zu berechnenden Objekte relevant für die Bildrate, mit viel Liebe reich mit Objekten ausgestattete Strecken sind also mitunter eine starke Bremse.


    #Allgemein: Mich hat noch dieser Text in der Loksimdoku zu Versuchen angeregt.



    Bei einem Standbild im Bahnhof zeigte sich kein Unterschied zwischen der Einstellung auf 512 und meiner bevorzugten auf 4096. Während der Fahrt sank die Bildrate an den gleichen Stellen bei der Einstellung auf 512 mitunter um ein paar fps bei gleicher Qualität ab, mein Rechner kann das wohl jetzt selbst ausgleichen.


    Gruß

    Gerd

    Ein Kluger bemerkt alles. Ein Dummer macht über alles eine Bemerkung. Heinrich Heine

    Hallo Gerd,

    Zitat von Nemo

    Bei einem Standbild im Bahnhof zeigte sich kein Unterschied zwischen der Einstellung auf 512 und meiner bevorzugten auf 4096. Während der Fahrt sank die Bildrate an den gleichen Stellen bei der Einstellung auf 512 mitunter um ein paar fps bei gleicher Qualität ab, mein Rechner kann das wohl jetzt selbst ausgleichen.

    Dabei ist auch relevant, welche Kantenlänge die auf der Strecke verwendeten Texturen haben. Wenn der Großteil davon die 512 Pixel nicht überschreitet, hat die Änderung der Einstellung nur einen marginalen Effekt. Sind alle Texturen schon kleiner oder gleich der Einstellung, dann werden sie auch nicht heruntergerechnet.


    Gruß, Klaus

    Hallo Klaus,


    ich habe das so interpretiert: Es wird die maximale Kantenlänge der Grafikdateien (für mich also der darzustellenden Objekte) erwähnt. Bei größeren Objekten (z.B. Häuserfronten) muss eine kleinere Textur mehr gestreckt werden als eine größere, um das 3D-Gerüst zu bedecken. Die Grafikkarte braucht also etwas längere Zeit zur Berechnung. Zum Ausgleich und zur Vermeidung von Qualitätsverlusten reduziert die Grafiksoftware daher bei mir die Bildrate. Die Empfehlung zur maximalen Texturgröße mit 512 px habe ich schon immer für einen Mythos gehalten.


    Gruß

    Gerd

    Ein Kluger bemerkt alles. Ein Dummer macht über alles eine Bemerkung. Heinrich Heine

    Hallo Gerd,


    nein, es geht dabei um die Kantenlängen der Texturdateien. Je größer die sind, desto länger dauert die Berechnung, unabhängig davon, wie viel von der Textur auf welcher Fläche dargestellt wird. Der eingestellte Wert kommt zum Tragen, wenn Texturdateien in der Strecke verwendet werden, die größere Kantenlängen haben. Dann werden diese Texturen - und nur diese - um die entsprechende 2er-Potenz reduziert. Da die meisten Texturen sowieso nicht größer als 512 Px sind, merkst Du einen natürlich erst so richtig, wenn Du eine noch geringere Größe einstellst. Und das siehst Du dann auch an der Darstellungsqualität. Bei meinen Signalen dürfte ebenfalls keine Textur über 512 Px sein. Aber ich glaube z.B. bei meinen 481er-Objekten. Da habe ich die Funktion vom Editor genutzt, mehrere Texturen zusammenzufassen, da mal gesagt wurde, dass viele kleine Texturen den Speicher mehr belasten, als eine große Textur mit den gleichen Inhalten. Wenn Du den Zug auf der Strecke hast und in den Optionen auf 512 Px gehst, müsstest Du den Unterschied sehen.


    Gruß, Klaus

    Hallo Klaus,


    ehrlich gesagt, ich sehe keinen Unterschied. Als ich vor gut 20 Jahren zum Loksim kam, waren gerade Windows 98 und die Version 2.3 aktuell. Bei den Prozessoren hatte ich gerade vom K6 auf den Athlon umgerüstet und hochwertige Grafikkarten waren zu teuer. Die aktivsten Objektbauer waren damals Frieder, Rainer Z. und Peter S. und diese hatten dann in Zusammenarbeit mit Andreas Hofmann die Empfehlung zur maximalen Texturgröße und später das Arbeiten mit Kulissen entwickelt. Bei den heutigen leistungsfähigen Rechnern halte ich diese Empfehlung für überholt. 3D-Objektbau ist nicht meine Stärke, ich arbeite mehr mit Flächenobjekten zur Ausgestaltung. Und bei so einem Mohnfeld reicht eine 1024er Texturgröße mal gerade für die vernünftige Darstellung eines Quadrats von 25 mal 25 Metern, eine hochgerechnete kleinere ergibt statt konturierter Blüten eher ein Gemisch von umgerührter roter Grütze mit etwas Vanillesoße in der Darstellung. Ich bevorzuge sowieso bei meinen Streckenexperimenten vorhandene Gebäudeobjekte und so lange es keine 3D-Führerstände mit Seitenfenstern gibt setze ich einfach nur flache (Kulissen-)Objekte mit Vorder- und Rückseite ein. Das betrifft sowohl das Windrad und den Glambecker Taubenturm für das einzelne Gehöft,...



    ...als auch den Storchenturm von Alt Gaul und die Burgruine als Zeugen der Vergangenheit.



    Auch für große Objekte wie Kraftwerk oder Brikettfabrik reicht eine 1024 *1024 Textur aus, bei der Vorder- und Rückseite übereinander angeordnet sind.



    Solche flachen Objekte erfüllen erst einmal ihren Zweck und dürften weniger Rechenleistung benötigen als echte 3D-Objekte, die mit viel Mühe und Zeitaufwand herzustellen wären. Die Texturen mache ich nicht größer als notwendig, das Limit ist die 1024er Größe.


    Gruß

    Gerd

    Ein Kluger bemerkt alles. Ein Dummer macht über alles eine Bemerkung. Heinrich Heine