Neo

Hallo Torsten, im Moment ist nicht vorgesehen, dass Straßen an Gleisen andocken können, weil es sich hierbei um verschiedene Transportwege handelt. Warum wäre das für dich wichtig? Viele Grüße, Neo

Hallo, technisch würde das funktionieren, wäre aber schon etwas aufwendig. Ich werde mir zeitnah eine Übersicht der "doppelten" Modelle im Katalog verschaffen, eventuell genügt es auch, wenn der ein oder andere Modellbauer seine Modelle manuell zusammenfasst. Die alten Modelle müssen aber dennoch als Archiv erhalten bleiben, da sonst Fragezeichen entstehen, wodurch es sich hier nur um eine kosmetische Verbesserung des Online-Katalogs handelt. Viele Grüße, Neo

Hallo SputniKK, gibt es einen speziellen Grund, warum du den ursprünglichen 2-Achs-Wagen nicht aktualisiert und stattdessen den Wagen als neues Modell hochgeladen hast? Viele Grüße, Neo

Hallo Streitross, das kann ich dir ehrlich gesagt gar nicht beantworten. Ich habe gerade im Forensystem nachgeschaut und konnte dort keine Einstellung finden, die sich auf eine Beschränkung der "Gefällt mir" bezieht. Melde dich einfach nochmal, falls das wiederholt auftritt, dann wende ich mich an den Hersteller. Viele Grüße, Neo

Hallo SputniKK, schön deine Modelle, den Wagon mit Dach würde ich mir aber aufsparen, das wäre ein prima Kandidat für die Modellvariationen ab V4, also eine Erweiterung des normalen Wagons. Viele Grüße, Neo

Hallo SputniKK, eine LOD-Stufe mit ca. der Hälfte der Polygone wäre nicht schlecht wenn es möglich ist. Viele Grüße, Neo

Die "Mauer" ist doch eindeutig nicht zu übersehen . Nett gemacht quackster. Viele Grüße, Neo

Hallo, die EV beschränkt sich ja vom Konzept her eher auf das Prüfen von Bedingungen und das Setzen von Eigenschaften. Selbst bei komplexen Anlagen stellt das im Moment noch lange keinen Performanceengpass dar, weshalb es von meiner Seite auch keine Pläne gibt, die EV um konkurrierende Zugriffe zu erweitern. In der Hinsicht muss es also keine Bedenken geben, dass in absehbarer Zeit eine ältere EV nicht mehr funktioniert. Viele Grüße, Neo

Hallo RaDiBo, das ist korrekt. Viele Grüße, Neo

Hallo RaDiBo, die EV läuft single-threaded, weshalb es keine konkurrierenden Zugriffe gibt. Alle Aktionen eines Ereignisses laufen direkt nacheinander ab, in der Reihenfolge, wie sie definiert worden. Löst eine Aktion selbst ein neues Ereignis aus, dann werden die Aktionen dort erst nach Abarbeitung aller aktuellen Aktionen verarbeitet. Der von dir genannte Wiki-Artikel stammt von BahnLand, weshalb ich auch nicht direkt sagen kann, warum dort von konkurrierenden Zugriffen gesprochen wird, aber bestimmt wird er dies zeitnah aufklären. Viele Grüße, Neo

Hallo, das ist mehr oder weniger mein Ziel und auch der Grund, warum ich mich etwas schwer tue, die Felder für "Bedingungen erfüllt/nicht erfüllt" nebeneinander darzustellen, weil das noch nicht die Probleme löst. Ein etwas komplexeres Ereignis besitzt häufig mehr als zwei Verzweigungen, was mit dem aktuellen System nicht abbildbar ist, das funktioniert nur mit einer Baumstruktur. Die neue EV wird daher nicht mehr zwischen Bedingungen und Aktionen trennen, sondern diese in einer einzelnen Ansicht zusammenfassen, mit vom Nutzer beliebig definierbaren Pfaden. Dabei muss keiner Angst haben, vor lauter "if" und "else" die Übersicht zu verlieren, sondern kann sich auf eine schöne Visualisierung freuen, die sofort erkennen lässt, welcher "Codepfad" zu welcher Bedingung gehört (soweit meine Ideen im Kopf ). Wie bereits erwähnt, habe ich im Moment selber kein Interesse an zusätzlichen Hilfen für die EV, sondern würde lieber die Zeit nutzen, um diese generalzuüberholen. Darauf aufbauend könnte man dann über weitere Hilfen nachdenken. Viele Grüße, Neo

