Animation wird in der 3. LoD-Stufe teilweise nicht angenommen

[BahnLand]

Hallo Neo,

ich bin gerade dabei, den von mir redesignten schweizerischen RAe TEE II fertigzustellen. Alle Fahrzeuge besitzen hierbei 3 LoD-Stufen, die alle mit animierter Innenbeleuchtung (ein- und ausschaltbar) versehen sind.

Leider wird beim Hochladen der LoD-Stufen in den Online-Katalog die Animation für die dritte LoD-Stufe teilweise nicht übernommen. Hier ein konkretes Beispiel:

Innerhalb des Verwendungszeitraums der RAe-Triebzüge wurde der Speisewagen zweimal stark verändert: Ursprünglich besaß der Speisewagen zwei Speiseräume und im Barbereich zusätzliche Sitzplätze. Nach dem ersten Umbau wurden die Sitzplätze im Barbereich entfernt und einer der Speiseräume in ein Großraumabteil 2. Klasse umgebaut. Nach der Ausmusterung aller Triebzüge blieb einer als Museums-Triebzug erhalten und wurde in den 1.-Klasse-TEE-Triebzug zurückgebaut, wobei allerdings nicht alle Änderungen des ersten Umbaus zurückgenommen wurden. So wurde zwar der zweite Speiseraum wieder hergerichtet, aber die Sitzplätze im Barbereich wurden nicht rekonstruiert. Ich habe daher von diesem Speisewagen 3 Varianten hergestellt: den TEE_WR, den EC_BR und den Museums_WR (Hst[oric]_WR).

Die zweite LoD-Stufe gibt es wie die erste in 3 Varianten. Für die dritte LoD-Stufe verwende ich die TEE-WR-Variante in allen 3 Fällen.

Beim Hochladen als TEE_WR und als Hst_WR wird die eigentlich animierte dritte LoD-Stufe als "Nicht-animiert" übernommen, während bei der TEE_BR-Variante (wird später mit anderer Textur die graue EC_BR-Variante) die dritte LoD-Stufe als "animiert" akzeptiert wird.

Animation nicht angenommen

Animation angenommen

Animation nicht angenommen

Wie kann es sein, dass dieselbe X-Datei mit ebenso derselben Anim-Datei einmal wie erwartet als "animiert" übernommen wird und zweimal die Animation der dritten LoD-Stufe (bei identischen Dateien) ignoriert wird?

In der beigefügten ZIP-Datei habe ich die betroffenen x-Dateien aller 3 LoD-Stufen (Suffix _0, _1 und _2) für alle 3 Varianten  (TEE_WR_0/_1/_2, Hst_WR_0/_1 und TEE_BR_0/_1, letztere jeweils mit TEE_WR_2 als dritter LoD-Stufe) abgelegt. Vielleicht kannst Du etwas erkennen, was in meiner "Konfiguration" nicht stimmt, und was ich selbst nicht sehe.

RAe_TEE_WR_2.zip

Viele Grüße
BahnLand

Bearbeitet 1. August 2017 von BahnLand

