BahnLand

Hallo Brummi und Neo, vielen Dank für Eure Hinweise. Ich habe inzwischen noch etwas "herumgespielt" und bin zu folgenden Ergebnissen gelangt: Um die Separierung von Landschaftsteilen, die so bleiben sollen, wie sie sind, und solchen, die "geglättet" werden sollen, wird man wohl nicht herumkommen. Bei früheren Versuchen, über "als nicht zu berücksichtigen" gekennzeichnete Flächenbereiche zu glätten, habe ich an den Grenzen stets "Verläufe" bekommen, die ich im Nachhinein dann immer wieder von Hand "wegretuschieren" musste. Ich habe mir daher ein kleines Programm geschrieben, das bei einem vorgegebenen Höhenprofil alle Höhen > 0 unberücksichtigt lässt, und die Höhe der Punkte mit vorgefundener "Höhe 0" anhand der in X- und Y-Richtung vorgefundenen Randpunkte mit "Höhe >0" neu berechnet. Die berechneten Höhen orientieren sich hierbei (etwa) an zwischen den Randpunkten in X- und Y-Richtung (virtuell) gespannten "Gummifäden". Die CSV-Variante für die Abspeicherung und das Einlesen des Höhenprofils (die ich bisher nicht zur Kenntnis genommen hatte), ist genau die Lösung für mein "Treppenstufen"-Problem, das auf die Beschränkung des Graustufenbildes auf 256 Abstufungen zurückzuführen ist. Die folgenden Bilder sollen den Unterschied zwischen der Anwendung des Graustufenbildes und der CSV-Daten für den Export und Import des Höhenprofils verdeutlichen: Als Ausgangsbasis habe ich eine Anlage gewählt, bei der nur die "Gleistrassen" über die "Geländeanpassung" des Modellbahn-Studios "angehoben" wurden. Außerdem habe ich von Hand die Anlagen-Ränder entsprechend der in der Nachbarschaft vorhandenen Gleisniveaus angepasst. Die restlichen Flächen wurden auf der Höhe "0" belassen (Bild 1). Um den Unterschied zwischen den beiden Import-Varianten für das Höhenprofil zu verdeutlichen, habe ich dieses Profil um den Faktor 8 "überhöht" (Bild 2). Damit entspricht die Gesamthöhe von 2000 mm etwa der Gesamthöhe meiner Gotthard-Anlage. Für die Darstellung der "Klassischen" Methode habe ich von der "flachen" Anlage (Bild 1) ein Graustufenbild exportiert und in diesem die Höhen der Trassen-Zwischenräume mithilfe meines Programms angepasst (ebenfalls ein Graustufenbild). Dieses wurde anschließend importiert und auf die Höhe "2000 mm" gedehnt. Das Ergebnis zeigt die in den vorangehenden Beträgen erwähnten "Reis-Terassen" und "Rampen-Treppen" (Bild 3). Exportiert man dagegen das Höhenprofil als CSV-Datei undrealisiert die "Interpolation"  anhand der dort hinterlegten z-Koordinaten, kann man die Höhen der Zwischenpunkte deutlich genauer bestimmen. Schreibt man die neu berechneten Höhen-Koordinaten in die CSV-Datei zurück und importiert diese als Höhenprofil in die Anlage des Modellbahn-Studios, erhält man das im nachfolgenden Bild 4 gezeigte Ergebnis. Die in den beiden letzten Bildern sichtbaren "Abbruchkanten" haben ihre Ursache in den abrupten Höhensprüngen an den Kreuzungen zweier Schienenwege. Da die Rampe des jeweils oberen Gleises bis zur "Brücken-Aussparung" direkt an die untere Trasse heranführt, wirken sich diese "scharfen" Übergänge auch auf die (virtuellen) Gummifäden - und damit auch auf das erzeugte Landschaftsprofil aus. Geht es im Endeffekt nur darum, ein "ausgespartes Loch" in einer vorhandenen Landschaft zu "füllen", dürften solche "Sprünge" eher seltener auftreten. Insgesamt glaube ich, dass ich mit diesem Lösungsansatz bei meiner Gotthard-Anlage - wenn ich sie in Zukunft in das Modellbahnstudio übernehmen werde - weiterkommen kann. Viele Grüße BahnLand  

Hallo, meine Erfahrung ist, dass die Geschwindigkeiten mehrerer Loks innerhalb eines Zuges sich aufsummieren. Ich habe dies insbesondere an dem Effekt festgestellt, dass ein Triebzug stehen blieb, wenn die beide Triebköpfe an den Zugenden jeweils dieselbe Geschwindigkeit zugeordnet bekommen hatten (die Orientierung beider Triebköpfe ist gegenläufig). Deshalb achte ich immer darauf, dass nur die Lok (der Triebkopf), der sich in Fahrtrichtung "vorne" befindet, eine Geschwindigkeitszuweisung erhält. Dies ist insbesondere dann relevant, wenn die Geschwindigkeit über die Ereignisverwaltung Gleis-abhängig zugewiesen wird. Viele Grüße BahnLand