Hallo SputniKK, wenn du die Arbeiten am Anhänger abgeschlossen hast, dann verschiebe ihn gern nach Triebwagen. Viele Grüße, Neo

Hallo SputniKK, ich kann bisher nur das Modell "V1" im Test-Ordner sehen, ist der Upload deiner neuen Version erfolgreich abgeschlossen. Übrigens ist es nicht sinnvoll für jede Version ein eigenes Modell hochladen, besser du aktualisiert das alte Modell. Viele Grüße, Neo

Hallo BahnLand, nein, Animationen werden auch in Zukunft die Basis für interaktive Modelle darstellen, es wird lediglich eine Abstraktionsschicht eingeführt, die die Ansteuerung solcher Animationen vor dem Nutzer verbirgt, und stattdessen "Zustände" einführt, die der Nutzer aktivieren/deaktivieren kann. Welche Aktionen dann dahinter ablaufen, bestimmt der Modellbauer, der neben Animationen auch auf weitere Werkzeuge wie z.B. das Abspielen von Sounds zurückgreifen kann. Das wäre das Ziel ja. Im Idealfall kann der Nutzer die Beleuchtung eines einzelnen Objektes manuell steuern, per EV oder "global", um z.B. in der Dunkelheit alle Lichter anzuschalten. Lasst uns hier aber erstmal eine Pause einlegen, ich habe noch viele Ideen für V4, die ich aber erst nach dem Release per Update angehen möchte. Gern können wir dann konkreter über solche Features sprechen. Viele Grüße, Neo

Hallo Ralf, die Drehscheiben besitzen nur ein Gleis, was je nach aktiver Weichenstellung in die entsprechende Position gedreht wird. Wenn du auf ein "Lok betritt ein Gleis" reagieren möchtest, dann genügt die Angabe der ganzen Drehscheibe als Gleis. Wenn du Aktionen nur für bestimmte Weichenstellungen der Drehscheibe ausführen möchtest, dann kannst du das Ereignis zusätzlich durch eine Bedingung "Weiche steht auf Position" einschränken. Viele Grüße, Neo

Hallo BahnLand, der Hauptgrund für die Entfernung mancher Funktionen, die ich als "deprecated" ansehe, ist schlichtweg die Zeit. Klar ist in der Theorie das Beibehalten verschiedener Codepfade bis zur Umsetzung der neuen Funktionen sinnvoller, jedoch bedeutet das in der Praxis einen erhöhten Entwicklungs- und Wartungsaufwand, gerade wenn wie in diesem Fall viele Änderungen an den alten Funktionen durchgeführt werden. Auch wenn man es noch nicht sieht, aber das Studio wurde in V4 im Bereich 3D-Modelle und Animationen praktisch neu entwickelt, alles ausgerichtet auf die kommenden "Modellaktionen". Um halbwegs meine Timeline einzuhalten musste ich mich entscheiden, alte Funktionen zu entfernen, die eh in Kürze durch einen besseren Mechanismus ersetzt werden, oder aber den Veröffentlichungszeitpunkt immer weiter herauszuschieben. Ich plane übrigens die Umstellung aller Objekttypen auf die neuen "Aktionen" noch in V4, es wird daher wieder regelmäßige Updates geben, die V4 um neue Funktionen erweitert (wenn auch schrittweise für jeden Objekttypen getrennt). Die Einschränkungen werden sich daher meiner Meinung nach in Grenzen halten. Viele Grüße, Neo

Hallo, ich begrüße eure Gedanken zur Vereinfachung der EV. Wenn einzelne Verbesserungswünsche nicht zu aufwendig umzusetzen sind, bin ich gern bereit, diese in einem V4-Update mit einzubauen, um so die Wartezeit auf eine neue EV zu verkürzen. Version V3 wird keine funktionellen Updates mehr erhalten, da dies wirtschaftlich nicht tragbar ist. Verbesserungen können daher nur in V4+ einfließen. Viele Grüße, Neo

