MBS Companion V2

[gmd]

Hallo,
hier der naechste schritt in meiner definition the animationen/schalter wie auch immer man das nennt.

 

Ich definiere scenarien in meiner app, die als folge von aktionen (Animationen/Schaltern) ablaufen.
Scenarien sind zb. Aufruesten, Halt Bahnhof, Abfahrt Bahnhof, Rangieren, Wartung, Notfall Strecke, usw.
Die Aktionsnamen sind generisch und fuer alle modelle gleich. Ich verwende nicht nur An/Aus sondern unterscheide aktionstypen (Licht,Tuer etc.)
Auswahl einer aktion kann betriebsabhaengig sein, je nachdem in welcher richtung eine lok auf dem gleis steht ist es unterschiedlich welches licht
bei vorwaertsfahrt einzuschalten ist. Meine app weiss in welcher richtung fuer die lok vorne oder hinten ist. Ich habe zu jeder lok die info wie sie steht
wenn die koordinaten 0,0,0 und die drehung 0,0,0 ist. Loks werden meist 90 grad gedreht zu gleisen aufgesetzt, es gibt aber ausnahmen, -90 ist
dann gegenrichtung. Die App weis das , ich muss das nicht in scripten unterscheiden und auch nicht aufpassen wie ich die lok aufgesetzt habe.

Fuer jedes modell generiere ich einen mapper der meine "virtuelle" aktion/animation in den tatsaechlichen string umwandelt und in einem script als
parameter einsetzt.
Nicht alle aktionen sind fuer alle modelle vorhanden oder auch nicht unbedingt integriert (Zuglauschilder). Manche aktionen werden durch scripte
simuliert, oder durch eigene modellanimationen  ersetzt (weite zukunft).

Zu beachten ist: Diese aktionen laufen nur ab wenn eine kamera auf das objekt focusiert ist. Ansonsten ist das ja verschwendung von rechnerleistung.

Die Aktionsnamen stellen eine art standardisierten schalternamen dar, und ich bin gerne bereit meine liste fuer die verschiedenen typen zur diskussion zu stellen, und auch meine namen and einen konsensus anzupassen, aber bis so etwas existiert, werde ich weiter mein mapping benutzen.
Werde von zeit zu zeit weitere sequnzen posten, derzeit implementiere ich weitere anzeige funktionen die mir helfen vollstaendigkeit zu ueberpruefen und die mapper zu erzeugen, fuer die ersten beispiele.

Gruss
Gmd

 

 

 

Bearbeitet 3. Februar von gmd

[Phrontistes]

vor 7 Stunden schrieb gmd:

Diese aktionen laufen nur ab wenn eine kamera auf das objekt focusiert ist

Gute Idee. Das muss ich bei meiner (konventionellen) Programmierung auch noch einbauen.

[HaNNoveraNer]

Wie willst du denn rausfinden, ob das Objekt irgendwo am Bildschirm mit angezeigt wird?   Das wäre ja eine LOD Stufe für Animationen. 

[gmd]

51 minutes ago, HaNNoveraNer said:

Wie willst du denn rausfinden, ob das Objekt irgendwo am Bildschirm mit angezeigt wird?   Das wäre ja eine LOD Stufe für Animationen. 

die aussage bezog sich auf scenarien, nicht einzelne animationen.. die app controlliert die camera views.
gruss
Gmd

[Phrontistes]

vor 1 Stunde schrieb HaNNoveraNer:

Wie willst du denn rausfinden, ob das Objekt irgendwo am Bildschirm mit angezeigt wird?

Ich programmiere wie gesagt konventionell - und weiß auch ganz genau, wo "die" Kamera (es gibt natürlich viele zwischen denen umgeschaltet wird) gerade hinschaut. Mit einer konventionellen Programmierung kann man aber bestenfalls ein größeres Diorama mit einer begrenzten Zahl von Zügen steuern. @gmds Ziel ist es, eine Anlage beliebiger Größe mit beliebig aufzusetzenden Zügen in den Griff zu bekommen.

[gmd]