Hallo Brummi, ja, das mit dem "Weichzeichnen" habe ich auch schon probiert. Aber wie Du schon angedeutet hast, gehen dann die "Maxima" und "Minima" verloren (d.h. sie werden "abgeschwächt"). Aber gerade diese sollten natürlich erhalten bleiben, wenn sie z.B. einen Abhang (z.B. eine Bergwiese), eine Felswand mit Tunnelportal oder einen Bahndamm oder Einschnitt darstellen. Dort kann ich die "Glättung" dann überhaupt nicht gebrauchen und bin doch wieder auf "individuelle Anpassungen" angewiesen. Da wäre es natürlich toll, wenn ich die Bereiche, wo "geglättet" werden soll (oder umgekehrt: wo nicht) genau vordefinieren könnte. Ich habe aber noch ein ganz prinzipielles Problem, bei dem mir auch die beste Glättung nichts hilft: Das zu importierende Höhenfeld (Graustufenbild) hat maximal 256 Abstufungen (0=schwarz, 255=weiß). Möchte man damit einen größere Höhendifferenz als 256 überbrücken (bei meiner Gotthard-Anlage liegen zwischen dem niedrigsten und dem höchsten Punkt 2000 m), muss diese in maximal 256 Abstufungen unterteilt werden (das wären hier dann knapp 8 m pro Höhenstufe, was etwa der doppelten Höhe eines Zuges zwischen Schienenoberkante und Wagendach entspricht). Da bei meiner Anlage der Landschafts-Maßstab gegenüber dem Fahrzeug-Maßstab nochmals um den Faktor 4 verkleinert ist, verringert sich dort die Differenz zwischen zwei Höhenstufen (Graustufen im Höhenfeld)  auf die halbe Zughöhe. Aber auch dies ist auf der Anlage immer noch deutlich als "Treppenstufe" sichtbar.  Dass man hiermit sogar eine "glatte" Landschaft "zerstören" kann, indem man aus der "intakten" Landschaft ein Höhenfeld exportiert und dieses ohne irgendeine Änderung wieder importiert, habe ich ebenfalls im alten Forum in diesem Beitrag beschrieben. Der Grund liegt darin, dass die auf der Anlage selbst vorgenommenen Höheneinstellungen zwar (fast beliebig) feinstufig sein können, diese aber beim Exportieren eben auf die maximal vorhandenen 256 Graustufen "aufgeteilt" werden  (die Treppenstufen kommen also beim Exportieren rein). Und beim Importieren hat dann das MBS nicht mehr die Informationen zur Verfügung, um die "verloren gegangenen" Zwischenstufen wieder rekonstruieren zu können. Dies mag bei "zufallsgesteuerten" Höhenprofilen nicht so auffallen, da es hier von Natur aus keine "glatten" Flächen gibt, aber gerade diese gehen hier gezwungenermaßen verloren. Meiner Ansicht nach lässt sich dieses Problem nur dadurch lösen, dass die Höhenfeld-Abbildung nicht mehr auf 1 Byte (mit 256 Werten) beschränkt, sondern auf 2 Bytes aufgebohrt wird (das wären dann 65536 mögliche Abstufungen, die man wohl niemals komplett ausreizen wird). Allerdings wäre das Höhen-Bild dann kein "Graustufenbild" mehr, sondern ein "Farbverlaufsbild" zwischen den Farben Rot und Grün mit allen Helligkeitsstufen zwischen Schwarz und Weiß (leider lässt sich dann die jeweilige Höhe in diesem Bild nicht mehr so einfach an der "Helligkeit" ablesen). Ob dies im MBS einfach zu realisieren ist oder einen höheren Aufwand erfordert, kann jedoch nur Neo beurteilen. Eine für mich durchaus wünschenswerte Alternative zum "Aufbohren" des Höhenfeldes wäre eine Glättungsfunktion, die man im MBS direkt anwenden könnte. Dann könnte man zwar weiterhin nur 256 Höhenstufen über das Höhenfeld einlesen, aber die anschließende Glättung durch das MBS selbst (am liebsten mit jeweils auswählbarem Flächenbereich, in dem die Glättung wirksam sein soll) würde dieses Manko dann meines Erachtens wieder wett machen. Aber auch da kann  nur Neo ermessen, wie viel Aufwand hinter einer solchen Realisierung steckt. Viele Grüße BahnLand

Hallo Brummi, tolle Idee. Da sieht man, wie kreativ man mit einem "Zufallsgenerator" umgehen kann, wenn man weiß, wie. Ich stehe allerdings vor dem Problem, dass ich "reale Landschaften" nachbilden möchte. Z.B. existert von mir im alten Forum (zum 3D-Eisenbahnplaner) eine Gotthard-Modul-Anlage, die ich nach den Höhenlinien aus der Topographischen Karte der Schweizerischen Eidgenossenschaft erstellt habe (leider habe ich es bisher (noch) nicht geschafft, die Anlage in das Modellbahn-Studio zu übertragen). Wenn ich das generierte Höhenlinien-Modell als Höhenfeld einlese, bekomme ich eine aus "Chinesischen Reistreppen" bestehende Landschaft. Hier fehlt mir noch ein "geeignetes" Programm, um die Niveaus zwischen den Höhenlinien so zu interpolieren, dass eine (relativ) "glatte" Oberfläche entsteht. Mit der Nutzung der Höhenmodus-Funktion des MBS wird man hierbei genauso wenig "glücklich" wie mit dem Verwenden von Schienenstücken, um die "Glättung" durch die "Gelände-Anpassung" unter dem Gleis zu erreichen. Es wird also wahrscheinlich noch ein Weilchen dauern, bis ich hier eine "optimale" Gelände-Darstellung "finde". Viele Grüße BahnLand