Hallo BahnLand, ich denke, dass nur die wenigsten Nutzer eine Ereignisverwaltung zum Umschalten der Spitzen- und Schlusslichter implementieren werden, weshalb ich persönlich auf dieses Detail verzichten würde (bzw. es nur über die Automatik steuern lassen würde). Technisch habe ich mir über eine richtige Lösung von solchen Lichtern noch keine Gedanken gemacht, es ist aber wahrscheinlich, dass du deine Modelle anpassen musst, wenn du irgendwann die saubere Lösung verwenden möchtest. Allerdings gibt es dafür noch keinen Zeitplan. In V4 wird man die Automatik nicht mehr deaktivieren können, da ich die Animationslogik schrittweise ändere. Um Eigenschaften oder Funktionen eines Modells zu aktivieren, soll der Nutzer keine Animationen abspielen müssen, weil das nicht nachvollziehbar ist (da kommt von alleine auch keiner drauf). Vielmehr wird jedes Modell eine Liste von Aktionen besitzen, die der Nutzer aktivieren kann. Ob sich hinter der Aktion eine Animation versteckt, eine Eigenschaft gesetzt oder ein Sound abgespielt wird, spielt für den Nutzer dann keine Rolle mehr, das kann der Modellbauer frei definieren. Den Anfang werden hier die neuen Gleise machen, bei denen jede Weichenstellung aus Aktionen besteht, die z.B. eine Spur aktivieren oder aber eine Animation abspielen (für Drehscheiben, Schiebebühnen etc). Das bedeutet also, dass du dich bei deinen Spitzen- und Schlusslichtern für eine Sache entscheiden musst. Entweder die Lichter werden vom Studio gesteuert ( _AnimRunPositive/_AnimRunNegative) oder der Nutzer muss sie selber verwalten. Im Studio werden für RAe_TEE_WR_0.x insgesamt 76766 Eckpunkte generiert. Viele Grüße, Neo

Hallo, nein, diese Duplizierung gibt es nur bei Verwendung von Flächennormalen. Eine Texturkoordinate kann man nicht zu einer Fläche zuordnen, sondern das gibt es nur bei Eckpunkten. Ein Würfel mit eckigen Kanten hat also mit oder ohne Texturen 24 Eckpunkte. Eigentlich nicht, denn der Modellbauer sollte auch weiterhin primär auf die Anzahl der Polygone achten, und darauf, richtige "Smooth-Einstellungen" zu treffen. Die Anzahl der Eckpunkte lässt sich nicht direkt steuern, sondern hängt von den beiden genannten Punkten ab. Das 65k-Limit war bisher nie ein Thema, weil in den ganzen Jahren nicht ein einziges Modell gebaut wurde, was diese Grenze überschritt. Alle deine sehr detailliert ausgearbeiteten Loks kommen mit weniger als 65k-Vertices zurecht. Daher finde ich es nicht verhältnismäßig, von Schuhkartons zu reden. Ich möchte dich dann aber auch bitten, auf Hinweise zu nicht vorhandenen FPS-Probleme deinerseits zu verzichten, denn wir haben auch schon oft genug geklärt, dass dein Computer nicht der Maßstab für das 3D-Modellbahn Studio ist, und dass Performance-Probleme bei vielen Leuten existieren und im Studio angegangen werden müssen. Ich erkläre das gern: Wie erwähnt arbeiten Grafikkarten am performantesten mit 2-Byte-Indizes, was eine maximale Ansteuerung von 65536 Vertices ermöglicht. Hat ein Modell mehr als diese Vertices, muss es aufgesplittet und in mehreren Teilen verarbeitet werden, was immer nachteilig ist (nicht umsonst gibt es die Anweisung, so wenige Materialien wie möglich zu nutzen, da jedes Material einen "Rendervorgang" bedeutet). Man könnte bei solchen Modellen auch auf 4-Byte-Indizes wechseln, was jedoch einige Codeänderungen in der 3D-Engine bedeuten würde, die meiner Meinung nach nicht im Verhältnis zu den wenigen Modellen, die diese Grenze überschreiten könnten, steht. Wie bereits erwähnt, wir reden hier von theoretischen Problemen, denn bisher gibt es kein offizielles Modell, was die Grenze überschritten hat (abgesehen von lobos mit Bordmitteln gebautes Schloss). In BahnLands speziellen Fall ist das Problem eher eine Verwendung von doppelter Geometrie für einen Spezialeffekt, der durch das Studio auch anders erreicht werden kann. Das Aufsplitten von Modellen mit mehr als 65k-Vertices ist keine große Sache für mich, weshalb ich auch bereit bin, auf das 65k-Limit zu verzichten, solange jedem klar ist, dass solche Modelle dann zwingend eine LOD-Stufe benötigen, die deutlich unter dieser Grenze liegt. Viele Grüße, Neo

