BahnLand

Hallo Marko, ich hoffe, dass Du Dein originales Höhenfeld nur für die Präsentation hier im Forum in das JPG-Format umgwandelt und nicht versucht hast, dieses (wieder in BMP zurück konvertiert) auf die Bodenplatte zu bringen. Das JPG-Format macht nämlich alle "gleichmäßigen" Farbabstufungen durch die Komprimierung kaputt (verfranst das Bild künstlich, um so trotz Komprimierung das Bild fast wie das Original aussehen zu lassen). Ich habe Dein unteres Höhenfeldbold einmal auf eine Anlage importiert und das folgende Ergebnis aus der zurück konvertierten JPG-Datei bekommen: Füge mal Deinem Höhenfeld in den beiden gegenüberliegenden Ecken wie in dem unteren Bild gezeigt eine kleine weiße (Farbwert (255,255,255)) und schwarze Fläche (Farbwert (0,0,0)) hinzu (leider konnte auch ich das Bild hier nur im JPG-Format hochladen, aber das Original hat das BMP-Format). Wenn Du dann nochmal versuchst, das Höhenfeld auf die Anlage zu bringen, wirst Du sehen, dass die untere Eckfäche tatsöchlich auf Höhe 150 und die obere Eckfläche auf Höhe 2500 liegt (bei mir hat's zumindest so funktioniert). Ich vermute daher, dass bei Deinem Höhenfeld die dunkelsten Flächen (nahe dem Farbwert (0,0,0)) für die unteren Ebenen irgendwie verloren gegangen sind. Viele Grüße BahnLand

Hallo fex, Danke für das Däumchen und auch allen anderen für die "Gefällt-mir"-Klicks! Was da nach 30 Tagen abläuft, ist die Lizenz für die Vollversion "Sketchup 2016". Denn wenn Du Sketchup Make installierst, bekommst Du automatisch für diese 30 Tage die Vollversion bereitgestellt. Wenn die 30 Tage um sind, wird dann automatisch auf Sketchup Make 2016 (die Light Version von Sketchup 2016) zurückgeschaltet. Sketchup Make hat keine zeitliche Beschränkung und kann daher von Dir bis zum "Sankt-Nimmerleins-Tag" benutzt werden. Wenn Du nicht gerade obj-Dateien exportieren oder importieren möchtest, reicht Sketchup Make (d,h, die Light Version) nach meiner bisherigen ERkenntnis vollkommen aus. Ich verwende auch nur Sketchup Make und habe zumindest bisher noch nicht bemerkt, dass mir irgend eine dringend benötigte Funktionalität fehlen würde. Übrigens gibt es jetzt auch schon Sketchup 2017 und Sketchup Make 2017. Mit diesen Versionen kannst Du den neuen DirectX-Exporter ebenfalls einsetzen. Viele Grüße BahnLand

Hallo Lobo, die eingezogenen "Fensterhöhlen" machen schon was her, und die Dachgauben sind Dir auch sehr gut gelungen. Viele Grüße BahnLand

Hallo Lobo, nach der Größe des Zylinders zu urteilen könnte es sich auch um einen Urenkel von William Wilson handeln, der als erster Lokführer des Adlers zwischen Nürnberg und Fürth pendelte. Zumindest erschien mir dessen Kopfbedeckung in dem zum 100-Jährigen Bestehen der deutschen Eisenbahn gedrehten Film etwas zu "überdimensioniert" . Bei Deiner Bank, wo man offenbar günstig MBS-Aktien kaufen kann (), gefallen mir besonders die Kugellampen am Haupteingang mit der jeweils hell leuchtenden Halbkugel im unteren Bereich. Ich vermute, dass Du da jeweils zwei Kugeln des Grundkörper-Sortiments in der Höhe etwas versetzt übereinander gestülpt hast, sodass man oben und unten jeweils eine Hälfte der beiden Kugeln sieht (liege ich da richtig?). Viele Grüße BahnLand

Hallo Wolfgang, das mit dem Flag hatte ich verstanden. Nur wegen der verschiedenen Werte 0 und 1 dachte ich, ich hätte eventuell etwas übersehen. Ansonsten ist Dein Algorithmus für mich jetzt klar. Vielen Dank für Deine zusätzliche Erklärung. Man kann bei den Ereignissen "Zug betritt/verlässt Gleis" die Fahrtrichtung des Zuges schon erkennen, wenn man in der Ereignisdefinition zusätzlich die Bedingung "Lok/Wagen steht auf einem Gleis" auswertet. Wichtig ist hierbei, dass das als Auslöser verwendete Gleisstück und das Gleisstück, auf welches man sich in der Bedingung bezieht, unmittelbar aneinander anschließen. Man betrachte hierzu beispielsweise das grün-blaue Gleispaar vor der Diesellok im Bild links vorne. Ich möchte hierzu das Gleisstück, welches als Auslöser für die Ereignisse "Zug betritt Gleis" und "Zug verlässt Gleis" herangezogen wird, als "Ereignisgleis", und das Gleis, das in der Bedingung "Lok/Wagen steht auf einem Gleis" betrachtet wird, als "Prüfgleis" bezeichnen. Sei nun das grüne Gleis das Ereignisgleis (Zug betritt/verlässt grünes Gleis) und das blaue Gleis das Prüfgleis (Lok/Wagen steht auf blauem Gleis). Ist nun bei dem Ereignis "Zug betritt grünes Gleis" die Bedingung "Lok/Wagen steht auf blauem Gleis" erfüllt, fährt der auslösende Zug von rechts nach links. Ist die Bedingung nicht erfüllt, fährt der Zug von links nach rechts. Man kann also für beide Fahrtrichtungen getrennte Aktionen ausführen lassen. Erklärung für das Erkennen der Fahrtrichtung: Fährt der Zug von links nach rechts, betritt er das grüne Ereignisgleis, bevor er das blaue Prüfgleis erreicht. Er kann sich also zum Zeitpunkt der Ereignis-Auslösung nicht auf dem Prüfgleis befinden. Die Bedingung ist also nicht erfüllt. Fährt der Zug dagegen von rechts nach links, muss er zuerst das blaue Prüfgleis passieren, bevor er das grüne Ereignisgleis erreicht. Zum Zeitpunkt der Ereignisauslösung befindet er sich also gezwungenermaßen noch auf dem Prüfgleis, sodass die Bedingung erfüllt ist. Beim Ereignis "Zug verlässt Gleis" ist die Fahrtrichtung des Zuges in Abhängigkeit davon, ob die Bedingung erfüllt ist oder nicht, vertauscht: Ist bei dem Ereignis "Zug verlässt grünes Gleis" die Bedingung "Lok/Wagen steht auf blauem Gleis" erfüllt, fährt der auslösende Zug von links nach rechts. Ist die Bedingung nicht erfüllt, fährt der Zug von rechts nach links. Auch hierfür eine Erklärung: Fährt der Zug von links nach rechts, befährt er das blaue Prüfgleis im Anschluss an das grüne Ereignisgleis. In dem Moment, wo er das Ereignis "Zug verlässt grünes Gleis" auslöst, befindet er sich also noch auf dem blauen Prüfgleis. Die Bedingung "Lok/Wagen befindet sich auf blauem Gleis" ist also erfüllt. Fährt der Zug dagegen von rechts nach links, passiert er also das blaue Prüfgleis vor dem grünen Ereignisgleis, muss er zu dem Zeitpunkt, wo er das grüne Ereigisgleis verlässt, zwangsläufig auch das blaue Prüfgleis bereits verlassen haben. Deshalb ist hier beim Auslösen des Ereignisses "Zug verlässt grünes Gleis" die Bedinging "Lok/Wagen steht auf blauem Gleis" nicht erfüllt. Wer Lust hat, kann jetzt einfach mal das ganze Szenario durchspielen, wenn man die Funktionalität des grünen und des blauen Gleises vertauscht, also das blaue Gleis als Ereignisgleis ("Zug betritt/verlässt blaues Gleis") und das grüne Gleis als Prüfgleis ("Lok/Wagen steht auf grünem Gleis") verwendet. Wie sehen die Schlussfolgerungen für "Bedingung erfüllt" und "Bedingung nicht erfüllt" dann aus? Tipp: Die Begriffe "lnks" und "rechts" müssen in der obigen Beschreibung einfach vertauscht werden. Aber warum? Die Antwort auf die Frage steckt in meinen beiden "Erklärungen". Viel Spaß beim Tüfteln. Bei dem obigen Bild werden übriges die Gleispaare "grün/blau" mit dem Ereignis "Zug betritt Gleis" verwendet. Sie erfüllen damit den Zweck der in den vorangegangenen Beiträgen beschriebenen Beginn-Gleise. Die Gleispaare "gelb/orange" werden dagegen mit dem Ereignis "Zug verlässt Gleis" verwendet. Sie entsprechen damit den Ende-Gleisen der vorangegangenen Beiträge. Dadurch, dass durch die Zusatzberdingung die Fahrtrichtung des Zuges erkannt werden kann, braucht man hierfür die Objektvariablen "<Lok>.BüAusgang" als Indikator-Variablen, ob der Zug in den Bahübergangvereich ein- oder ausfährt, nicht mehr. Man löst das Schließen der Schranken (über das Hochsetzen des Belegungszählers) einfach nur dann aus, wenn sich der Zug beim Passieren des jeweiligen Beginn-Gleises zum Bahnübergang hin bewegt. Fährt der Zug vom Bahnübergang weg, wird diese Aktion nicht ausgeführt. Umgekehrt verhält es sich beim Öffnen der Schranken an den Ende-Gleisen. Die Aktion "Belegungszähler herunterzählen" (bei "0" werden die Schranken geöffnet) darf nur angestoßen werden, wenn sich der das Ende-Gleis passierende Zug vom Bahnübergang weg bewegt. Fährt der Zug auf den Bahnübergang zu darf, der Zähler nicht heruntergesetzt werden. Viele Grüße BahnLand

Hallo Wolfgang, nachdem ich jetzt Dein Video zweimal angesehen habe, ist mir klar, wofür Du die Objektvariable "<Lok>.BüAusfahrt" benötigst. Du identifizierst hierdurch die Fahrtrichtung des Zuges und verhinderst dadurch, dass die Schranken geschlossen werden, wenn der Zug ein Beginn-Gleis in der "falschen" Richtung "betritt". Das mache ich bei meinem Algorithmus über die Abfrage, ob ein Fahrzeug des Zuges auf dem unmittelbaren Nachbargleisstück steht. Auch damit kann ich erreichen, dass die Schranke nur dann geschlossen wird, wenn sich der das Beginn-Gleis betretende Zug in Richtung zum Bahnübergnag hin und nicht in entgegengesetzter Richtung bewegt. Damit benötige ich die Zug-bezogene Objekt-Variable nicht, und konnte daher mit ihr in der EV von Gertschi auch nichts anfangen. Auf die Indikator-Variable "Schranke_geschlossen" hatte ich bei meiner Demo-Anlage ebenfalls verzichtet, da der Anstoß zu Schließen einer bereits geschlossenen Schranke eigentlich "Ins Leere" läuft und damit zumindest bei meiner Demo keine Auswirkung hat. Sobald aber mit dem Schließen der Schranke Zusatz-Aktionen verbunden sind, wie bei Deinem Beispiel das Aktivieren des Läutewerks, benötigt man diesen Indikator, um ein erneutes Läuten bei bereits geschlossener Schranke zu verhindern. Insofern habe ich beim Betrachten Deines Videos jetzt doch wieder etwas dazugelernt. Zu dem Problem von Gertschi hast Du ja die Lösung schon formuliert. Nur eine Frage häbe ich noch? Warum unterscheidest Du bei der Objektvarable "<Lok>.BüAusfahrt" die Werte 0 und 1 für den Ein- und Ausfahrbereich des Bahnübergangs-Abschnitts? Es wird doch nur überprüft, ob die Variable leer oder nicht leer ist, um beim "Betreten" eines Beginn-Gleises "richtig" reagieren zu können (oder habe ich etwas übersehen?). Viele Grüße BahnLand

Hallo Gertschi, was bezweckst Du mit der Objektvariable _Trigger1.BüAusfahrt, und warum verknüpfst Du diese Variable mit der Lok? Ist diese Variable der Belegungszähler für den Bahnübergang, um feststellen zu können, wann die Schranke wieder geöffnet werden darf? Wenn ja, bräuchtest Du zwei getrennte Belegungszähler für Bahnübergang A und Bahnübergang B, die beide den Wert 0 besitzen, solange sich kein Zug in den Bahnübergangs-Bereichen befindet (siehe die Vorgangsbeschreibung weiter unten). Du hast in Deinem Anlagenbild nur die Beginngleise ausgezeichnet (grün für Bahnübergang A, blau für Bahnübergnag B). Welches sind die Endegleise? Meinst Du damit die gelben Gleise für Bahnübergang A und die roten Gleise für Bahnübergang B? Du kannst _Trigger1 nicht einfach durch _Trigger2 ersetzen. Denn bei den Ereignissen Zug betritt/verlässt Gleis (ich vermute, dass Du Dich auf diese beziehst) repräsentiert _Trigger1 immer die Lok, deren Zug das Gleis betriitt oder verlässt, und _Trigger2 das Gleis, das betreten oder verlassen wird. Bei anderen Ereignissen der EV können _Trigger1 und _Trigger2 dagegen ganz andere Typen von Objekten repräsentieren. Ich habe mr mal Deine Anlage 2 - fertig Test Steuerung.mbp aus diesem Beitrag, auf die Du Dich beziehst, angeschaut. Da habe ich aber noch keine Objektvariable _Trigger1.BüAusfahrt gefunden. Kann es sein, dass dieser Stand Deiner Anlage nicht aktuell ist? Zum theoretischen Ablauf: Nähert sich ein Zug Bahnübergang A und betritt dabei in Fahrtrichtung zum Bahnübergang A hin ein diesem Bahnübergang zugeordnetes Beginngleis, muss der Belegungszähler für diesen Bahnübergang A um 1 hochgezählt werden. Sind die Schranken dieses Bahnübergangs zu diesem Zeitpunkt geöffnet (das ist der Fall, wenn der Belegungszäheler vor dem Erhöhen den Wert 0 besaß), müssen sie geschlossen werden. Entfernt sich der Zug vom Bahnübergang und verlässt dabei ein Endegleis in Fahrtrichtung vom Bahnübergang weg, wird der Belegungszähler für diesen Bahnüberang um 1 erniedrigt. Geht der Zähler hierbei auf 0, befindet sich kein Zug mehr im Bereich dieses Bahnübergangs, sodass dessen Schanken geöffnet werden können. Soll dieser Ablauf außer für den Bahnübergang A auch für einen weiteren Bahnübergang B realisiert werden, müssen alle verwendeten "Betriebsmittel" (das sind die Beginngleise, die Endegleise und auch der Belegungszähler!) neu eingerichtet werden. Wird für den zweiten Bahnübergang dann (vom ersten Bahnübergang völlig unabhängig) die gleiche Ablaufsteuerung realisiert, spielt es überhaupt keine Rolle, ob sich die "Belegungsabschnitte" um die einzelnen Bahnübergänge herum (also die Abschnitte zwischen Beginngleis und Endegleis für jedes Gleis am Bahnübergang und jede Fahrtrichtung) überscneiden oder nicht. Jedes "Zug-betritt/verlässt Gleis"-Ereignis bezieht sich immer genau auf einen der betrachteten Bahnüberänge und steuert somit auch nur diesen, ohne etwas von möglichen anderen Bahnüberängen "zu wissen". Trotzdem wird jeder Bahnübergang - für sich betrachtet - ordentlich geschlossen, wenn sich ein Zug nähert, und auch wieder ordentlicxh geöffnet, wenn sich "der letzte" Zug entfernt. Es gibt hierbei keinerlei Synchronität zwischen mehreren existierenden Bahnübergängen. Schau Dir bitte zwecks der hier beschriebenen Bahnübergangs-Schaltung einmal diese Beschreibung und das zugehörige Anlagenbeispiel an. Das sollte Dir eingentlich weiterhelfen. Eine fertige Anlage mit Bahnübergangssteuerung findest Du übrigens im Online-Katalog in der Rubrik "Experimentelle Anlagen": Bahnübergangs-Steuerung. Allerdings ist dort die Schrankensteuerung für jedes Gleis nur in einer Fahrtrichtung realisiert Viele Grüße BahnLand

Hallo Gertschi, ich habe mir gerade Deine Anlage 2 angeschaut. Ganz schön verzwickt. So ganz habe ich den Überblick über die verschachtelte Linienführeung mit den vielen Tunneln noch nicht gefunden. Aber gefallen tut mir die Analge sehr! Viele Grüße BahnLand

Hallo zusammen, aufgrund von Neo's Beitrag habe ich den Exporter und - vor allem - auch die Dokumentation noch einmal "angefasst". Mit der Aussage, dass es einen "Standard"-Maßstab für die an das Modellbahn-Studio zu übergebenden Modelle nicht mehr geben wird, ist die Einstellung "Zielgröße" in meinem DirectX-Exporter theoretisch überflüssig geworden, weil man dann, wenn man als Zielgröße für die X-Datei grundsätzlich die Originalgröße verwendet, gleich diesen Maßstab als _Scale_-Information weitergeben kann. Da es aber aufgrund der ursprünglichen zwingenden Anforderung "H0-Maßstab" im ehemaligen 3D-Eisenbahnplaner, der auch in den bisherigen Versionen des Modellbahn-Studios als "Standard-Maßstab" beibehalten wurde (jetzt allerdings wegen der möglichen _Scale_-Objekt-Definition nicht mehr zwingend einzuhalten), und in bisherigen "Zwischenlösungen" die neuen "Standard-Maßstäbe" 1:1 und 1:100 angedacht wurden, hatte ich bereits in der Februar-Version meines DirectX-Exporters indirekt (über die MBS-Versions-Auswahl) die Auswahlmögichkeit der Zielgröße in den Exporter-Einstellungen eingeführt. Die aktuelle Zielgröße stellt also "nur" eine Verallgemeinerung der Einstellung "Zielgröße" mit Eliminierung des Versionsbezugs dar. Wie Quackster an anderer Stelle mit Recht anmerkte, kann es nicht sein, dass aufgrund einer Änderung der Zielgröße in der X-Datei aufgrund neuer Vorgaben bei der Neugenerierung eines bereits bestehenden Modells vorhandene X-Datei-Erweiterungen (z.B. AnimationSet-Definitionen) neu berechnet (umskaliert) und damit auch neu geschrieben werden müssen. Deshalb lasse ich die individuelle Auswahl-Möglichkeit der Zielgröße in meinem DirectX-Exporter bestehen. Dem Modellbahn-Studio ist es nach Neo's letzter Aussage schließlich egal, in welchem Maßstab ihm das Modell vorgelegt wird, da es in jedem Fall die Information benötigt, in welchem Maßstab das Modell in der X-Datei vorliegt. Durch die automatische Ergänzung der X-Datei um diese Information mittels des "_Scale_-Objekt-Frames" durch den DirectX-Exporter, wenn die entsprechende Exporter-Einstellung gesetzt ist (_Scale_-Objekt : hinzufuegen), erspart man sich die händische Eingabe des X-Datei-Maßstabs beim Hochladen des Modells in den Online-Katalog und auch das Bereitstellen eines solchen Objekts im Sketchup-Modell. Deshalb lasse ich auch diese Exporter-Einstellung bestehen. Mit der Ersetzung der als Zielgröße eigentlich "sinnlosen" Einstellung "H0*Zoll" durch "wie Original", was bedeutet, dass als ZIelgröße der Maßstab der Originalgröße übernommen werden soll, kann jeder Anwender des DirectX-Exporters selbst entscheiden, ob er wie in obigem Beitrag von Neo beschrieben als Zielgröße grundsätzlich die Originalgröße des Sketchup-Modells weitergeben oder die Zielgröße individuell auswählen möchte. Entsprechend kann der Anwender auch entscheiden, ob er die Abfrage des Maßstabs durch das Modellbahn-Studio beim Hochladen beantworten oder diese Information bereits vorab in der X-Datei hinterlegen (lassen) möchte. Im DirectX-Exporter einmal eingegebene Einstellungen bleiben für alle danach durchgeführten Export-Vorgänge bestehen, bis sie der Anwender durch einen neuen Aufruf des Einstellungs-Dialogs explizit ändert. Anbei die aktualisierte Fassung des DirectX-Exporters und der zugehörigen Beschreibung. Noch ein Erklärungsversuch zur auswählbaren Einstellung "H0*Zoll" bei der Originalgröße: Sketchup ist ein amerikanisches Programm und gibt an der Ruby-Schnittstelle, die vom DirectX-Exporter "angezapft" wird, die Modellmaße in der Einheit "Zoll" gemessen aus. Das Modellbahn-Studio und auch dessen Vorläufer 3D-Eisenbahnplaner sind deutsche Programme und interpretieren die in der X-Datei hinterlegten Maßangaben als cm-Maße. Hierdurch ergibt sich der Effekt, dass dann, wenn beim Export keine entsprechende Transformation der Modellmaße erfolgt, beispielsweise ein Würfel, der in Sketchup mit einer Kantenlänge von 1 Zoll (= 2,54 cm) erstellt wurde, nach dem Export in der X-Datei dieselben Koordinaten-Angaben aufweist, diese aber im Modellbahn-Studio (oder 3D-Eisenbahnplaner) zur Darstellung des Würfels mit einer Kantenlänge von 1 cm, also zu einer um den Faktor 2,54 verkleinerten Darstellung gegenüber der Originalgröße des Sketchup-Modells führen. Da der vor der Existenz des eigenen DirectX-Exporters benutzte Exporter von Erwan de Cadoudal (https://sites.google.com/site/edecadoudal/sketchupwithdirectx) nur eine solche 1:1 Übernahme der Sketchup-Koordinaten in die X-Datei unterstützte, mussten daher alle Sketchup-Modelle, die im damaligen 3D-Eisenbahnplaner im Maßstab H0 dargestellt werden sollten, in Sketchup in dem um das 2,54-fache vergrößerten Maßstab "H0*Zoll" konstruiert werden. Da diese Modelle bei marginalen Änderungen auch heute noch für das Modellbahn-Studio exportiert werden können sollen, ohne sie hierfür umskalieren zu müssen, habe ich in den Einstellungen des DirectX-Exporters auch diesen Maßstab als Originalgröße berücksichtigt. Viele Grüße BahnLand

Hallo Lobo, dass die Verwendung der Ebene anstatt des Quaders nicht in allen Fällen funktioniert und zudem mit mehr Arbeitsaufwand verbunden sein kann, ist mir völlig klar. Dies gilt vor allem, wenn man die 3-Dimensionalität betonen möchte. Denn gerade dann werden eben mehr als nur eine Seite des Quaders sichtbar, die man dann auch alle durch entsprechende Ebenen ersetzen müsste. Und dann ist die Einsparung von Polygonen ja auch nicht mehr so hoch (siehe meine Beispiele der Reduzierung auf 1/6 oder "nur" auf 1/3). Insofern ist mein obiger Beitrag auch weniger als "Kritik", sondern mehr als "Anregung" zu verstehen. Also: Erfreue uns weiter mit Deinen schönen Modellen! Viele Grüße BahnLand

Hallo Lobo, ich sehe an Deinem "Rohbau" der Kirche, dass Du die Außenwände des Turms mittels Quadern realisierst. Gibt es einen Grund, dass Du hier anstelle des Quaders nicht die Ebene verwendest? Auch wenn dadurch das Problem der vielen Materialien nicht gelöst wird, könntest Du hierdurch immerhin eine ganze Menge von Polygonen einsparen: Bei den diagonalen Wänden könntest Du beispielsweise den Polygon-Verbrauch auf 1/6, bei den geraden Wänden auf 1/3 absenken. Der Grund dafür ist, dass bei den diagonalen Wänden jeweils nur eine Seite des Quaders von außen sichtbar ist, während es bei den Quadern für die geraden Wände zwei Seiten sind (für die einander gegenüber befindlichen Außenwände des Kirchturms). Eine hier für das gesamte Bauwerk ganz gröb geschätzte Reduzierung der Polygonzahl auf 1/3 wäre ja auch schon was wert. Ansonsten sind Deine Gebäude, die Du ja gerade am Fließband fertigst, schon eine Augenweide. Ich verstehe, warum Quackster damit schon seine Anlage "bepflastert" . Viele Grüße BahnLand

Hallo alle Sketchup-Modellbauer, der hier bereitgestellte neue Sketchup-DirectX-Exporter ist zwar ein Plugin, aber nicht für das Modellbahn-Studio, sondern für Sketchup (um dort Modelle für das Modellbahn-Studio exportieren zu können). Download aktuelle Version DirectX-Exporter V5 (31.10.2024).zip Download ältere Versionen DirectX-Exporter V4 (16.04.2021).zip DirectX-Exporter V3.zip Ich habe noch ein wenig an meinem Sketchup-DirectX-Exporter herumgebastelt und dabei folgende Korrekturen und Erweiterungen vorgenommen: Fehlerbehebung bei Teilobjekten ohne Flächen Wenn in einem Sketchup-Modell gruppierte Bauteile vorhanden waren, für die keine Flächen darzustellen waren, brach der Export bisher mit Fehler ab. Der Fehler wird jetzt abgefangen. Wird nun ein Bauteil ohne zu realisierende Flächen erkannt, wird dies im Export-Protokoll zwar angezeigt, die Bearbeitung aber fortgesetzt und "sauber" beendet. Im Protokoll werden Bauteile ohne darzustellende Flächen mit "0 Flächen" ausgewiesen. DirectX-Exporter funktioniert jetzt auch mit den neuen Sketchup-Versionen Es ist mir gelungen, die Ursachen, warum der DirectX-Exporter bisher mit den neueren Sketchup-Versionen nicht eingesetzt werden konnte, zu identifizieren und zu beseitigen. Hauptknackpunkt war hierbei die Verwendung einer neueren Ruby-Version durch Sketchup, durch welche UTF-8-Codes, zu denen insbesondere die deutschen Umlaute ä, ö, ü und das scharfe ß gehören, nicht mehr unterstützt werden und daher zu einem Abbruch des Ruby-Scripts (also des DirectX-Exporters) mit Fehler führen. Ich habe deshalb alle Umlaute und das scharfe ß in den Textausgaben durch "ae", "oe", "ue" und "ss" ersetzt. Auch wenn's jetzt etwas "weniger schön" aussieht, funktioniert es jedenfalls. Ein weiteres Problem stellte die inkompatible Änderung der Datums- und Uhrzeit-Ausgabe dar, die ich zur Berechnung der Ausführungszeit für den Export verwende. Hier hat sich das Ausgabeformat geändert, sodass ich einen neuen Lokalisierungs-Algorithmus für die Uhrzeit benötigte. Der DirectX-Exporter stellt jetzt automatisch fest, in welchem Format Datum + Uhrzeit ausgegeben werden, und wählt dann selbst die passende Aufbereitungsvariante aus. Somit kann der Exporter nun gleichermaßen sowohl mit den älteren Sketchup-Versionen (z.B. Sketchup V8) als auch mit den neuern Sketchup-Versionen (z.B. Sketchup 2016 oder Sketchup 2017) eingesetzt werden. Ausgabe in verschiedenen Zielgrößen und Hinzufügen eines _Scale_-Objekts möglich Laut Neo wird sich der vom Modellbahn-Studio verwendete "Standard"-Maßstab in der angekündigten neuen Version 4 von H0 (1:87) auf den Vorbild-Maßstab (1:1) oder den Maßstab 1:100 ändern (noch nicht endgültig festgelegt). Damit muss der Modellbauer zukünftig seine Modelle entweder in der neuen "Eingangs-Größe" für das Modellbahn-Studio abliefern oder in sein Modell das "_Scale_"-Objekt integrieren, mit dem er dem Modellbahn-Studio mitteilen kann, dass sein Modell eine vom "Standard" abweichende "Eingangs-Größe" besitzt. Letzteres ist vor Allem für solche Modelle von essentieller Bedeutung, die bereits für die bisherige Version des Modellbahn-Studios übergeben wurden, und deren X-Datei nach dem Export durchgeführte Änderungen und Erweiterungen (z.B. eine nachträglich hinzugefügte AnimationSet-Definition) enthalten. Bei einer Umstellung des Maßstabs für die mit dem DirectX-Exporter zu erzeugenden X-Datei müssten auch die hinzugefügten Änderungen und Erweiterungen entsprechend "umskaliert" werden. Lässt man dagegen den Maßstab für die X-Datei unverändert (mit ebenfalls unveränderter Erweiterung), und fügt stattdessen das _Scale_-Objekt ein, wirkt sich die dann implizit durchgeführte "Umskalierung" durch das Modellbahn-Studio auf die gesamte X-Datei (einschließlich der hinzugefügten Änderungen) aus (der Modelbauer muss selbst die Umskalierung nicht mehr machen). Der DirectX-Exporter bietet nun in den Einstellungen sowohl die Möglichkeit, eine neue Zielgröße für die beim Export zu erstellende X-Datei zu spezifizieren, als auch das _Scale_-Objekt durch den DirectX-Exporter automatisch hinzufügen zu lassen. Der DirectX-Exporter testet dann zuerst, ob in dem zu exportierenden Sketchup-Modell bereits ein _Scale_-Objekt vorhanden ist. Wenn nein, erzeugt der DirectX-Exporter das _Scale_-Objekt selbst, indem der den dort zu hinterlegenden Maßstab, in dem er auch die X-Datei erzeugt, aus den Einstellungen für die Zielgröße herausliest, und die X-Datei selbsttätig um dieses _Scale_-Objekt ergänzt. _Gizmo-Objekt zur individuellen Positionierung des Koordinatenkreuzes im MBS-Modell In den Einstellungen des DirectX-Exporters besteht bisher die Möglichkeit, den von Sketchup anhand der Positionierung des Sketchup-Modells relativ zum Koordinatenkreuz "abgelieferten" Koordinaten-Ursprung des Modells unverändert zu übernehmen oder ihn - für jede Koordinaten-Richtung getrennt - an den Minimal- oder Maximal-Wert aller Eckpunkte des Modells oder den daraus berechneten Mittelpunkt zu verlegen. Mit dem "_Gizmo"-Objekt besteht nun die Möglichkeit, diesen "Koordinaten-Ursprung" im Sketchup-Modell an jede beliebige Stelle zu verlegen und dadurch bei der Anzeige des Modells im Modellbahn-Studio dessen Gizmo exakt an dieser Stelle zu positionieren. Hierzu fügt man in das Sketchup-Modell eine Bauteil-Gruppe ein, der man die Bezeichnung "_Gizmo" gibt. Das Bauteil muss aus einer eingefärbten Fläche bestehen (am besten eine horizontale quadratische Fläche), deren geometrischer Mittelpunkt (Mitte zwischen den kleinsten und größten Koordinaten des Bauteils) als individuell zu positionierendes Koordinatenkreuz verwendet wird. Dieses "_Gizmo"-Bauteil wird dann an jene Stelle im Modell verschoben, wo bei der Anzeige durch das Modellbahn-Studio das Gizmo positioniert werden soll. Beim Export des Sketchup-Modells bestimmt dann der DirectX-Exporter die Mittelpunkt-Koordinaten des _Gizmo-Bauteils und verwendet diese anstelle der Exporter-Einstellungen für die X-, Y- und Z-Ausrichtung, um das Gesamtmodell relativ zu diesem "Gizmo"-Koordinatenkreuz zu verschieben. Das "_Gizmo"-Objekt selbst (also das entsprechende Bauteil im Sketchup-Modell) wird nicht Bestandteil der X-Datei und damit auch nicht Teil des Modells im Modellbahn-Studio. Beispiel für die Wirkungsweise des _Gizmo-Objekts: Das obige Bild zeigt zwei Varianten desselben quadratischen Flächenmodells, die sich nur durch die Position des hellblauen Vierecks unterscheiden. Dieses ist die mit "_Gizmo" bezeichnete Bauteil-Gruppe des Sketchup-Modells. Beim linken Bild fällt dessen Mittelpunkt mit dem Mittelpunkt des Gesamtfläche zusammen. Beim rechten Bild ist der Mittelpnkt des _Gizmo-Objekts in die äußere Ecke des grünen Quadrats verschoben. Auf dem zweiten Bild sind 4 gleichartige Flächenodelle auf einer Bodenplatte des Modellbahn-Studios platziert, die sich wie folgt unterscheiden: Die beiden Flächen in der oberen Zeile besitzen kein _Gizmo-Objekt. Es sind daher die Angaben für die X-, Y- und Z-Ausrichtung in den Einstellungen des DirectX-Exporters gültig. Beim linken Bild ist dort die Angabe "unveraendert" für alle 3 Richtungen eingestellt. Es sollte also die originale Position des Koordinatenkreuzes aus dem Sketchup-Modell übernommen werden. Leider sind die Werte, die Sketchup für das Koordinatenkreuz relativ zum Modell ausgibt, in x-Richtung etwas verschoben, sodass auch das Gizmo im Modellbahn-Studio entsprechend etwas verschoben ist. Da das Gesamtmodell zum Koordinatenursprung symmetrisch aufgebaut ist, kann man diesen Fehler von Sketchup durch die Exporter-Einstellungen "mittig" für die X- und die Y-Richtung beheben. Bei am Koordinatenkreuz unsymmetrisch ausgerichteten Sketchup-Modellen kann man aber auch hier die Position des Koordinatenkreuzes gegenüber dem Sketchup-Modell nicht auf das Modell im Modellbahn-Studio übertragen. Denn es gibt ja nur die Einstellungen "kleinster oder größter Koordinatenwert aller Eckpunkte" oder "Mittelpunkt zwischen kleinstem und größtem Koordinatenwert", der ja nicht zwingend mit dem Koordinatenursprung zusammenfallen muss. Bei den zwei unteren Beispielen wurde im Sketchup-Modell ein _Gizmo-Objekt erzeugt und wie im vorangehenden Bild positioniert. Vergleicht man hierzu die untere Modell-Reihe in der Darstellung des Modellbahn-Studios, sieht man, dass das Gizmo jeweils exakt an jener Stelle platziert ist, an welcher es auch im Sketchup-Modell platziert wurde. Dies gilt unabhängig davon, in welcher Position das Sketchup-Modell bezogen auf das dortige Koordinatenkreuz platziert ist. So, nun möchte ich Euch bitten, den neuen DirectX-Exporter, den ich Euch hier in dem beiliegenden ZIP-Paket beigelegt habe, einmal auszuprobieren. Bitte folgt bei der "Installation" des Exporters der als PDF-Datei ebenfalls in diesem Paket abgelegten aktualisierten Beschreibung. Denn die Dateien müssen in Abhängigkeit von der verwendeten Sketchup-Version in unterschiedlichen Verzeichnissen abgelegt werden. Ist der DirectX-Exporter erst einmal im zur Sketchup-Version "passenden" Plugins-Verzeichnis abgelegt, ist die Handhabung sowohl bezüglich der unterschiedlichen Sketchup-Versionen als auch in Bezug zu der existierenden und der angekündigten Version des Modellbahn-Studios identisch. Ich bin auf Eure Eindrücke sehr gespannt. Viele Grüße BahnLand

Hallo Hans, Zu Frage 1: Bei den "Doppel-Fahrzeugen" ist immer eines die "Lok" und das andere der "Wagen", unabhängig davon, ob es sich bei dem "Wagen" wirklich um einen solchen oder in Wahrheit um eine zweite Lokomotive handelt. Diese wird aber dann nicht angetrieben, sondern nur von der anderen gezogen oder geschoben. Bei der aus den beiden V100 bestehenden Doppeltraktion ist die V100a die "Lok" und die V100b der "Wagen", und zwar unabhängig von der Fahrtrichtung. Es zieht oder schiebt also immer die V100a, während die V100b nie selbst fährt, sondern immer gezogen oder geschoben wird (es findet also kein Austausch der Rollen statt). Insofern ist V100a mit BR38 der Schlepptenderlok(-Konfiguration) und V100b mit deren Schlepptender BR38T direkt vergleichbar (auch da werden die Rollen nicht vertauscht). Die Einzellok V200 dagegen belegt sowohl die Rolle der "Lok" als auch jene des "Wagens". Die "Lok" referenziert grundsätzlich in der Objekt-Variable "Lok.Hinten" den "Wagen", wobei BR38.Hinten = BR38T und V100a.Hinten = V100b ist. Die V200 referenziert sich dagegen selbst: V200.Hnten = V200. Vielleicht hätte ich anstelle von "Hinten" die Objektvariable als "Anhängsel" bezeichnen sollen. Dann wäre es möglicherweise etwas klarer gewesen. Zu Frage 2: Dass V100a und V100b zum selben Loktyp gehören, ist nicht zwingend. Man hätte die Doppeltraktion aber auch aus verschiedenen Loktypen zusammensetzen können (hätte dann genauso funktioniert). Man hätte also die Doppeltraktion auch mit einer E10 als "Lok" und einer V60 als "Wagen" ausstatten können. Dann hätte man der E10 die Objektvariable E10.Hinten = V60 zugewiesen, die E10 wäre immer das angetriebene Fahrzeug gewesen, und die V60 wäre immer als passives Fahrzeug mitgeführt worden. Zu Frage 3: Heißt die Variable "Var", referenziert man deren Inhalt immer mit "$Var". In dem von Dir gezeigten Bild muss man die Lok, deren Name in der Variable Lok1 enthalten ist, also mit $Lok1 referenzieren. Beim Eintrag für die Geschwindigkeit greife ich aber auf den Inhalt einer Objektvariable zu, wobei das Objekt selbt ebenfalls über eine Variable referenziert wird. Hierbei muss das Objekt dann in runde Klammern gesetzt weden, um die Indirektion anzuzeigen: Wenn in der Variable Lok1 der Name BR38 hinterlegt und deren Geschwindigkeit zum "Herantasten" in der Objektvariable BR38.VTast abgespeichert ist, erreicht man diesen Wert, indem man über Lok1 zuerst die Lok BR38 identifiziert, und dann über die Klammer anzeigt, dass man auf die mit "." angehängte Objektvariable zugreifen möchte. Das dem gesamten Ausdruck vorangestellte $-Zeichen besagt dann schließlich, dass der Inhalt dieses Ausdrucks angezeigt werden soll. Also in "Einzelschritten" aufgelöst: Lok1 = BR38 und BR38.VTast = 20 => $(Lok1).VTast = Inhalt von (Lok1).VTast = Inhalt von BR38.VTast = 20 Die Schreibweise wird übrigens im Wiki unter "Variablen" erklärt. Findet man bei der Referenzierung einer Variablen einen Unterstrich vor, gehört dieser zum Bezeichner der Variable. Vorzugsweise besitzen die Bezeichner der vom Modellbahn-Studio bereitgestellten "System"-Variablen einen führenden Unterstrich. Beispielsweise ist _Trigger1 jene Variable, welche die beim den Ereignissen "Zug betritt/verlässt Gleis" der Auslöser ist identifiziert. Dabei kann man dann insbesondere auf die "vordefinierten" Objektvariablen _Trigger1._Name (Beszeichnung der auslösenden Lokomotive) und _Trigger1._CurrentSpeed (aktuelle Geschwindigkeit der auslösenden Lokomotive) zugreifen. Hat man der referenzierten Lok dann noch zusätzlich selbst eine Objektvariable "verpasst" (z.B. die Objektvariable V100a.Hinten ohne Unterstrich), so tritt auch bei deren Referenz kein Unterstrich auf (ist immer Teil des enthaltenden Variablen-Namens). Beispiele: Lok V100a mit der "Wagenlok" (dem Anhängsel) V100b löse ein Ereignis "Lok betritt Gleis" aus, wobei deren Name in der Variablen Lok1 hinterlegt würde. Dann sind die nachfolgende Ausdrücke wie folt zu interpretieren: Lok1 = $_Trigger1._Name = V100a _Trigger1._CurrentSpeed = V100a._CurrentSpeed = Objektvariable der Lok V100a, welche deren aktuele Geschwindigkeit enthält (Lok1)._CurrentSpeed = V100a._CurrentSpeed = Objektvariable der Lok V100a, welche deren aktuele Geschwindigkeit enthält $_Trigger1._CurrentSpeed = $V100a._CurrentSpeed = 160 (Wert der aktuellen Lok-Geschwindigkeit) $(Lok1)._CurrentSpeed = $V100a._CurrentSpeed = 160 (Wert der aktuellen Lok-Geschwindigkeit) _Trigger1.Hinten = V100a.Hinten = Objektvariable mit der Referenz auf das "Anhängsel" (Lok1).Hinten = V100a.Hinten = Objektvariable mit der Referenz auf das "Anhängsel" $_Trigger1.Hinten = $V100a.Hinten = V100b $(Lokk1).Hinten = $V100a.Hinten = V100b Zu Frage 4: Die Variablen Lok1, Lok2, Lok3 und Lok4 werden verwendet, um sich die Identität der Loks, die in Gleis 1 (Kopfbahnhofgleis), Gleis 2 (Gleisabschnitt vor Signal des Streckenblocks 2), Gleis 3 (Gleisabschnitt vor Signal des Streckenblocks 3) und Gleis 4 (Bereitschafsgleis(stummel) für "Ablöse"-Lok) eingefahren sind, zu merken. Die einmal dort hinterlegte Information wird erst dann neu überschrieben, wenn die nächste Lok in das betreffende Gleis einfährt. Dass es 4 solche "Gedächtnis"-Variablen, aber nur 3 Loks gibt (die V100b als "Wagenlok" zählt hierbei nicht), muss zwangläufig eine Lok immer in zwei dieser Varablen auftauchen. Ich hätte also anstatt "Lokx" besser schreiben sollen: "in Gleis x zuletzt eingefahrene Lok" (das war mir aber zu lang ). Jeder Lok im Modellbahnstudio ist über das Vorzeichen der Geschwindigkeit eindeutig die Richtung "vorne" (die Richtung, in welche die Lok mit positiver Geschwindigkeit fährt) und "hinten" (entgegengesetzte Richtung) zugeordnet. Entsprechend sind die Kupplungen der Lok in der Ereignisverwaltung (Aktion "Kupplung aktivieren/deaktivieren" mit der Kupplungs-Auswahl "Vordere Kupplung / Hintere Kupplung") gekennzeichnet. Da bei der Dampflok BR38 mit (nicht angetriebenem) Schlepptender BR38T die Ausrichtung "vorne/hinten" eindeutig vorgegeben ist, also die "Lok" sich "vorne" und der "Wagen" sich "hinten" befindet, und daher für das Entkuppeln die beiden Kupplungen "Lok-vorne" und "Wagen-hinten" deaktiviert werden, die anderen beiden Kupplungen "Lok-hinten" und "Wagen-vorne" aber aktiviert bleiben müssen, war die logische (und für den Algorithmus zwingende) Schlussfolgerung, beide Loks der Doppeltraktion in die gleiche Richtung auszurichten sowie die vordere Lok als "Lok" und die hintere Lok als "Wagen" zu verwenden. Da ich die vordere Lok mit V100a und die hintere Lok mit V100b bezeichnet habe, folgt hieraus, dass V100a die "Lok" und V100b der "Wagen" ist und daher die Bezeichnung V100b in der Objektvariable V100a.Hinten hinterlegt ist. Also: Mit den Bezeichnungen V100a und V100b werden verschiedene Loks (die vordere und die hintere der Doppeltraktion) gekennzeichnet, wobei jede Lok wie beabsichtigt einen eindeutigen Namen besitzt (die zweite Lok jedoch als "Anhängsel" ("Wagen") der ersten mitläuft). Viele Grüße BahnLand

Hallo fex, bei Sketchup ist das ebenfalls ganz einfach (im Prinzip analog zu Blender): Bilde aus den Fenstern, die Du beleuchtet haben möchtest, eine Gruppe und gib dieser einen Namen, der mit "_LS" beginnt. Das ist alles. Denn den Rest macht das Modellbahn-Studio, das anhand des mit "_LS" beginnenden Namens erkennt, dass es sich hier um ein Objekt, handelt, das im Schatten oder bei Nacht nicht abgedunkelt werden darf. Erschrick bitte nicht, wenn Du dann beim Hochladen der x-Datei in den Online-Katalog in der "Modell-Statistik" eine um 1 erhöhte Anzahl von "Materialien" findest. Denn "beleuchtete" und "unbeleuchtete" Flächen können nicht zusammen in einem Objekt verarbeitet werden. Auch wenn Du insgesamt nur eine Multitextur verwendest, wird diese für beleuchtete und unbeleuchtete Flächen jeweils als "separates" Material betrachtet. Schon deshalb muss der Überprüfungs-Mechanismus, der die "Qualität" des hochgeladenen Modells bestimmt, mindestens 3 Materialien zulassen, weil als drittes Material möglichereise noch jenes für (halb-)tranpsarente Flächen dazu kommt. So, nun hat mich Quackster mal wieder überholt. Ich lasse aber den Betrag trotzdem hier stehen. Viele Grüße BahnLand

Hallo EASY, das sieht ja schon sehr beeindruckend aus. Ich bin auf das Endergebnis schon sehr gespannt. Viele Grüße BahnLand

Hallo Schlagerfuzzi, es gibt verschiedene Möglichkeiten, einen Countdown zu vewenden. Hier ein paar Varianten aus meinem Anlagenbeispiel (Anfrage004.mbp): Klassischer Countdown-Aufruf mit bestimmter Zeitvorgabe (Gruppe "Kopfbahnhof Einfahrt"). Countdown-Start in Definition "Herantasten2", Countdown-Ausführung in Definition "Entkuppeln1" oder Countdown-Start in Definition "Aufrücken4", Countdown-Ausführung in Definition "Ausfahrbereitschaft4". In beiden Beispielen wird eine Aktion angestoßen, die erst nach Ablauf der vorgegebenen Zeit einmalig ausgeführt wird. Periodische Aktionsschleife mit Abbruch (ebenfalls Gruppe "Kopfbahnhof Einfahrt"). Countdown-Start in Definition "Herantasten2" mit automatischem "Neustart", Countdown-Ausführung in Definition "Herantasten2", die so lange wiederholt wird, bis das Abbruchkriterium in der Bedingung erfüllt ist. Dann wird der Countdown explizit gestoppt. Möglicher Anstoß derselben Aktionsfolge aus verschiedenen Definitionen heraus. Countdown-Start in Definition "Einfahrt3" (Gruppe "Streckenblock3") sowie in Definition "Freigabe Block2" ("Gruppe Streckenblock2"), Unmittelbare Countdown-Ausführung (Wartezeit = 0) in Definition "Zugstart3" (Gruppe "Streckenblock3"). Viele Grüße BahnLand

Sieht gut aus! Viele Grüße BahnLand

Hallo Schlagerfuzzi, wie Henry kann ich solche Herausforderungen nicht einfach an mir vorüber ziehen lassen, sondern muss selbst ausprobieren, was da alles geht. Henry war allerdings schneller, weil ich noch ein paar "Gimmiks" einbauen wolte. Doch nun ist auch meine Variante Deines Anfrage-Beispiels fertig. Ich habe in der Anlage die ankommenden bzw. abgehenden Gleisstränge miteinander verbunden und noch einen weiteren Zug darauf gestellt. Auf der freien Strecke gibt es zwei Blockabschnitte, die für die beiden Züge zusammen mit dem Kopfbahnhof-Gleisabschnitt (kurz "Kopfgleis") 3 Blockabshnitte ergeben, die von den Zügen im Blockverkehr hintereinander befahren werden. Im Kopfgleis wird die bisherige Zuglok wie bei Henry abgehängt und am anderen Ende des Zuges die Lok vom Bereitschaftsgleis angehängt. Nachdem der Zug mit der neuen Lok das Kopfgleis verlassen hat, fährt die unrsprüngliche Zuglok für ihren nächsten Einsatz in das Bereitschaftsgleis. Aufgrund des Zusammenfügens der bei beiden ursprüngklich freien Gleisenden vollziehen die Züge beim Umfahren des Kopfgleises eine 540°-Drehung, sodass die Loks nach einer Umrundung entgegengesetzt ausgerichtet sind. Daher sind die Loks den Zügen abwechselnd vorwärts und rückwärts vorgespannt, was sich auch auf das Vorzeichen der dem Triebfahrzeug zugewiesenen Geschwindigkeit auswirkt. Das Vorzeichen dieser Geschwindigkeit ist also eine variable Größe, die bei der Steuerung der Züge mit berücksichtigt werden muss. Weiters habe ich untershedliche Lok-Konfigurationen vor die Züge gespannt: Es gibt eine "einfache" Lok, eine Dampflok mit Schlepptender, der fallweise von der Lok hinterher gezogen oder voran geschoben wird, und eine Doppeltraktion aus 2 Lokomotiven als dritte Lok-Konfiguration. Sowohl bei der Dampflok mit Schlepptender als auch bei der Doppeltraktion sollen die beiden Fahrzeuge der im Kopfgleis auszutauschenden Lok-Konfigurationen nicht getrennt, sondern als zusammengehörende Einheit betrachtet werden. Trotzdem gibt es auch hier immer ein Fahrzeug, welches als das Triebfahrzeug ausgewiesen ist und damit als einziges in der Lok-Konfiguration eine Geschwindigkeit zugewiesen bekommt. Das "Zweitfahrzeug" wird als Wagen (Schlepptender der Dampflok) oder "Wagenlok" (zweite V100 der Doppeltraktion) mitgeführt. Die Zusammengehörigkeit wird dadurch gekennzeichnet, dass das Zweitahrzeug beim Triebfahrzeug in einer Objektvariable hinterlegt ist (<Lok>.Hinten, mit <Lok> als Platzhalter für das jeweilige Triebfahrzeug). Bei der Schlepptender-Dampflok ist der Tender immer "hinten". Bei der Doppeltraktion müssen beide Loks gleich ausgerichtet sein. D.h. bei beiden zeigt die "positive Geschwindigkeit" in dieselbe Richtung. Dann wird die vordere Lok als Triebfahrzeug und die hintere Lok als zugehöriges Zweitfahrzeug ausgezeichnet. Auch bei der "einfachen" Lok wird ein Zweitfahrzeug ausgewiesen. Nur wird hier die Lok selbst eingetragen. Dadurch ist es möglich, sowohl Einzelfahrzeuge als auch Lok-Konfigurationen aus 2 Fahrzeugen in der Ereignisverwaltung identisch zu behandeln (beim einfachen Fahrzeugen beziehen sich dann die Anweisungen für das zweite Fahrzeug einfach auf die Lok selbst). Wo wird nun der Bezug auf das Zweitfahrzeug benötigt? Beim Entkuppeln der Lok-Konfiguration vom Zug. Es darf nur die vordere Kupplung des Triebfahrzeugs und die hintere Kupllung des Zweitfahrzeugs deaktiviert werden, damit die beiden Fahrzeuge nicht voneinander getrennt werden. Damit auch beim zweiten Fahrzeug die "richtige" Kupplung als "hintere" Kupplung angesprochen wird, muss dieses dieselbe Ausrichtung wie das Triebfahrzeug besitzen. Beim präzisen Stoppen des Zuges über der Trennstelle im Kopfgleis, damit der Zug nach dem Abkuppeln der Lok-Konfiguration durch ein an dieser Stelle eingebautes "Sperrgleis" beim "Auffahren" der ablösenden Lok-Konfiguration "festgehalten" werden kann und nicht weitergeschoben wird. Diese Position des Zuges im Kopfgleis ist genau dann erreicht, wenn sich sowohl das Triebfahrzeug als auch das Zweitfahrzeug beim Überfahren des Sperrgleises nicht mehr auf dem davor liegenden "Haltegleis" befinden. Handelt es bei der in den beiden obigen Punkten betrachteten Lok-Konfiguration um eine einfache Lok, erreicht man durch die Identifizierung dieser Lok auch als "Zweitlok", dass diese Mechanismen auch dann mit denselben Algorithmen funktionieren. Doch nun zur Steuerung der Züge im Kopfgleis selbst. Grob gesehen ist es der gleiche Ablauf wie bei Henry's Realisierung. Im Detail ist sie jedoch etwas anders gelöst: Der Hauptunterschied ist das rote Sperrgleis (eine Weiche mit langem (durchgehendem) und kurzem (abgeschnittenem) Pfad. Steht die Weiche auf "lang", kann der Zug ungehindert darüber fahren. Steht die Weiche auf "kurz", wird der am "Eingang" der Weiche stehende Zug an der Weiterfahrt gehindert, weil es für den kurzen Pfad keine Fortsetzung gibt. Als es die Möglichkreit, die Kupplungen zu deaktivieren, im Modellbahn-Studio noch nicht gab, konnte man hiermit Züge entkuppeln, wobei der vordere Teil, der den "Eingang" in die Weiche bereits passiert hatte, nach dem Sperren weiterfahren konnte, während der hintere Teil durch die Sperre "festgehalten" wurde. Wenn der Zug hierbei jedoch nicht "ganz exakt" an der richtigen Stelle angehalten wurde, gab es beim Sperren unschöne "Bocksprünge". Deshalb wird nun für das Entkuppeln selbst die Eigenschaft der Kupplungs-Deaktivierung genutzt. Um zu verhindern, dass die auf der anderen Seite auffahrende "neue" Zuglok nach dem Ankoppeln den Zug so lange weiter schiebt, bis es eine Möglichkeit gibt, diesen über ein passendes Ereignis zu stoppen, wird das Sperrgleis trotzdem benötigt. Durch dessen Sperrung, nachdem die abgekoppelte Lok weggefahren, aber bevor die ablösende Lok aufgefahren ist, wird ein Weiterschieben des Zuges blockiert. Die restliche Logik entspricht im Wesentlichen jener von Henry, nur dass sie durch das Hinzufügen von Signalen und das Schließen des "Kreises" mit weiteren Blockabschnitten etwas "verfeinert" worden ist, und hierbei die unterschiedlichen Fahrtrichtungs-Ausrichtungen der Triebfahrzeuge und aus mehreren Fahrzeugen bestehende Lok-Konfigurationen berücksichtigt wurden. Die beigefügte Anlage wird mit dem Schalter rechts vorne gestartet und gestoppt. Nach dem Zurücksetzen des Schalters fahren die Züge noch weiter, bis sie - wenn auch möglicherweise in abweichender Fahrzeug-Anordnung - vor den Blocksignalen der Ringstrecke und im Bereitstellungsgleis für die "Ablöse"-Lok zum Stillstand gekommen sind. Ich wünsche beim Testen der beiliegenden Anlage und beim Studieren der Ereignssteuerung viel Vergnügen. Anfrage004.mbp Viele Grüße BahnLand

Hallo Quackster, oh jaaaaa! Meine Schwester hatte als (geschätzt) 7-8-Jährige eine sehr "intime" Bekanntschaft mit einem solchen Gefährt gemacht: Unser Vikar besaß eine Isetta. Eines Tages, als ich mit meiner Schwester unterwegs war, lief sie plötzlich unbedacht auf die Straße, als gerade unser Vikar daher "gebraust" kam. Glücklicherweise stieg der sofort "in die Eisen" (auf die Bremse), sodass die Isetta gerade so zum Stehen kam, dass meine kleine Schwester genau an der Stoßstange stand - die Arme "wie ein Engel" seitlich auf der Isetta-Tür ausgebreitet. Meine Schwester hatte dabei nicht einmal eine Schramme abbekommen. An den Schreck, der dem Vikar ins Geschicht geschrieben gewesen sein muss, und an die nachfolgende obligatorische Standpauke kann ich mich allerdings nicht mehr erinnern. Auch wenn mir damals - ich war ja selbst noch ein Kind - nicht bewusst war, welch einen riesigen Schutzengel meine Schwester gehabt hatte, und wie das Ganze auch anders hätte ausgehen können, ist mir dieses Szene - wenn auch etwas verblasst - bis heute in Erinnerung geblieben. In der Konfirmationszeit haben wir Konfirmanden unserem Vikar dann auch noch einen Streich gespielt: Das Gelände unserer Kirche war gegenüber der Straße etwas erhöht und durch ein kleines Mäuerchen abgegrenzt (dürfte etwa 60-80 cm hoch gewesen sein). Daneben gab es einen Parkstreifen, auf dem unser Vikar immer seine Isetta abgestellt hatte, wenn er in der Kirche war. Einmal nach dem Konfirmanden-Unterricht, als der Vikar danach noch in der Kirche zu tun hatte, ergiffen einige meine "Konfirmanden-Kollegen" die Chance, hoben die Isetta in gemeinsamer Anstrengung an und setzten sie - mit der Tür zum Mäuerchen gewandt - unmittelbar vor diesem ab. Und dann ab durch die Mitte .... ! Ich weiß bis heute nicht, wie der Vikar in seine Isetta kam. Jedenfalls war er am nächsten Tag wieder mit ihr unterwegs. Ja ja, das waren schon urige Gefährte, die da zu jener Zeit über unsere Straßen rollten. Da gab es noch das Goggo(mobil) (meine Tante hatte ein solches besessen), den Lloyd ("Leukoplastbomber"), den Messerschmitt Kabinenroller ("Schneewittchensarg") und den Janus von Zündapp. Letzterer besaß eine Front- und Hecktür ala Isetta, und die hinteren Passagiere saßen rückwärts im Auto. Ich freue mich schon auf das fertige MBS-Modell, das ganz bestimmt auch auf meinen Anagen zum Einsatz gelangen wird. Viele Grüße BahnLand

Hallo Michael, mein KFZ-Kennzeichen ist "M", also eine gaaaanz andere Ecke. Viele Grüße BahnLand

Hallo Michael, dass in Bild 3 die Wertzuweisung "$Haltegleis2.lok" für die Geschwindigkeits-Anzeige nicht funktioniert, liegt nicht an dieser Wertzuweisung, sondern daran, dass es das Objekt "Haltegleis2" auf Deiner Anlage nicht gibt. Damit kannst Du auch die Objektvariable "Haltegleis2.lok" im Bild 1 nicht setzen (diesen Fehler bekommst Du nur nicht mit). Gib mal irgendeinem Gleisstück auf Deiner Anlage den Namen "Haltegleis2", und Du wirst sehen, dass dann Bild3 sehr wohl funktioniert. Dass es dieses Gleis auf Deiner Anlage bisher nicht gibt, konnte ich nicht wissen. Und bei Deiner Korrektur kannst Du sogar auf die Variablen-Zuweisung in Bild 1 ganz verzichten (funktioniert so ja wegen dem nicht vorhandenen Objekt eh nicht). Wenn Du aber die hier festgestellte Geschwindigkeit in einer später auszuführenden Ereignisdefinition wiederverwenden möchtest, kommst Du um die Zwischenspeicherung in einer Variablen nicht herum. Wenn Du dafür dann eine Objekt-Variable verwendest (wie in Bild 1), musst Du allerdings sicherstellen, dass das Objekt auch wirklich existiert. Sonst nimm eine "einfache" Variable (ohne "."), da Du hier keine Abhängigkeit von einem Objekt hast (die aber manchmal gewünscht ist). Viele Grüße BahnLand

Hallo Michael, Um die EV kommst Du nicht herum. Aber dennoch ist es ganz einfach: Du benötigst im Prinzip nur eine Ereignisdefinition "Zug betritt Gleis", in der Du der einfahrenden Lok (oder der Lok des einfahenden Zuges) die Geschwindigkeit zuweist, die Du ihr vorab in einer Objektvariable zugeordnet hast. Im Bild siehst Du oben die vorab zugeordneten Höchstgeschwindigkeiten. Unten habe ich die Ereignisdefinition abgebildet. Das war's dann auch schon. Ich habe Dir auch noch die hier abgebildete Demo-Anlage beigelegt: Unterschiedliche Geschwindigkeiten.mbp Die anderen Ereignisdefinitionen, die Du da findest, sind "nur Beiwerk", um die Demo nachstellen zu können. Maßgebend für Dich ist nur die Ereignisdefinition "VMax", die sich auf das oben beige eingefärbte "Ausfahrt"-Gleis bezieht. Viel Spaß beim Ausprobieren wünscht BahnLand

Hallo Reinhard, de Bahnhof ist Dir wirklich sehr gut gelungen. Schade, dass Du das gesamte Modell verloren hast. Aber jetzt hast Du ja schon Routine. Da gehts es dann wahrscheinlich beim zweiten Versuch etwas schneller. Viele Grüße BahnLand

Hallo, Neo hat in das Modellbahn-Studio seinen "Video.Grabber" integriert (im Modellbahn-Studio zu finden unter "Plugins - Simulation - Video-Aufzeichnung"). Dieses Plugin schneidet die Einzelbilder des Programmablaufs mit, indem es die Animation des Modellbahn-Studios nach jedem Einzelschritt kurz anhält und eine Hardcopy des Szenarios macht. Durch dieses Verfahren wird garantiert, dass jedes Einzelbild der Animation tatsächlich "erwischt" und in dem aus den Einzelbildern erstellten Video auch tatsächlich angezeigt wird. Dadurch ist ein flüssiger Ablauf der Animation sebst dann gewährleistet, wenn der reale Ablauf bei normaler Geschwindigkeit wegen einer zu geringen FPS-Zahl "ruckelt". Lässt man dagegen ein externes Videoschnitt-Programm parallel zum Modellbahn-Studio mitlaufen, wird das Ruckeln bei geringer FPS-Zahl mit aufgezeichnet. Es wird sogar noch verschlimmert, da das Videoschnitt-Programm verständlicherweise Rechenleistung "absaugt", die dann dem Modellbahn-Studio selbst nicht mehr zur Verfügung steht. Anbei ein schon früher von mir veröffentlichtes Beispiel, das ich mit dem Aufzeichnungs-Plugin von Neo mitgeschnitten habe, und das in "real" nicht so flüssig dargestellt werden konnte. Viele Grüße BahnLand

Hallo zusammen, für alle, die die bisher schon mehrmals gelaufenen Diskussionsrunden bezüglich der Anzahl von Poygonen und Materialien bei aus Bordmittlen und alternativ mittels 3D-Modellierungsprogramm erstellten Modellen für das MBS und die Kriterien für deren Aufnahme in den Online-Katalog - sowie das "Fragezeichen"-Problem bei nicht im Online-Katalog hinterlegten Modellen nicht kennen, möchte ich hier die Problematik noch einmal zusammenfassen, ohne eine neue Diskussionswelle zu diesem Thema entfachen zu wollen. 3D-Modelle sind grundsätzlich aus Flächendreiecken (Polygonen) zusammengesetzt und mit Farben oder Texturen (beides Materialien) belegt. Je detailgetreuer ein Modell wiedergegeben werden soll, umso mehr Polygone sind für dessen Darstellung erforderlich. Je mehr Polygone ein Modell besitzt, umso mehr Arbeit müssen das auszuwertende Programm und insbesondere die Grafikkarte (bzw.die sie steuernde Grafik-Engine) aufwenden, um das Modell korrekt darstellen zu können. Nach Neo's Aussage können heutige Grafikkarten Tausende von Polygonen quasi "In einem Aufwasch" und damit sehr optimal bearbeiten, solange diese sich auf dasselbe Objekt beziehen. Werden jedoch für ein Modell verschiedene Materialien verwendet, muss für alle Bauteile des Modells, die jeweils mit einem eigenen Material versehen sind, ein separates Objekt erzeugt und in der Grafikkarte auch separat angesteuert werden. Damit belasten Modelle mit vielen unterschiedlichen Materialien die Grafikkarte in besonderem Maße und tragen somit wesentlich zur Reduzierung der Verarbeitungsgeschwindigkeit (FPS-Rate des Modellbahn-Studios) bei. Besitzt ein sehr detailreiches Modell mehrere zig-Tausend Polygone, lassen sich mit einem 3D-Modellierungsprogramm verschiedene Varanten desselben Modells mit unterschiedlicher Detailtiefe (und damit einer unterschiedliche Anzahl von Polygonen und Materialien) erstellen, die dann zusammen in Form von mehreren LoD-Stufen ("Levels of Details") dem in den Online-Katalog hochzuladenden Modell zugewiesen werden können. Das Modellbahn-Studio kann dann für dessen Darstellung in Abhängigkeit von der Entfernung des Modells von der betrachtenden Kamera die jeweils geeignete LoD-Stufe für dessen Darstellung auswählen: Modelle mit kurzer Entfernung zur Kamera füllen deren Blickfeld mehr aus als weiter entfernte Modelle. Deshalb werden im Nahbereich auch weniger Modelle von der Kamera erfasst. Die Darstellung dieser wenigen Modelle mit vollem Detailreichtum fällt also weniger ins Gewicht als bei Modellen in der Ferne, von denen sich sehr viele im Blickfeld der Kamera befinden können. Je weiter ein Modell von der Kamera entfernt ist, umso weniger Modell-Details können von der Kamera noch unterschieden werden. In diesem Fall reicht es aus, das Modell mit einer geringeren Detailtiefe (also mit einer entsprechend gröberen LoD-Stufe) darzustellen, was gegenüber der vollen Detailausprägung zu einer deutlichen Reduzierung des Verarbeitungsaufwands führen kann. Dadurch lassen sich bei gleicher Grafikleistung mehr Modelle darstellen, als wenn bei allen Modellen immer die volle Detailtreue auch dann, wenn sie eigentlich nicht sichtbar ist, berechnet werden müsste. Um das Problem der "zu vielen" Materialien zu entschärfen, kann man bei 3D-Modellierungsprogrammen mehrere Farben und Einzeltexturen zu einem Texturatlas (auch Multitextur genannt) zusammenfassen. Um die einzelnen Flächen des Modells dann mit dem korrekten Texturabschnitt zu belegen, wird die Textur auf jeder Fläche in die richtige Position geschoben und gegebenenfalls noch gestreckt. So ist es im Idealfall möglich, auch bei Modellen mit komplexer Oberflächen-Kolorierung mit einem Material auszukommen. In Summe hat man also bei Modellen, die mit einem 3D-Modellierungsprogramm erstellt werden, verschiedene Möglichkeiten, diese zugunsten einer performanten Grafik-Darstellung zu optimieren. Erstellt man nun ein Modell mittels Bordmitteln (d.h. aus den im Online-Katalog vorhandenen Grundkörpern), greifen diese Optimierungsmöglichkeiten nicht. Denn es gibt im Modellbahn-Studio nicht die Möglichkeit, das Modell in verschiedenen Detailierungsvarianten (d.h. mit unterschiedlich vielen Grundkörpern) zu bauen und diese dann als Detailierungsstufen für dasselbe Modell zu verwenden. Außerdem kann jedem Grundkörper nur maximal eine Textur (oder Farbe) zugewiesen werden, die dann für alle Oberflächen des Grundkörpers gleichermaßen verwendet wird. Diese kann man zwar insgesamt in 2 Richtungen skalieren. Es ist aber nicht möglich, sie auf den Oberflächen des Grundkörpers durch Verschieben individuell zu positionieren. Damit ist es bei Grundkörper-Modellen prinzipiell nicht möglich, eine gemeinsame Multitextur für unterschiedlich zu kolorierende Oberflächen zu verwenden. Nun gibt es zwar im Modellbahn-Studio bei Grundkörper-Modellen eine beim Hochladen in den Online-Katalog wirkende Optimierung, bei der die einzelnen Grundkörper-Objekte eines Bordmittel-Modells zu einem Objekt zusammengefasst werden. Diese Optimierung ist aber nur für solche Grundkörper wirksam, die mit demselben Material "bemalt" wurden. Die Anzahl der für ein Bordmittel-Modell separat darzustellenden Objekte wächst gezwungenermaßen mit der Anzahl der verwendeten Farben und Texturen (jede explizit spezifizierte Farbe ist wie jede verwendete Textur ein separates Material). Bezüglich der Polygonzahl hat Lobo gezeigt, dass man auch mit Bordmitteln (Grundkörpern) Modelle bauen kann, die sich mit gleichartigen Modellen, die mit einem 3D-Modellierungsprogramm erstellt wurden, durchaus messen lassen können. Voraussetzung für diesen "positiven" Vergleich ist allerdings, dass sämtliche Grundkörper-Obeflächen "sichtbare" Teile des Modells darstellen und das Bordmittel-Modell nicht mehr Materialien benötigt als das vergleichbare Modell aus dem 3D-Modellierungsprogramm. In allen anderen Fällen muss man leider davon ausgehen, dass die Darstellung des Bordmittel-Modells mehr Grafik-Leistung beansprucht. Nach meinen bisherigen Erkenntnissen wird die Version 4 des Modellbahn-Studios nicht unterscheiden, ob ein Modell mit einem 3D-Modellierungsprogramm erstellt oder aus Grundkörpern zusammengefügt wurde. Exakte Kriterien kenne auch ich noch nicht. Aber es wird wohl darauf hinaus laufen, dass neben der Anzahl der Polygone in stärkerem Maße die Anzahl der verwendeten Materialien ein Kriterium dafür sein wird, ob ein Modell im Online-Katalog für die Allgemeinheit freigegeben werden kann oder nicht. Privat (also unveröffentlicht) werden die Modelle immer im Online-Katalog abgelegt werden können. insbesondere wird es (nach meinem heutigen Kenntnisstand) auch mit der Version 4 möglich sein, eigene private Modelle im Online-Katalog als mbe-Dateien zu exportieren und damit anderen Hobby-Kollegen (z.B. hier im Forum als Datei-Anhang) zur Verfügung zu stellen, die sie dann wieder in ihren privaten Teil des Online-Katalogs importieren können. Dass es auf die hier veröffentlichten Bordmittel-Modelle eine relativ geringe Resonanz gibt, führe ich insbesondere darauf zurück, dass diese nicht "freizügig" auf Anlagen eingesetzt werden können, die man selbst im Online-Katalog "veröffentlichen" möchte. Denn auf jeder Anlage, die entweder im Online-Katalog für die Allgemeinheit freigegeben oder in Form einer mbp-Datei im Forum als Datei-Anhang zur Verfügung gestellt wurde, und die auf der Anlage platzierte Modelle enthält, die nicht im Online-Katalog für die Allgemeinheit freigegeben sind, werden bei allen Anwendern, welche die Anlage starten (außer beim Erbauer der Anlage selbst), diese Modelle als Fragezeichen dargestellt, solange nicht vom jeweiligen Anwender selbst die erforderlichen mbe-Dateien in den eigenen privaten Teil des Online-Katalogs importiert und dann die Fragezeichen durch diese ersetzt wurden. Es ist also für fremde Nutzer solcher Anlagen immer ein zusätzlicher Aufwand, die Anlage so in Betrieb zu setzen, wie es vom Anlagenbauer gedacht ist, es sei denn, dass dieser auf das Einbinden von Modellen, die im Online-Katalog nicht "veröffentlicht" sind, bei seinen freizugebenden Anlagen komplett verzichtet. Zur letzteren Spezies (die in der Regel auf die Verwendung von nicht im Kataolog öffentlich zugänglichen Modellen verzichtet) gehöre auch ich, weshalb auch von mir eher selten Reaktionen auf mit Bordmitteln erstellte Modelle im Forum zu finden sind. Nichtsdestotrotz bin auch ich von vielen Schmuckstücken begeistert, die da "allein mit Bordmitteln" geschaffen werden - auch wenn ich sie selbst auf meinen Anlagen, die ich veröffentlichen möchte, nicht einsetzen kann, ohne den anderen Anwendern das mühsame händische Ersetzen der Fragezeichen zuzumuten. Viele Grüße BahnLand