~cab

Wow, Danke! Dem T4D mit der fiktiven Nummer 222491-7 gefällt das Wegen des Eintrages: ich hatte letzlich das Binary aufgemacht. Das brachte mich dann erst auf den Gedanken, dass das Problem die Szenen selbst sein könnten, weshalb die Fehlermeldung nicht passen wollte und ich den Thread aufmachte. Ich habe mich weder mit der Spezifikation befasst noch das JSON komplett angesehen und unterlag deshalb der Annahme, die Collections trügen ein Array für eine Relation. Nach Spec soll man mit den Collections alles tun können, einschließlich in andere blend-Files verlinken. Und wenn Blender (2.91) dabei Mal nicht abschmiert, funktioniert das auch und sieht dann so aus: Ob das Ding mit den Scenen das Allerheilmittel ist weiß ich nicht. Ich benutze Blender seit 2.3 und kenne noch immer nur einen Bruchteil: man lernt, was man braucht. Ich würde Instanzen nehmen, aber a) solche Instanzen sind eher für Memory-Geschichten und nicht für den Workflow und locked (siehe oben Beispiel mit den Sitzen); b) der Exporter ignoriert die eh. \o/ Yay! Dann kann ich mir tatsächlich irgendeinen Wagen raussuchen und den im Katalog publizieren, mit der Option doch irgendwann noch eine Variation zu adden. Mich hielt davon ab, dass alle Entscheidungen mit Publikation final sind. (Die beiden Museumswagen schließe ich vorerst aus: dann guckt ganz sicher jemand und dann krieg ich auf die Mütze )

Moin @Reinhard, keine Sorge: es werden keine 22k Varianten. Es wird eher darauf hinauslaufen, dass ich die markantesten Änderungen nehme, um eine Variation abzuleiten. Es bleibt dann aber ein einziges Blender-File ohne der Möglichkeit Collections in Szenen zu verlinken. Zumindest, solang MBS beim Import herumflucht, nur weil eine Collection in mehr als einer Szene liegt. Wenn ich Abkürzungen verwendet habe, die nur von Insidern verstanden werden, bitte ich um Entschuldigung und frage nach, an welcher Stelle ich nachbessern soll, damit das Geschriebene verständlicher ist. (ER = Einrichter, ZR = Zweirichter, Tw = Triebwagen, Bw = Beiwagen, Atw/Abw = Arbeitstrieb-/-beiwagen, Gtw/Gbw = Gütertrieb-/-beiwagen — falls das gemeint war) Das gesuchte Modell ist der T4D. Er fuhr in 4 Städten: Dresden, Leipzig, Magdeburg und Halle und prägte 5 Jahrzehnte deren Stadtbild. Das Modell existiert in H0 und ist im Handel erwerbbar. Geschätze 80% aller Objekte kann ich direkt für die 30cm breiteren T3D für Schwerin und Chemnitz übernehmen — und dann sind wir auch schon fast beim T3 für Prag u. a. Städten in Osteuropa. Der Fahrzeugtyp dürfte einen ähnlichen Stellenwert haben wie die Düwag-Wagen — in Osteuropa auf jeden Fall einen relevanten. Gleichzeitig lässt sich dieses Thema wunderbar mit Eisenbahn verknüpfen, denn die Fahrzeuge wurden via Güterverkehr geliefert und ČKD ist Nachfolger von Ringhoffer. Nur einmal den Anfang finden und dann kann man ganz neue Welten erschließen — nicht unbedingt abseits von Lokomotiven. MBS bietet viele Möglichkeiten — es fehlt schlicht an Material und ich möchte, wenn ich einen Btf im Stil der 70er Jahre nachbauen will, dann doch eher nicht auf Altbau-Wagen als Platzhalter zurückgreifen müssen. Nehme ich das dann vorhandene Material, bin ich schnell beim T2, beim T1… Einige System-Komponenten bzw deren Weiterentwicklungen finden typübergreifend Verwendung. Sie gehören quasi zu etwas, dass man als Corparate Design bezeichnen könnte. Es ist ein Copy-Paste-Spiel in Blender: und dann sind wir wieder beim Komposit und das Spiel wiederholt sich. https://de.wikipedia.org/wiki/Kompositum_(Entwurfsmuster)#Verwendung Der einzige Grund für ein neues Blender-File ist der Sprung vom T3 auf den T5, weil symmetrisches Baukastenprinzip statt "asymmetrisches Kunstprojekt". Aktuell ist es eher ein Spaß — ob für den Katalog lass ich offen. Nebenbei will ich herausfinden, wie sich derartig komplexere Strukturen/Vorbilder verwalten und MBS-kompatibel erstellen lassen, ohne mehr Aufwand als nötig zu betreiben. Eine Szene in Blender nach Wagen- oder Fabriknummer zu benennen, alle benötigten Teile dorthin zu verlinken, und nur noch eine szenengebundene Collection für die Lackierung aufzusetzen, schien mir ein geeignetes Mittel. Die Textur wird durch ein Skript geschrieben, die Farben liegen in einer Datenbank, auf der Festplatte liegt ein Hardlink zum Blender-File... Dein Link zu deinem Schienenbus: Ja, es erschlägt einen erst einmal (wissend, dass es bei mir nicht anders aussähe) — aber irgendwo gibt es sicher jemanden, der das gern nutzen würde. Und wenn es nur einer ist, dann hat man als Modellbauer eben diesem einem anderen eine Freude gemacht Ja: das ist schwierig, wenn man mit den Fahrzeugen augewachsen ist. Es ist wirklich einfacher, wenn die Distanz sehr groß ist. Je weniger Details bekannt sind, weil man nur Fotos aus den 1920ern hat, desto einfacher. Desto enfacher ist es auch, weil alle anderen auch nur das genutzte Referenzbild kennen und deshalb keiner meckern wird. — Das ist umso schwieriger, wenn man selbst gebürtiger Meckerer ist, wie ich eben einer bin — ich weiß einfach, was dann kommen wird und das will ich dann vermeiden… während ich mit dem Projekt zeitgleich Aggro von hier ziehe: zu überfeatured, zu viele Details, zu viele Animationen (kommt bald)… Mein Modell wird Katalog-kompatibel sein, wird wohl aber, zumindest bis das Lektorat durch ist und eine Entscheidung bzgl. Variationen gefallen ist, vorerst ein Download im Forum oder sonstwo bleiben. Es gibt geeignete Communities wo eine Publikation zumindest eine Zielgruppe treffen würde, die MBS nicht nutzen, weil MBS (bisher) eher ein Ding für Eisenbahner ist und Straßenbahnen eben ein Nebenprodukt sind: fährt eben auch auf Schienen. Das ist nicht nur Schade, sondern verschwendetes Potential. Was ich beim MBS-Mitbewerber aus dieser Kategorie Tatra-Stab gesehen habe — und das auch noch gegen Bezahleng — hat u. a. dazu geführt, dass ich es so mache, wie ich es gerade mache und nicht anders: es ist dort nicht sonderlich hübsch anzusehen. Gleichzeitig gehe ich nicht davon aus, dass sich aktuell hier kaum einer für eine Variante "Wagenkastengerippe", "abgestellt für Verschrottung", Schemel auf Drehgestellen für Schienentransport oder gar eine einzelne Tür für seine Gartenlaube interessieren würde: die Möglichkeiten sind aber alle gegeben. Allein das Interesse an Ringhoffer-Eisenbahn/Schienenfahrzeuge, ČKD Tatra, vor allem aber Prager und damit verbundener Ostblock-Straßenbahn-Geschichte, dürfte zu speziell sein. Ich erstelle das Modell aktuell nicht unter der Prämisse, es solle auschließlich für den MBS-Online-Katalog sein. Modellstraßenbahner sind irgendwie eh immer die belächelten, das war schon vor 25 Jahren so: es ist zu regional begrenzt und zu klein. Als Modellstraßenbahner habe ich hingegen eine Abneigung gegen gekürzte Personenwagen und unrealistische Kurvenradien bedingt durch die Abmessungen des Wohnzimmers… — während die Münchner Tram auf 12 oder 14 Meter Radius klarkommen muss. Ein Düwag- oder Tatra-Wagen hat zumindest das Potential, dass ihn irgendwann mehr als 2 Leute im MBS nutzen. Eine der Barrieren, die gegen eine direkte Publikation im Online-Katalog sprechen, ist u. a., dass, wenn ich es richtig verstanden habe, nachträgliche Änderungen, einschließlich dem Hinzufügen einer neuen Variation, auf Grund der GUID-Vergabe, unmöglich sind, ohne dabei das komplette Modell zurückzuziehen. Ein Update würde Fragezeichen auf der Platte bringen; eine Veröffentlichung ist somit ein unveränderliches Etwas. Fehlerkorrektur ist damit ausgeschlossen und es würde mich auf die Palme bringen, wenn ich einen Fehler im Katalog-Modell fände, wissend, dass ich den nicht mehr berichtigen kann — während ich außerhalb des Katalogs das Modell bei Github mit Changelog samt Lebensgeschichte des Orignals in Variationen hochladen kann. Die Fabriknummern, HU-Daten etc., sind ja alle vorhanden… Es fehlen ein Daten/Maße, Schriften, teilweise Referenzmaterial; ich müsste vor Ort sein und das geht wegen Covid nicht. Deshalb dümpelt das ganze Projekt seit März vor sich hin. Es fehlen Texturen, ich komme nicht ins Museum; mich trennen 600km vom Vorbild und jemanden beauftragen kommt wegen Urheberrecht nicht in Frage. Und irgendwie wäre das schon lustig: eine Katalog-Kategorie ČKD und dort liegt alles drin, was man dann eben so braucht — einschließlich Ersatzteile für die Werkstatt-Deko BTT: Ein komplexes Projekt bedarf einer anderen Herangehensweise und MBS zerknirscht den Workflow ohne im Wiki (Stand Threaderöffnung) darauf hinzuweisen, was man in Blender nicht tun sollte, bzw. entstand der Thread wegen der unglücklichen/unpassenden Fehlermeldung.Unabhängig von diesem Projekt, würde ich es prinzipiell so ansetzen: wenn ein Triebwagen in einen Beiwagen umgebaut (bzw. umgekehrt) oder ich mich in einem Kontext befinde, in dem Objekte aus Variante A sich sehr mit denen in Variante B überschneiden, würde ich auch dort alle relevanten gemeinsamen Collections in eigene Szenen verlinken, statt permanent mit den Checkboxen der Collections herumzuspielen.