Hallo BahnLand, ich habe das automatische Zusammenfassen deaktiviert. Eigentlich sollte es das nicht. Stell dir mal einen einfachen Würfel vor. Dieser besitzt 8 Eckpunkte und 6 Flächennormalen. Auf der Grafikkarte ergibt das dann 24 Eckpunkte (jede Seite hat seine eigenen 4 Eckpunkte). Bei Verwendung der Kantenglättung besitzt jeder Eckpunkt einen gemittelten Normalenvektor von allen angrenzenden Flächen, weshalb auch auf der Grafikkarte nur 8 Eckpunkte benötigt werden (natürlich wird der Würfel dann beleuchtungstechnisch "rund" dargestellt). So weit die Theorie, am besten du probierst das einmal in Sketchup aus, ob die Kantenglättung auch genau so arbeitet. Du kannst das auch mit zwei Flächen, die 90° zueinander stehen, ausprobieren, um weniger Testdaten zu analysieren. Hier bezog ich mich auf das Kantenglättungs-Tool, also nicht deinen Exporter. Dein Exporter wird auch weiterhin nur die Daten exportieren, die dir Sketchup liefert, aber bei deinen Wagons z.B. schaut die Decke etwas kantig aus, so als könnte dort das Glättungstool eine Verbesserung erwirken. Sehr gut. Wird erledigt. Sieh meine Tipps nur als Anregung. Am Ende kannst du deine Modelle gestalten wie du möchtest, solange sie sich an die technischen Spezifikationen halten. Es besteht nur die Gefahr, dass du deine Modelle erst recht irgendwann nochmal anpassen musst, wenn du eigene Lösungen implementierst. Speziell solche Animationen, die nur zum Umschalten von Zuständen genutzt werden, möchte ich langfristig vermeiden, weil das für den Nutzer nicht sehr intuitiv zu bedienen ist. Gerade bei solchen Lichtern könnte man schön eine Glühbirne in einem Steuerpult unterbringen und der Nutzer wüsste sofort, dass es sich hier um das Umschalten von Licht handelt. Wenn du stattdessen eigene Animationen verwendest, kann das Studio das nicht automatisiert erkennen, und du musst deine Modelle wieder anpassen. In deinem speziellen Fall, bei Verwaltung hunderter Rollmaterialien, ist es denke ich immer gut, größere Änderungen kurz mit mir zu besprechen, damit du keine Änderung einbaust, die irgendwann in eine Sackgasse führen und wir rechtzeitig über die besten Möglichkeiten sprechen können. Im Falle deiner schaltbaren Innenbeleuchtung kann ich dir wie gesagt nur empfehlen, auf doppelte Geometrie und die Umschaltanimationen zu verzichten. Wenn du damit leben kannst, dass die Beleuchtung zunächst immer aktiv ist, dann genügt die Verwendung eines _LS-Objektes. Dadurch würden deine Modelle dann automatisch von den neuen Lichtfunktionen profitieren, selbst wenn diese im Moment noch gar nicht vollständig konzipiert sind. Da es aber heute schon viele andere Modelle (z.B. Gebäude) mit _LS-Objekten gibt, werden die Lichtfunktionen auf jeden Fall solche Objekte automatisiert berücksichtigen. Ich würde es gerne vermeiden, weil auch so eine kleine Funktion große Kreise zieht, z.B. die Anpassung der Ereignisverwaltung, da sicherlich einige Leute den Schalter auch automatisiert bedienen wollen. Für mich würde das dann wieder Zusatzaufwand bei der Konvertierung bedeuten, wenn dann die richtigen Lichtfunktionen kommen. Viele Grüße, Neo