Das thema visualisierung von ablaeufen is noch ein anders. Ich arbeite nicht nur mit den Mbs kameras.
Die maus controlliert das viewport (sicht auf die anlage). Nun stellt euch mal vor ihr habt zwei joysticks, wie bei der steuerung fuer eine drone und zwei einstellraeder fuer zoom und gimbal position (kamera hoch und runter) und damit steuerst du die sicht auf die anlage unabhaengig von kameras. Damit kann das programm auch jederzeit jeden beliebigen blickwinkel reproduzieren. Grundfunktionen dieses knozepts verwende ich zur position von objekten auf weissem hintergrund zur erstellung der seitenbilder oder auch die screenshots fuer die animationen (steuerungsfenster).
Der phantasie sind da keine grenzen gesetzt.
Gruss
Gmd

Edit: Hier ein beispiel joystick_driver

Bearbeitet 3. Februar von gmd

[gmd]

Hallo,
heute mal wieder ein filmchen. Habe mir ein testbett gebaut, um die schlaternamen besser vergleichen zu koennen falls irgendwo problem enstehen. Ausserdem ist so eine einrichtung auch geeignet alle moeglich scripte zu testen, nicht nur schalter.

Hier zunaechst das statische bild. unter dem mbs, mein Lua center mit allen verfuegbaren lua snippets (gruppiert bei objekttyp/funktion).
Die scripte sind direct als beispiel ausfuehrbar enthalten aber parameter definitionen die von meinem preprozessor ausgewertet werden.
Im film kann man sehen wie im script editor das eigentliche script aussieht bevor es als json message verschickt wird.
Rechts die objektauswahl, die viele zwecken dient, unter anderem seitenphotos zu erstellen oder die schalterliste zu photografieren, und
vieles mehr, ist auch die grundlage fuer meinen zugdesigner.
Nun hier ist der film, ich denke der sagt noch mehr was dies bedeutet. nur noch eines, hier wurde auch eine geteilte verarbeitung zwischen
Mbs und app eingesetzt. Das Mbs hat grundscripte geladen, die dann auch von der app angesprochen werden, also zum beispiel das
rotierende gleis ist mit Mbs Lua gemacht, waere ueber die schnittstelle einfach nicht performant genug.

Animation/Schalter Testing

Gruss
Gmd

 

Bearbeitet 4. Februar von gmd

[gmd]

Hallo,
hier mal wieder ein update. Ein forummitglied hat die letzte version bekommen und erfolgrecih installiert und zum laufen gebracht, im wesentlichen als studienobjekt fuer seine eigene entwicklung zu steuerung einer echtanlage und Mbs als simulation. Die posts hier dienen auch als eine art dokumentation.

Zwei themen heute, Animationen/Schalter und blockerkennung oder allgemeiner, spurenerkennung.

Zunaechst Animationen

Habe meine funktionen zur ordnung der animationen/schalter fertig. Kann gruppiere, sortieren, filtern und meine eigenen keywords hinzufuegen (gruppenweise) die dann als basis einer einheitlichen benennung dienen. Daraus wird dann ein mapper erzeugt der die "virtuellen einheitlichen" schalter auf die physisch vorhandenen schalter umlenkt, und vielleicht ist diese liste ja mal irgendwann leer, ich halte aber nicht den atem an . 

Nun zu blockerkennung. Weiter oben hatte ich ja schon beschrieben wie ich eine Tracer lok auf der anlage fahren lasse und ueber events das layout rekonstruiere. Das hat soweit auch funktioniert, ist mir aber einfach zu langsam und hat auch einen haken, es is nicht wirklich fuer strassen und auch nicht fuer isolierte spuren geeignet. Der gedanke kam in erster linie auch weil mein hirn nicht mehr so frisch ist wie es mal war .. und mein mathe kopf noch weniger. Nun habe ich mich aber doch durchgerungen mich wieder mit 3d geometrie zu beschaeftigen und lese die koordinaten,rotationen und geometrie informationen aus und errechne die verbundenen elemente. Und damit ich auch sehe was das passiert habe ich ein paar simple 3d klassen gesucht, die in meiner umgebung helfen ein 3d layout anzuzeigen, und zwar nur spuren, keine gleise, oder strassen etc. Lediglich zu dem zweck blockstrecken, unschuetzbare verbindungen usw zu identifizieren  und schliessendlich auch kontakte und signale automatisch zu positionieren.
Ich habe die routinen fuer gebogene und gerade spuren fertig und baue jetzt an den weichen (ist ja nur eine kombination der fertigen funktionen) und dann noch das flexgleis mit wer weis wievielen segmenten. Ist aber auch nur eine kombination schon vorhandener logik. Jetzt kann ich kuerzester zeit layouts einlesen und darstellen und konfigurieren und muss nicht mehr endlos lange auf die tracer lok warten, die sowiso nicht ueberall hinkommt. Wird interessant wenn ich das auf strassen mit x fahrspuren anwende, aber das ist noch zukunft .