Hallo Lobo, es ist immer wieder faszinierend, was Du so mit Bordmitteln auf die Beine stellst. Die Schleusen-Szene erinnert mich an eine Beitragsserie von Dir und Auxallie aus dem alten Forum, wo Auxallie mithilfe der Ereignisverwaltung einen interessanten Ablauf geschaffen hat.  Ob diese Abläufe (und vielleicht auch die Fährschiff-Beladung) in der neuen MBS-Anlage wieder realisiert werden? Viele Grüße BahnLand

Die Modelle sind - LoD hin oder her - jedenfalls großartig! Viele Grüße BahnLand

Hallo Seehund, man lernt nie aus . Gibt's von diesem Gefährt auch ein Foto? Viele Grüße BahnLand

Hallo Seehund, der Panorama-Wagen sieht im Zugverband klasse aus. Der hätte dem Triebwagen auch beim Vorbild sehr gut gestanden. Doch dort hat es diesen Wagen nie gegeben. Warum hast Du eigentlich den Triebkopf bei den Dieselloks und die Zwischenwagen bei den Personenwagen eingefügt? Nach meinem Empfinden würden alle diese Fahrzeuge genauso wie Deine nicht angetriebenen ICE-3-Fahrzeuge besser in den Triebwagen-Ordner passen, wo auch Deine angetriebenen ICE-3-Fahrzeuge und der Schienenbus mitsamt Beiwagen zu finden sind.  Eigentlich gehört auch der ICE 1 von Neo hierhin ("ICE-Lok" = Triebkopf und "ICE Personenwagen"+"ICE Bordrestaurant" = Mittelwagen), die ja auch beim Vorbild bei der Baureihenbezeichnung als Elektrotriebwagen (401, 402, 403, 406, ...) und als Beiwagen zu den Elektrotriebwagen (801-808) eingeordnet sind. Bei den Dieseltriebwagen waren/sind übrigens die motorisierten Fahrzeuge der Baureihen-Nummerngruppe 600 (VT11 = 601, 602 war der Gasturbinen-Triebkopf), die Schienenbusse Gruppe 700 (VT98/VT95 = 798/795) und die Beiwagen der Gruppe 900 (VB11 Mittelwagen = 901, Schienenbus-Beiwagen VB98/VB142 = 998/995) zugeordnet. Was ist übrigens aus Deinen schönen 26,4m-TEE-Wagen geworden? Dort hattest Du doch den Dome-Car beim alten 3D-Eisenbahnplaner ebenfalls realisiert. Wirst Du diese Wagen in absehbarer Zeit wieder zur Verfügung stellen (passend zur E03, E10 und V200)? Die würden auch gut mit den Eurofima-Wagen in den TEE-Farben zusammenpassen. Viele Grüße BahnLand

Hallo EASY, der "Gläserne Zug" ist Dir hervorragend gelungen. Vielen Dank für das wunderschöne Modell (ja, Kategorie "Triebwagen" ist korrekt). Wird's den auch in den anderen Farbgebungen (z.B. Epochen 4 (Olympiablau) und 5 (Enzianblau)) geben? Viele Grüße BahnLand

