BahnLand

Hallo Schlagerfuzzi, wenn Du eine "0" weg nimmst und "Schluchten" durch "Täler" ersetzt, wirst Du im Tessin fündig. Da gibt es nämlich das "Centovalli", das sich von Locarno am Lago Maggiore in der Schweiz bis Domodossola in Italien erstreckt. Auf den beiden Google-Darstellungen unten kann man sehr gut erkennen, wie zerklüftet dieses Tal (mitsamt seinen Seitentälern) ist. Blick vom Grenzort Camedo (unten) nach Osten bis Locarno (ganz oben rechts) Blick nach Westen von Locarno (unten) in Richtung Domodossola Durch das Tal der "100 Täler" fährt auch eine Eisenbahn: die Meter-spurige Centovalli-Bahn. Als ich 1972 in Costa (das ist auf dem ersten Bild der "am Berghang klebende" Ort links oberhalb von dem im Tal liegenden Camedo) im Urlaub war, war ich zwar am richtigen Ort, aber zu falschen Zeit. Deshalb konnte ich damals die dortige Eisenbahnbrücke nur ohne Zug fotografieren. Viele Grüße BahnLand

Was es nicht alles gibt ... staunt ein vollkommener Feuerwehr-Laie. Die von Dir "vorgebogenen" Schläuche kommen ja erst beim Einsatz so richtig zur Geltung. Das hast Du mit Deinen Fotos bewiesen. Hut ab! Viele Grüße BahnLand

Hallo SputniKK, ich stimme Wüstenfuchs zu. Das Fahrzeug ist eindeutig ein Triebwagen-Anhänger und gehört daher in die Triebwagen-Sparte - auch wenn das in der Vergangenheit für etiche Beiwagen zu Triebwagen (z.B. ICE und TEE-Triebzug VT11) nicht praktiziert wurde.. Viele Grüße BahnLand

Hallo Viciente, "Wehret den Anfängen!" Viele Grüße BahnLand

Hallo, ich halte die konsequente Kleinschreibung - vielleicht auch wegen meines fortgeschrittenen Alters - ebenfalls als ziemlich gewöhnungsbedürftig und beim Lesen als (subjektiv) unangenehm. In meiner Studienzeit kursierte bei uns eine Glosse zur "Rationalisierung in der Rechtschreibung", die diese "Unsitte" bereits damals (in den 1970er Jahren) aufs Korn nahm, und die eigentlich sehr gut hierher passt: Rationalisierung in der Rechtschreibung Der Technikeinsatz auf dem Gebiet der Textverarbeitung hat zwar beachtliche Zeit- und damit Kostenersparnis gebracht, aber der Rationalisierungserfolg könnte ungleich größer sein, wenn endlich die Regeln für die deutsche Rechtschreibung vereinfacht würden. Hierzu bietet sich folgendes 6-Stufen-Programm an: Erster Schritt: Wegfall der Großschreibung. einer sofortigen einführung steht nichts im weg, zumal schon viele grafiker und werbeleute zur kleinschreibung übergegangen sind. zweiter schritt: wegfall der dehnungen und schärfungen. dise masname eliminirt schon di gröste felerursache in der grundschule. den sin und unsin unserer konsonantenverdopelung hat onein nimand kapirt. driter schrit: v und ph werden ersezt durch f, z und sch durch s. das alfabet wird um swei buchstaben redusirt. sreibmasinen und sesmasinen fereinfachen sich. wertfole einsaskräfte könen der wirtsaft sugefürt werden. firter srit: q, c und ch werden ersest durch k, j und y durch i, pf durch f. iest sind son seks bukstaben drausen, und di sprake ist woltuend klar. di sulseit kan sofort fon neun auf swei iare ferkürst werden. anstat aksig prosent rektsreibunterikt könen nüslikere und kualifisirtere fäker wi fisik, kemi, reknen mer geflegt werden. fünfter srit: wegfal fon ä, ö und ü. ales uberflusige ist iest ausgemerst. di ortografi ist wider slikt und einfak. naturlik benotigt es einige seit, bis dise fereinfakung uberal riktig ferdaut ist, fileikt sasungsweise ein bis swei iare. dan folgt ein sekster srit: p ersest durk b, g auk durk k, t ersest durk d, und warum ersest man nikt w durk f? fen ale dise fordsride durkkesesd sind, durfde als naksdes sil di fereinfakunk der nok sfirikeren und unsinikeren deudsen kramadik anfisird ferden. ein bar lesde susassride durfen nikd felen, um das srifdbild nok edfas feider su bereiniken: adidifer sibder srid: ersas fon x durk ks. fi einfak sbrake dok sein kan: mid der ferbanunk eines lesden ferfliksden buksdabens aus alen deksden had sik iesd das alfabed fon ursbrunklik dreisik buksdaben (einslislik der umlaude und dem sarfen s) auf nurmer funfsen buksdaben halbird. di ferblibenen buksdaben sind abdefhiklmnorsu. adidifer akder srid: fekfal aler saseiken. fer kamfde in der sule nikd mid der korekden sesunk fon bunkd koma und semikolon farum solde man das alde sbrikford er reded one bunkd und koma nikd auk in di srifdform einflisen lasen ansdad den deksd durk unrekelmasike underbrekunken su ferunsdalden kan man iesd den bekrif flisdeksd fordlik nemen Für alle, denen dieser Text nun doch zu schwierig zum Lesen ist, das Ganze nochmal in "klassischer Schreibweise": Rationalisierung in der Rechtschreibung Der Technikeinsatz auf dem Gebiet der Textverarbeitung hat zwar beachtliche Zeit- und damit Kostenersparnis gebracht, aber der Rationalisierungserfolg könnte ungleich größer sein, wenn endlich die Regeln für die deutsche Rechtschreibung vereinfacht würden. Hierzu bietet sich folgendes 6-Stufen-Programm an: Erster Schritt: Wegfall der Großschreibung. Einer sofortigen Einführung steht nichts im Weg, zumal schon viele Grafiker und Werbeleute zur Kleinschreibung übergegangen sind. Zweiter Schritt: Wegfall der Dehnungen und Schärfungen. Diese Maßnahme eliminiert schon die größte Fehlerursache in der Grundschule. Den Sinn und Unsinn unserer Konsonantenverdoppelung hat ohnehin niemand kapiert. Dritter Schritt: v und ph werden ersetzt durch f, z und sch durch s. Das Alphabet wird um zwei Buchstaben reduziert. Schreibmaschinen und Setzmaschinen vereinfachen sich. Wertvolle Einsatzkräfte können der Wirtschaft zugeführt werden. Vierter Schritt: q, c und ch werden ersetzt durch k, j und y durch i, pf durch f. Jetzt sind schon sechs Buchstaben draußen, und die Sprache ist wohltuend klar. Die Schulzeit kann sofort von neun auf zwei Jahre verkürzt werden. Anstatt achtzig Prozent Rechtschreibunterricht können nützlichere und qualifiziertere Fächer wie Physik, Chemie, Rechnen mehr gepflegt werden. Fünfter Schritt: Wegfall von ä, ö und ü. Alles Überflüssige ist jetzt ausgemerzt. Die Orthographie ist wieder schlicht und einfach. Natürlich benötigt es einige Zeit, bis diese Vereinfachung überall richtig verdaut ist, vielleicht schätzungsweise ein bis zwei Jahre. Dann folgt ein Sechster Schritt: p ersetzt durch b, g auch durch k, t ersetzt durch d, und warum ersetzt man nicht w durch f? Wenn alle diese Fortschritte durchgesetzt sind, dürfte als nächstes Ziel die Vereinfachung der noch schwierigeren und unsinnigeren deutschen Grammatik anvisiert werden. Ein paar letzte Zusatzschritte dürfen nicht fehlen, um das Schriftbild noch etwas weiter zu bereinigen: Additiver siebter Schritt: Ersatz von x durch ks. Wie einfach Sprache doch sein kann: Mit der Verbannung eines letzten verflixten Buchstabens aus allen Texten hat sich jetzt das Alphabet von ursprünglich dreißig Buchstaben (einschließlich der Umlaute und dem scharfen ß) auf nurmehr fünfzehn Buchstaben halbiert. Die verbliebenen Buchstaben sind abdefhiklmnorsu. Additiver achter Schritt: Wegfall aller Satzzeichen. Wer kämpfte in der Schule nicht mit der korrekten Setzung von Punkt, Komma und Semikolon? Warum sollte man das alte Sprichwort: Er redet ohne Punkt und Komma, nicht auch in die Schriftform einfließen lassen? Anstatt den Text durch unregelmäßige Unterbrechungen zu verunstalten, kann man jetzt den Begriff Fließtext wörtlich nehmen. Viele Grüße BahnLand