Hallo @Reinhard, Danke für die Antwort. Das Projekt, um dass es hier geht, entspricht eigentlich einem Komposit-Pattern. Zum Verständnis werde ich das etwas ausführen, auch, warum ich alles in einem File ablege und warum ich keine neuen Files für LOD-Stufen aufmache. Es war einmal ein Hersteller, der ~22000 Fahrzeuge baute… Diese untergliedern sich in 2, für mich relevante, Typen zu ~14000 und ~4000 Fahrzeugen. — Ich bin genügsam und konzentriere mich auf die 4000 RGW-Fahrzeuge und breche auch diese nochmal herunter auf einen ganz bestimmten Kunden und bin nun bei ~800. Auch das breche ich runter auf die Baujahre: und bin dann bei 18. Diese Fahrzeuge wurden in Chargen ausgeliefert, die sich in einzelnen kleineren Elementen von den Fahrzeugen anderer Chargen unterscheiden: Größe von Dachluken, Türblatt-Layout, Weiterentwicklungen… Es wäre das, was in MBS als Variation läuft. — Ich weiß noch nicht, wie weit ich das Spiel treibe: je nachdem, was sich recherchieren lässt, veranschlage ich vorab schon mal für jedes Bj (Charge) eine Variation zu erstellen: das wären 18 Tw-Variationen und 15 Bw-Variationen — für den Auslieferungszustand, für einen von vier Kunden. Diesen Umstand ignoriere ich jetzt erst einmal, denn er sei hier nicht relevant. Er soll nur veranschaulichen, dass es bei meinem Projekt nicht, wie anfangs geplant, um einen Bauklotz in zwei Farben geht. Irgendwas dazu muss ich mir aber einfallen lassen, denn die Baujahre decken die Epoche IVa-c ab und diese unterscheiden sich eben (Leuchtstoffröhren strahlen eben heller als Glühbirnen). Vielleicht mache ich eine Umfrage unter ehemaligen Fahrern: most loved und most hated Charge — was witzig klingt, aber gar nicht so weit weg von der Realität ist: mir sind Fahrzeuge bekannt, die derer Art verhasst bei Fahrern und Fahrgästen waren, dass sie umnummeriert werden mussten, weil sie niemand mehr fahren bzw. niemand mehr einsteigen wollte. Weil der Hersteller bis dato noch nie Beiwagen baute, machte er es sich einfach und schmiss einfach alles raus, was nicht nach Triebwagen aussieht. Ich habe hier die Original-Kontruktionspläne von den beiden Drehgestell-Typen: das Bw-Gestell ist keine Neukonstruktion. Wir haben also EINE Fahrzeug-Plattform: Türen und Fenster-Anordnung ist identisch, der Wagenkasten ist identisch — nur die GfK-Front unterschiedet sich. Stattdessen haben wir nur einen Stromabnehmer, einen Fahrersitz und Scheinwerfer hinzuzufügen… Und wenn der Hersteller nicht Insolvenz anmelden hätte müssen, würde er noch heute Schienenfahrzeuge bauen. Arbeitsweise: Eines war mir von Anfang an klar: so ein Puzzle-Modellbau macht zwar richtig Spaß aber erfordert etwas Umsichtigkeit bei der Planung. Ich hatte schon überlegt ein Library-Blender-File zu machen: hat aber den Nachteil, dass ich gänzlich unflexibel bei Textur-Koordinaten werde, denn die werden in der Quell-Datei gesetzt. Dann kann ich aber nicht mehr sagen, verlinke Mesh aus Datei.blend zu Koordinate X,Y,Z und mach mir das an dieser Stelle rot, verlinke es noch einmal und mache es grau… Dazu kommt: das Export-Plugin zickt seit jeher bei Instanzen herum (er ignoriert sie einfach). Man muss den Umweg über FBX gehen… Um in Blender nicht alles zweimal machen zu müssen, erstelle ich also zwei Collections: Tw und Bw. 80% aller Meshes liegen in beiden Collections, die restlichen 20% nur im Tw, vernachlässigbar wenige nur im Bw. Wir bauen nun also unseren Tw und Bw und belassen alles in den beiden Collections, denn selbst die Texturen stimmen zu 90% überein. Beim Export fürs MBS aktivieren wir nur die Collection (bzw. früher den Layer) mit Tw oder Bw und freuen uns. Meine Arbeitsweise für LOD1 und LOD2 sieht so aus: Nach dem Texturieren erstelle ich die Collections für die zusätzlichen LOD-Stufen und Blender hat nun 6 Collections: LOD0_Tw, LOD0_Bw LOD1_Tw, LOD1_Bw LOD2_Tw, LOD2_Bw Einige Elemente aus LOD0 verlinke ich direkt (Shift+M) nach LOD1: zB Planes, wo es nichts zu reduzieren gibt. Es handelt sich um einen Link und kein Duplikat. Bei anderen Elementen, die ich nicht weglassen kann (Räder), aber das Mesh reduzieren will, dupliziere ich das Mesh des Rades (Shift+D) aus LOD0, präfixe den Mesh-Namen des Duplikates mit LOD1 und verschiebe es in die Collection für das LOD1-Modell. Ich deaktiviere LOD0 im Outliner und kann das Lod1-Mesh so weit bearbeiten, wie ich es für LOD1 wünsche. (Es bietet es sich an erst zu verlinken (Shift+M), dann zu entfernen (Shift+Alt+G); Grund: versehentliches Deselektieren oder anderes unbeabsichtigtes Verhalten kann dazu führen, dass man seine zu verschiebenden/verlinkenden Objekte in Orphaned Data wiederfindet). Die Teile, die man tatsächlich von LOD0 bis LOD2 "durchschleift" werden immer weniger. Ich ziehe es vor im LOD0 anzufangen, andere gehen den umgekehrten weg — was aber, subjektiv, nachteilig ist.) Davon abgesehen bietet es sich in einigen Fällen an, erst einmal einen Link des Meshes zu erstellen (Alt+D) und dieses in der anderen LOD-Collection zu verlinken: nur um zu sehen, ob ein Decimate-Modifier nicht auch schon weiterhilt. Vorteil: alles ist hier übersichtlich, alles hat immer die gleichen Koodinaten und ich kann LOD-übergreifend Textur-Koordinaten der Meshes bearbeiten und mich darauf verlassen, dass es beim Wechsel zwischen den LOD-Stufen im MBS nicht flackert oder etwas verrutscht. Wir haben nun also unsere Modelle für TW und Bw in allen LOD-Stufen, aber er tut noch nichts. Ein Modell ohne Animation ist langweilig. Ich möchte also eine Tür öffnen. So eine Tür besteht in meinem Modell aus 4 Türflügeln: das sind 4 Animationen mit insgesamt 8 Key-Frames (Start+Stop). Bei dem hier oft praktizierten "eine Lod-Stufe ist ein Blender-File" stünde man nun vor dem Problem: man hätte in 3 Files diese 8 Key-Frames zu setzen: und wehe da stimmt dann etwas nicht! — Dafür ist mir meine Zeit zu schade. (Nachtrag: und den Beiwagen haben wir nun vergessen, weil der liegt in einer anderen Datei… Also 6 Files insgesamt, denn der Beiwagen hat ja auch eine Tür an selbiger Stelle, die auch geöffnet werden will ) Ich erstelle also eine neue Collection: ConfigAnimation. In dieser Collection liegen NUR Empties. Diese Emtpties halten NUR die Action für die Animation. Für meine Tür und die 4 Türflügel sind das 4 Empties, die um die Z-Achse rotieren. Meine Türflügel werden von Tw und Bw gemeinsam benutzt. Die Türflügel für LOD0 sind also verlinkt in LOD0_Bw und LOD0_Tw. Ich muss also nur die Türflügel in 3 Collections anpassen: LOD0, 1 und 2; ich definiere die Empties aus der Collection ConfigAnimation als Parent für meine Türflügel. Beim Export fürs MBS sind jetzt also für jeden Export zwei Collections aktiv: ConfigAnimation ist immer dabei, und ansonsten wie gehabt jede LOD-Stufe für sich. Aus diesem Konstrukt ConfigAnimation+LOD-Collections kann ich binnen Sekunden einen Türflügel für alle 3 LOD-Stufen als Variation ohne Fenster erstellen und weiß, das er funktioniert. Ich brauche nur einen existierenden Türflügel duplizieren: er hat bereits sein Parent zugewiesen und selbst wenn man jetzt Unfug macht, indem man den aktuellen Frame und damit den Zustand seines Parents ändert: seine Koordinaten sind relativ noch immer die gleichen. Gleich im Anschluss aktiviere ich alle 3 Collections, selektiere meine neuen Türflügel aus alles LOD-Stufen gleichzeitig, gehe in den Edit-Mode, und kann für alle LOD-Stufen gleichzeitig die Textur setzen... Nur noch die neue Export-Collections zuweisen: fertig. (Und die Türen habe ich jetzt genommen, weil ich die eben durch habe: es gibt in meinem Fall nicht nur unterschiedliche Fensterbreiten, Mehr-Fenster-Türflügel, sondern auch in der Länge gekürzte Türflügel) Kommen wir nun zu dem Wunsch nach den Szenen: Das o.g. funktioniert alles recht gut, solang es bei wenigen Collections bleibt: config mit Empties und 3 Collections für LOD-Stufen… Und die oben beschriebenen Baujahre als Feature-Collections… Alles hübsch, alles easy, alles lustig… Dann kommt die Realität: Unabhängig davon, gab es, auf Grund verschiedener politischer Umstände, keine Möglichkeit seitens des o. g. Herstellers Fahrzeuge zu liefern, die der Kunde tatsächlich benötigte. Der Kunde fing nun an einzelne Wagen seinen Bedürfnissen selbst anzupassen. Und das nicht nur, weil der Hersteller Probleme damit hatte, Ersatzteile zu liefern: ausschlachten von Neufahrzeugen gegenüber Verwendung von Ersatzteilen war an der tagesordnung. Und es war billiger. Aus der einen o. g. Plattform für Tw und Bw wurden schließlich 6. - Triebwagen (ER, ZR) - Beiwagen (ER, ZR) - Arbeitsfahrzeuge Während die ER-Versionen noch Gemeinsamkeiten haben, sind die ZR-Varianten interessanter: Bw-ZR und Tw-ZR haben nichts miteinander zu tun. Das ist der Asymmetrie des Wagenkastens (links vs rechts) zu verschulden und der Technik, die unveränderlich platziert ist. Die Fahrzeuge unterscheiden sich im wesentlichen nur in wenigen Punkten: Anzahl und Platzierung der Türen/Fenster und diese Veränderungen ergeben damit eine neue Plattform. Das Wort Plattform benutze ich an dieser Stelle für alles, was einen solchen Umbau ausmacht. Und sei es nur eine einzelne Kiste, die für eine andere Plattform umgesetzt wurde: dann ist es auch eine neue Plattform. All das, was nicht länger als gemeinsames Objekt für alle zu exportierenden Fahrzeuge gültig ist, sei es durch weglassen, hinzufügen oder verschieben, nenne ich hier Plattform). Wir haben nun also eine Kiste in den Koordinaten geändert, der Rest bleibt wie er ist, im Zustand der ursprünglich vom Hersteller gelieferten Fahrzeuge. Wir gestaltet man nun seine Collections? Wie organisiert man ein solches Projekt? — Abstraktion. Und ausgerechnet @Neo, der ja wohl Programmierer ist — und im Gegensatz zu mir nicht nur aus Langeweile — sollte das nachvollziehen können. Denn wovor ich stehe ist etwas, dass diesem von mir lieblos zusammengeklatschen Chart entspricht: In der Summe bleibt es dabei, was ich eingangs schrieb: es ist ein Komposit. Mit den Collections habe ich binnen einer Datei ein ziemlich hohes Maß an Flexibilität: ich aktiviere/deaktiviere die Colletions, die ich für mein Modell wünsche und kann Zeit sinnvoller nutzen. Meine Empties für die Animationen bilden den Rahmen, der für alle Modelle und Variationen gültig ist. Was auch immer ich tu: die Tür wird immer aufgehen. Bei mir sieht das so aus und das System ist recht praktikabel: 1. Config (gilt für alles, was diese Datei verlässt: Koordinaten-Ursprung, _WheelSet, _Wheel...): 2. Als nächstes wähle ich die Plattform, in diesem Fall einen ZR, mit Türen bei rechts 1 und 5, links 5 und 8. Das sind die Animationen. 3. Alle Meshes, die sich ALLE Fahrzeuge auf LOD0 teilen — also mindestens die Drehgestellrahmen, Achsen und Räder: 4. Alle Meshes, die nur für die Plattform ZR, mit Türen bei rechts 1 und 5, links 5 und 8 bestimmt sind — ohne Animationen innerhalb dieser Collection. 5. Ich will einen Tw: Bei Lod 1 und später bei 2 wiederhole ich das Spiel und aktiviere für den Export alles, was ich in LOD 1 auch aktiv hatte: Beispiel-Objekt: Die Fensterscheibe (4 Vertices) eines Türflügels; Tw und Bw teilen sich das Objekt, alle anderen Platformen nutzen das Objekt ebenfalls. Durch die nur 4 Vertices liegt das Object auch in allen notwendigen LOD-Stufen 0xxx und 1xxx (mit LOD2 habe ich noch nicht wirklich angefangen): Entscheidend für mich ist, dass Animationen und Textur-Koordinaten zentral verwaltet werden und nicht durch 3 Files flattern: Szenen? Als Filter, der Übersichtlichkeit wegen: ich würde gern alle Collections, die ich jetzt hier in diesen Screenshots aktiviert habe in eine Szene verlinken, die dann die Wagennummer bekommt. Dann wird beim Export nichts vergessen.