Hallo Franz, Gartenbahner und Neo, zur "Gegenkontrolle" habe ich mir mal meine alte Demo-Anlage (entspricht der Anlage von Neo, jedoch mit etwas längeren Zügen) als zusätzliches RocrRail-Projekt hereingeladen. Mit der neuen RocStudio-Version von Neo hatte ich keine Schwierigkeiten mehr, die Weichen und Signale über den RocRail-Gleisplan zu schalten. Allerdings fuhren "meine" Züge anfangs in die falsche Richtung los (ich weiß nicht, warum), sodass ich sie um 180° drehte. Danach konnte ich die Züge sowohl von Hand (verschieben von einem Block in einen anderen) als auch über die Vollautomatik steuern. Allerdings habe ich es trotz der unterschiedlichen Geschwindigkeits-Einstellungen nach den Angaben von Franz weiterhin nicht geschafft, dass die Züge langsam anfahren oder weich abbremsen (beides geschieht mit einem "Ruck"). Danach habe ich versucht, mein ehemaliges RocRail-Projekt für die 18-Zug-Anlage zu laden. Auch hier konnte ich sowohl die Weichen als auch die Signale über den RocRail-Gleisplan erfolgreich schalten. Allerdings musste ich mehr als die Hälfte aller Weichen "umpolen", weil sie "in echt" genau anders herum schalteten als im RocRail-Gleisplan. Dieses Phänomen gab es auch schon früher und lässt sich dadurch erklären, dass RocRail bei den Gleisplan-Weichen nicht erkennt, ob die "Weichengerade" in der Horizontale/Vertikale oder Diagonale liegt. Deshalb gibt es bei RocRail in den Weichen-Eigenschaften auch die Möglichkeit, die Schaltung genau umzukehren (also "umzupolen"). Dies hat aber bei den RocRail-Versuchen vor etwa einem Jahr nicht funktioniert, weshalb ich die Umpolung bei den Weichen in der MBS-Anlage (im Gleiseditor) vornehme, indem ich die Fahrwege 1 und 2 der Weichen vertausche. Danach werden die Weichen über den RocRail-Gleisplan korrekt gestellt. Beim Versuch, die ersten Fahrten "von Hand" anzustoßen (Zug im Rocrail-Gleisplan von dem durch ihn belegten Block in einen angrenzenden leeren Block verschieben), bin ich allerdings kläglich gescheitert: Anstelle den im Gleisplan ausgewählten Block "anzuvisieren", wählt RocRail einen ganz anderen Zielblock aus (gelbe Einfärbung), legt auch den Weg dorthin fest, aber schaltet weder die Weichen in der MBS-Anlage noch wird der Zug tatsächlich gestartet. Da ich gerade mitten drin bin, meine Eurofima-Wagen LoD-fähig zu machen, habe ich momentan nicht die Geduld und Ausdauer, nebenher auch noch nach den möglichen Ursachen in meiner RocRail-Definition zu fahnden, wegen denen ich die Anlage momentan nicht zum Laufen bringe. Deshalb stelle ich Euch für den Fall, dass Ihr Zeit und Lust habt, Euch mit dieser RocRail-Konfiguration zu befassen, die "RocRail-angepasste" Anlage selbst (mbp-Datei) und die RocRail-Konfigurationsdateien für die Anlage (18-Zug-Anlage.xml (anstelle der Datei plan.xml), occ.xml, rocrail.ini (für den Server) und rocview.ini (für den Viewer)) in der beigefügten ZIP-Datei zur Verfügung. Diese Dateien müssen in das RocRail-Verzeichnis übernommen werden (bitte die anderen xml- und ini-Dateien vorher sichern ). Falls Ihr keine Zeit und/oder Lust habt, macht es auch nichts. Dann werde ich mich eben erst später damit wieder auseinandersetzen (ich muss mir viel wieder neu aneignen, was ich seit vorigem Jahr schon wieder vergessen habe). Viele Grüße BahnLand     Rocstudio_18-zug-anlage.zip

Hallo Lobo, auch wenn das mit der "Bordmittel-Optimierung" (noch?) ein Problem ist, finde ich es doch immer wieder faszinierend, wie viel und detailliert man auch "nur" mit Bordmitteln bauen kann. Für die Bestückung eines kleinen (eventuell sogar animierten) Dioramas finde ich auch solche Bordmittel-Modelle allemal "geeignet", da hier ja der mit Modellen zu "bestückende" Raum beschränkt ist. Bei Großanlagen mit "weitläufigen" Dimensionen muss dann jeder für sich selbst entscheiden, ob er solche Modelle darauf stellen oder lieber auf sie verzichten möchte. Viele Grüße BahnLand

Hallo Neo, wäre es möglich, die Höhe des Gleisbetts variabel zu gestalten und über den Gleiseditor konfigurierbar zu machen? Man würde hiermit gleich mehrere Fliegen mit einer Klappe erschlagen: Man bekäme die "lästigen schwarzen Striche" weg, die heute übrig bleiben, wenn man die Gleistextur durch eine "Straßentextur" ersetzt, bei der die Schienenbereiche transparent ausgelegt sind (die Problematik wurde unter anderem hier diskutiert). Wäre die Höhe des Gleisbetts konfigurierbar, könnte man den "Straßenbelag" auf die Höhe der Schienenoberfläche (oder sogar knapp darüber) verschieben, womit die störenden schwarzen Linien verschwunden wären. Hierdurch wäre es auch nicht mehr notwendig, alle mit "Dummy-Loks" verknüpften Straßenfahrzeuge auf das (jetzige) Gleisbett-Niveau abzusenken. Man könnte sie auf dem Niveau der Schienenoberfläche belassen, wodurch auch solche Straßenfahrzeuge, die bereits heute im Online-Katalog als "Lokomotiven" deklariert sind und daher grundsätzlich auf Schienen-Niveau fahren, beispielsweise auf der (entsprechend angepassten) Straßen-Anlage "Auto-Bahn" einsetzen (was heute nicht geht, da die Autos hier "über die Straße schweben"). Man könnte - wieder mit speziellen Gleistexturen - "Straßenbahngleise" erzeugen, bei denen die Schienen im Straßenplanum (und nicht darüber) liegen. Über die spezielle Gleistextur könnte man dann zusätzlich "Rillenschienen" imitieren (siehe hierzu die Beiträge "Realisierung von Gleisen im Straßenplanum" und "H0-Straßenbahn-Gleissystem von HAMO" aus dem alten Eisenbahnplaner-Forum). Durch Beibehaltung des ursprünglichen Schienenniveaus (Erhöhung des Gleisbett-Niveaus anstelle einer möglichen Absenkung der Schienen) wäre es problemlos möglich, nahtlos zwischen Gleisen im Straßenplanum und solchen im (normalen) Schotterbett zu wechseln, da die Ebene der Schienenoberfläche "unangetastet" bliebe. Schließlich könnte man hiermit auch "versandete" oder "verkrautete" Gleise darstellen, wie sie z.B. im BW-Bereich (zumindest in der Dampflokzeit) oder bei weniger "gepflegten" Nebenbahn- oder Feldbahnstrecken vorzufinden sind oder waren. Viele Grüße BahnLand