Hallo Hans, kennst Du dieses Heft von 2005? In ihm ist die von Modellbahnspass genannte Anlage ausführlich beschrieben. Ich kann Dir gegebenenfalls via Email ein paar Scans zuschicken. 2009 und 2016 habe ich mit Google Maps die Gleisanlagen des Stuggarter Hauptbahnhofs mitsamt seinem Gleisvorfeld "abgescannt". Der Scan von 2016 dürfte sich hierbei von der aktuellen Ansicht nicht viel unterscheiden. Die Ansicht von 2009 könnte ich Dir aber auch zur Verfügung stellen, falls Du Interesse daran hast. Noch ein kleiner Hinweis zu Deiner Beschreibung: Die Bahn von Stuttgart nach Bad Cannstatt überquert nach dem Verlassen des Rosenstein-Tunnels nicht den Main (da sträuben sich mir als unweit von Stuttgart gebürtigem Schwaben die Haare ), sondern den Neckar! Viele Grüße BahnLand

Hallo Hans, von oberen Geländer links (da, wo die 3 Güterwagen stehen, aber im Bild etwas rückwärtig), habe ich mal auf die Strecke zwischen Stuttgart Hbf und Bad Cannstatt (kurz vor dem Rosenstein-Tunnel) hinunter fotografiert (wie man sieht, war ich leider nicht "allein" ). Das war vor knapp 47 Jahren. Im Vergleich zum aktuellen Google-Bild hat sich da seither nicht viel verändert. Dies wird jedoch mit "Stuttgart 21" nicht so bleiben und daher bald "Geschichte" sein. Viele Grüße BahnLand

Hallo zusammen, die nachfolgende Liste ist ein Versuch, einmal alle bisher eingegangenen Festure-Wünsche zum Thema "Ereignisverwaltung" an einer Stelle zusammenzufassen. Die Liste besteht aus den Feature-Wunsch-Überschriften, die gleichzeitig als Links zu den zugehörigen Originalbeiträgen realisiert sind. Natürlich kann ich nicht garantieren, dass ich möglicherweise den einen oder anderen Feature-Wunsch-Beitrag übersehen habe. Die Liste sollte dennoch "weitgehend" vollständig sein. EV-steuerbare Blickwinkel-Einstellung der Kamera Abfrage des Kupplungszustandes per EV deaktivierte Objekte EV - Geschwingigkeitsabhängigkeit Bremsen und Beschleunigen Funktion "Verbindung" für Signale über EV steuern Geschwindigkeitsübernahmen bremsschienen und Ev Ereignis/Gruppe aktivieren/deaktivieren in EV Variablen der Ereignisverwaltung "gesammelt" löschen Suchfunktion für Ereignisverwaltung erweitern Indirektionen mit Variablen in der Ereignisverwaltung Objektaufruf per EV Raise Event Function EV - Add "ALL" and/or Same Name Conditions Native Variables and Properties Treeview Variables in EV Zufallszahlen per Variable Kupplungsereignis EV Export, Editieren und Import EV-Ereignis Bewegung Alte Wünsche wiederbelebt Eingabefeld und EV-Ereignis Signalsteuerung mittels Variable Ausgabe des Fahrzeug-Namens (nicht Lok) als zusätzlichen Trigger-Wert beim Ereignis "Zug betritt/verlässt Gleis" Neues Kommando "Wagen steht auf Gleis" Entkupplungsgleis (Ereignis Wagon) Random auf Bereich erweitern Wertzuweisung an dynamisch bstimmte Objektvariable Variable "_Time" etwas anders? Ereignis Lokstart Lokgeschwindigkeit als Auslöser für die EV Allgemeine Objektaktionen EV-Ergänzung Zugriff auf Ereignisverwaltung Beschleunigen/Abbremsen von Loks Lokgeschwindigkeit als Bedingung für EV Arbeiten mit der EV Druckfunktion für die EV Ereignisse für ganze Gleisgruppen Gleis-Abfrage, welches Rollmaterial auf dem Gleis steht sortierte gleisnamen in ev Zufallserzeugung in der EV Aktuelle Kamera auslesen Kamera-Aktivierung durch Ereigisverwaltung wahlweise ausschalten Variable für Nachtschaltung Kamera "Verfolgen..." Ausgabe der Koordinaten in der EV RunOnce in der EV Eingang über Event Management Ereignisverwaltung Animation vor.- oder rückwärts in der EV Idee für die EV-Überarbeitung Kombinierte Bedingungen in der EV EV und manuelle Variablenänderung Merkfunktion für die EV EV + Dropdownfelder Zusammengesetzte Variablen Trigger-Übersicht zus. Bedingung Timer aktiv Aktionsfenster in EV Event bei Animation Stop Skalierung von Modellen über die Ereignisverwaltung Andocken per Ereignisverwaltung Ansprechnamen für Ereigsnisteuerung Entkuppeln Bedingungen sind nicht erfüllt kenntlich machen Auf der Drehscheibe per Ev. eine Lok anhalten Import EV Einen noch für die Ereignissteuerung Erweiterte Zusatzbedingungen in der Ereignisverwaltung Wünsche für die Ereignissteuerung - neue Auslöser und Aktionen Trace für die Ereignisverwaltung Ereignis/Gruppe Fenstergrösse Einlesen außerhalb veränderter Definitionen der Ereignisverwaltung Variablen-Initialisierung Fenster Ereignissteuerung Variablen Ein bisschen Automatik wäre schön Handhabung der Ereignissteuerung Ereingissteuerung, erweitern. Zug/Wagen steht auf einem Gleis Ereignissteuerung : Kommentare Ereignissteuerung, Austausch von Objekten Aktion suchen Multischaltung Position Ereignissfenster Ereignissteuerung : Zähler Ereignissverwaltung Ausdrucken Ereignis-gesteuerte Kamera-Umschaltung zeitweise deaktivieren Kameras ereignisabhängig aktivieren Wenn man die Liste durchgeht, wird man schnell feststellen, dass es etliche "Dubletten" gibt, die man hätte vermeiden können, wenn es eine solche (eventuell sogar automatisch und dynamisch erzeugte) Liste schon früher gegeben hätte. Ferner ist mir persönlich aufgefallen, dass man bei vielen Überschriften auf Anhieb nicht erkennen kann, um welches Anliegen es sich hierbei konkret handelt. Deshalb könnte ich mir vorstellen, dass man eine solche Liste mit einer kurzen Stichwort-Liste für jeden Eintrag ergänzt, welche das jeweilige Anliegen konkretisiert - oder zukünftig gleich eine "selbst-erklärende" Überschrift wählt. Ich habe mir die Inhalte der oben aufgeführten Feature-Wünsche nicht im Einzelnen angeschaut, sondern im Wesentlichen einfach die Überschriften kopiert. Deshalb sind hier auch etliche Wünsche enthalten, die bereits realisiert sind. Dennoch halte ich es sinnvoll, auch diese THemen hier einzubinden, damit der Betrachter dieser Liste sofort weiß, dass diese Features nicht mehr als Wunsch formuliert zu werden brauchen. Ich würde daher vorschlagen, dass eine solche Liste für jeden Titel auch noch einen Eintrag "erledigt/offen/nicht realiert" enthält, mit dem der Status des Feature-Wunsches sofort ersichtlich ist. Und natürlich halte ich es bei einer solch großen Liste für sinnvoll, dass man hier gleichgeartete (d.h. ein gleiches Thema betreffende) Beiträge gruppiert. Dies könnte beispielsweise durch die oben angesprochene Stichwortliste geschehen, die man als "Kategorisierung" ansehen könnte. Hierbei würde jedes "Sichwort" als Kategorie interpretiert, in der alle Beiträge, denen dieses Stichwort zugeordnet ist, zusammengefasst würden. Beiträge mit mehreren "Kategorie-Stichworten" würden dann allen diesen Kategorien zugeordnet. Und die Forensoftware könnte möglicherweise - falls direkt einstellbar oder durch den Anbieter des Forums entsprechend programmierbar - die Kategorisierung (Gruppierung) nach diesen Stichworten dann gleich automatisch erledigen. Damt möchte ich es aber für's erste gut sein lassen. Ich möchte mich hier schon einmal für die bereits zugewiesenen "Gefällt mir"-Klicks bedanken, die nur dadurch möglich waren, dass ich schon ziemlich am Anfang der Liste versehentlich auf den "Absende-Knopf" gekommen bin. Die Liste ist nun (hoffentlich) vollständig. Viele Grüße BahnLand

