Blender: glb-Export aus Scene ► Fehler

[~cab]

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

Bearbeitet 14. Dezember 2020 von ~cab
Blender-File und glb-Files hinzugefügt

[Neo]

Hallo ~cab,

die Fehlermeldung ist etwas zu allgemein. Konkret besagt die Fehlermeldung, dass die glb-Datei Eigenschaften aufweist, die vom Studio nicht unterstützt werden. Konkret geht es um die verschiedenen Szenen. Aktuell unterstützt das Studio nur glTF-Dateien mit einer Szene. Welchen Hintergrund hat es bei dir mit mehreren Szenen zu arbeiten?

Viele Grüße,

Neo

[~cab]

Vielen Dank für die Antwort.

32 minutes ago, Neo said:

Welchen Hintergrund … ?

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?

 

[Reinhard]

Hallo @~cab,

so recht wird man aus deinem minimalen Screenshot noch nicht schlau. Ich biete dir an, mir die blend-Datei mal anzuschauen, wenn du sie mir (inkl. der verwendeten Bilddateien) zur Verfügung stellst - hier im Forum als zip oder per PN. Alles was ich bisher erkenne, lässt in mir 2 Fragen "aufploppen":

1. Warum willst du alles, was geht und irgendwie dazu gehören könnte, in einer einzigen blend-Datei unterbringen? Das Prinzip, mehrere Versionen als blend-Datei zu speichern, macht das alles doch einfacher, jedenfalls bei mir. (Jede LOD hat seine eigene blend-Datei)

2. es gab mal Zeiten, da hat 3D-MBS die Namensgebung von Objekten (in Blender) genau genommen (Umlaute waren z.B. nicht möglich). Nun bin ich nicht ganz sicher, wie das heute ist - ich habe mir die Namensgebung ohne Umlaute angewöhnt. Aber eine Raute (hashtag, #) als Namen der Collections finde ich doch sehr ungewöhnlich. Ich stelle mir die Frage, ob 3D-MBS das verarbeiten kann?

Gruß
Reinhard

Bearbeitet 23. Dezember 2020 von Reinhard

[~cab]

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.


 

Bearbeitet 24. Dezember 2020 von ~cab
Tippfehler :/

[Reinhard]

Hallo @~cab,

das ist ja eine ausführliche Antwort, von der ich - zugegeben - nicht mal die Hälfte verstehe/nachvollziehen kann. Aber ich habe mich hier "eingeklingt", deshalb will ich mal verdeutlichen, wie das bisher bei mir ankommt.

Auf die Details, die ich nicht verstehe, will ich mal gar nicht eingehen (man will ja nicht als kompletter Idiot dastehen), aber wenn du in der Erklärung bereits mit Begriffen und Abkürzungen um dich schmeißt, von denen ich ausgehe, dass sie nur von Insidern verstanden werden, dann macht es wenig Sinn, das im Einzelnen aufzusplitten...

Aber zum 3D-MBS und dem Modellbau dafür.

Wenn ich dich richtig verstehe, bist du dabei, Fahrzeuge für das 3D-MBS zu erstellen - das freut mich! Und du arbeitest mit Blender - freut mich nochmal, weil ich da ein bisschen mitreden kann, bei Problemen vielleicht ein wenig helfen kann.

Welches Fahrzeug das werden soll, habe ich noch nicht verstanden, aber wohl eines, für das es um die 22.000 Varianten geben soll, die du für dich schon mal auf 14.000 Varianten reduziert hast...

Musst du nicht weiter darauf eingehen, ich weiß, dass du die Zahlen in einem anderen Zusammenhang genannt hast.

Aber zur "Artenvielfalt" eines einzigen Modells zeige ich dir hier mal einen Beitrag, den ich im Zusammenhang mit dem MAN-Schienenbus hier eingestellt habe und bei dem ich dachte, auch ein Problem mit der "Artenvielfalt" zu haben

in diesem Beitrag

Die sehr sinnvolle Nachfrage von @Neo (2 Einträge unter meiner Arten-Nachfrage) brachte mich dann dazu, nur an das für das 3D-MBS Sinnvolle nachzudenken.

Was ich damit sagen will: Braucht es tatsächlich von einem Modell tausende oder hunderte Varianten, die man vielleicht als Insider erkennt, von denen aber der "gewöhnliche" User gar nichts hat, weil er die feinen Unterschiede vlt. nicht mal erkennt? Macht es nicht Sinn, ein Modell zu erstellen, ein-zwei Variationen, die deutliche Unterschiede aufweisen und gut ist es?

Wenn ich dich richtig verstanden habe, würde dann auch dein Problem mit der Verlinkung der Ebenen untereinander entfallen. Vermutlich würde 3D-MBS dein Modell dann auch problemlos übernehmen?

Gruß
Reinhard

 

Bearbeitet 24. Dezember 2020 von Reinhard

[~cab]

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

 

Quote

Die Leute werden erschlagen von der schieren Vielfalt, das wird deiner Arbeit gar nicht gerecht. Mein Tipp, konzentriere dich auf eine Bauform und nimm kleinere Abweichungen von der Realität in Kauf.

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.


 

Bearbeitet 24. Dezember 2020 von ~cab

[Neo]

Hallo ~cab,

ich kann deine Arbeitsweise gut nachvollziehen, zeigt sie doch viele Parallelen zur modernen Softwareentwicklung. Auch wenn ich nicht beurteilen kann, ob Blender für genau deinen Einsatzzweck die Collections geschaffen hat, das Konzept dahinter ist schlüssig.

Ich selber interessiere mich vorwiegend für die Daten, die in der glTF-Datei vorliegen, und dort gibt es keine "Verlinkungen von Collections". glTF kennt eine beliebige Anzahl von Szenen, die jeweils eine Objekthierarchie referenzieren, und der glTF-Exporter erstellt eine glTF-Szene pro Collection. Dass das Studio glTF-Dateien mit mehr als einer Szene aktuell verbietet liegt eher daran, dass ich zum Zeitpunkt der glTF-Implementierung noch nicht entscheiden wollte, wie mit mehreren Szenen vorgegangen wird (das Szenenkonzept kennt z.B. das alte X-Format nicht).

Da es jetzt einen ersten konkreten Einsatzzweck mehrerer Szenen gibt, wäre es eine Überlegung wert, einfach alle Szenen einer glTF-Datei zu einer Szene beim Import zusammenzufassen. So scheinen es auch die anderen glTF-Viewer zu tun. Diese Änderung kann ich gern zeitnah mit berücksichtigen.

vor einer Stunde schrieb ~cab:

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.

Das ist nicht korrekt, veröffentlichte Modelle können ohne Probleme nachträglich aktualisiert/erweitert werden. Das passiert ständig, weil häufig Fehler korrigiert werden. Und bei jeder neuen Hauptversion des Studios werden viele Modelle so auf den neuesten Stand gebracht. Zu beachten gibt es bei Modellaktualisierungen lediglich, dass sich grundsätzliche Abmessungen, Variations- und Animationsnamen nicht ändern. Neue Variationen, Materialanpassungen oder geometrische Korrekturen sind aber kein Problem.

Viele Grüße,

Neo

[~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.

 

 

Quote

Das ist nicht korrekt

\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 )

 

 

Bearbeitet 24. Dezember 2020 von ~cab