Hallo EASY, ich denke, dass es die in diesem Beitrag beschriebene Konstruktion ist (siehe das fünfte Bild von oben), die ich damals von Auxallie aus dem alten 3D-Eisenbahnplaner-Forum "abgekupfert" hatte. Viele Grüße BahnLand

Hallo Roter Brummer, Dein erstes Modell ist Dir sehr gut gelungen. Gratulation! Viele Grüße BahnLand

Hallo zusammen, ich sehe schon - habe bezüglich RocRail schon wieder einiges "verlernt" . Insgesamt lief die Demo-Anlage auf Anhieb. Nur meine ich mich zu erinnern, dass ich mit dem alten RocRail-Anschluss von Franz tatsächlich "weiche" Anfahrten und Bremsungen hatte. Aber wie ich Neo kenne, wird das demnächst auch noch kommen. Jedenfalls kann ich meinerseits bestätigen, dass die von Franz oben gezeigten "Lok"-Einstellungen auch bei mir nicht wirken. Jetzt muss ich wohl noch die beiden anderen RocRail-Projekte wieder aus der Schublade ziehen (meine "Achterbahn-Anlage" und die "18-Zug-Anlage"), bei denen ich damals hoffnungslos gescheitert war. Viele Grüße BahnLand

Hallo Neo, neugierig, wie ich nun mal bin, habe ich die neuesten Anlagen aus dem Online Katalog ausprobiert. Dabei sind mir folgende "Ungereimtheiten" aufgefallen, die vermutlich durch die Namensgleichheit zweier fast identischer Anlagen ausgelöst werden: Es handelt sich um die beiden Anlagen "Übungsanlage Märklin" und "Übungsanlage Märklin" (verschiedene Links!!!) in der Kategorie "Kleine Anlagen". Hat man eine dieser beiden Anlagen im Modellbahn-Studio geladen, sind die Funktionen der oberen Button-Leiste jeweils um einen Button nach links versetzt (Animation-Button schaltet Geräusche an/aus, Cockpit-Kamera-Button wechselt zwischen Tag- und Nacht-Modus, 2D-Button aktiviert die Technische Zeichnung, 3D-Button aktiviert die 2D-Ansicht usw.; die Freie Kamera kann nur über das Menü ausgewählt werden). Bei der zweiten Übungsanlage steht zusätzlich die Cockpit-Ansicht des ersten (und nur dieses)  ICE-Triebkopfs "auf dem Kopf". Eine fast identische Anlage, aber mit abweichendem Namen, gibt es noch einmal unter "Experimentelle Anlagen": "severin xxl spezialbahn". Dort treten die oben beschriebenen Fehler genauso wenig auf wie bei allen anderen von mir ausprobierten Anlagen (einschließlich meiner eigenen). Hieraus resultiert meine Vermutung, dass es an der Namensgleichheit der beiden erstgenannten Anlagen liegen könnte. Viele Grüße BahnLand P.S.: Das Problem mit der "auf dem Kopf stehenden" Cockpit-Ansicht ist gelöst: Der Autor der Anlage hat wohl vor dem Abspeichern die Cockpit-Ansicht mit der Maus "verdreht" und nicht mehr zurückgestellt. Ich konnte die Ansicht mit der Maus wieder "gerade biegen". Das Problem mit den Funktionsbuttons ist aber weiterhin da.  

Hallo Torsten, Dein Klapp-Mechanismus ist wirklich beeindruckend. Und den seitlichen Blick in den "Untergrund" hast Du auch sehr schön gelöst. Anerkennende Grüße BahnLand

Hallo zusammen, diese "Vewirrung" habe vermutlich ich durch meine Namensgebungen für spezielle Objekte  und die zugehörigen Definitionen in der Ereignisverwaltung verursacht. Ich stelle bei den Objekten, die ich in der Ereignisverwaltung referenzieren möchte, gerne ein Sonderzeichen (hier das Zeichen "#") voran, damit mir in der Übersicht aller Objekte (im Selektieren-Menü) die für mich "relevanten" Objekte alle zusammenhängend vor allen anderen Objekten angezeigt werden. So muss ich nicht immer die gesamte Objektliste "absuchen", wenn ich ein solches ("hervorgehobenes") Objekt in der Ereignisverwaltung referenzieren möchte. Neben dem "#" könnte bei mir für solche Zwecke eventuell noch das "_"-Zeichen (der "Unterstrich") zum Einsatz kommen. Aber ich glaube, dass ich bisher nur den "Gartenzaun" hierfür verwendet habe. Bezüglich der ">"'- und "<"-Zeichen hat Lutz Recht: Auch ich verwende diese (nur) im Sinne der "üblichen" arithmetischen Variable-Wert-Vergleiche. Die gestiftete "Verwirrung" war nicht beabsichtigt (sorry). Aber das Voranstellen des "Gartenzauns" in der Bezeichnung der (für mich) "relevanten" Objekte hat mir persönlich "das Leben mit der Ereignisverwaltung" erheblich einfacher gemacht. Viele "überkreuzte" Grüße BahnLand