Hallo Schlagerfuzzi, Du kannst die Oldtimer gerne mal reinstellen. Mal sehen, was Du so geknipst hast. Das könnte dann vielleicht Qusckster reizen. Ich bin nicht so der Autobauer, da ich mehr auf Schienenfahrzeuge stehe. Aber auch da gibt es "Oldtimer" . Viele Grüße BahnLand

Hallo Frank, ich persönlich würde für eine individuelle Steuerungsmöglichkeit plädieren, die ja nach Deiner Erzählung auch beim Miniatur-Wunderland angewendet wurde. Dies liegt bei mir einfach daran, dass ich Anlagen möglichst vorbildnah gestalten möchte. Und da gehen einfach nicht alle Lichter überall gleichzeitig an oder aus. Hierzu ein konkretes Beispiel aus dem Fahrzeugbereich: Bei abgestellten Zügen oder parkenden Auzos gehen nicht mit der Dämmerng automatisch die Lichter an. Sie bleiben die gesamte Zeit des "Stillstands" aus. Anderes Beispiel: Wenn jemand einen U-Bahnhof nachbilden möchte, leuchten hier die Lampen in der U-Bahn-Station oder jene der durchfahrenden Züge auch bei Tag. Denn hier gibt es kein Tageslicht. Erst wenn eun U-Bahn-Zug möglicherweise aus dem Untergrund heraus ans Tageslicht gelangt, wird (bei Tag) seine Beleuchtung ausgeschaltet. Beide dargestellten Szenarien lassen sich mit einem "globalen" Ein-Ausschalter für die Beleuchtung nicht realistisch darstellen. Viele Grüße BahnLand

Hallo Ralf, da bei der Drehscheibe bezüglich des Gleises nicht zwischen der "Brücke" und den Gleisstummeln drum herum unterschieden wird, sondern die Drehscheibe nur insgesamt als "Gleis" identifiziert wird, wirst Du über "Zug betritt Gleis" oder "Zug verlässt Gleis" nicht exakt bestimmen können, wann eine einfahrende Lok das Brückengleis "betritt" oder das überfahrene Stummelgleis verlässt. Du kannst das Problem aber trotzdem lösen, indem Du mit dem Ereignis "Zug verlässt Gleis" für das "Strahlengleis" arbeitest, über welches die Lok auf die Drehscheibe auffährt. Allerdings musst Du dann dieses Ereignis für alle Strahlengleise definieren, die an die Drehscheibe angeschlossen sind. Im Einzelnen gehst Du dann wie folgt vor: Lasse die Lok, die auf die Drehscheibe fahren möchte, von jedem Strahlengleis aus immer mit derselben Geschwindigkeit einfahren. Definiere dann für jedes Strahlengleis das "Zug verlässt Gleis"-Ereignis mit der Zusatzbedingung "Lok/Wagen steht auf einem Gleis, Lok/Wagen = Auslöser 1:Lok, Gleis = Drehscheibe" (dies ist wichtig, damit das Ereignis nicht ausgelöst wird, wenn die Lok das Strahlengleis in die andere Richtung von der Drehscheibe weg verlässt). WEise diesem dann einen Countdown-Aufruf als Aktion zu, z.B. "Countdown starten, Name = Halte-Countdown, Dauer = n Sekunden" (auf das "n" komme ich später zurück). Der Countdown ist für alle Strahlengleise derselbe. D.h. der Name des Countdowns ist für alle Strahlengleise identisch. Deshalb benötigst Du nun auch nur eine einzige Countdown-Ereignisdefinition der Form "Countdown läuft ab, Name = Halte-Countdown", die für die Einfahrt aus jedem beliebigen Strahlengleis zur betrachteten Drehscheibe gleichermaßen aktiviert wird. Hiier trägst Du dann als Aktion "Lokgeschwindigkeit setzen, Lok = [Alle Loks], Gleis = Drehscheibe, Geschwindigkeit = 0 mm/s" ein. Wie groß das "n" für die Dauer des Countdown-Aufrufs zu wählen ist, musst Du selbst durch Versuche herausfinden. Du wirst aber sicher nach wenigen Versuchen die richtige Dauer herausgefunden haben, damit die Lok vor dem Anhalten das Stummelgleis der Einfahrt verlassen, aber das gegenüberliegende Stummelgleis noch nicht erreicht hat, also komplett auf der Drehscheibenbrücke steht. Probier es einfach mal aus. Bitte beachte, dass dann, wenn für die Loks die Eigenschaft "Weichen freischalten" gesetzt ist (dies ist die Voreinstellung), beim "Betreten" der Drehscheibe diese automatisch auf das Strahlengleis der auslösenden Lok eingestellt wird, und zwar unabhängig davon, ob gerade eine Lok von einem anderen Strahlengleis ein- oder ausfährt. Hier bist Du gefordert,,zu verhindern, dass mehrere Loks gleichzeitig auf die Drehscheibe fahren wollen. Eine Möglichkeit, dies zu verhindern, sind sogenannte "Sperrgleise". Bitte gib einmal "Sperrgleis" in das Suchfeld ein. Dann findest Du etliche Beiträge zu diesem THema. Viele Grüße BahnLand

Hallo Neo, dann werden wir Modellbauer diese "Lücke" wohl oder übel irgendwie überbrücken müssen. Da ich natürlich heute nicht weiß, wie die neue Funktionalität aussehen wird, und wie diese im Modell zu realisieren ist, gehe ich davon aus, dass ich meine vorher veröffentlichten Modelle für den Einbau dieser neuen Funktionalität dann sowieso nochmal anpacken muss. Insofern spielt es vermutliich auch keine Rolle, ob ich die im RAe realisierten Animationen bereits jetzt oder erst dann ausbaue, wenn die neue Funktionalität zur Verfügung steht. Denn ich hoffe, dass Du die Animationen nicht insgesamt "abschaltest". Für den Anwender wird es dann so oder so eine inkompatible Änderung in der Steuerung der Animation über die EV geben. Viele Grüße BahnLand