Hallo BahnLand, bisher sprichst du immer von einer Kombination von Eckpunkt + Texturkoordinate, korrekt wäre aber Eckpunkt + Texturkoordinate + Normalenvektor. Es gibt zwar in der DirectX-Datei den Begriff eines Flächen-Normalenvektors, die Grafikkarte selbst kennt diesen aber nicht, und benötigt alle Informationen im Eckpunkt. Daher werden die Flächen-Normalen beim Import den jeweiligen Eckpunkten zugewiesen, und wird ein Eckpunkt von zwei Flächen genutzt, deren Normalenvektoren sich unterscheiden, muss dieser Eckpunkt dupliziert werden. Dadurch kommt es zu den Unterschieden. Folgendes kann ich noch dazu sagen: Prüfe bitte zunächst, ob du tatsächlich überall Flächennormalen benötigst. In Blender gibt es die Optionen "Flat" und "Smooth", was am Ende nichts anderes ist als die Aktivierung/Deaktivierung von Flächennormalen. Bei "Flat" bekommen alle 3 Eckpunkte einer Fläche den Normalenvektor der Fläche. Bei "Smooth" besitzt jeder Eckpunkte einen individuellen Normalenvektor. Letzteres führt zu weniger Duplizierungen, aber eben auch zu runderen Ergebnissen (sinnvoll bei Kugeln und allem was rund ist). Eventuell gibt es in Sketchup auch so eine Option. Eventuell gibt es auch noch doppelseitiges Material, dessen Rückseite nicht zwingend benötigt wird (war bei Sketchup standardmäßig nicht jedes Material doppelseitig?) Deinen Exporter müsstest du dahingehend erweitern, dass Eckpunkte, die von mehreren Flächen mit unterschiedlichen Flächennormalen referenziert werden, auch entsprechend doppelt gezählt werden. Gern kann ich die Anzahl der Eckpunkte aber auch im Studio anzeigen. Versuch wie bereits erwähnt die doppelte Geometrie für die Beleuchtung zu vermeiden, denn auch unabhängig des 65k-Limits bedeutet das einen zusätzlichen Berechnungsaufwand für das Studio. Viele Grüße, Neo

Hallo quackster, die 3D-Modelle waren nur ein Beispiel, natürlich werden auch alle anderen Themen behandelt. Aber wie gesagt bin ich selber mit dem alten Wiki nicht mehr zufrieden, und plane nach der Veröffentlichung von V4 auch eine Überarbeitung der restlichen Webseite, inkl. zentraler "Wissensdatenbank". Ich denke diese wird schon in das Forum integriert, allerdings in einer übersichtlicheren Art als eine einfache Liste von Themen. Hier muss ich die genauen Möglichkeiten aber erst noch evaluieren, generell baue ich aber auch weiterhin stark auf die Mitarbeit der Community. Viele Grüße, Neo

Hallo BahnLand, ich kann dir versichern, dass ich Entscheidungen bzgl. des Entfernens von Funktionen nicht leichtfertig treffe. Es ist schwierig im Vorfeld der Entwicklung konkrete Angaben zu machen, da sich diese bis zum Release noch ändern können und ich auch bis zum Ende an Einstellungen feile und optimiere. Eine erste Erwähnung des 65k-Limits gab es im Januar, als ich die Auswirkungen des Limits untersucht habe. Da im gesamten Online-Katalog nur ein Modell betroffen war, bin ich davon ausgegangen, dass sich die Auswirkungen in Grenzen halten. Das 65k-Limit ermöglicht eine starke Code-Optimierung, was am Ende der Performance zu Gute kommt. Der 4-Byte Standard zählt hier leider nicht, da Grafikkarten mit 2-Byte-Indexzugriffen immer noch am schnellsten arbeiten. Was am Ende ein Vertex/Eckpunkt ist gibt nicht das Studio, sondern die Grafikkarte vor. Eckpunkte, mit gleichen Positionen, aber unterschiedlichen Normalenvektoren oder Texturkoordinaten, müssen auf der Grafikkarte getrennt behandelt werden, zählen daher mehrfach. Ich kenne mich mit Sketchup nicht aus, daher kann ich wenig zu deren Zählweise sagen, aber wenn das Studio dahingehend unterstützend wirken kann, dann lass es mich wissen. Bisher war das Thema Eckpunkte nicht wichtig, weil es praktisch kein Modell im Katalog betroffen hat. Der Vergleich mit Seehund ist meiner Meinung nach nicht fair, denn gerade wegen den vielen Problemen in der Vergangenheit habe ich in V4 so viel Arbeit in die neuen 3D-Modelle gesteckt, damit es danach keine Fragen zu den technischen Anforderungen mehr gibt. Generell empfehle ich dir und jedem anderen, Fragen, die mich direkt betreffen, auch direkt an mich zu stellen, z.B. per PN, damit ich nichts übersehe. Dem Thema Licht möchte ich in naher Zukunft verstärkte Aufmerksamkeit widmen, genaue Planungen gibt es jedoch noch nicht. Trotzdem würde ich dir von deiner Lösung abraten, denn zwei Objekte zu integrieren, nur um zwei Beleuchtungszustände abzubilden, ist für das Studio ein großer Berechnungsaufwand, denn beide Objekte müssen immer verarbeitet werden, auch bei einer Skalierung von 0. Auch wenn dich diese Antwort nicht befriedigen wird, aber solange das Studio keinen nativen Support für solche Lichteffekte hat, würde ich auf solche Sonderlösungen verzichten, weil sonst die Gefahr besteht, dass du in einem halben Jahr deine Modelle wieder anpassen muss. Für jetzt empfehle ich dir, auf die Innenraumbeleuchtung zu verzichten (oder dauerhaft zu aktivieren), und auf eine richtige Unterstützung zu warten. Wenn ich mich um das Thema Licht kümmere, dann möchte ich auch solche Themen wie Rücklichter, richtige Scheinwerfer, zentral gesteuerte Gebäude- und Straßenbeleuchtung usw. angehen, wodurch bessere Ergebnisse erzielt werden können als durch das Animieren von beleuchteten/unbeleuchteten _LS-Modellen. Viele Grüße, Neo