Hallo Neo, das hatte ich mir fast gedacht. Aber wie bereits angedeutet: Es dürfte aus der Entfernung für die zweite LoD-Stufe (und weitere) kaum auffallen, dass das Fahrzeug ohne Spurkränze deshalb 0,4 mm zu tief platziert wird. Trotzdem Danke für diese Information. Vielleicht kann ich sie ja ein andermal gebrauchen. Gruß   BahnLand

Hallo Neo, wenn ich einem Radsatz einen vollen (am der Auflagestelle des Rades auf die Schiene nicht abgeflachten) Spurkranz verpasse, muss ich das damit ausgestattete Fahrzeug mittels des "Abstand"-Parameters etwas absenken, damit die Räder wieder auf den Schienen laufen und nicht darüber schweben. Wenn ich nun verschiedene LoD-Stufen habe, wobei der Radkranz nur in der LoD-Stufe 0 vorhanden ist, kann ich für das gesamte Modell trotzdem nur einen "Abstand" definieren. Wie wird dies nun bei der Darstellung des Fahrzeugs gehandhabt? Ist dieser Abstand nun für alle LoD-Stufen gültig? Werden also die höheren LoD-Stufen ohne Spurkranz "in die Schiene gedrückt", wenn ich die niedrigste  (Detail-reichste) LoD-Stufe korrekt aufsetzen möchte? Auseinander gezogene LoD-Stufen eines Drehgestells Ich weiß, dass dies aufgrund der Beobachtungs-Entfernung, in der die höheren LoD-Stufen erst angewendet werden, eigentlich überhaupt keine Rolle spielen sollte, weil der Versatz im Vergleich zur Höhe des Gesamtmodells doch "fast verschwindend" klein ist. Trotzdem würde mich interessieren, wie das MBS damit umgeht. Viele Grüße BahnLand

Hallo Neo, wir hatten ganz am Anfang des Modellbahn-Studios schon mal über das Thema "Wechsel der Fahrzeugeigenschaft Lok/Wagen" diskutiert, doch leider finde ich den Thread nicht mehr. Damals ging es um die Frage, warum das Auswahlkästchen "Lok oder Wagen" des alten Eisenbahnplaners nicht in das Modellbahnstudio übernommen wurde. Du hattest dies damals damit begründet, dass im MBS für "Loks" und "Wagen" bestimmte Optimierungen vorgenommen würden, die ein einfaches Umschalten zwischen diesen beiden Varianten nicht mehr zuließen.  Mir ist inzwischen eine Idee gekommen, wie man möglicherweise zumindest die eine Richtung (mache aus einer "Lok" einen "Wagen") relativ einfach "in den Griff" bekommen könnte, ohne dass Du Deine Lok/Wagen-spezifischen Optimierungen aufgeben müsstest. Wenn Du die Zuweisung eines Geschwindigkeitswerts für eine Lok insgesamt abschaltbar machen würdest, und zwar unabhängig davon, ob die Geschwindigkeit über das hier gezeigte Eigenschaftsfenster direkt oder über die Ereignisverwaltung ("Lokgeschwindigkeit setzen") zugewiesen wird, wäre zumindest der Einsatz einer Lokomotive als "nicht angetriebene Wagenlok" gelöst. Als Schnittstellen-Erweiterung im Eigenschaften-Fenster des Modellbahn-Studios könnte ich mir ein Häkchen vor der "Geschwindigkeit" vorstellen, mit dem, wenn es nicht gesetzt ist, die Geschwindigkeitsvorgabe und die Geschwindigkeits-bezogenen Lok-Eigenschaften im Eigenschaften-Fenster ausgegraut werden.  In der Realisierung müsste man dann die Programmteile, die für das Zuweisen einer Geschwindigkeitsvorgabe für die betroffene Lok zuständig sind, einfach "ignorieren" (überspringen), damit die Lok wie heute auch "nur im Zugverband mitgezogen" wird - solange sie eben nicht über ein gerade befahrenes Gleis eine Geschwindigkeitszuweisung erfährt (genau diese darf eben nicht wirksam werden).  Natürlich ist das mit dem "einfach Programmcode überspringen" leicht dahin gesagt. Aber ich könnte mir vorstellen, dass der Aufwand für die entsprechende Code-Anpassung doch überschaubar ist. Die umgekehrte Problematik, dass (normalerweise nicht angetriebene) Wagen alleine fahren (z.B. am Ablaufberg), ist damit natürlich nicht gelöst. Da hattest Du aber ja schon einmal die Idee eines "Schwerkraft-Antriebs" (wahrscheinlich ähnlich der "Geschwindigkeitsanpassung am Berg" für Lokomotiven) angedeutet. Viele Grüße BahnLand