Hllo, vielleicht sollten wir eine Liste von Stichworten aufstellen, was bisher an Verbesserungs- und Vereinfachungs-Vorschlägen für die EV vorgebracht wurde (mit entsprechenden Links auf die originalen Beiträge). Aber vielleicht hat das ja auch Neo schon für sich gemacht. Jedenfalls freut es mich, dass Neo bereit ist, auch noch in V4 (obwohl der große Umbau der EV erst für V5 vorgesehen ist) die Realisierung nicht zu aufwendiger Veresserungsvorschläge in einem Update zu berücksichtigen. Viele Grüße BahnLand

Hallo Neo, Leider kann ich selbst nicht feststellen, wie häufig Modelle von mir im Modellbahn-Studio von anderen Anwendern geutzt werden oder wurden. Aber als ich seinerzeit meine "Lichtscheiben" für die Lokomotiv-Scheinwerfer im Online-Katalog bereitstellte, hatte ich doch einige positive Resonanz bekommen. Insofern kann ich mich hier Deiner Meinung nicht anschließen. Bei der Integration der animierten Lichter in das Modell hat mich natürlich die technisch Machbarkeit gereizt. Av´ber es war damit auch die Absicht verbunden, die bisherigen Lichtscheiben, die jede für sich ein separates Modell darstellen, und die daher auch von der Grafikkarte jeweils separat verarbeitet werden müssen, überflüssig zu machen. Uns Modellbauer davon abzuraten, die entsprechenden Animationen in die Modelle einzubauen, widerspricht also Deinem Ziel, auf Modelle, die als Ergänzng an andere Modelle "angeheftet" werden, möglichst zu verzichten, wenn der Modellbauer die dadurch abgebildete Funktionalität beibehalten möchte. Und auch da müssen diese jeweils als separates "Lichtsignal" realisierten Lampen explizit von Hand oder über die EV geschaltet werden. Du weißt schon, dass dies eine inkompatible Änderung ist, die sich auch auf bestehende Anlagen auswirkt (wo diese Steuerung via EV bereits eingebaut ist). Und es ist schon eine gravierender Unterschied, ob ein Nutzer keine Animationen abspielen muss (das ist bereits heute der Fall) oder nicht mehr kann. Letzteres ist für die betroffenen Nutzer ein Rückschritt in der Funktionalität, solange nicht eine entsprechende "Ausweich-Funktionalität" zur Verfügung steht. Wieso muss diese Funktionalität ausgebaut werden, solange sie noch nicht auf eine andere Weise angeboten wird? Und für den Fall, dass der Nutzer auf diese Funktionalität nicht selber kommt, gibt es ja immer noch die Kurzbeschreibung für das Modell, die von uns Modellbauern ja auch intensiv genutzt wird. Ich habe mal nachgeschaut, bei welchen "vordefinierten" Animationen heute das Automatik-Auswahlkästchen vorhanden ist, das Du in MBS V4 abschaffen möchtest: _AnimaRunPositive und _AnimRunNregative Wenn diese Funktionalität nur noch "automatisch" abgespielt werden kann, werden bei den Zügen die Spitzen- und SChlusslichter vor jedem Halt zeigenden Signal ausgehen. Selbiges gilt für beleuchtete Straßenbahrzeuge vor jeder roten Ampel. _AnimRun Über diese Animation gesteuerte Stromabnehmer werden bei jedem Zughalt - sei es bei einem Halt im Bahnhof oder vor einem Halt zeigenden Signal - abgesenkt. Dies entspricht nun wirklich nicht dem Vorbild. Außerdem gibt es hier nicht die Möglichkeit, zwischen verschiedenen Stromabnehmern eines Triebfahrzeugs auszuwählen: Entweder werden die Stromabnehmer alle synchron bewegt, oder ein nicht in die Animation aufgenommener Stromabnehmer bleibt für immer unbeweglich. _AnimBarrier Diese für Bahnschranken vorgesehene Animation reagiert im Automatik-Modus ausschließlich auf die Annäherung oder Entfernung eines Zuges mit sehr geringer "Sensor-Reichweite". Dies führt bei mehrgleisigen Bahnübergängen dazu, dass nur Züge auf dem "nächstgelegenen" Gleis erfasst werden und die Schranken auf das Passieren eines ZUges auf einem entfernteren Gleis überhaupt nicht reagieren. Ich habe hierzu eine kleine Demo-Anlage gebaut, bei der ich jedoch stets auf Schranken-Paare zurückgreifen musste, weil ich im Online-Katalog keine "Einzelschranken" gefunden habe, welche die "_AnimBarrier"-Animation eingebaut haben. AnimBarrier.mbp Deshalb bitte immer nur die "äußeren" Schranken beachten und über die "inneren" Schranken hinwegzusehen! Vorne in der Mitte befindet sich ein Bahnübergang von Seehund für mehrere Gleise. Sein Mittelpunkt (= Position des "Sensors") befindet sich im Bereich des mittleren Gleises. Passiert nun ein Zug auf einem äußeren Gleis den Bahnübergang, bleiben die Schranken geöffnet, weil der "Sensor" zu kurz greift. Hinten links habe ich zwei "zweigleisige" Bahnübergänge von Seehund so positioniert, dass jeder 2 Gleise "abdeckt". Hierdurch sind zwei Schranken zwischen den Gleisen positioniert, die hier "wegzudenken" sind. Da sich hier der "Sensor" jedes Bahnübergangs in der Mitte zwischen zwei benachbarten Gleisen befindet, wird die Schließung durch beide Gleise ausgelöst. Passiert ein Zug das mittlere Gleis, werden daher beide Schranlkenanlagen geschlossen. Wird dagegen ein äußeres Gleis befahren, bleibt die SChanke für das andere äußere Gleis geöffnet. Beim dritten Beispiel hinten rechts habe ich zweimal die eingleisige Schrankenanlage aus dem "Grundausbau" jeweils für die beiden äußeren Gleise eingebaut. Hier wird jeweils nur eine Schrankenanlage geschlossen, wenn ein Zug das zugehörige äußere Gleis passiert. Wird das mittlere Gleis befahren, bleiben beide Schrankenanlagen geöffnet. Bei einelnen Schrankenbäumen würde man denselben Effekt feststellen können, wenn es diese mit der _AnimaBarrier-Animation gäbe. Aber hier wurde - meines Erachtens eben gerade wegen dieser Nebeneffekte - auf die Verwendung der _AnuimBarrier-Animation verzichtet und stattdessen eine "nicht-vordefinierte" Animation eingebaut, die man nun über die EV gezielt steuern kann, aber auch über die EV oder von Hand gezielt steuern muss. Wenn Du nun die Abschaltbarkeit der Automaik ausbaust, ohne gleichzeitig eine Alternative anzubieten, sind die Modellbauer gezwungen, "private" Animationen anzubieten (für die es dann eben gruundsätzlich keine Automatik gibt), wenn sie auf die besagten Animationen nicht ganz verzichten wollen. Als ich diesen Satz laß, habe ich zuerst einen Luftsprung gemacht und dachte, dass die obigen Gedanken nun überflüssig werden, ... ... aber dieser Nachsatz hat mich dann sofort wieder auf den Boden der Tatsachen zurückkehren lassen. Es ist ja schön, dass man mit den Gleisen ab V4 als Modellbauer jene Freiheit zur Verfügung hat (wir haben ja auch schon sehnlichst darauf gewartet), die offenbar für andere Modell-Typen in V4 noch nicht zur Verfügung stehen wird. Aber warum wird dann die alte Funktionalität schon vorab abgeschaltet? Ich kann nicht verstehen, warum alte Programmierpfade nicht solange noch beibehalten und durchlaufen werden können, bis die sie ersetzenden Programmierpfade fertiggestellt sind. Was hindert Dich daran, alte und neue Programmierpfade für eine Übergangszeit nebeneinander stehen zu lassen und mit einer "Weiche" zu versehen? Du kannst ja die alten Funktionalitäten mit dem Vermerk versehen, dass diese Teilfunktionen in der vorliegenden Form nicht mehr weiterentwickelt und gewartet werden, weil für sie in kurzfristiger Zeit eine funktionell verbesserter Ersatz vorgesehen ist. Das ist allemal besser, als eine bestehende Funktionalität einfach (zumindest zeitweise) ersatzlos zurückzuziehen. Viele Grüße BahnLand

