Nach der Entschlüsselung der Bahn-OVLs vor etwa einem Monat ist nun auch der zweite von drei Schritten erfolgt; die Strukturanalyse der Schienen-OVLs ist größtenteils abgeschlossen. Nur Schienen mit Sonderfunktionen (z.B. Bremsen, Tilt, Wagenrotation) sind noch unbekannt.
Somit ist es mir nun möglich, beliebige Graphiken und Verläufe (TrackSplines) für CTR-Schienenteile zu verwenden. Das Ganze geht allerdings bisher nur "per Hand", d.h. sehr aufwändig, mithilfe eines Hexeditors. Eine automatische Verarbeitung von 3D-Daten aus Blender/Sketchup wäre wünschenswert. Um zu verstehen, wo das Problem liegt, muss ich kurz erklären, wie die Schienenteile aufgebaut sind:
Prinzipiell handelt es sich bei Schienenteilen um 3D-Graphikdaten, z.B. wie bereits von CSOs bekannt. Anders als bei CSOs sind darüberhinaus in den Schienen-OVLs noch sogenannte TrackSplines vorhanden, die festlegen, wo die Wagen entlangfahren (das wird von RCT3 nicht über die Graphik der Schiene gesteuert!). Zudem kommen noch einige Extra-Schienendaten hinzu, die es bei CSOs nicht gibt.
Damit gibt es zwei Möglichkeiten, selbsterstellte Schienengraphiken aus Blender/Sketchup in RCT3 reinzukriegen:
1.) Man benutzt wie üblich den Importer, um die komplizierte Umwandlung von ASE-Graphikdaten in CSO-Daten durchzuführen. Danach müsste mein Tool CTR_Creator diese CSOs und die oben erwähnten, zusätzlichen Daten einlesen, um die Schienen-OVLs zu generieren.
2.) Wenn CTR_Creator ähnliche Routinen wie der Importer hinzubekommen würde, könnte man in einem Schritt mittels CTR_Creator alle Eingangsdaten (ASE-Graphiken, TrackSplines und Zusatzinfos) einlesen, diese verarbeiten und Schienen-OVLs erstellen.
Gegen Möglichkeit 1 spricht die Tatsache, dass der Importer CSOs schreibt, die zwar funktionieren, aber eine andere Struktur als normale Szenerie-OVLs besitzen. Deshalb müsste ich nicht nur die Bahn-, Schienen- und Wagen-Strukturen analysieren, sondern auch noch die Struktur von CSOs herausfinden. Das ist eine Arbeit, zu der ich ehrlich gesagt, keine Lust habe. (Warum gibt der Importer nicht Szenerie-OVL-konforme Strukturen aus?
)
Gegen Möglichkeit 2 ist einzuwenden, dass es sehr arbeits- und zeitaufwändig wäre, alle wichtigen Routinen des Importers nochmals in CTR_Creator nachzuprogrammieren. Ausserdem möchte ich nicht JonWil und Belgabor ihrer genialen Meisterleistung berauben, indem ich einfach ihren Importer-SourceCode kopiere (auch wenn kein Copyright drauf ist)! :Respekt:
Hat jemand einen weiteren Lösungansatz oder zumindest eine Idee, wie man das Problem mittels einer der beiden oben beschriebenen Möglichkeiten relativ einfach lösen kann?
PS: Bei CTR-Wagen wird das Problem sogar noch größer, da Wagen haufenweise BoneAnimations verwenden.
Somit ist es mir nun möglich, beliebige Graphiken und Verläufe (TrackSplines) für CTR-Schienenteile zu verwenden. Das Ganze geht allerdings bisher nur "per Hand", d.h. sehr aufwändig, mithilfe eines Hexeditors. Eine automatische Verarbeitung von 3D-Daten aus Blender/Sketchup wäre wünschenswert. Um zu verstehen, wo das Problem liegt, muss ich kurz erklären, wie die Schienenteile aufgebaut sind:
Prinzipiell handelt es sich bei Schienenteilen um 3D-Graphikdaten, z.B. wie bereits von CSOs bekannt. Anders als bei CSOs sind darüberhinaus in den Schienen-OVLs noch sogenannte TrackSplines vorhanden, die festlegen, wo die Wagen entlangfahren (das wird von RCT3 nicht über die Graphik der Schiene gesteuert!). Zudem kommen noch einige Extra-Schienendaten hinzu, die es bei CSOs nicht gibt.
Damit gibt es zwei Möglichkeiten, selbsterstellte Schienengraphiken aus Blender/Sketchup in RCT3 reinzukriegen:
1.) Man benutzt wie üblich den Importer, um die komplizierte Umwandlung von ASE-Graphikdaten in CSO-Daten durchzuführen. Danach müsste mein Tool CTR_Creator diese CSOs und die oben erwähnten, zusätzlichen Daten einlesen, um die Schienen-OVLs zu generieren.
2.) Wenn CTR_Creator ähnliche Routinen wie der Importer hinzubekommen würde, könnte man in einem Schritt mittels CTR_Creator alle Eingangsdaten (ASE-Graphiken, TrackSplines und Zusatzinfos) einlesen, diese verarbeiten und Schienen-OVLs erstellen.
Gegen Möglichkeit 1 spricht die Tatsache, dass der Importer CSOs schreibt, die zwar funktionieren, aber eine andere Struktur als normale Szenerie-OVLs besitzen. Deshalb müsste ich nicht nur die Bahn-, Schienen- und Wagen-Strukturen analysieren, sondern auch noch die Struktur von CSOs herausfinden. Das ist eine Arbeit, zu der ich ehrlich gesagt, keine Lust habe. (Warum gibt der Importer nicht Szenerie-OVL-konforme Strukturen aus?
)Gegen Möglichkeit 2 ist einzuwenden, dass es sehr arbeits- und zeitaufwändig wäre, alle wichtigen Routinen des Importers nochmals in CTR_Creator nachzuprogrammieren. Ausserdem möchte ich nicht JonWil und Belgabor ihrer genialen Meisterleistung berauben, indem ich einfach ihren Importer-SourceCode kopiere (auch wenn kein Copyright drauf ist)! :Respekt:
Hat jemand einen weiteren Lösungansatz oder zumindest eine Idee, wie man das Problem mittels einer der beiden oben beschriebenen Möglichkeiten relativ einfach lösen kann?
PS: Bei CTR-Wagen wird das Problem sogar noch größer, da Wagen haufenweise BoneAnimations verwenden.
.
.
). An DLLs gibt es nur jonwils alte libOVL.dll, und die ist genau das was die nicht-konformen OVLs erzeugt. Meine eigene OVL-Bibliothek ist rein für statisches linken ausgerichtet, sollte sich aber mit Borland C++ compilieren und linken lassen.
). Anders sieht es da mit den OVL-Strukturen aus; die kann ich gerne veröffentlichen, sobald ich mit meiner Arbeit fertig bin -- allerdings werden weltweit höchstens ein Dutzend RCT3-User die Strukturen verstehen (JonWil, Belgabor, Vodhin, TheCook...)