Hallo Seehund, vielen Dank für Deinen Hinweis mit dem Aufbringen der Textur, was ich auch gleich ausprobieren musste : Ich habe einen Drehgestell-Torso, dem ich bisher zwei Texturen zugeordnet habe: Eine Maßzeichnung als "Orientierungshilfe" für das "Ausschneiden der Konturen" und für einige Teile schon die fertige Drehgestell-Textur, die neben der Drehgestell-Seitenansicht auch die für den noch hinzuzufügenden Radsatz zu verwendenden Textur-Ansichten (insbesondere das "Vollrad") enthält. In einem separaten "Projekt" habe ich den Radsatz vorgefertigt. Bei diesem habe ich dieselbe Textur verwendet, die auch beim Drehgestell zuletzt vorhanden sein soll, und ihr in Google Sketchup (ja, ich arbeite (bislang) noch mit diesem Zeichentool) auch denselben Namen verpasst. Fügt man nun den Radsatz mittels "Copy & Paste" in das Drehgestell-Projekt ein, sind weiterhin "nur" zwei Materialien (keine drei) vorhanden (nämlich die Maßzeichnung und einmalig die in beiden Projekten verwendete Drehgestell-Textur). Wenn ich dieses Projekt (Drehgestell-Torso, kombiniert mit einem Radsatz) dann in eine X-Datei exportiere, und diese in das Modellbahnstudio einlese, sehe ich auch dort nur 2 Materialien und dementsprechend auch nur zwei Unterobjekte. Es scheint also (zumindest bei Google Sketchup) so zu sein, dass zwei Materialien, die denselben Namen besitzen und dieselbe Texturdatei verwenden (eine Farbzuordnung habe ich nicht vorgenommen), als identisch erkannt werden (vielleicht liegt es ja auch am Exporter, der jedes Material nur einmal aufnimmt und referenziert). Wie das beigefügte Bild zeigt, hat das Zusammenfügen der beiden (getrennt texturierten) Objekte zu einem Modell hervorragend funktioniert, zumal auch die ursprünglich vorgenommenen Textur-Positionierungen beim Zusammenfügen erhalten geblieben sind. Die etwas über 400 Polygone sind dem Radsatz zuzuschreiben, dessen Radkanten "Kreisen mit 24 Ecken" entsprechen und damit für die vielen Flächendreiecke "verantwortlich" sind (die "Kantenglättung" hat offenbar keine negativen Auswirkungen). Dass diese nicht zu Polygonen mit mehr als 3 Eckpunkten zusammengefasst sind, scheint kein Problem darzustellen. Denn bei Versuchen mit einer entsprechend "optimierten" X-Datei für einen einfachen Würfel (siehe Dateien "Wuerfel_3.x" und "Wuerfel_3.mbe" in beiliegender ZIP-Datei) habe ich festgestellt, dass die dort explizit definierten Flächen-Quadrate (6 Polygone (Würfelseiten) mit 4 Ecken) beim Einlesen in das Modellbahn-Studio wieder in Flächen-Dreiecke zerlegt wurden (siehe das folgende Bild, das trotzdem 12 Polygone anzeigt). Ich habe in beiliegendem ZIP-Paket (insbesondere für Neo) einmal denselben Würfel in 3 verschiedenen "Optimierungsstufen" sowohl als X-Dateien als auch als fertige mbe-Modelle beigelegt: Der rote Würfel_1 entstand aus dem Sketchup-Modell durch X-Export. Er unterscheidet sich von den anderen 2 Beispielen durch die vorhandenen 24 Eckpunkte (statt 8), die insbesondere dann beibehalten werden müssen, wenn die den Flächen zugeordneten Texturen (oder auch wie hier nur deren Textur-Koordinaten) nicht übereinstimmen. Beim grünen Wuerfel_2 habe ich die Texturkoordinaten händisch "bereinigt" (wegen der Einfarbigkeit möglich) und dadurch die Eckpunkte auf das Minimum "8" reduziert, aber die von Sketchup erzeugten Dreiecks-Polygone beibehalten. Beim dritten blauen Würfel_3 habe ich dann schließlich jeweils 2 Dreieck-Polygone zu einem quadratischen Polygon zusammengefasst. Hierzu ein paar Fragen an Neo: Gibt es aus der Sicht des MBS überhaupt einen Unterschied zwischen den Varianten 2 und 3? Wirken sich eventuell zu viele in der X-Datei definierte Eckpunkte (Vergleich der Varianten 1 und 2) negativ auf die grafische Aufbereitung durch das MBS aus (wohlgemerkt: alle 3 Beispiele besitzen dieselbe Polygonzahl und Anzahl von Unterobjekten)? Der einzige Wermutstropfen, den ich momentan bezüglich des zu betreibenden Aufwands für die Bereitstellung Darstellungs-optimierter Modelle sehe, ist die Notwendigkeit, gewölbte Flächen (z.B. Zylinderflächen) in einzelne ebene Flächenstücke aufteilen zu müssen, um sie anschließend aus einer "Textur-Palette" heraus separat mit den korrekten Textur-Ausschnitten belegen zu können (Verschieben und Drehen von Texturen geht in Sketchup bei gewölbten Flächen nicht - aber vielleicht ist das ja nicht nur ein "Sketchup-spezifisches" Problem?). Da ich kein Problem habe, Drehgestelle und sich drehende Speichenräder mittels Sketchup und dem passenden Direct-X-Exporter herzustellen, und ich denke, dass ich die Optimierungs-Anforderungen nach meiner bisherigen Erkenntnis damit auch erfüllen kann (nur bei Animationen wie sich öffnenden Toren oder Schranken bzw. sich drehenden Windmühlenflügeln hätte ich bisher ein Problem), ist für mich Google Sketchup als Zeichentool für MBS-3D-Modelle "weiter im Rennen". Viele Grüße BahnLand     Wuerfel.zip