Hallo Neo, ich habe jetzt in den DirectX-Exporter einen zusätzlichen Zähler für die Zuordnungs-Tripel "Eckpunkt-Koordinaten + Textur-Koordinaten + Normalenvektor-Koordinaten" eingebaut, der sich jedoch nicht auf die zu erzeugende x-Datei auswirkt, und bin für den hier diskutierten Speisewagen auf folgendes Ergebnis gekommen: Aufbereitet: 28 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen - insgesamt: 15902 Flaechen, 41058 Eckpunkte, 52688 Polygone, - : 1470 Normalen-Vektoren, 2 Materialien, 1 Texturen - : 76778 Eckpunkt-Textur-Normalenvektor-Zuordnungen Kannst Du bitte überprüfen, ob die von mir berechnete Zahl mit jener, die Du beim import des Modells festgestellt hast, übereinstimmt? Wenn ich die Verdoppelung des Innenraums weglasse, bekomme ich folgende Ergebniswerte: Aufbereitet: 24 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen - insgesamt: 9960 Flaechen, 26074 Eckpunkte, 33954 Polygone, - : 1297 Normalen-Vektoren, 2 Materialien, 1 Texturen - : 46988 Eckpunkt-Textur-Normalenvektor-Zuordnungen Wenn ich dann noch eine Kantenglättung durchführe, erhöht sich zwar die Zahl der Normalenvektoren, aber die Zahl der Zuordnungs-Tripel reduziert sich wie von Dir beschrieben trotzdem. Aufbereitet: 24 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen - insgesamt: 9960 Flaechen, 26074 Eckpunkte, 33954 Polygone, - : 1992 Normalen-Vektoren, 2 Materialien, 1 Texturen - : 37304 Eckpunkt-Textur-Normalenvektor-Zuordnungen Alledings habe ich es bei diesem Test mit der Kantenglättung etwas übertrieben. Ich werde daher bei dem in den Katalog hochzuladenden Modell etwas "behutsamer" vorgehen und deshalb etwas mehr Eckpunkt-Textur-Normalenvektor-Tripel in Kauf nehmen (ich bleibe ja dann auf jeden Fall unter den 46988 aus der mittleren Messung). Viele Grüße BahnLand

Hallo Quackster, wie EASY schon geschrieben hat, bewegt sich dann das Fahrzeug halt doch weiter. Und wenn Du es dann für einen "Zwangshalt" auf ein "Sperrgleis" ("Sperrweiche") auffahren lässt, gehen die Lichter halt doch wieder aus. Deshalb bin auch ich von dieser "Lösung" ganz schnell wieder abgekommen. Aber wie geschrieben: Man kann die "Automatik" ausschalten. Und dann kann man die Lichter wohl definiert auch im Stand einschalten - was ich ja auch mit meinen "Multi-Animationen" (Liste von Animationen) mache. Viele Grüße BahnLand

Hallo Neo, die LoD-Stufen sind bei meinen Modellen (insbesondere dem oben beschriebenen) da: LoD-Stufe 0: 52688 Polygone, 41050 Eckpunkte (nach meiner Zählung, ohne Normalenvektor-Berücksichtigung) LoD-Stufe 1: 10038 Polygone, 11101 Eckpunkte LoD-Stufe 2: 218 Polygone, 222 Eckpunkte Trotzdem werde ich wie angeraten die "Innenraum-Verdoppelung" (notgedrungen) entfernen und nur die _LS-Variante beibehalten. Anscheinend hältst Du auch nichts davon, dass ich die verschiedenen Spitzenlichlicht-Zustände über entsprechende Animationen schalte. Wenn ich mich hier auf die drei Zustände "Aus", "3-Licht-Sptzensignal" und "2-Licht-Schlusssignal" beschränke, kann ich zwar die "vordefinierten" Animationsbegriffe "_AnimRunPositive" und "_AnimRunNegative" verwenden, bei denen mit dem Anfahren in Abhängigkeit von der Fahrtrichtung das "richtige" Licht automatisch angeschaltet wird (wenn die Automatik aktiviert ist). Aber da es beim Vorbild "unrealistisch" ist, dass das Licht erst beim Anfahren angeht, kann ich diese Automatik sowieso nicht nutzen und muss daher auf "Handbetrieb" (ggf. durch die EV gesteuert) umschalten. Dann spielt es aber auch keine Rolle mehr, ob die Animationen nun die vordefinierten oder andere Bezeichnungen besitzen, und ob dann davon 2 oder 5 Animationen im Modell bereit gestellt werden. Ich möchte daher die verschiedenen Spitzen- und Schlusslicht-Varianten, die für den RAe beim Vorbild wegen dessen international freizügiger Einsetzbarkeit eine Besonderheit darstellen, beibehalten - auch auf die Gefahr hin, dass ich dann zu einem späteren Zeitpunkt die AnimationSet-Definition noch einmal anpassen muss (betrifft ja nicht die Lichtflächen-Definitonen im Mesh-Modell - oder doch?). Viele Grüße BahnLand

Hallo Neo, da hatte ich die Glättung ohnehin vor, aber erst ganz zum Schluss, wenn alles andere "erledigt" ist (ist dann in Sketchup nur noch eine Schieberegler-Verstellung). Diese Erklärung hat mir bei meinem Verständnis jetzt doch weitergeholfen. Danke. Ich werde das testen, sobald ich die Möglichkeit habe, die Anzahl der "betroffenen" Eckpunkte anzeigen zu lassen. Viele Grüße BahnLand