Hier ein beipiel der ausgabe, noch ganz elementar mit gleisnamen als label und mittelpunkte und endpunkte markiert.  Aus der moeglichkeit jetzt jedes gleis und jede strecke genau zu kennen, lassen sich natuerlich auch weitere funktionen ableiten, wie anzeige von streckenlaengen, berechnen von bremsbereichen usw.
Das ist ein wesentlicher schritt zur schnelleren streckenerkennung und verwertung.
Gruss aus dem warmen Australien. Im Nordosten hatten wir in 3 tagen einen meter regen .. nicht schnee aber regen. Weiss gar nicht was das in schnee waere , sowas wie 10m ? So wie derzeit in Japan.  -
Gmd
 

 

[gmd]

Hallo,

ein update bezueglich des gleisplans.

Hier eine kleine testanlage .. Ist ein teil meine gesamtanlage 

und hier der ausgelesene 3d spur plan.
Die alte schnittstelle hat ein paar macken die man umschiffen muss.. mal sehen wie das alles mit der neuen geht.
Wird aber noch dauern bis ich das umgestellt habe, da ich ja jetzt erst mal diese neuen daten verarbeiten kann
und meine blockerkennung vorantreibe.
Einige weichen werden noch nicht richtig gezeichnet, aber das werde ich auch noch beseitigen. Der plan is auch
interaktiv, d.h. ich kann jedes spur segment selektieren und dann spaeter alle moeglichen funktionen dranhaengen.
es sind strassen mit gezeichnet, da die schnittstelle sie als gleise meldet, wie auch die spuntwaende und tunnelroehre,
aber das werde ich noch ausblenden, da ich ja alle guids kenne und mein katalog auch die typen kennt. Dann wird
das auch schneller, weil ich nicht immer das MBS fragen muss.
So ganz allmaehlich bekommt das ganze mehr form , allerdings immer noch eine menge zu tun.
Gruss
Gmd

 

[gmd]

Hallo,
mal wieder ein zwischenbericht. Ich arbeite ja an verschiedenen baustellen gleichzeitig, je nach lust und laune. Die letzten tage habe ich allerdings auschliesslich mit blockerkennung verbracht. Wie oben berichtet habe ich den gleisplan ausgelesen und gezeichnet, zur kontrolle im wesentlichen.
Dann habe ich funktionen gebaut und mit consolausgaben getestet, was aber nur bis zu einem gewissen mass funktioniert. Dann habe ich erstmal weitere
anzeigenfunktionen gebaut, mit denen ich ergebnisse der analysenfunktionen besser pruefen kann, und auch interaktive elemente auf dem modell direkt auswaehlen kann.

Alle gleise eingelesen mit eindeutigen namen und allen eigenschaften.

Gleisstrecken und temporaere bloecke ermittelt. Hierauf aufbauend werden die steuerungselemente zugewiesen,
signale, bremskontakte, einfahr- und ausfahrkontakte, usw.

Blockverbindungen ueber weichen... und da ist noch ein fehler drin .. Diese info wird zur dynamischen
fahrstrassensteuerung verwendet.
Diese anzeigen werden spaeter nicht mehr wirklich gebraucht, wenn dann nur zur fehlersuche.

Ich habe weitere funktionen erstellt, die aber noch keine eigene anzeige haben, das kommt als naechstes.
Diese funktionen sind:
Erkennen isolierter weichen, d.h. weichen die nur mit weichen verbunden sind, die bekommen sonderbehandlung.
Doppelte gleise: erkennen wenn gleise uebereinanderliegen, kommt vor, ist ein abfallprodukt.
Erkennen parallele gleise und daraus parallele bloecke ableiten.  Daran arbeite ich derzeit.

Unde wenn ich parallele bloecke erkannt habe, dann folgt logischerweise:
Erkennen bestimmter gleismuster wie, ausweich gleis auf strecke, bahnhof harfe mit durchfahrt usw.
Aus dem erkennen der gleismuster werden dann die signale und kontakte abgeleitet, groessere bloecke werden je nach
laenge in unterabschnitte geteilt (parameter maximale zuglaenge).

Gruss
Gmd