Vielen Dank für die Antwort. Organisatorisch. Bisher hatte ich LOD-Stufen in Layern verwaltet. Die Modelle/Files sind alle gleich strukturiert: Layer 1: Empties/Controller Layer 2: Lod0 (Objekte sind Empties in Layer 1 untergeordnet) Layer 3: Lod1 (Objekte sind Empties in Layer 1 untergeordnet) Layer 4: Lod2 (Objekte sind Empties in Layer 1 untergeordnet) Beim Export sind immer Layer 1 und dann der jeweilige LOD-Layer aktiv: Ich muss ich mir keine Gedanken über vergessene Objekte für Animationen machen (alles liegt in den Empties) und alles hat die gleichen Koordinaten — während ich innerhalb einer Datei ohne Aufwand die einzelnen LOD-Stufen editieren kann. Blender hat mit seinen Collections etwas verantsaltet, das hoch-komplex ist, weil es das Funktionsprinzip von Gruppen und Ebenen und Kategorien vermatscht — und deshalb nicht funktioniert. Dazu kommen Programm-Abstürze und dann liegt auch mal eine Collection wieder in Orphaned Data… Ich stehe vor dem Problem, dass ich ein Projekt habe, in dem 80% aller Objekte zwischen Trieb- und Beiwagen geteilt werden und zukünftige Ableitungen von diesem Modell auch irgendwohin müssen. Aktuell sieht das aus wie im Screenshot (Variationen sind noch nicht dabei) — und ist bereits jetzt eine Katastrophe: man muss aufpassen welche Häkchen man für den Export setzt und in welchen LOS-Stufen man etwas löscht. Das alles ist auf LOD0 noch okay — aber die Triebwagen-Animationen unterscheiden sich nun doch von denen eines Beiwagens und das sieht man auf LOD3 im MBS nicht mehr unbedingt, was man dort exportiert hat. Das brachte mich auf den Gedanken, die für die LOD-Stufen benötigten Collections in Szenen zu splitten: Tw Lod0,1,2 und Bw Lod0,1,2: Ich muss nur einmal die Szene einrichten und verlinke alle Collections die zur Szene gehören. Das funktionierte — bis zum Import ins MBS. Letztlich liegt in der glb nur eine Szene. Nur die Collections haben irgendwo den Hinweis, dass sie auch in anderen Szenen verlinkt sind: kann man diesen Hinweis beim Import nicht einfach skippen und MBS annehmen lassen, dass sie nur einer Szene zugehörig seien?