[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

[BahnLand]

Hallo Neo,

vor 3 Stunden schrieb Neo:

Das Problem existiert nicht mehr in V4, dort wurde die Modelloptimierung überarbeitet, sodass solche Probleme nicht mehr auftreten können.

Gute Nachricht.

vor 3 Stunden schrieb Neo:

Die Hauptdetailstufe ist für V4 zu komplex. Das Studio unterstützt ab V4 nur noch Modelle mit maximal 65535 Eckpunkten/Vertices

Sehr schlechte Nachricht.

Damit kann ich nämlich mit dem "Redesign" des in mehreren Wochen nun "optimierten" und "funktions-erweiterten" RAe TEE II wieder von vorne anfangen. Denn bisher war nie von einer Beschränkung der Eckpunkte die Rede. Vielmehr wurde der Schwerpunkt von ursprünglich der Anzahl Polygone auf die Anzahl der Unterobjekte (von der Anzahl der vewendeten Materialien abhängend) verlagert, wobei nach Deiner Aussage die Anzahl der Polygone zwar weiterhin eine Rolle spielen sollte, aber diese gegenüber jener der Materialien (Unterobjekte) in ihrer Relevanz in den Hintergrund tritt. Außerdem war ich bisher der Meinung, dass man das Problem der "zuvielen" Polygone (und damit auch der zu hohen Anzahl von Eckpunkten) gerade durch die LoD-Stufen lösen kann. Weshalb also die Begrenzung der Eckpunkte auch in der "Hauptdetailstufe"  auf 65536 (warum wird hier für die Integer-Zahl nicht ein drittes Byte spendiert - 4-Byte-Integer-Zahlen sind heute in der EDV-Programmierung Standard)?

Übrigens sagt mein Protokoll des DirectX-Exporters für dieses Fahrzeug:

Aufbereitet: 28 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen
- insgesamt: 15902 Flaechen, 41050 Eckpunkte, 52688 Polygone,
-          : 1470 Normalen-Vektoren, 2 Materialien, 1 Texturen
Dateipfad: D:\Daten\Eisenbahn\3D-Modellbau\Sketchup\SBB_RAeII\DirectX
X-Datei-Ausgabe:  RAe_TEE_WR_0.x
Plugin-Protokoll: RAe_TEE_WR_0.txt

Ich denke daher (ich müsste es nochmal überprüfen), dass ich jeden Eckpunkt auch dann, wenn er Teil mehrerer aneinander grenzender Flächen ist, nur einmal gezählt habe, währed Du einen zu mehreren Flächen gehörenden Eckpunkt entsprechend mehrmals zählst.

Bisher war bei den Ressourcen-Beschränkungen von Eckpunkten nie die Rede. Insbesondere gibt es bisher seitens des Modellbahn-Studios keinerlei Informationen über die Anzahl Eckpunkte, die in einem hochgeladenen / hochzuladenden Modell vorhanden sind. Dies bedeutet, dass ich für die Erfassng der "vielfachen" Eckpunkte auch das Exporter-Script noch einmal zusätzlich umschreiben (entsprechend erweitern) muss.

Es wäre wirklich schön gewesen, wenn ich solche Informatonen wesentlich früher und nicht kurz vor Freigabe der Version 4 erhalten hätte. Dann hätte ich nämlich einerseits dies gleich in die Planung des RAe-Redesigns einfließen lassen können, und ich hätte dies auch im Exporter-Script, das ich für die V4 im Prinzip neu geschrieben habe, bereits berücksichtigen können.

In diesem Sinne kann ich in gewisser Weise nachvollziehen, warum beispielsweise Seehund die "schöpferische Mitarbeit" am Modellbahn-Studio eingestellt hat. Es kommt auch bei mir wenig Freude auf, wegen immer wieder neuen nachgeschobenen Einschränkungen alte Modelle immer wieder aufs Neue umgestalten zu müssen, und damit keine Zeit mehr zu haben, auch wieder mal "etwas Neues" auf die Beine zu stellen.

Natürlich kann ich wie z.B. Quackster alle Modelle mit nicht-transparenten Fenstern versehen. Dann benötige ich keine Inneinrichtung und auch keine Innenbeleuchtung mehr. Ich finde aber, dass gerade diese "Details" den Reiz solcher Modelle ausmachen. 

Ich hatte übrigens schon vor über einem Monat hier folgende Frage gestellt:

Dazu eine weitere Frage an Neo:
Wäre es eventuell möglich, _LS-Objekte mit einer schaltbaren Eigenschaft "aktive Leuchtkraft ein/aus" zu versehen, die man dann über die Modell-Eigenschaften im Modellbahn-Studio und auch in der Ereignisverwaltung ähnlich wie die Animationen heute auflisten und damit deren Leuchtkraft gezielt ein- und ausschalten kann?

Leider habe ich von Dir auf diese und eine andere Frage im genannten Beitrag bisher keine Antwort erhalten. Da es diese Eigenschaft heute im Modellbahn-Studio nicht gibt, muss ich für die Schaltbarkeit der Beleuchtung das betroffene _LS-Objekt (den "Innenraum") zweimal bereitstellen (neben dem _LS-Objekt zusätzlich als "Nicht-_LS-Objekt"), was man sich bei der in meiner Frage vorgeschlagenen Funktionalität sparen könnte. Bei dem in Eingangsbeitrag genannten Speisewagen des RAe-TEE-Triebzugs habe ich für eine Ausprägung des Innenraums folgende Zahlen ermittelt:

Aufbereitet: 4 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen
- insgesamt: 5942 Flaechen, 14980 Eckpunkte, 18734 Polygone,
-          : 173 Normalen-Vektoren, 1 Materialien, 1 Texturen
Dateipfad: D:\Daten\Eisenbahn\3D-Modellbau\Sketchup\SBB_RAeII
X-Datei-Ausgabe:  RAe_TEE_WR_0_Innenraum.x
Plugin-Protokoll: RAe_TEE_WR_0_Innenraum.txt

Ich könnte also in diesem Modell 18734 Polygone oder 14980 Eckpunkte nach meiner Zählung einsparen (nach Deiner Zählung müsste es demnach ein Vielfaches sein), wenn ich den "Innenraum" wegen der Ein-/Ausschaltmöglichkeit der Innenbeleuchtung nicht zweimal bereitstellen müsste. Dies wäre bei diesem Modell eine Einsparung von mehr als einem Drittel der insgesamt gezählten Ressourcen (siehe oben)!

Übrigens hier noch zur Info und zum direkten Vergleich die Zahlen für die zweite und dritte LoD-Stufe dieses Modells:

Aufbereitet: 20 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen
- insgesamt: 3852 Flaechen, 11101 Eckpunkte, 10038 Polygone,
-          : 262 Normalen-Vektoren, 2 Materialien, 1 Texturen
Dateipfad: D:\Daten\Eisenbahn\3D-Modellbau\Sketchup\SBB_RAeII\DirectX
X-Datei-Ausgabe:  RAe_TEE_WR_1.x
Plugin-Protokoll: RAe_TEE_WR_1.txt

Aufbereitet: 6 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen
- insgesamt: 31 Flaechen, 222 Eckpunkte, 218 Polygone,
-          : 29 Normalen-Vektoren, 2 Materialien, 1 Texturen
Dateipfad: D:\Daten\Eisenbahn\3D-Modellbau\Sketchup\SBB_RAeII\DirectX
X-Datei-Ausgabe:  RAe_TEE_WR_2.x
Plugin-Protokoll: RAe_TEE_WR_2.txt

Viele Grüße
BahnLand

P.S.:
Den Vorwurf, dass Du die Beschränkung auf 65000 bisher nicht kommuniziert hast, muss ich zurücknehmen (siehe hier - ich möchte mich daher für diesen Vorwurf entschuldigen!). Mir war aufgrund von "meiner" Zählung der Eckpunkte nur nicht bewusst, dass ich hier mit meinem Modell darunter fallen könnte. Trotzdem bitte ich meine oben dargestellten Ressentiments bezüglich der Eckpunkt-Beschränkung bzw. der beschriebenen Möglichkeit, dass hier auch das Modellbahn-Studio "positiv" einwirken könnte, stehen lassen.

Nochmals viele Grüße
BahnLand
 

 

Bearbeitet 2. August 2017 von BahnLand

[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

[BahnLand]

Hallo Neo,

Deine Argumentation leuchtet mir ja ein.

Dennoch verstehe ich nicht, wie Du zu dem Ergebnis kommst, dass mein Speisewagen-Modell des RAe das Limit von 65536 Eckpunkten überschreitet. Dennoch habe ich jetzt nochmal sowohl in meinem Script als auch in der x-Datei, die ja die Grundlage für die Grafikarte bildet, nachgeforscht.

Meine im letzten Beitrag geäußerte Vermutung, dass ich jeden Eckpunkt nur einmal zähle, ist falsch. Tatsächlich zähle ich die sich unterscheidenden Kombinationen aus Eckpunkt-Koordinaten und Textur-Koordinaten. Treten also identische Eckpunkt-Koordianten mehrmals, aber mit unterschiedlichen Texturkoordinaten-Zuweisungen auf, werden sie bei mir auch entsprechend oft gezählt. Ich zähle aber nicht Duplikate der Kombination Eckpunkt- + Textur-Koordinaten. Deshalb bleibe ich mit der Gesamtzahl der Eckpunkt-Koordinaten auch deutlich unter dem 3-fachen der Polygon-Anzahl (jedes Poygon hat 3 Ecken). Dies ist aber auch nicht notwendig, da bei aneinander angrenzenden Polygonen, die zur selben Fläche mit einer Flächen-weiten Texturzuweisung gehören, sich die "gemeinsamen" Eckpunkte in den Texturkoordinaten nicht unterscheiden. Sie brauchen daher in der x-Datei auch nur einmal aufgelistet zu werden.

Prinzipiell besteht eine Mesh-Definition innerhalb einer x-Datei (hier am Beispiel eines einfachen Würfelds) aus folgenden Teilbereichen:

Der erste Abschnitt enthält die an die Grafikkarte zu übergebenden Eckpunkt-Koordinaten, aus denen im zweiten Abshnitt die Polygone gebildet werden. Die Materialliste enthält die Textur-Zuordnungen zu den einzelnen Polygonen, wobei Textur-Koordinaten (für das Mapping) den Polygon-Eckpunkten zugeordnet werden. Die Anzahl der Material-Zuordnungen entspricht also der Anzahl der Polygone, während die Anzahl der aufgelisteten Textur-Koordinaten der Anzahl der vorhandenen Expunkt-Koordinaten entspricht. Für die Grafikkarte muss die Kombination "Expunkt-Koordinate + Textur-Koordinate" eindeutig sein. Sie braucht aber nicht zwingend mehrfach vorhanden zu sein. Innerhalb der Gruppe der Eckpunkt-Koordinaten und jener der Textur-Koordinaten (jeweils für sich betrachtet) können sich daher Einträge wiederholen. Die Normalen-Vekoren brauchen für jede Flächen-Ausrichtung nur einmal vorhanden zu sein, deshalb ist diese Liste (zumindest hier) deutlich kürzer als alle anderen Listen. In der letzten Spalte werden die Normalen-Vektoren den einzelnen Polygonen zugeordnet, sodass die Anzahl der Normalenvektor-Zuordnungen wieder mit der Anzahl der ausgewiesenen Polygone übereinstimmt.

Ich habe nun einmal für den im vorangegangenen Beitrag aufgeführten Speisewagen exakt diese Mesh-Einträge (für enthaltenen alle Meshes (Frames) aufsummiert und bin hierbei exakt auf jene Zahlen gekommen, die vom Ausgabe-Protokoll des DirectX-Exporters ausgegeben werden.

15902 Flaechen, 41050 Eckpunkte, 52688 Polygone, 1470 Normalen-Vektoren, 2 Materialien, 1 Textur

In der x-Datei, die an die Grafikkarte "weitergereicht" wird, werden für den Speisewagen also 41050 Kombinationen aus Eckpunkt- und Textur-Koordinaten, 52688 Polygone mit entsprechend vielen Material(Textur)- und Normalenvektor-Zuordnungen sowie 1470 Normalenvektor-Definitonen ausgewiesen. Da der Grafikkarte eigentlich nicht mehr zur Verfügung stehen kann, als in der x-Datei hinterlegt ist, ist mir völlig schleierhaft, wo die von Dir festgestellte Überschreitung der Maximalzahl von 65536 Eckpunkten herkommt.

Bitte gib mir zusätzliche Informationen, wie ich diese "Überschreitung" selbst feststellen kann, und woher diese Erhöhung der Anzahl von Eckpunkt-Definitionen herrührt. Ich würde sie gerne "nachvollziehen" (verstehen) können, um zukünftig mit meinen Modellen unter dem von Dir vorgegebenen Limit bleiben zu können.

Viele Grüße
BahnLand

Bearbeitet 2. August 2017 von BahnLand

[EASY]

Hallo BahnLand

... es macht mich irgendwie langsam neugierig... nun weiß ich nicht ob es etwas bringt, darum schreibe ich einfach mal meine Idee dazu auf...

... Wäre es möglich, daß Du mir das Modell als .obj und/oder als .3ds zuschicken kannst... ich würde es gerne einmal in Blender als .x Datei exportieren (.x Import geht leider nicht)... mich würde interessieren wie viele Eckpunkte Blender zählt und was die daraus ergebende Zählung der "Blender" .x Datei bei Neo ergibt...
... ich weiß nicht ob dieser "Umweg" Export-Import-Export das Modell "verfälscht"... aber ist viellleicht mal einen Versuch wert...

Gruß
EASY

Bearbeitet 2. August 2017 von EASY

[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

[BahnLand]

Hallo EASY,  ... und Neo,

vor 4 Stunden schrieb EASY:

Wäre es möglich, daß Du mir das Modell als .obj und/oder als .3ds zuschicken kannst

da ich nur die Light-Version "Sketchup Make" habe, kann ich die Sketchup-Source nur als DAE-Datei (Collada) exportieren. Und das wird Dir wahrscheinlich nichts nützen. Da es aber seit kurzem die Möglichkeit gibt, ein in das Modellbahn-Studio hochgeladenens Modell als obj-Datei zu exportieren, habe ich hiervon Gebrauch gemacht.

RAe_TEE_WR_0_obj.zip

Allerdings befürchte ich ebenfalls, dass diese OBJ-Datei durch den "Umweg" über das Modellbahn-Studio bereits verfälscht worden ist. Denn wenn - wie Neo schreibt - beim Import in das Modellbahn-Studio die "zusätzlichen" (von mir nicht registrierten) Eckpunkt-Einträge entstehen, vermute ich, dass diese dann auch in der OBJ-Datei enthalten sind.

Viele Grüße
BahnLand

------------------------------------------------------------------------------------------------------------------------------------
Eigentlich ist es kein schöner Zug der Foren-Software, zwei Beiträge, die im Prinzip nichts miteinander zu tun haben und an verschiedene Adressaten gerichtet sind, einfach zusammenzuschieben! Gibt es da keine Möglichkeit, dies zu unterbinden?
------------------------------------------------------------------------------------------------------------------------------------

Hallo Neo,

vor 1 Stunde schrieb Neo:

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.

In Sketchup gibt es die Funktionalität der "Kantenglättung", die nach meinem Verständnis den Flat/Smooth-Optionen von Blender entspricht: Bei einer Kantenglättungs-Einstellung von 0° sind alle Kanten sichtbar. Bei einer Glättungs-Einstellung größer als 0° werden alle Kanten, deren Knickwinkel unterhalb dieser °-Einstellung liegen, geglättet. Wenn ich diese Glättung anwende, hat dies zwar keine Auswirkungen auf de Anzahl der vom DirectX-Exporter erzeugten Eckpunkt- und Polygon-Einträge. Die Anzahl der aufgelisteten Normalen-Vektoren kann sich dagegen ändern, sowie deren Zuordnung zu den Polygonflächen. Insofern vermindert sich zwar die Anzahl der Duplikate bei der Kombination "Eckpunkt-Koordinate - Textur-Koordinate - Normalenvektor". Doch die Zahl sich unterscheidender Kombinationen steigt hierdiurch an.  

vor 1 Stunde schrieb Neo:

Prüfe bitte zunächst, ob du tatsächlich überall Flächennormalen benötigst.

Ich wüsste nicht, wie ich das anstellen soll. Sketchup gibt mir an der Ruby-Schnittstelle (für den DirectX-Exporter) die Normalen-Vektoren für alle Polygone (für alle deren Ecken) aus. Woran soll ch nun erkennen, dass solche Flächennormalen "überflüssig" sind, und wie formuliere ich das in der x-Datei, ohne dass sich nachher das Modellbahn-Studio weigert, diese Datei anzunehmen (wegen falscher DirectX-Codierung)? Ich bin bisher immer davon ausgegangen, dass ich einen Fehler bekomme, wenn die Anzahl der Normalenvektor-Zuordnungen nicht mit der Anzahl darzustellender Polygone übereinstimmt.

vor 1 Stunde schrieb Neo:

Eventuell gibt es auch noch doppelseitiges Material, dessen Rückseite nicht zwingend benötigt wird (war bei Sketchup standardmäßig nicht jedes Material doppelseitig?)

Prinzipiell gibt Sketchup für jede Fläche eine Vorder-und Rückseite aus. Da ich jedoch an der Rupy-Ausgabe des Sketchup-Modells erkennen kann, ob eine Fläche mit dem "Standard-Material" (keine Textur oder Farbe zugewiesen) oder mit einer Textur/Farbe "belegt" ist, kann ich alle Flächen, die nicht explizit "bemalt" wurden, über die Einstellungen im DirectX-Exporter "ausklammern" lassen. Dass Sketchup grundsätzlich zwei Seiten jeder Fläche ausgibt, wovon eine möglicherweise nicht dargestellt werden soll, stellt also für den DirectX-Exporter kein Problem dar.

vor 1 Stunde schrieb Neo:

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.

Das werde ich wohl machen müssen (interessiert mich ja auch selbst). Trotzdem würde ich es gut finden, wenn Du die Anzahl der nach dem Import von der Grafikkarte zu bearbeitenden Eckpunkte im Vorschau-Fenster des Modells mit ausgeben würdest.

vor 1 Stunde schrieb Neo:

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.

Das tut weh, da ich eigentlich bestrebt bin, dann, wenn ich im Modellbahn-Studio etwas hin bekomme, was im ersten Moment als nicht lösbar erscheint, weil es keine "Standard-Funktionalität" ist, ich es eigentlich auch anwenden möchte. Dass Du Dir "nach der V4" Gedanken über die Beleuchtung machen möchtest, ist zwar schön und gut und auf jeden Fall begrüßenswert. Aber ich möchte eben mit dem Bau meiner Modelle nicht warten, bis die Funktion zu einem späteren Zeitpunkt irgendwann zur Verfügung steht. Und wenn ich dann die Funktion später in meine bereits gebauten Modelle übernehmen möchte, stehe ich wieder vor dem Problem, dass ich meine bereits fertiggestellten Modelle wieder neu anpacken und anpassen muss, oder die neue Funktionalität dort "außen vor" bleibt.

Was spricht eigentlich dagegen, "bis zum großen Wurf" zumindest ein paar kleine "Behelfs-Funktionen" zur Vergügung zu stellen (wie z.B. den Ein-Ausschalter für die _LS-Beleuchtung), um die Wartezeit bis zur endgültigen neuen Funktionalität damit überbrücken zu können?

Viele Grüße
BahnLand

Bearbeitet 2. August 2017 von BahnLand

[Neo]

Hallo BahnLand,

vor 9 Stunden schrieb BahnLand:

Eigentlich ist es kein schöner Zug der Foren-Software, zwei Beiträge, die im Prinzip nichts miteinander zu tun haben und an verschiedene Adressaten gerichtet sind, einfach zusammenzuschieben! Gibt es da keine Möglichkeit, dies zu unterbinden?

ich habe das automatische Zusammenfassen deaktiviert.

vor 9 Stunden schrieb BahnLand:

Insofern vermindert sich zwar die Anzahl der Duplikate bei der Kombination "Eckpunkt-Koordinate - Textur-Koordinate - Normalenvektor". Doch die Zahl sich unterscheidender Kombinationen steigt hierdiurch an.  

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.

vor 9 Stunden schrieb BahnLand:

Ich wüsste nicht, wie ich das anstellen soll.

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.

vor 9 Stunden schrieb BahnLand:

Dass Sketchup grundsätzlich zwei Seiten jeder Fläche ausgibt, wovon eine möglicherweise nicht dargestellt werden soll, stellt also für den DirectX-Exporter kein Problem dar.

Sehr gut.

vor 9 Stunden schrieb BahnLand:

Trotzdem würde ich es gut finden, wenn Du die Anzahl der nach dem Import von der Grafikkarte zu bearbeitenden Eckpunkte im Vorschau-Fenster des Modells mit ausgeben würdest.

Wird erledigt.

vor 9 Stunden schrieb BahnLand:

Das tut weh, da ich eigentlich bestrebt bin, dann, wenn ich im Modellbahn-Studio etwas hin bekomme, was im ersten Moment als nicht lösbar erscheint, weil es keine "Standard-Funktionalität" ist, ich es eigentlich auch anwenden möchte.

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.

vor 9 Stunden schrieb BahnLand:

Was spricht eigentlich dagegen, "bis zum großen Wurf" zumindest ein paar kleine "Behelfs-Funktionen" zur Vergügung zu stellen (wie z.B. den Ein-Ausschalter für die _LS-Beleuchtung),

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

[EASY]

Hallo Neo,

... nun bin ich erst einmal etwas erschrocken... und frage mal nach ob ich es richtig verstehe...
 

Zitat

vor 9 Stunden schrieb Neo:

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.

wenn ich einen Würfel nehme, dann hat dieser für mich 8 Eckpunkte. Da jeder Eckpunkt von 3 Flächen benutzt wird deren Normalvektor in unterschiedliche Richtungen zeigen, hat dann der Würfel für die Grafikkarte (und für die Zählung als Modell im MBS) 24 Eckpunkte? (Nach Deiner Beschreibung würde jeder Eckpunkt ja 2 mal dupliziert)  Und was mich noch etwas verwirrt ist das "+" bei Texturkoordinate... Wenn ich dann Würfel noch mit einer Textur belege fließen dann noch einmal 8 oder gar 24 Punkte in die Berechnung mit ein? so daß ich schlimmstenfalls auf 48 komme...

Bisher sind Modellbauer auf Polygone "geeicht"... das Thema Echpunkte scheint etwas komplexer zu sein... hier sehe ich schon etwas Klärungsbedarf Deinerseits (im Vorfeld !)... nicht daß es "plötzlich" für den Modellbauer zu bösen Überraschungen kommt... ich bin zwar geduldig und lernfähig aber es ärgert mich doch, wenn ich hinterher erfahre, was ich vorher hätte beachten müssen...

Gruß
EASY

[seehund]

Hallo Bahnland und Neo,

vor 17 Stunden schrieb Neo:

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.

Darüber ist eigentlich genug geschrieben worden und sollte langsam mal der Vergangenheit angehören.

Wie man aber ein vollanimiertes Dampflok-Modell im 65K-Modus bauen soll, wird bestimmt nicht nur mir schwer fallen. Wenn schon ein einzelnes Speichenrad ca. 2500 Vertices ohne Textur-Koordinaten hat, kommen bei einer 6 achsigen Lok schon 30.000 Vertices zusammen und dann fehlen immer noch das Fahrgestell, Kessel, Aufbau und alle anderen Bauteile. ( und davon ist das meiste auch noch Rund ) Da DirectX- und 3DS-Exporter keiner Norm unterliegen, kommen hier schnell Unterschiede von bis zu 40% zustande, je nachdem welches Erstellungs-Programm und welche Exporter verwendet werden.

Wenn Modelle die nur aus Flächen bestehen können um eine Vorgabegrenze nicht zu überschreiten, sind wir genau da, wo mir immer vor graute, nämlich beim Bau von texturierten Schuhkartons. Sogar im EEP können solche Modelle (obwohl teilweise mit exzellenter Textur) nur aus einiger Entfernung betrachtet, soeben noch durchgehen. Denn obwohl hoch gepriesen, wird beim EEP auch nur mit Wasser gekocht. Gute Modelle haben dort auch immer über 120.000 Vertices.

Den Grund, den Neo bewog die Modelle zu begrenzen, kann ich nicht nachvollziehen, da ich sogar auf meinem 13 Jahre alten AMD-Zweitrechner noch nie Probleme mit der FPS hatte.

Gruß Seehund

[BahnLand]

Hallo Neo,

vor 49 Minuten schrieb Neo:

aber bei deinen Wagons z.B. schaut die Decke etwas kantig aus, so als könnte dort das Glättungstool eine Verbesserung erwirken.

da hatte ich die Glättung ohnehin vor, aber erst ganz zum Schluss, wenn alles andere "erledigt" ist (ist dann in Sketchup nur noch eine Schieberegler-Verstellung).

 

vor 49 Minuten schrieb Neo:

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

Diese Erklärung hat mir bei meinem Verständnis jetzt doch weitergeholfen. Danke. Ich werde das testen, sobald ich die Möglichkeit habe, die Anzahl der "betroffenen" Eckpunkte anzeigen zu lassen.

Viele Grüße
BahnLand

Bearbeitet 3. August 2017 von BahnLand

[Neo]

Hallo,

vor 21 Minuten schrieb EASY:

Wenn ich dann Würfel noch mit einer Textur belege fließen dann noch einmal 8 oder gar 24 Punkte in die Berechnung mit ein?

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.

vor 23 Minuten schrieb EASY:

Bisher sind Modellbauer auf Polygone "geeicht"... das Thema Echpunkte scheint etwas komplexer zu sein

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.

vor 28 Minuten schrieb seehund:

Wie man aber ein vollanimiertes Dampflok-Modell im 65K-Modus bauen soll, wird bestimmt nicht nur mir schwer fallen.... Wenn Modelle die nur aus Flächen bestehen können um eine Vorgabegrenze nicht zu überschreiten, sind wir genau da, wo mir immer vor graute, nämlich beim Bau von texturierten Schuhkartons.

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.

vor 33 Minuten schrieb seehund:

Darüber ist eigentlich genug geschrieben worden und sollte langsam mal der Vergangenheit angehören....da ich sogar auf meinem 13 Jahre alten AMD-Zweitrechner noch nie Probleme mit der FPS hatte.

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.

vor 37 Minuten schrieb seehund:

Den Grund, den Neo bewog die Modelle zu begrenzen, kann ich nicht nachvollziehen

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

[BahnLand]

Hallo Neo,

vor 3 Minuten schrieb Neo:

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.

die LoD-Stufen sind bei meinen Modellen (insbesondere dem oben beschriebenen) da:

LoD-Stufe 0:    52688 Polygone, 41050 Eckpunkte (nach meiner Zählung, ohne Normalenvektor-Berücksichtigung)
LoD-Stufe 1:    10038 Polygone, 11101 Eckpunkte
LoD-Stufe 2:        218 Polygone,     222 Eckpunkte

Trotzdem werde ich wie angeraten die "Innenraum-Verdoppelung" (notgedrungen) entfernen und nur die _LS-Variante beibehalten.

vor einer Stunde schrieb Neo:

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.

Anscheinend hältst Du auch nichts davon, dass ich die verschiedenen Spitzenlichlicht-Zustände über entsprechende Animationen schalte. Wenn ich mich hier auf die drei Zustände "Aus", "3-Licht-Sptzensignal" und "2-Licht-Schlusssignal" beschränke, kann ich zwar die "vordefinierten" Animationsbegriffe "_AnimRunPositive" und "_AnimRunNegative" verwenden, bei denen mit dem Anfahren in Abhängigkeit von der Fahrtrichtung das "richtige" Licht automatisch angeschaltet wird (wenn die Automatik aktiviert ist). Aber da es beim Vorbild "unrealistisch" ist, dass das Licht erst beim Anfahren angeht, kann ich diese Automatik sowieso nicht nutzen und muss daher auf "Handbetrieb" (ggf. durch die EV gesteuert) umschalten. Dann spielt es aber auch keine Rolle mehr, ob die Animationen nun die vordefinierten oder andere Bezeichnungen besitzen, und ob dann davon 2 oder 5 Animationen im Modell bereit gestellt werden. Ich möchte daher die verschiedenen Spitzen- und Schlusslicht-Varianten, die für den RAe beim Vorbild wegen dessen international freizügiger Einsetzbarkeit eine Besonderheit darstellen, beibehalten - auch auf die Gefahr hin, dass ich dann zu einem späteren Zeitpunkt die AnimationSet-Definition noch einmal anpassen muss (betrifft ja nicht die Lichtflächen-Definitonen im Mesh-Modell - oder doch?).

Viele Grüße
BahnLand

[quackster]

hallo BahnLand,

die Animationsbegriffe "_AnimRunPositive" und "_AnimRunNegative"  waren mir garnicht so geläufig, klingen aber interessant.

kannst du den einer stehenden lok nicht die geschwindigkeit 0,01 zuweisen? hat das den nicht auch schon auswirkungen auf die genannten animationsbegriffe?

vg quackster

 

[EASY]

Hallo quackster,

Die die Animationsbegriffe "_AnimRunPositive" und "_AnimRunNegative" reagieren schon auf die Zuweisung von kleinen Geschwindigkeiten (eigentlich alles was von 0 verschieden ist)... allerdings ist es für die Allgemeinheit schwer zu vermitteln, daß wenn man einen bestimmten Effekt haben möchte, der Lok niemals eine Geschwindigkeit von 0 zuordnen sollte... außerdem macht sich eine Drift von "nur" 0,01 mm/s mit der Zeit bemerkbar und kann die ganze EV durcheinanderbringen...

Ich gebe zu, daß ich gerne mit solcher "Hinterlisten" arbeite... allerdings wächst bei mir die Einsicht, daß es dann mehr eine Spielerei für mich ist und nicht so ganz für den allgemeinen Gebrauch bestimmt sein sollte...

Gruß
EASY

[BahnLand]

Hallo Quackster,

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

Viele Grüße
BahnLand

[BahnLand]

Hallo Neo,

ich habe jetzt in den DirectX-Exporter einen zusätzlichen Zähler für die Zuordnungs-Tripel "Eckpunkt-Koordinaten + Textur-Koordinaten + Normalenvektor-Koordinaten" eingebaut, der sich jedoch nicht auf die zu erzeugende x-Datei auswirkt, und bin für den hier diskutierten Speisewagen auf folgendes Ergebnis gekommen:

Aufbereitet: 28 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen
- insgesamt: 15902 Flaechen, 41058 Eckpunkte, 52688 Polygone,
-          : 1470 Normalen-Vektoren, 2 Materialien, 1 Texturen
-          : 76778 Eckpunkt-Textur-Normalenvektor-Zuordnungen

Kannst Du bitte überprüfen, ob die von mir berechnete Zahl mit jener, die Du beim import des Modells festgestellt hast, übereinstimmt?

Wenn ich die Verdoppelung des Innenraums weglasse, bekomme ich folgende Ergebniswerte:

Aufbereitet: 24 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen
- insgesamt: 9960 Flaechen, 26074 Eckpunkte, 33954 Polygone,
-          : 1297 Normalen-Vektoren, 2 Materialien, 1 Texturen
-          : 46988 Eckpunkt-Textur-Normalenvektor-Zuordnungen

Wenn ich dann noch eine Kantenglättung durchführe, erhöht sich zwar die Zahl der Normalenvektoren, aber die Zahl der Zuordnungs-Tripel reduziert sich wie von Dir beschrieben trotzdem.

Aufbereitet: 24 Gruppen, 0 Komponenten, 0 nicht gruppierte Flaechen
- insgesamt: 9960 Flaechen, 26074 Eckpunkte, 33954 Polygone,
-          : 1992 Normalen-Vektoren, 2 Materialien, 1 Texturen
-          : 37304 Eckpunkt-Textur-Normalenvektor-Zuordnungen

Alledings habe ich es bei diesem Test mit der Kantenglättung etwas übertrieben. Ich werde daher bei dem in den Katalog hochzuladenden Modell etwas "behutsamer" vorgehen und deshalb etwas mehr Eckpunkt-Textur-Normalenvektor-Tripel in Kauf nehmen (ich bleibe ja dann auf jeden Fall unter den 46988 aus der mittleren Messung).

Viele Grüße
BahnLand

[Neo]

Hallo BahnLand,

vor 1 Stunde schrieb BahnLand:

Ich möchte daher die verschiedenen Spitzen- und Schlusslicht-Varianten, die für den RAe beim Vorbild wegen dessen international freizügiger Einsetzbarkeit eine Besonderheit darstellen, beibehalten - auch auf die Gefahr hin, dass ich dann zu einem späteren Zeitpunkt die AnimationSet-Definition noch einmal anpassen muss

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.

vor 6 Minuten schrieb BahnLand:

Man kann die "Automatik" ausschalten.

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.

vor 8 Minuten schrieb BahnLand:

76778 Eckpunkt-Textur-Normalenvektor-Zuordnungen

Im Studio werden für RAe_TEE_WR_0.x insgesamt 76766 Eckpunkte generiert.

Viele Grüße,

Neo

 

[BahnLand]

Hallo Neo,

vor 4 Stunden schrieb Neo:

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

Leider kann ich selbst nicht feststellen, wie häufig Modelle von mir im Modellbahn-Studio von anderen Anwendern geutzt werden oder wurden. Aber als ich seinerzeit meine "Lichtscheiben" für die Lokomotiv-Scheinwerfer im Online-Katalog bereitstellte, hatte ich doch einige positive Resonanz bekommen. Insofern kann ich mich hier Deiner Meinung nicht anschließen.

Bei der Integration der animierten Lichter in das Modell hat mich natürlich die technisch Machbarkeit gereizt. Av´ber es war damit auch die Absicht verbunden, die bisherigen Lichtscheiben, die jede für sich ein separates Modell darstellen, und die daher auch von der Grafikkarte jeweils separat verarbeitet werden müssen, überflüssig zu machen. Uns Modellbauer davon abzuraten, die entsprechenden Animationen in die Modelle einzubauen, widerspricht also Deinem Ziel, auf Modelle, die als Ergänzng an andere Modelle "angeheftet" werden, möglichst zu verzichten, wenn der Modellbauer die dadurch abgebildete Funktionalität beibehalten möchte. Und auch da müssen diese jeweils als separates "Lichtsignal" realisierten Lampen explizit von Hand oder über die EV geschaltet werden.

vor 4 Stunden schrieb Neo:

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

Du weißt schon, dass dies eine inkompatible Änderung ist, die sich auch auf bestehende Anlagen auswirkt (wo diese Steuerung via EV bereits eingebaut ist). Und es ist schon eine gravierender Unterschied, ob ein Nutzer keine Animationen abspielen muss (das ist bereits heute der Fall) oder nicht mehr kann. Letzteres ist für die betroffenen Nutzer ein Rückschritt in der Funktionalität, solange nicht eine entsprechende "Ausweich-Funktionalität" zur Verfügung steht. Wieso muss diese Funktionalität ausgebaut werden, solange sie noch nicht auf eine andere Weise angeboten wird?

Und für den Fall, dass der Nutzer auf diese Funktionalität nicht selber kommt, gibt es ja immer noch die Kurzbeschreibung für das Modell, die von uns Modellbauern ja auch intensiv genutzt wird.

Ich habe mal nachgeschaut, bei welchen "vordefinierten" Animationen heute das Automatik-Auswahlkästchen vorhanden ist, das Du in MBS V4 abschaffen möchtest:

• _AnimaRunPositive und _AnimRunNregative
  Wenn diese Funktionalität nur noch "automatisch" abgespielt werden kann, werden bei den Zügen die Spitzen- und SChlusslichter vor jedem Halt zeigenden Signal ausgehen. Selbiges gilt für beleuchtete Straßenbahrzeuge vor jeder roten Ampel.
• _AnimRun
  Über diese Animation gesteuerte Stromabnehmer werden bei jedem Zughalt - sei es bei einem Halt im Bahnhof oder vor einem Halt zeigenden Signal - abgesenkt. Dies entspricht nun wirklich nicht dem Vorbild. Außerdem gibt es hier nicht die Möglichkeit, zwischen verschiedenen Stromabnehmern eines Triebfahrzeugs auszuwählen: Entweder werden die Stromabnehmer alle synchron bewegt, oder ein nicht in die Animation aufgenommener Stromabnehmer bleibt für immer unbeweglich.
• _AnimBarrier
  Diese für Bahnschranken vorgesehene Animation reagiert im Automatik-Modus ausschließlich auf die Annäherung oder Entfernung eines Zuges mit sehr geringer "Sensor-Reichweite". Dies führt bei mehrgleisigen Bahnübergängen dazu, dass nur Züge auf dem "nächstgelegenen" Gleis erfasst werden und die Schranken auf das Passieren eines ZUges auf einem entfernteren Gleis überhaupt nicht reagieren. Ich habe hierzu eine kleine Demo-Anlage gebaut, bei der ich jedoch stets auf Schranken-Paare zurückgreifen musste, weil ich im Online-Katalog keine "Einzelschranken" gefunden habe, welche die "_AnimBarrier"-Animation eingebaut haben.
  
  AnimBarrier.mbp
  
  Deshalb bitte immer nur die "äußeren" Schranken beachten und über die "inneren" Schranken hinwegzusehen!
  
  Vorne in der Mitte befindet sich ein Bahnübergang von Seehund für mehrere Gleise. Sein Mittelpunkt (= Position des "Sensors") befindet sich im Bereich des mittleren Gleises. Passiert nun ein Zug auf einem äußeren Gleis den Bahnübergang, bleiben die Schranken geöffnet, weil der "Sensor" zu kurz greift. Hinten links habe ich zwei "zweigleisige" Bahnübergänge von Seehund so positioniert, dass jeder 2 Gleise "abdeckt". Hierdurch sind zwei Schranken zwischen den Gleisen positioniert, die hier "wegzudenken" sind. Da sich hier der "Sensor" jedes Bahnübergangs in der Mitte zwischen zwei benachbarten Gleisen befindet, wird die Schließung durch beide Gleise ausgelöst. Passiert ein Zug das mittlere Gleis, werden daher beide Schranlkenanlagen geschlossen. Wird dagegen ein äußeres Gleis befahren, bleibt die SChanke für das andere äußere Gleis geöffnet. Beim dritten Beispiel hinten rechts habe ich zweimal die eingleisige Schrankenanlage aus dem "Grundausbau" jeweils für die beiden äußeren Gleise eingebaut. Hier wird jeweils nur eine Schrankenanlage geschlossen, wenn ein Zug das zugehörige äußere Gleis passiert. Wird das mittlere Gleis befahren, bleiben beide Schrankenanlagen geöffnet.
  
  Bei einelnen Schrankenbäumen würde man denselben Effekt feststellen können, wenn es diese mit der _AnimaBarrier-Animation gäbe. Aber hier wurde - meines Erachtens eben gerade wegen dieser Nebeneffekte - auf die Verwendung der _AnuimBarrier-Animation verzichtet und stattdessen eine "nicht-vordefinierte" Animation eingebaut, die man nun über die EV gezielt steuern kann, aber auch über die EV oder von Hand gezielt steuern muss.

Wenn Du nun die Abschaltbarkeit der Automaik ausbaust, ohne gleichzeitig eine Alternative anzubieten, sind die Modellbauer gezwungen, "private" Animationen anzubieten (für die es dann eben gruundsätzlich keine Automatik gibt), wenn sie auf die besagten Animationen nicht ganz verzichten wollen.

vor 5 Stunden schrieb Neo:

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.

Als ich diesen Satz laß, habe ich zuerst einen Luftsprung gemacht und dachte, dass die obigen Gedanken nun überflüssig werden, ...

vor 5 Stunden schrieb Neo:

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

... aber dieser Nachsatz hat mich dann sofort wieder auf den Boden der Tatsachen zurückkehren lassen. Es ist ja schön, dass man mit den Gleisen ab V4 als Modellbauer jene Freiheit zur Verfügung hat (wir haben ja auch schon sehnlichst darauf gewartet), die offenbar für andere Modell-Typen in V4 noch nicht zur Verfügung stehen wird. Aber warum wird dann die alte Funktionalität schon vorab abgeschaltet? Ich kann nicht verstehen, warum alte Programmierpfade nicht solange noch beibehalten und durchlaufen werden können, bis die sie ersetzenden Programmierpfade fertiggestellt sind. Was hindert Dich daran, alte und neue Programmierpfade für eine Übergangszeit nebeneinander stehen zu lassen und mit einer "Weiche" zu versehen?

Du kannst ja die alten Funktionalitäten mit dem Vermerk versehen, dass diese Teilfunktionen in der vorliegenden Form nicht mehr weiterentwickelt und gewartet werden, weil für sie in kurzfristiger Zeit eine funktionell verbesserter Ersatz vorgesehen ist. Das ist allemal besser, als eine bestehende Funktionalität einfach (zumindest zeitweise) ersatzlos zurückzuziehen.

Viele Grüße
BahnLand

[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

[BahnLand]

Hallo Neo,

dann werden wir Modellbauer diese "Lücke" wohl oder übel irgendwie überbrücken müssen.

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

Viele Grüße
BahnLand

[fmkberlin]

vor 11 Stunden schrieb Neo:

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.

Halo Neo,

Würden dann alle Lichter (_LS-Objekte), die sich auf der Anlage befinden, an-/ausgehen?

VG

fmkberlin

 

[Neo]

Hallo BahnLand,

vor 2 Stunden schrieb BahnLand:

Denn ich hoffe, dass Du die Animationen nicht insgesamt "abschaltest".

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.

vor einer Stunde schrieb fmkberlin:

Würden dann alle Lichter (_LS-Objekte), die sich auf der Anlage befinden, an-/ausgehen?

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