Hallo EASY, ... und Neo, da ich nur die Light-Version "Sketchup Make" habe, kann ich die Sketchup-Source nur als DAE-Datei (Collada) exportieren. Und das wird Dir wahrscheinlich nichts nützen. Da es aber seit kurzem die Möglichkeit gibt, ein in das Modellbahn-Studio hochgeladenens Modell als obj-Datei zu exportieren, habe ich hiervon Gebrauch gemacht. RAe_TEE_WR_0_obj.zip Allerdings befürchte ich ebenfalls, dass diese OBJ-Datei durch den "Umweg" über das Modellbahn-Studio bereits verfälscht worden ist. Denn wenn - wie Neo schreibt - beim Import in das Modellbahn-Studio die "zusätzlichen" (von mir nicht registrierten) Eckpunkt-Einträge entstehen, vermute ich, dass diese dann auch in der OBJ-Datei enthalten sind. Viele Grüße BahnLand ------------------------------------------------------------------------------------------------------------------------------------ Eigentlich ist es kein schöner Zug der Foren-Software, zwei Beiträge, die im Prinzip nichts miteinander zu tun haben und an verschiedene Adressaten gerichtet sind, einfach zusammenzuschieben! Gibt es da keine Möglichkeit, dies zu unterbinden? ------------------------------------------------------------------------------------------------------------------------------------ Hallo Neo, In Sketchup gibt es die Funktionalität der "Kantenglättung", die nach meinem Verständnis den Flat/Smooth-Optionen von Blender entspricht: Bei einer Kantenglättungs-Einstellung von 0° sind alle Kanten sichtbar. Bei einer Glättungs-Einstellung größer als 0° werden alle Kanten, deren Knickwinkel unterhalb dieser °-Einstellung liegen, geglättet. Wenn ich diese Glättung anwende, hat dies zwar keine Auswirkungen auf de Anzahl der vom DirectX-Exporter erzeugten Eckpunkt- und Polygon-Einträge. Die Anzahl der aufgelisteten Normalen-Vektoren kann sich dagegen ändern, sowie deren Zuordnung zu den Polygonflächen. Insofern vermindert sich zwar die Anzahl der Duplikate bei der Kombination "Eckpunkt-Koordinate - Textur-Koordinate - Normalenvektor". Doch die Zahl sich unterscheidender Kombinationen steigt hierdiurch an. Ich wüsste nicht, wie ich das anstellen soll. Sketchup gibt mir an der Ruby-Schnittstelle (für den DirectX-Exporter) die Normalen-Vektoren für alle Polygone (für alle deren Ecken) aus. Woran soll ch nun erkennen, dass solche Flächennormalen "überflüssig" sind, und wie formuliere ich das in der x-Datei, ohne dass sich nachher das Modellbahn-Studio weigert, diese Datei anzunehmen (wegen falscher DirectX-Codierung)? Ich bin bisher immer davon ausgegangen, dass ich einen Fehler bekomme, wenn die Anzahl der Normalenvektor-Zuordnungen nicht mit der Anzahl darzustellender Polygone übereinstimmt. Prinzipiell gibt Sketchup für jede Fläche eine Vorder-und Rückseite aus. Da ich jedoch an der Rupy-Ausgabe des Sketchup-Modells erkennen kann, ob eine Fläche mit dem "Standard-Material" (keine Textur oder Farbe zugewiesen) oder mit einer Textur/Farbe "belegt" ist, kann ich alle Flächen, die nicht explizit "bemalt" wurden, über die Einstellungen im DirectX-Exporter "ausklammern" lassen. Dass Sketchup grundsätzlich zwei Seiten jeder Fläche ausgibt, wovon eine möglicherweise nicht dargestellt werden soll, stellt also für den DirectX-Exporter kein Problem dar. Das werde ich wohl machen müssen (interessiert mich ja auch selbst). Trotzdem würde ich es gut finden, wenn Du die Anzahl der nach dem Import von der Grafikkarte zu bearbeitenden Eckpunkte im Vorschau-Fenster des Modells mit ausgeben würdest. Das tut weh, da ich eigentlich bestrebt bin, dann, wenn ich im Modellbahn-Studio etwas hin bekomme, was im ersten Moment als nicht lösbar erscheint, weil es keine "Standard-Funktionalität" ist, ich es eigentlich auch anwenden möchte. Dass Du Dir "nach der V4" Gedanken über die Beleuchtung machen möchtest, ist zwar schön und gut und auf jeden Fall begrüßenswert. Aber ich möchte eben mit dem Bau meiner Modelle nicht warten, bis die Funktion zu einem späteren Zeitpunkt irgendwann zur Verfügung steht. Und wenn ich dann die Funktion später in meine bereits gebauten Modelle übernehmen möchte, stehe ich wieder vor dem Problem, dass ich meine bereits fertiggestellten Modelle wieder neu anpacken und anpassen muss, oder die neue Funktionalität dort "außen vor" bleibt. Was spricht eigentlich dagegen, "bis zum großen Wurf" zumindest ein paar kleine "Behelfs-Funktionen" zur Vergügung zu stellen (wie z.B. den Ein-Ausschalter für die _LS-Beleuchtung), um die Wartezeit bis zur endgültigen neuen Funktionalität damit überbrücken zu können? Viele Grüße BahnLand