Hallo Seehund und Neo, ich sehe das genauso - dass hier wirklich "herausgeholt" wurde, was möglich war. Gerade deswegen halte ich es für etwas "irritierend", wenn bei der Ansicht im Modellbahnstudio in der zweiten Stufe (Level 1) bei der Qualitätsbewertung das Ausrufezeichen (wegen "zu komplexer Geometrie" ) erscheint, nur weil die ohnehin schon kleine Anzahl von Polygonen in der ersten Stufe (Level 0, 216 Polygone) in der nächsten Stufe nicht noch einmal halbiert werden konnte (144 Polygone). Und eine "Reduzierung" der Unterobjekte ist ohnehin nicht mehr möglich (kleiner als 1 geht nicht). Wäre es möglich, bei eh schon kleiner Polygon- und Unterobjekt-Zahl den Bewertungs-Algorithmus hier etwas "toleranter" zu gestalten? Ansonsten, Seehund, würde mich dein Aufwand schon auch interessieren,  weil ich mich gerade ebenfalls an meinem ersten "LoD"-Modell (meinem Eurofima-Wagen) versuche, mich aber noch ganz "am Anfang" befinde (ich fange wieder bei "0" mit den Radsätzen und den Drehgestellen an). Viele Grüße BahnLand

Hallo Franz, das ist wirklich verblüffend. Da muss ich mir mal die X-Datei genauer ansehen. Vielen Dank dafür. Viele Grüße BahnLand

Hallo Franz, hast Du für den von Dir beschriebenen Effekt solche "Bauteile" (Straßenstücke) verwendet, bei denen das Gizmo mit einem der Andockpunkte zusammenfällt? Ich hab's nämlich nur bei solchen Beispielen geschafft, Deinen Hinweis zumindest ansatzweise nachzuvollziehen. Bei "meinen" Bauteilen mit Andockpunkten ist das Gizmo immer zentriert. Und dann funktioniert das mit der Beibehaltung des "Verknüpfungspunktes" beim Drehen eines der zusammengedockten Bauteile (zumindest bei mir) nicht: Zunächst erfordert es am Gizmo eine gewisse "Kraftanstrengung", um den Andockpunkt "aufzubrechen". Und dann bewegt sich der Andockpunkt des zu drehenden Objekts mit der Drehung vom Andockpunkt des anderen Objekts weg. Kommen sich die Andockpunite wieder "nahe genug", schnappt das gedrehte Objekt wieder ein, und auch dessen Ausrichtung ist wieder an jene des anderen Objekts angepasst. Sitzt das Gizmo wie bei einigen gebogenen Straßenteilen des Online-Katalogs an der Stelle eines Andockpunktes, kann ich das von Dir beschriebene Verhalten nachvollziehen, wenn ich die Drehung nicht mit dem Gizmo, sondern durch die Modifikation des Drehwinkels im Eigenschaftsfenster durchführe. Nur dort werden auch kleine Winkel-Änderungen wirksam, ohne dass das Objekt gleich wieder in die ursprüngliche Ausrichtung zurückschnappt. Genau das passiert aber, wenn ich nachträglich wieder das Gizmo verwende. Das Problem, das ich bei der Verlagerung des Gizmos an die Stelle eines Andockpunktes sehe, liegt jedoch darin, dass ich hierfür nur genau einen Andockpunkt verwenden kann. Besitzen die aneinander zu fügenden Modelle jeweils genau zwei Andockpunkte, kann man wenigstens immer einen Andockpunkt mit und einen ohne Gizmo zusammenfügen, um eine (mit Einschränkung) "biegsame" Kette zu bekommen. Dann lässt sich aber die Orientierung eines Modells in der Kette nicht mehr umkehren. Als Resultat bleibt für mich daher nur die Lösung, Gizmo und Andockpunkt nicht miteinander zu verquicken und stattdessen wirklich Andockpunkte zu schaffen, die eine Verdrehung der Objekte analog dem "Biegen" von Gleisen zulassen. Viele Grüße BahnLand