Hallo quackster, in den Anfangszeiten konnten die internen Mitglieder dort auch neue Beiträge hinzufügen. Da jedoch im Laufe der Zeit immer mehr Problemchen im Forum gelöst worden, und das verwendete Webseitenframework keine vernünftige Suche im Wiki-Bereich erlaubt, hat das Wiki immer mehr an Bedeutung verloren. Langfristig möchte ich das Forum "Anleitungen und Tutorials" mit dem alten Wiki zusammenführen, sodass es nur noch eine zentrale Anlaufstelle gibt. Es geht um das Prinzip, dass ein Wiki/Hilfeseite nur noch dann notwendig ist, wenn über die normale Bedienung des Programms heraus noch Fragen offen sind. Wenn jemand eine Hilfeseite benötigt, um zu erfahren, wie man im Studio eine neue Anlage erzeugt, dann sollte man eher an der Bedienung des Programms arbeiten, statt die Hilfe auszubauen. Dieses Prinzip strebe ich an. Es soll keine Hilfeseite benötigt werden, um die EV grundsätzlich bedienen zu können. Ich kann das Warten auf neue Versionen/Funktionen gut nachvollziehen, gerade weil ich auch viele Ideen habe, nur leider kann ich es mir nicht immer aussuchen. Die neue EV, so wie ich sie mir vorstelle, benötigt ein Grundgerüst, was ich erst jetzt mit der kommenden Version V4 in ersten Zügen auf die Beine stelle. Es braucht hier noch viel Vorarbeit, gerade weil das Studio, basierend auf dem 3D-Eisenbahnplaner, noch viele alte Strukturen besitzt, die erst aufgeräumt werden müssen. @Alle Für mich ist die Antwort auf die Frage, was ein Nutzer an Hilfen für das 3D-Modellbahn Studio braucht, immer "alles was möglich ist". Wir haben hier das Forum, was schon viele Probleme lösen konnte, und wir haben interessante YouTube-Videos. Das Ziel war ja von Anfang an, dass sich jeder hier einbringen kann. Wer also weitere Tutorial-Videos in Form von Nachbauanleitungen veröffentlichen möchte, ist gern dazu eingeladen. Bei 6000 registrierten Nutzern im Forum kann man davon ausgehen, dass jede Hilfe mindestens von einem Nutzer dankend angenommen wird. Viele Grüße, Neo

Hallo BahnLand, es handelt sich hier um ein Problem im Studio. In der X-Datei gibt es das Unterobjekt "Innenraum". Für LOD0 und LOD1 besteht dieses Objekt aus zwei Unterobjekten, und wird vom Studio zu einem Unterobjekt zusammengefasst. Bei LOD2 hingegen gibt es keine 2 Unterobjekte, weshalb ein anderer Codepfad greift. Das erkennst du auch in der Objekthierarchie, diese unterscheidet sich für LOD0/1 für den Innenraum von LOD2. Wegen der unterschiedlichen Behandlung erkennt das Studio bei LOD2 nicht, dass es sich dort bei "Innenraum" um den selben "Innenraum" von LOD0 und 1 handelt. Das Problem existiert nicht mehr in V4, dort wurde die Modelloptimierung überarbeitet, sodass solche Probleme nicht mehr auftreten können. Gerade in Hinblick auf die bald erscheinende neue Version habe ich noch folgende Hinweise für dich: Die Hauptdetailstufe ist für V4 zu komplex. Das Studio unterstützt ab V4 nur noch Modelle mit maximal 65535 Eckpunkten/Vertices V4 benötigt als Benennung für LOD-Stufen folgendes Format: Modell.x, Modell_LOD1.x und Modell_LOD2.x Viele Grüße, Neo