Tach, ich habe in Blender Collections in einer Scene verlinkt (New Scene, Linked Copy) und exportiere aus einer solchen heraus. In MBS V6 importieren kommt ein Fehler, der, nach dem was ich jetzt so sah, absolut nichts mit Sonderzeichen zu tun hat. Die Scene kann auch einfach ABC heißen… Gibt es eine Lösung dafür oder muss ich die Blender-Datei komplett umschnitzen? Edit: Das Problem existiert anscheinend nur, wenn eine Colletion in einer weiteren Scene verlinkt ist; unabhängig davon aus welcher Scene man die markierten Objekte exportiert. ExportTest.zip

Ich will ja gar nichts dazu sagen. Aber… Danke! Bei den T3/T4 Modell käme das gelegen. Nicht weil ich es drauf anlege, und schon gar nicht wegen des Bodys: der tuckert trotz endlosen Rundungen mit 2k herum (hrhr) Als ich mit dem Projekt anfing, das muss März gewesen sein, war ich wirklich sparsam. Abgesehen von den Drehgestellen, denn ich hab die Werkzeichnungen und da waren mir 8k Eckpunkte wirklich Brille. Stromabnehmer Typ ESS48 "nur" 3k. Gesamt 29k. Aber dann fing es an, erst langsam. 4 Türflügel: á 3k (da ist nicht mal die Sicke drin). Ich brauch 3, in Sonderfällen 5: Summe 9-15k. 26 Sitze: á 269. T3/T4 ohne diesen ganzen Klimmbimm sieht nicht gut aus. Nicht so, wie man ihn eben kennt. Das ist auch nicht mit Texturen zu beheben. Puffer nach oben soll immer gegeben sein, so dass ich später am gleichen Modell einfach eine 4. Tür einsetzen kann, ohne den Halben Wagen zu überarbeiten. Dann war noch Licht. Ich habe mir verschiedene Lösungen angesehen: @BahnLand war so freundlich etwas zusammenzufummeln, dass ich haben will. Genau so und nicht anders. Leider ist genau diese Lösung für das T4-Modell ein kleiner Wahnsinn Das Konzept geht wirklich auf, wenn man 30er-Jahre-Bahnen mit Bänken — oh, diese Sitze! — hat. Der ganze Kleinkram frisst dermaßen viel, dass ich ab einem bestimmten Zeitpunkt beschlossen hab "Sch*** drauf — löschen kannst später immer noch". Das Löschen schieb ich jetzt vor mir her… Durch die entstandene freie Zeit fiel mir bei genauerer Betrachtung auf, dass Modelle nicht konfigurabel sein werden. Seit dem liegt der T4D wirklich nur noch rum. Mein Verständnis einer Variation ist ein anderer Stromabnehmer/andere Lackierung, der Rest bleibt, wie er ist. Beim Betrieb des T4D in den 4 Betrieben, die ihn zu hunderten einsetzen, gab es aber nicht "die" Bahn. Je nach Entwicklungsstand/Charge mal ein Beispiel: Allein für DD kenne ich 5 verschiedene Stromabnehmer, 3 verschiedene Rückleuchten, 4 Lüfter für diese Zwangsbelüftung, 3 Prellelemente: in allen Kombinationen. Das wären 5*3*4*3 Variationen in der Standard-Lackierung… Leipzig und Halle waren auch sehr experimentierfreudig, Magdeburg weiß ich gar nicht…Ich denke niemand will 180 Variationen haben… Das erste, was mir dazu in den Sinn kam: zusammenklickbare Modelle. Leider mag die Engine überhaut gar keine Kontaktpunkte an einem Fahrzeug. Gruppieren geht, ist aber umständlich von der Benutzung. Das ist schon philosophisch, wehlab ich vor ein paar Wochen zu zusammenklickbaren Fahrzeugen schon einmal einen Thread aufmachen wollte. Habs dann gelassen, weil dei Meinungen hierzu sehr weit auseinander gehen könnten. Einen wirklichen Kompromiss sehe ich als Modellbauer in diesem Fall aber auch nicht: entweder man sucht sich eine Wagen-Nummer heraus und baut genau diese nach… — aber damit öffnet man die Büchse der Pandora: User-Anfragen nach Version X für Wagen Y. Wird es irgendwann etwas "zusammenklickbares" geben? Stelle den Body, 5 Stromabnehmer, Rücklichter in den Katalog und lass den User entscheiden, wie er welche Teile ans Fahrzeug pappt.