Hallo Neo, Deine Argumentation leuchtet mir ja ein. Dennoch verstehe ich nicht, wie Du zu dem Ergebnis kommst, dass mein Speisewagen-Modell des RAe das Limit von 65536 Eckpunkten überschreitet. Dennoch habe ich jetzt nochmal sowohl in meinem Script als auch in der x-Datei, die ja die Grundlage für die Grafikarte bildet, nachgeforscht. Meine im letzten Beitrag geäußerte Vermutung, dass ich jeden Eckpunkt nur einmal zähle, ist falsch. Tatsächlich zähle ich die sich unterscheidenden Kombinationen aus Eckpunkt-Koordinaten und Textur-Koordinaten. Treten also identische Eckpunkt-Koordianten mehrmals, aber mit unterschiedlichen Texturkoordinaten-Zuweisungen auf, werden sie bei mir auch entsprechend oft gezählt. Ich zähle aber nicht Duplikate der Kombination Eckpunkt- + Textur-Koordinaten. Deshalb bleibe ich mit der Gesamtzahl der Eckpunkt-Koordinaten auch deutlich unter dem 3-fachen der Polygon-Anzahl (jedes Poygon hat 3 Ecken). Dies ist aber auch nicht notwendig, da bei aneinander angrenzenden Polygonen, die zur selben Fläche mit einer Flächen-weiten Texturzuweisung gehören, sich die "gemeinsamen" Eckpunkte in den Texturkoordinaten nicht unterscheiden. Sie brauchen daher in der x-Datei auch nur einmal aufgelistet zu werden. Prinzipiell besteht eine Mesh-Definition innerhalb einer x-Datei (hier am Beispiel eines einfachen Würfelds) aus folgenden Teilbereichen: Der erste Abschnitt enthält die an die Grafikkarte zu übergebenden Eckpunkt-Koordinaten, aus denen im zweiten Abshnitt die Polygone gebildet werden. Die Materialliste enthält die Textur-Zuordnungen zu den einzelnen Polygonen, wobei Textur-Koordinaten (für das Mapping) den Polygon-Eckpunkten zugeordnet werden. Die Anzahl der Material-Zuordnungen entspricht also der Anzahl der Polygone, während die Anzahl der aufgelisteten Textur-Koordinaten der Anzahl der vorhandenen Expunkt-Koordinaten entspricht. Für die Grafikkarte muss die Kombination "Expunkt-Koordinate + Textur-Koordinate" eindeutig sein. Sie braucht aber nicht zwingend mehrfach vorhanden zu sein. Innerhalb der Gruppe der Eckpunkt-Koordinaten und jener der Textur-Koordinaten (jeweils für sich betrachtet) können sich daher Einträge wiederholen. Die Normalen-Vekoren brauchen für jede Flächen-Ausrichtung nur einmal vorhanden zu sein, deshalb ist diese Liste (zumindest hier) deutlich kürzer als alle anderen Listen. In der letzten Spalte werden die Normalen-Vektoren den einzelnen Polygonen zugeordnet, sodass die Anzahl der Normalenvektor-Zuordnungen wieder mit der Anzahl der ausgewiesenen Polygone übereinstimmt. Ich habe nun einmal für den im vorangegangenen Beitrag aufgeführten Speisewagen exakt diese Mesh-Einträge (für enthaltenen alle Meshes (Frames) aufsummiert und bin hierbei exakt auf jene Zahlen gekommen, die vom Ausgabe-Protokoll des DirectX-Exporters ausgegeben werden. 15902 Flaechen, 41050 Eckpunkte, 52688 Polygone, 1470 Normalen-Vektoren, 2 Materialien, 1 Textur In der x-Datei, die an die Grafikkarte "weitergereicht" wird, werden für den Speisewagen also 41050 Kombinationen aus Eckpunkt- und Textur-Koordinaten, 52688 Polygone mit entsprechend vielen Material(Textur)- und Normalenvektor-Zuordnungen sowie 1470 Normalenvektor-Definitonen ausgewiesen. Da der Grafikkarte eigentlich nicht mehr zur Verfügung stehen kann, als in der x-Datei hinterlegt ist, ist mir völlig schleierhaft, wo die von Dir festgestellte Überschreitung der Maximalzahl von 65536 Eckpunkten herkommt. Bitte gib mir zusätzliche Informationen, wie ich diese "Überschreitung" selbst feststellen kann, und woher diese Erhöhung der Anzahl von Eckpunkt-Definitionen herrührt. Ich würde sie gerne "nachvollziehen" (verstehen) können, um zukünftig mit meinen Modellen unter dem von Dir vorgegebenen Limit bleiben zu können. Viele Grüße BahnLand

Hallo SputniKK, sieht schon gut aus! Viele Grüße BahnLand

Hallo Neo, Gute Nachricht. Sehr schlechte Nachricht. Damit kann ich nämlich mit dem "Redesign" des in mehreren Wochen nun "optimierten" und "funktions-erweiterten" RAe TEE II wieder von vorne anfangen. Denn bisher war nie von einer Beschränkung der Eckpunkte die Rede. Vielmehr wurde der Schwerpunkt von ursprünglich der Anzahl Polygone auf die Anzahl der Unterobjekte (von der Anzahl der vewendeten Materialien abhängend) verlagert, wobei nach Deiner Aussage die Anzahl der Polygone zwar weiterhin eine Rolle spielen sollte, aber diese gegenüber jener der Materialien (Unterobjekte) in ihrer Relevanz in den Hintergrund tritt. Außerdem war ich bisher der Meinung, dass man das Problem der "zuvielen" Polygone (und damit auch der zu hohen Anzahl von Eckpunkten) gerade durch die LoD-Stufen lösen kann. Weshalb also die Begrenzung der Eckpunkte auch in der "Hauptdetailstufe" auf 65536 (warum wird hier für die Integer-Zahl nicht ein drittes Byte spendiert - 4-Byte-Integer-Zahlen sind heute in der EDV-Programmierung Standard)? Übrigens sagt mein Protokoll des DirectX-Exporters für dieses Fahrzeug: Aufbereitet: 28 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen - insgesamt: 15902 Flaechen, 41050 Eckpunkte, 52688 Polygone, - : 1470 Normalen-Vektoren, 2 Materialien, 1 Texturen Dateipfad: D:\Daten\Eisenbahn\3D-Modellbau\Sketchup\SBB_RAeII\DirectX X-Datei-Ausgabe: RAe_TEE_WR_0.x Plugin-Protokoll: RAe_TEE_WR_0.txt Ich denke daher (ich müsste es nochmal überprüfen), dass ich jeden Eckpunkt auch dann, wenn er Teil mehrerer aneinander grenzender Flächen ist, nur einmal gezählt habe, währed Du einen zu mehreren Flächen gehörenden Eckpunkt entsprechend mehrmals zählst. Bisher war bei den Ressourcen-Beschränkungen von Eckpunkten nie die Rede. Insbesondere gibt es bisher seitens des Modellbahn-Studios keinerlei Informationen über die Anzahl Eckpunkte, die in einem hochgeladenen / hochzuladenden Modell vorhanden sind. Dies bedeutet, dass ich für die Erfassng der "vielfachen" Eckpunkte auch das Exporter-Script noch einmal zusätzlich umschreiben (entsprechend erweitern) muss. Es wäre wirklich schön gewesen, wenn ich solche Informatonen wesentlich früher und nicht kurz vor Freigabe der Version 4 erhalten hätte. Dann hätte ich nämlich einerseits dies gleich in die Planung des RAe-Redesigns einfließen lassen können, und ich hätte dies auch im Exporter-Script, das ich für die V4 im Prinzip neu geschrieben habe, bereits berücksichtigen können. In diesem Sinne kann ich in gewisser Weise nachvollziehen, warum beispielsweise Seehund die "schöpferische Mitarbeit" am Modellbahn-Studio eingestellt hat. Es kommt auch bei mir wenig Freude auf, wegen immer wieder neuen nachgeschobenen Einschränkungen alte Modelle immer wieder aufs Neue umgestalten zu müssen, und damit keine Zeit mehr zu haben, auch wieder mal "etwas Neues" auf die Beine zu stellen. Natürlich kann ich wie z.B. Quackster alle Modelle mit nicht-transparenten Fenstern versehen. Dann benötige ich keine Inneinrichtung und auch keine Innenbeleuchtung mehr. Ich finde aber, dass gerade diese "Details" den Reiz solcher Modelle ausmachen. Ich hatte übrigens schon vor über einem Monat hier folgende Frage gestellt: Dazu eine weitere Frage an Neo: Wäre es eventuell möglich, _LS-Objekte mit einer schaltbaren Eigenschaft "aktive Leuchtkraft ein/aus" zu versehen, die man dann über die Modell-Eigenschaften im Modellbahn-Studio und auch in der Ereignisverwaltung ähnlich wie die Animationen heute auflisten und damit deren Leuchtkraft gezielt ein- und ausschalten kann? Leider habe ich von Dir auf diese und eine andere Frage im genannten Beitrag bisher keine Antwort erhalten. Da es diese Eigenschaft heute im Modellbahn-Studio nicht gibt, muss ich für die Schaltbarkeit der Beleuchtung das betroffene _LS-Objekt (den "Innenraum") zweimal bereitstellen (neben dem _LS-Objekt zusätzlich als "Nicht-_LS-Objekt"), was man sich bei der in meiner Frage vorgeschlagenen Funktionalität sparen könnte. Bei dem in Eingangsbeitrag genannten Speisewagen des RAe-TEE-Triebzugs habe ich für eine Ausprägung des Innenraums folgende Zahlen ermittelt: Aufbereitet: 4 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen - insgesamt: 5942 Flaechen, 14980 Eckpunkte, 18734 Polygone, - : 173 Normalen-Vektoren, 1 Materialien, 1 Texturen Dateipfad: D:\Daten\Eisenbahn\3D-Modellbau\Sketchup\SBB_RAeII X-Datei-Ausgabe: RAe_TEE_WR_0_Innenraum.x Plugin-Protokoll: RAe_TEE_WR_0_Innenraum.txt Ich könnte also in diesem Modell 18734 Polygone oder 14980 Eckpunkte nach meiner Zählung einsparen (nach Deiner Zählung müsste es demnach ein Vielfaches sein), wenn ich den "Innenraum" wegen der Ein-/Ausschaltmöglichkeit der Innenbeleuchtung nicht zweimal bereitstellen müsste. Dies wäre bei diesem Modell eine Einsparung von mehr als einem Drittel der insgesamt gezählten Ressourcen (siehe oben)! Übrigens hier noch zur Info und zum direkten Vergleich die Zahlen für die zweite und dritte LoD-Stufe dieses Modells: Aufbereitet: 20 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen - insgesamt: 3852 Flaechen, 11101 Eckpunkte, 10038 Polygone, - : 262 Normalen-Vektoren, 2 Materialien, 1 Texturen Dateipfad: D:\Daten\Eisenbahn\3D-Modellbau\Sketchup\SBB_RAeII\DirectX X-Datei-Ausgabe: RAe_TEE_WR_1.x Plugin-Protokoll: RAe_TEE_WR_1.txt Aufbereitet: 6 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen - insgesamt: 31 Flaechen, 222 Eckpunkte, 218 Polygone, - : 29 Normalen-Vektoren, 2 Materialien, 1 Texturen Dateipfad: D:\Daten\Eisenbahn\3D-Modellbau\Sketchup\SBB_RAeII\DirectX X-Datei-Ausgabe: RAe_TEE_WR_2.x Plugin-Protokoll: RAe_TEE_WR_2.txt Viele Grüße BahnLand P.S.: Den Vorwurf, dass Du die Beschränkung auf 65000 bisher nicht kommuniziert hast, muss ich zurücknehmen (siehe hier - ich möchte mich daher für diesen Vorwurf entschuldigen!). Mir war aufgrund von "meiner" Zählung der Eckpunkte nur nicht bewusst, dass ich hier mit meinem Modell darunter fallen könnte. Trotzdem bitte ich meine oben dargestellten Ressentiments bezüglich der Eckpunkt-Beschränkung bzw. der beschriebenen Möglichkeit, dass hier auch das Modellbahn-Studio "positiv" einwirken könnte, stehen lassen. Nochmals viele Grüße BahnLand

Hallo Neo, ich bin gerade dabei, den von mir redesignten schweizerischen RAe TEE II fertigzustellen. Alle Fahrzeuge besitzen hierbei 3 LoD-Stufen, die alle mit animierter Innenbeleuchtung (ein- und ausschaltbar) versehen sind. Leider wird beim Hochladen der LoD-Stufen in den Online-Katalog die Animation für die dritte LoD-Stufe teilweise nicht übernommen. Hier ein konkretes Beispiel: Innerhalb des Verwendungszeitraums der RAe-Triebzüge wurde der Speisewagen zweimal stark verändert: Ursprünglich besaß der Speisewagen zwei Speiseräume und im Barbereich zusätzliche Sitzplätze. Nach dem ersten Umbau wurden die Sitzplätze im Barbereich entfernt und einer der Speiseräume in ein Großraumabteil 2. Klasse umgebaut. Nach der Ausmusterung aller Triebzüge blieb einer als Museums-Triebzug erhalten und wurde in den 1.-Klasse-TEE-Triebzug zurückgebaut, wobei allerdings nicht alle Änderungen des ersten Umbaus zurückgenommen wurden. So wurde zwar der zweite Speiseraum wieder hergerichtet, aber die Sitzplätze im Barbereich wurden nicht rekonstruiert. Ich habe daher von diesem Speisewagen 3 Varianten hergestellt: den TEE_WR, den EC_BR und den Museums_WR (Hst[oric]_WR). Die zweite LoD-Stufe gibt es wie die erste in 3 Varianten. Für die dritte LoD-Stufe verwende ich die TEE-WR-Variante in allen 3 Fällen. Beim Hochladen als TEE_WR und als Hst_WR wird die eigentlich animierte dritte LoD-Stufe als "Nicht-animiert" übernommen, während bei der TEE_BR-Variante (wird später mit anderer Textur die graue EC_BR-Variante) die dritte LoD-Stufe als "animiert" akzeptiert wird. Animation nicht angenommen Animation angenommen Animation nicht angenommen Wie kann es sein, dass dieselbe X-Datei mit ebenso derselben Anim-Datei einmal wie erwartet als "animiert" übernommen wird und zweimal die Animation der dritten LoD-Stufe (bei identischen Dateien) ignoriert wird? In der beigefügten ZIP-Datei habe ich die betroffenen x-Dateien aller 3 LoD-Stufen (Suffix _0, _1 und _2) für alle 3 Varianten (TEE_WR_0/_1/_2, Hst_WR_0/_1 und TEE_BR_0/_1, letztere jeweils mit TEE_WR_2 als dritter LoD-Stufe) abgelegt. Vielleicht kannst Du etwas erkennen, was in meiner "Konfiguration" nicht stimmt, und was ich selbst nicht sehe. RAe_TEE_WR_2.zip Viele Grüße BahnLand

Hallo zusammen, Vielen Dank für die Lobeeren. Die habe ich aber in diesem Fall nicht verdient, da ich selbst über den 1-achsigen Schienenbus-Anhänger auch nicht viel mehr weiß. Man kann aber im Internet ein paar Links finden, wo einiges zu den 1-Achs-Anhängern geschrieben steht: In Wikipedia findet man eine kurze Übersicht über den Wagen. Auf dieser Seite findet man ein schönes Protrait-Foto des Fahrzeugs, bei dem man sehr gut die beiden vohandenen Kupplungs-Varianten (unten die Scharfenberg-Kupplung für die Schienenbusse, oben die einfache Ösen-Kupplung für die Kupplungshaken der Aussichtstriebwagen ET91 und VT90) erkennen kann. Mit dieser Ösen-Kupplung konnte das Fahrzeug auch an andere Fahrzeuge mit Regelkupplung angehängt werden, wie insbesondere dieser Beitrag mit Anhang zeigt. Die Bilder in diesem Betrag zeigen, dass der Anhänger auch an den Prototyp-Schienebus und an den "normalen" Beiwagen des VT95 angehängt wurde. Zum Abschluss noch ein Bild aus einem EEP-Projekt, das man sicher als Vorlage für eine eigene Textur für das MBS-Modell verwenden kann. Bezüglich der Vorbildtreue im Modellbahn-Studio würde ich das nicht so eng sehen. Als Seehund seinen VT96 (ursprünglicher VT98) für das Modellbahn-Studio gebaut hatte, war er, soweit ich mich erinnere, nur mit kurzem Beiwagen versehen. Auf meinen Vorschlag hin kam dann noch der lange Beiwagen dazu. Alle Fahrzeuge haben hier die "normalen" Puffer der Fahrzeue mit Schraubenkupplung, obwohl es den kurzen Beiwagen "VB95" nur mit Scharfenberg-Kupplung und Stoßbügeln für die einmotorigen VT95 gab. Beim langen Beiwagen VB96/VB98 sind die "normalen" Puffer wie beim zweimotorigen VT96/VT98 jedoch korrekt. Hätte Seehund beide Varianten mit jeweills korrekten Puffern und Kupplungen bereitstellen wollwn, hätte er den Triebwagen zweimal (als VT96/VT98 und als VT95) ins Modellbahn-Studio stellen müssen, was Neo seinerzeit wegen "zu großer Ähnlichkeit" der Fahrzeuge abgelehnt hätte (in Version 4 haben wir da größere Freiheiten). Das ist übrigens bisher nicht aufgefallen oder wurde einfach stillschweigend toleriert. Denn auf größere Entfernung fällt dieser "Fehler" wirklich kaum auf. Ich sehe daher auch für den VB141 kein Problem, diesen hinter den VT96 zu hängen und einfach anzunehmen, es sei ein VT95, oder eben den in einem der oben referenzierten Beiträge beschriebenen "Sonderfall" anzuwenden. Was das Schieben des 1-Achs-Anhängers anbelangt, gehe ich davon aus, dass dies nur im Rahmen von Rangierbewegungen geschah und das Fahrzeug bei der normalen Streckenfahrt sich immer am hinteren Ende des Zuges befand. Viele Grüße BahnLand

Hallo Schlagerfuzzi, kannst Du uns bitte kurz schildern, was Du mit der EV-Steuerung von Verknüpfungen realisieren wolltest, und wie Du es schließlich gelöst hast? Ich glaube, dass das nicht nur mich interessieren würde. Viele Grüße BahnLand