Lustiges Spiel. Ich hab hier mal 3 Rechtecke mit 9, 13 und 15mm Breite angelegt.

Tach, ich habe aktuell 2 Modelle: - ein Modell wartet auf ein Lektorat - ein Modell wartet auf die Texturen; Und ich muss ohne Ende Vertices löschen, denn ich bin bei 58k/LOD0: was mich nicht stört, aber ich habe keinen Puffer mehr nach oben für eventuelle Umbau-Varianten, vgl T4D-Z Halle mit 2 Triebköpfen Aktuell ist eh alles doof: wegen Corona für nix Zeit. Dennoch habe ich das Interesse die beiden Modelle zeitnah fertigzustellen. Meine Frage ist: kommen mit der nächsten MBS-Version irgendwelche Features, die sich auf GFX beziehen? Normal-Maps etc? Ist da irgendwas geplant? Warte ich bis dahin oder mach ich die Modelle jetzt fertig und lad sie in den 5er Katalog? Beste Grüße

Zusammengehackt sähe das irgendwie so aus: var = variable const = unveränderlicher Wert Angaben in Millimeter 1:1, ab Schienenoberkante, irgendwelche Beispielwerte --- const Sensitiver Bereich Spline Oberleitung: S. var Oberleitung Unterkante: L. var Sensitiver Bereich beginnt bei: Ls = L-S. --- Modell wird in den Katalog aufgenommen und damit eh mindestens einmal analysiert. Diese Werte werden mit dem Modell gespeichert: const Schleifstück Oberkante (Empty#3) b. Stromabnehmer unten: Su, definiert in Animation Frame 1. const Schleifstück Oberkante (Empty#3) b. Stromabnehmer oben: So, definiert in Animation Frame n. const Schleifstück Oberkante (Empty#3) Distanz: D = So - Su. const Schleifstück Oberkante (Empty#3) Distanz pro Frame: Df = D/Frame n. --- Beispiel: Modell mit linearer Animation für den Stromabnehmer über 60 Frames wird in den Katalog geladen; diese 4 Werte ändern sich nicht mehr: const Su sei 3900 @ Frame 1 const So sei 7000 @ Frame 60 const -> D = 7000-3900 = 3100 const -> Df = 3100/60 = 51,66666 (pro Frame bewegt sich der Stromabnehmer also um ~51,66666mm auf-/abwärts. Modell wird auf Anlage gezogen: var Distanz, die sich der Stromabnehmer aktuell bewegen kann: d. a) Fahrzeug steht irgendwo (Empty#2 findet keinen Spline oberhalb seiner selbst): -> d = D = 3100. -> Fmin = 1 -> Fmax = 60 Bei "Animation abspielen" wird die Animation von Frame Fmin (Su) bis Frame Fmax (60 [×Df+Su=So=7000]) abgespielt. b) Fahrzeug steht unterhalb Oberleitung (Empty#2 hat sich an Oberleitungsspline angedockt): L sei 5800 bei Koordinate X/Y. S sei 400. -> die Animation steht nicht auf Frame 1 -> dann gilt der Stromabnehmer als angelegt: -> d = L-Su = 5800-3900 = 1900. -> und das Schleifstück (Empty#2) steht irgendwo zwischen Ls (5800-400=5400) und L (5800) -> dann prüfe, ob die Animation an einem gültigen Frame steht: -> Fmin = 1 -> Fmax = d/Df = 1900/51,66666 = 36,77419 = 36 (besser Luft nach oben, als dass der Stromabnehmer über der Fahrleitung hängt.) Bei "Animation abspielen" wird die Animation von Frame Fmin (Su) bis Frame Fmax (36 [×Df+Su=5760=~L=~5800]) abgespielt. Ohne die Möglichkeit zu berücksichtigen, dass MBS "zwischen den Frames" abspielen kann, ansonsten die 36,77419 auf den entsprechenden float umrechnen. -> mach das alles noch einmal, sobald sich die Koordinaten des Fahrzeuges ändern, synchron oder alle 1s/5=0,2s…, -> wenn der Kontakt zum Spline abbricht oder das Schleifstück den Bereich L - Ls verlässt, spiele weiter bis Frame 60 und weiter wie unter a) -> stoppe, wenn die Animation manuell rückwärts abgespielt, weil Stromabnehmer abzezogen, wird. So ganz ohne Bones/Collision… Auf den ersten wart, der mir dieses Bild ins Gesicht klatscht: https://de.wikipedia.org/wiki/Datei:El_2-Industrieellok_4-1305.jpg Beim Anblick des Bildes gällt mir auf, dass der Ansatz selbst dann funktionieren könnte, wenn man mit exotischem Zeug kommt: Dazu müsste man das ganze Konstrukt nur um seine eigene Achse drehen — den zugehörigen Oberleitungs-Spline eben auch: Z ist dann X und der 0-Punkt nicht die Platte, sondern die Gleismitte.

Hallo, weder gibt es O-Busse noch entsprechende andere Fahrzeuge mit Rollenstromabnehmern — und das wird wohl auch immer so bleiben. Alle anderen E-Fahrzeuge mit Stromabnehmern behelfen sich mit einer "MBS-genormten" statischen Höhe und die Oberleitung ist aktuell nur deshalb ein Spline, damit man es einfacher konfigurieren kann — aber technisch betrachtet handelt es mit jedem dieser Splines um ungenutztes Potential. Nimmt man die aktuellen Gegebenheiten, dann könnte Spline 1 das Gleis, Spline 2 eine Oberleitung, Spline1-User ist das Fahrzeug, Spline2-User könnte die Schleifkohle (_CP_Spline) sein. Schleifkohle folgt Fahrzeug. Das ganze kann man jetzt schon bauen. Nur der bewegliche Teil dazwischen fehlt: denn das ist imho inverse Kinematik und ich finde es verständlich, dass man auf Grund der Komplexität (entweder richtig oder gar nicht, und dann sind wir bei Bones) lieber die Finger davon lässt. Aber: Stromabnehmer!1111elf Ja, ich weiß: es gab Bahnen mit Unterstromzufuhr — aber nur punktuell, versuchsweise, gleiches für Akku-Bahnen. Ich überlege mit welchem "Hack" man auf derartige Kinematiksachen verzichten kann. Da stolperte ich letztens in diesem Forum nach Animations-Stop über LUA, damit man skripten kann, dass der Stromabnehmer zu Frame X gehen soll, damit er keine Wände im Betriebshof einreißt. Der Vorschlag ist aber nicht befreidigend, da ich dann erst ausrechnen muss, wie schnell das Fahrzeug ist, wie die Neigung der Oberleitung zur Schiene ist etc. um dann manuell den Frame anzuspringen — worüber eigentlich? Mit einem Fahrzeug-betritt-Gleis-Event? Alle 5mm ein Stück Gleis für ein neues Event: setze Stromabnehmer auf Frame 0.345? Oder mit einer Horde Timeout-Funktionen, die im 1s/24-Takt den Frame setzen? Und wenn ich 6 Monate später beschließe, das Fahrzeug soll mit 2km/h weniger auf den Betriebshof fahren, weil dort jetzt neue Weichen liegen, die nicht mit mehr als 4km/h befahren werden wollen, dann ändere ich 100-Timeout-Funktionen? Animationsstop via LUA ist zwar nice, aber nicht hierfür: derartiges für Stromabnehmer klingt nach Anti-Pattern… Etwas ähnliches kam mir aber auch schon in den Sinn, geht aber in eine andere Richtung und lässt sich aktuell nicht umsetzen. Das Thema des Threads könnte sein: Ich möchte via LUA mit den Koodinaten zweier Objekte spielen und über die Differenz einen Frame ansteuern. Ich habe das noch nicht zu Ende gedacht und eventuell denke ich auch falsch: Die Zutaten sind irgendwas mit Fahrzeug-Koordinaten (o. g. Spline-User1), zugehörige Zielkoordinaten an der Oberleitung (Spline-User2). Aus diesen beiden Koodinaten kann man dann die Soll-Höhe der Schleifkohle ermitteln und einen passenden Frame für die Stromabnehmerhöhe ansteuern. Das funktioniert am einfachsten wenn der Stromabnehmer in der Fahrzeugmitte sitzt, dann brauch ich nur die Z-Achse — in anderen Fällen steht die Distanz relativ zu den Fahrzeugkoordinaten. Bei Rollenstromabnehmern funktioniert das anders, denn der Rollenstromabnehmer ist drehbar gelagert. Das Problem ist hier eher nicht die Berechnung der Distanz zwischen Schleifkohle und Stromabnehmer-Halterung, sondern der Umgang mit der Animation/den beweglichen Teilen, denn es sind 2: um die Z-Achse sowie auf und ab. Es wäre ein bisschen heavy die Animationen in 2 Ebenen für 180°-Z-Achse mit jeweiligem Höhenwinkel zu rendern: 180° Z-Achse × (nur!) 45° Höhe = 8100 Frames Einfacher wäre es Rotation ist Softwareseitig über ein spezieles Objekt gelöst, dass sich um die Z-Achse dreht. Der Rest wäre dann wie bei "normalen" Stromabnehmern: auf und ab. Um das alles allgemeiner zu machen gibt es ein neues Objekt am Fahrzeug, dass seine eigenen Koordinaten mit sich herum trägt, falls der Stromabnehmer nicht in der Mitte des Fahrzeuges auf dem Dach montiert ist und entsprechend abweichende Koordinaten hätte. Zwei weitere für Soll- und Ist-Koordinate der Schleifkohle. Derer Daten kann ich abgreifen und aus der Differenz gezielt einen Frame für die Höhe ansteuern. Selbst wenn diese Spielerei nur alle 6 Frames berechnet würde, wäre das besser als gar nichts zu haben. Die Objekt-Hierarchie könnte dann so aussehen: 1. Fahrzeug (weiß jetzt schon wo es auf der Platte ist) 1.1 spezielles Empty#1 für Stromabnehmerhalterung wird am Gelenkmittelpunkt/Dach des Strobamnehmers positioniert (optional rotierbar um Z-Achse, weiß wo es sich am Fahrzeug befindet -> weiß wo es sich auf der Platte befindet, hat Tuple XYZ) 1.1.1 spezielles Empty#2 für Soll-Position Schleifkohle (kollidiert immer mit Splines oberhalb Empty#1, hat Tuple XYZ) 1.1.2 Modell Stromabnehmerhalterung 1.1.2.1 Modell Stromabnehmer (animiert auf/ab, Frame für Höhe via LUA aus… Empty#2-Empty#1… oder so) 1.1.2.1.1 Modell Schleifkohle 1.1.2.1.1.1 spezielles Empty#3 für Ist-Position Schleifkohle (positioniert an Oberseite der Schleifkohle, macht erst was, wenn Toleranzbereich Spline betreten wird, hat Tuple XYZ) -> Fahrzeug kommt auf Gleis: Empty#1 ist am Dach, Empty#2 dockt sich am Spline oberhalb des Fahrzeuges an. Beide wissen wo sie sind -> Animation "Stromabnehmer auf" wird gestartet -> Empty#3 kommt in Toleranzbereich für Oberleitungs-Spline, und erhält ein Bit "angelegt". Ab diesem Moment wird errechnet wie weit die Animation vor-zurückgespielt werden soll, um annähernd an #Empty2 zu kommen -> Update alle 0,1s oder so, dann wird die Animation entsprechend vor-/zurückgespielt. -> Berechnungen werden gestoppt wenn Fahrzeug steht -> Bit "angelegt" wird entfernt/Berechnungen werden gestoppt wenn "Strobabnehmer ab" abgespielt wird. Irgendwie… Ist dieser Ansatz diskussionswürdig? Gruß ~cab.

Hallo @fmkberlin, da es dir erst mal nur um das Fahrwerk geht, hier ein Link zur Sächsischen III K. Das Prinzip müsste ja das gleiche sein: https://www.schienendampf.com/34487225nx30160/vorstellung-test-und-fahrberichte-f23/saechsische-iiik-t1554.html http://www.accucraft.de/Produkte/1_20_3/Dampflokomotiven_1_20_3__Live_/Sachsische_IIIK__Live_Steam_/sachsische_iiik__live_steam_.html Eventuell mal in entsprechenden Museen nachfragen, ob es mehr Infos gibt? Verkehrsmuseum Dresden z. B. hat ein Archiv: https://www.verkehrsmuseum-dresden.de/de/führungen-bildung/bibliothek-archiv Schönen Abend noch.

Danke für die Antworten. Doch, alles gut Und das war die Frage gewesen: Könnte man das aushelbeln. Könnte ich als Programmierer einen bestimmten Bereich definieren, von dem die Engine zwar weiß, dass die Flächen da sind, diese aber erst zur Darstellung berechnet, wenn der der Fall eintritt, dass diese Flächen diesen Bereich verlassen und nicht permanent. Daran, dass eine entsprechende Prüfung allerdings rechenlastiger sein könnte als das eigentliche Rendern, hätte ich nun nicht gedacht. Danke @Neo für die Info. Edit: Screenshots für @BahnLand:

Immer vorhanden sein: im Sinne von "dem Renderer zur Verfügung stehen" oder im Sinne von "am 3D-Modell hängen"? Ich hab mal ein Dummy in Blender gebaut: Ignore.zip Die LOD-Stufen sind nicht das Problem: eher wenn man mit _ENV_X für Glitzerkram herumspielt bzw. Anti-Alias auf höchster Stufe stehen hat. Denn das fällt dort imho auch alles mit rein. Und ich gehe davon aus, dass die Skybox mitgerendert wird, selbst wenn ein Blech darüberliegt. Edit: Blender-File ausgetauscht. In der ersten Version war _Ignore parent von Torus, was zu Annahme hätte führen können, dass die Elemente eine Beziehung zu einander hätten. Es geht hier aber ausschließlich um die Koordinaten des _Ignore-Cubes und darum, was sich innerhalb dieser Koodinaten befindet und was nicht.

Vorab: Ich prog zwar selbst, aber meine Erfahrungen im Game-Design/DirectX/Shader gehen gegen null. Deshalb kann es sein, dass mein Verständnis für die 3D-Modelle etwas falsch und dieser Thread damit obsolet ist. Annahme: Ich erstelle ein Fahrzeug mit Fahrgestell. Dieses Fahrgestell liegt im Original hinter einer Blechklappe. Das Modell kann ich jetzt so bauen, a) dass ich das Fahrgestell ignoriere, da man dieses, bedingt durch die Blechklappe eh nie sehen wird, oder b) ich entscheide mich das Fahrgestell zu modellieren und später über eine animierte Blechklappe sichtbar zu machen (Werkstattaufenthalt etc). Mich interessiert b); Zustand Klappe geschlossen und Fahrwerk so nicht sichtbar: Imho hat es keinen Einfluss ob ich das Fahrwerk skaliere oder nicht, die Polygone werden mitgeschleppt und müssen mit jedem Frame neu berechnet werden, selbst wenn ich auf 0 skaliere. Die Normals über Keyframes zu flippen geht imho nicht (zumindest habe ich gerade nichts dazu gefunden) — und selbst wenn, weiß ich nicht, ob die Polygone des zu versteckenden Objektes immer noch berechnet werden, oder ob sich dass nur auf die Texturen bezieht. Meine Frage: würde die Möglichkeit funktionieren einen speziellen Cube zu definieren, zum Beispiel mit dem Namen _IGNORE, dessen Inhalte nicht gerendert werden? Zustand Klappe geschlossen und Fahrwerk nicht sichtbar -> Fahrgestell wird über Keyframe in die Koordinaten von _IGNORE gezogen und ist für MBS nicht mehr existent. Zustand Klappe geöffnet und Fahrwerk sichtbar -> Fahrgestell wird über Keyframe aus dem _IGNORE-Cube gezogen, ist für MBS sichtbar und wird gerendert. Ich stelle diese Frage, weil ich gerade ein Fahrzeug modelliere, dass ausfahrbare Puffer und andere Geschichten mitbringt, die in der Summe, selbst mit Gewalt, nicht unter 1000 Polygone zu bringen aber im Normalzustand des Fahrzeuges alle unsichtbar sind — und das wäre nur eine Fahrzeugseite. Gruß

[1] …sollte auch dann funktionieren, sofern Baumansicht deaktiviert ist. Ich bin Neuling in diesem Programm und hatte in der Testversion mal eine Kategorie angelegt, anschließend die Baumansicht deaktiviert. Es hat (mir zu lang) gedauert, bis ich herausfand, dass das nur dann geht, wenn man die Baumansicht aktiv hat. [2] Auch die beiden Checkboxen zur Aktivierung Baumansicht/Kleine Symbole sind in diesem Zusammenhang eher schlecht platziert. Der Button für das entsprechende Dropdown liegt im Suchfeld — an einer Stelle, an der ich eventuell eine Lupe als Submit-Button oder ein Zahnrad für Suchoptionen erwarten würde. Ich will niemandem auf die Füße treten – manchmal hilft nur der unbedarfte Blick eines Neulings: anfangs gab es noch mehr Punkte, die ich als wirklich störend empfand — unterdessen habe ich mich aber auch daran gewöhnt. Die Usability-Probleme sind damit nicht gelöst, sondern nur durch die Blindheit der Gewohnheit verschwunden. Vielen Dank.