Koordinatensystem für Zusi 3

[Carsten Hölscher]

Ich würde gerne mal ein paar Meinungen zu folgendem Problem einsammeln:
Es gibt hinsichtlich der Zusi 3-Belange zwei gängige Koordinatensysteme, die irgendwie unter einen Hut gebracht werden müssen.
Das bisher aus Zusi bekannte System ist das allg. übliche für alle mir bekannten Anwendungen aus Wissenschaft, Landvermessung und Technik. Vermutlich aus historischen Gründen ist in der 3D-Programmierung ein etwas eigenwilliges System üblich, also aus Lokführersicht x-Achse nach rechts, y-Achse nach oben, z-Achse nach vorne (das ist also nicht nur anders ausgerichtet, es ist auch noch entgegen der sonst üblichen Handhabung ein Linkssystem).


Grundsätzlich bieten sich drei Schnittstellen an:
1.) Man läßt die Zusi-Welt komplett wie sie ist. Das Problem ist dann nur der Umgang mit handelsüblichen 3D-Editoren, da diese wohl nicht alle ein umschaltbares Koordinatensystem haben. Wenn z.B. b3d-Objekte aus anderen Sims herübergeholt werden sollen, paßt das System nicht. Ein Umrechnen der Objekt-Koordinaten während des Zusi-Ladevorgangs ist auch schwierig, da es z.B. für x-Files fertige DirectX-Laderoutinen gibt.

2.) Zusi stellt sich komplett auf das DirectX-System um, Nachteil wäre die Schnittstelle zu Rolands Routinen mit dem für Landesvermessung sehr unüblichen Koordinatensystem und damit ggf. Verständnisschwierigkeiten beim Abgleich Karte/Zusi.

3.) Zusi bekommt 2 Koordinatensysteme, das bisherige für die Strecke und die Landschaft, das DirectX-System für die Objekte. Ich fürchte bei diesem Fall könnte es zu Verständisproblemen und Chaos kommen, da man nie genau weiß, welches System jetzt wie gilt.

Wer also für das Problem eine Meinung oder besser noch eine geniale Idee hat, der sollte die bitte kundtun.

Carsten

[Gerd Schütz]

Für die Strecken und Landschaftserstellung ist die jetzigen Anwendung mit Roland´s Tools doch Ideal. Das heißt doch es müßte für diesen Fall das alte Koordinatensystem erhalten bleiben.

Wie sieht es denn mit Konvertierungsmöglichkeiten aus? Von dem jetzigen Koordinatensystem zum möglichem neuen Koordinatensystem.

Um nicht die ganzen Strecken für ZUSI 3 mit evtl. neuem Koordinatensystem manuell zu ändern, wäre ein Konverter doch ohnehin notwendig.

Gruß
Gerd

[Thomas Gabler]

Ich weiß ja nicht, wie die künftigen Zusi-Editoren aussehen werden, aber wie wärs damit:

Im Fahrsimulator und in den Dateien selbst wird mit DX-Koordinaten gearbeitet, die Zusi-Editoren haben aber ein umschaltbares Koordinatensystem.

Tom

[Roland Ziegler]

Ich habe mit Carsten schon am Telefon überlegt und war erst der Ansicht, zwei Koordinatensysteme zu benutzen, bzw dem Anwender eine Transformation on the fly bei der Darstellung zu bieten.

Meine Tools orientieren sich natürlich an den üblichen Rechtssystemen der Geographie bzw Geodäsie, Länge = x, nach Ost zunehmend, Breite = y, nach Norden zunehmend, Höhe = z = nach oben zunehmend. (wobei man zugeben muss, dass es in der englischsprachigen Welt auch noch ein Linkssystem gibt, Breite = x und Länge = y, aber in jedem Fall z als Höhe, was mit der Verbreitung von UTM aber weiter verdrängt wird)

Der Streckeneditor ist auch ein klassisches Beispiel einer Kartenprojektion, in diesem Falle von Vektorkarten. Ungwöhnlich ist eigentlich nur, dass die x-Achse "nach oben" zeigt, also in ein "falsches Nord", aber z ist wieder die Höhe.

Eigentlich wäre alles ganz einfach, wenn man das Zusi-System insgesamt ließe wie es ist, wäre da nicht diese eine Kleinigkeit, der Import aus 3D-Editoren. Nun könnte man ja fragen, wieso, funktioniert doch prächtig, siehe meinen 3D-Modellbetrachter. Der schluckt x-Files im Linkssystem mit y als vertikaler Achse auf der einen Seite und ls-Files im Rechtsystem mit z als vertikaler Achse.

Aber, und das ist der Knackpunkt: Die Umrechnung von Meshes in Frame-Hierarchien. Jedes halbwegs komplexe 3D-Modell ist in Hierachien aufgebaut, selbst ein "einfaches" Zusi-Signal. Für jede Hierarchiebene ("Frame") gilt eine bestimmte Transformationsregel, die auch die Rotation beinhaltet (hat Zusi jetzt auch schon und bereitet jedermann Kopfzerbrechen und Verständnisprobleme (außer Tom vielleicht), wenn die Rotation um mehr als eine Achse erfolgt.)

Das heißt konkret, dass es, um beim einfachen Beispiel Signal zu bleiben, zwei verschiedene Bezugssysteme gibt. Schauen wir uns einen Signalflügel an, ein eher flaches Gebilde. Das Ding hat eine größere Ausdehnung quer zur Fahrrichtung, eine geringere in die Höhe, und dreht sich um eine Achse, die momentan im Zusi-System eine Parallele zur X-Achse, im DX-Linkssystem aber eine zur z-Achse ist.

Beim Einlesen eies 3D-Modells findet zwar eine Umrechnung statt, aber zumindest bei mir bislang nur bei den Transformationwerten, den Pivot-Punkten. Die Meshkoordinaten selbst bleiben unverändert.

Nach 2 Tagen Nachdenken bin ich inzwischen der Meinung, wir sollten entweder auch die Meshkoordinaten umrechnen, oder aber besser eine geeignete Zwischentransformation brerechnen, die auch für den Frame auf unterster Ebene ein "natürliche Bezugs-Orientierung" ergibt, egal wie das Mesh gerade aufgrund der Gesamtszene rotiert ist.

Damit wäre die Rotationsachse besagten Flügels immer ein Parallele zur x-Achse un nie etwas anderes. Meine Signalanimation macht hier nämlcih momentan noch Fallunterscheidungen.

Mein Fazit: Altes Zusi-Rechtssystem belassen, auch für 3D-Modelle. 3D-Modelle beim Import auf's Zusi-Modell anpassen, vorzugsweise nur duch Transformation der Pivot-Punkte, aus Geschwindigkeitsgründen. Für den Fahrsimulator ist rechts oder links und Achsenorientierung ziemlich schnuppe, es wird bekanntlich immer alles auf 2D transformiert. (Die x-Achse darf im Streckeneditor V3 dann aber bitte auch nach rechts zeigen. )

PS:
Die Historie des 3D-Linkssystems ist übrigens schnell erklärt. Zu Zeiten von 2D-Grafik war die Darstellungsebene auch schon der Bildschirm. Den Usprung setzte man wie auf dem Papier "unten links" - also anders als in "Windows", wo der Ursprung "oben links" liegt - und konnte wie vom Papier gewohnt prima mit x und y rechnen, x nach rechts, y nach oben. Weil das aber in der Ebene spielte, war oben dann eher so etwas wie "Nord". Jetzt kommt die dritte Dimension hinzu, in der Tiefe des Monitors. Dem wird die z-Achse zugewiesen, denn x und y sind ja schon vergeben. Aber jetzt wird aus Veranschaulichungsgründen das, was ganz tief im Monitor innen drin scheint, mit dem größten z-Wert versehen, die z-Achse geht also in den Monitor hinein. Und schon haben wir ein Linkssystem (3-Finger-Regel). Und außerdem wird y zwangsläufig zur vertikalen Achse. Aagrhh

[Daniel Rüscher aka Merlin]

Also ich plädiere auch für das Alte ZusiKoordinatensystem, Die Systemumrechnung muss ja nicht zur Laufzeit erfolgen, kann auch mit einem kleinen Tool geschehen das dann auch noch die dateien zu einer Datei packt, soll heißen: Zur einfacheren Handhabung könnte man doch auch hergehen und alle Dateien (wav, ls, lok, evtl auch die Texturen, bei einer Lok) in eine Packen.
Das hätte den Vorteil, das die Handhabung der verschiedenen Objekte wesentlich vereinfacht würde.

[mdeen]

IZu Zeiten von 2D-Grafik war die Darstellungsebene auch schon der Bildschirm. Den Usprung setzte man wie auf dem Papier "unten links" - also anders als in "Windows", wo der Ursprung "oben links" liegt

Bist du dich da ganz sicher? Ich muß ehrlich sagen das ich mich recht quälen muß um mir meine erste Programmierschritte hervor zu ragen, aber ich bin mir fast sicher das auf dem TRS-80 der Ursprung auch oben links war und daher 'pfeil hoch' mit x-1 zu bewerten war. Das macht generell auf Computerschirme sinn weil das der Anfang von alle Ausgaben vorstellt.
Ich kan mir ehrlich gesagt auch kein Programmierplatform bedenken wo das nicht so war. Auch X-Windows arbeitet so.
Allerdings habe ich nie mit hochprofessionelle 2D oder 3D pakete gearbeitet.

Maarten

[Carsten Hölscher]

man kann es sicherlich so machen, dass das alte Zusisystem komplett weiterhin gilt.
Man muß sich nur bewußt sein, dass z.B. das Bearbeiten einer b3d- oder x-Datei im externen Editor dann immer eine gedankliche Transformation erfordert. Also wenn ich im Streckeneditor der Meinung bin, meine Brücke erfordere in x-Richtung noch eine Korrektur, dann muß ich mir erstmal überlegen, welche Koordinate ich denn im Editor jetzt ändern muß.
Bei Objekten mit eindeutiger Ausrichtung und einem visuellen Editor ist das sicherlich nicht so schwer. Aber wenn ich an ein b3d-File im Texteditor denke...ich fürchte, das bekommt man schnell einen dicken Hals.

Ich favorisiere immer noch 2.), da es meiner Meinung nach für den normalen Streckenbastler die am seltensten gebrauchte Schnittstelle darstellt. Für alle Kartenfreaks könnte man ja die aktuellen Koordinaten - umgerechnt ins kassische Zusi-System - in der Statusleiste einblenden, um nicht zu viel nachdenken zu müssen.

In Zusi selbst zwei (umschaltbare) Systeme zu benutzen halte ich für reichlich fehleranfällig, zum einen für die Nutzer (man muß bei Absprachen immer das System dazusagen und sich immer wieder vergeeissern, was man gerade eingestellt hat) und programmiertechnisch klingt das auch nicht rundrum verlockend...

Zu den Konvertierungen: Bei meinen derzeitigen Tests werden die Zusi-ls-Dateien ins DirectX-System konvertiert (für str geht's natürlich genauso). Man könnte also Rolands Tools weiterbenutzen wie bisher (das gilt immer, egal welches System Zusi 3 bekommt), da Zusi erkennt, dass eine 2.x-Datei vorliegt und somit beim Laden alles gleich korrekt konvertiert wird.
Die ganze Diskussion geht also eher um die Frage, wie sich mal ein potentielles zukünftigen Zieglertool (das dann direkt Zusi 3-Format schreibt) verhält und wie ich die Koordinaten aus dem Zusi-Streckeneditor mit den Original-TOP50-daten vergleichen kann (diesen Bedarf hatte ich persönlich bisher beim Streckenbau zugegebenermaßen nicht).

Carsten

[Roland Ziegler]

3DC gehört ja zu den Tools, die mit diesem DX-nahen Linkssystem arbeiten. Glücklicherweise gibt es dort auch zuschaltbare Achsenindikatoren, notfalls für jeden Frame in der Hierarchie. Das ist meine Orientierung beim Bau. Denn beim Linkssystem fehlt zumindest mir jede Vorstellung.

Die könnte man sich zwar herleiten, über eine Eselsbrücke: Streckenmöbel -> Möbel. Möbel werden häufig angegeben mit Abmessungen Breite, Höhe und Tiefe. Das übertragen wir auf x, y und z. Wobei Tiefe einer Lokomotive dann deren Länge über Puffer ist. Dies mag zu Kopfschütteln führen, ist aber die DX interne Notation. Ob man sie nachmachen muss, ist eine andere Frage.

Für die Strecke sieht das dann so aus: Der Punkt, der 10 km östlich (= auf der Karte nach rechts), 5 km nördlich (= auf der Karte nach oben) vom Ursprung (Anfangspunkt) entfernt ist, und 200 m hoch liegt, wird zur Zeit ausgedrückt als

10000, 5000, 200

zukünftig aber als

-5000, 200, 10000

Ich stimme Carsten sicherlich insoweit zu, dass auch derzeit nur ein Teil der Streckenbauer in Koordinaten "denkt", sich also unter den Zahlenwerten (oberer Punkt) etwas vorstellen kann. Ich befürchte allerdings, dass die Zahl dieser Leute nach Einführung des Linkssystems (unterer Punkt) spürbar abnehmen wird.

Es ist ja nicht nur die Darstellung einzelner Punkte, es sind ja auch die Beziehungen zwischen den Punkten, bzw Vektoren, die sich bei Streckeneditor und Konsorten wesentlich in einer Ebene abspielen.

Wie beantwortet man bitte die Frage, ob man vom Punkt (1000,1000), oh nein, (-1000, unbekannte Höhe,1000) in Richtung Ost schauend zum Punkt (2000,2000) -> (-2000, unbekannt, 2000) eine Links- oder eine Rechtskurve bauen muss? Und wie muss ich den Winkel angeben, positiv oder negativ, oder vielleicht sogar in Promille?

Die Antwort für meine Tools ist klar. Es bleibt bei der Linkskurve. Der Winkel wird positiv. Denn die Tools basieren auf der 2D-Geometrie des üblichen Rechtssystems und werden natürlich intern weiter so rechnen, egal welche Darstellung sie importieren oder exportieren. Das ist auch einer der Unterschiede zwischen reinem 3D, wie es der Fahrsimulator benötigt, und 2D+Höhe, wie es Streckeneditoren, und alle Formen von Karten/GIS-Tools verwenden. Reinen 3D-Anwendungen ist das auch intern wurscht, sie haben kein Vorzugslage. Letztere aber sind 2D-Tools, mit spezieller Bedeutung der x/y-Ebene. Sie verarbeiten die Höhe als Attribut.

Für das Linkssystem würde ich meine obige Frage gar nicht beantworten wollen, denn die Antwort erscheint mir eh von nur rein akademischem Interesse, denn: aus der Linkskurve in Wirklichkeit wird im Linkssystem zumindest mathematisch eine Rechtskurve .

[Hans-Peter Schramm]

Moin,

also jetzt muss ich mich auch mal melden.
Bedingt durch meine Vorkenntnisse (Maschinenbau/CAD) habe ich ein recht ordentliches räumliches Verständnis, und kann mir unter den derzeitigen Koordinaten sehr viel vorstellen, sogar die Rotationen gehen noch ganz gut.
Da ich nicht ausschließlich mit den digitalen Top50-Karten arbeite, sondern auch mit zum Teil recht alten gescannten Originalkarten, plädiere ich für das beibehalten des derzeitigen Systems.
Von Linkssystemen halte ich generell nicht viel (Das ist schon im Automobilbereich ein Graus).

Gruß Hans-Peter

[Carsten Hölscher]

@Roland: Dein Tool könnte im Fall 2.) natürlich rechnen wie es lustig ist, lediglich unsere einzige Schnittstelle (Datenübernahme/-übergabe) müßte Bescheid wissen und entsprechende Vorzeichen- und Koordinatenanpassungen vornehmen. Der normale Nutzer würde kaum etwas davon bemerken.

@Hans-Peter: Ich bin ja auch mit "meinem" System aufgewachen und bei dem Gedanken an ein Linkssystem könnte ich auch...


Irgendeinen Tod muß man hier sterben. Das sollte möglichst der sein, der für die allermeisten Nutzer das geringste Problem darstellt. Die Schnittstelle mit der KO-Transformation dann gerade zwischen 3D-Editor und Zusi zu legen, wo man i.d.R. öfter in beide Richtungen vergleichen möchte, scheint mir nicht so richtig überzeugend.
Wenn ich etwas nach alter Karte erstelle, dann ist das nur der Weg in eine Richtung, also ist das Problem nur noch halb so groß.
Evtl. kann man auch erstmal die Grobabsteckung in Zeichnungskoordinaten machen und dann irgendwann am Ende ins neue System transformieren.
Ich möchte gerne das Zusi-System (und dazu muß man wohl auch externe Editoren zählen) in sich einheitlich haben.

Carsten

[Roland Ziegler]

Willst Du denn wirklich allen Ernstes verlangen, dass Streckenbauer zukünftig die Winkel mit invertiertem Vorzeichen eingeben, im Widerspruch zu dem was man mal in der Schule gelernt hat?

Oder beim Streckenelement, egal wie der Vektor zukünftig gespeichert wird, die 2. Koordinate, mitten drin, als Höhe?

Das betrifft gerade auch Deinen Streckeneditor, nicht nur meine Tools.

[Carsten Hölscher]

ja - das ist eine einmalige Umstellung, man wird sich schnell dran gewöhnt haben. Eine andauernde Transformation zwischen den Editoren würde einen das ganze Zusi-Leben lang verfolgen.


Carsten

[Roland Ziegler]

schade.

[Carsten Hölscher]

@Roland: Wir beide sind bei der ganzen Thematik sicherlich irgendwie vorbelastet, ich dadurch dass ich Zusi zwangsläufig eher aus Programmierer-Sicht betrachte, bei Dir läßt sich eine "über das normale Maß hinausgehende" Beschäftigung mit der Landvermessung nicht leugnen
Wir beide hätten vermutlich mit keiner der Ansätze ernsthafte Schwierigkeiten. Ich vermute/hoffe, mit meinem Ansatz die für den math. durchschnittlich vorgebildeten Streckenbastler günstigste Lösung zu finden. Wenn sich ein paar der Anwender aus dieser Gruppe dazu äußern würden, wäre das auch nicht schlecht. Vielleicht sehe ich ja Probleme, die keine sind.
Das Problem, das ich meine zu sehen, wäre z.B. folgender Fall: Ich habe einen Bf, vielleicht in geom. etwas schwieriger Lage (Kurve o.ä.), und möchte in Canvas3D die passendende Bahnsteigüberdachung bauen. Man wir also wohl zwischen Canvas3D und Stecken-Eddi hin- und herpendeln und iterativ versuchen, das Dach an die Gleislage anzupassen. Ich würde ein Problem erwarten, wenn dabei im Canvas3D ein anderes Koordinaten-System gilt, ich also bei jeder Verschiebung/Verdrehung erst überlegen muß "Stecken-Eddi +y entspricht Canvas -x" usw.

Carsten

[Thomas Gabler]

Mich würde jetzt mal klipp und klar interessieren: Wie ist das bei 3D-Studio oder 3DCanvas? Welches Koordinatensystem haben die denn? Arbeiten Profi-Tools echt mit Linkssystemen? *schauder* Als Mathematiker biegen sich mir sämtliche Zehennägel auf...

Tom

[Carsten Hölscher]

nach meinem Kenntnisstand hat Canvas3D (nur) das Linkssystem.

Carsten

[Max Senft]

Hi,

nachdem ich jetz ausm Urlaub zurück bin, muss ich als kleiner unwissender Gymnasiast sagen, dass mir persönlich das Linkssystem lieber wäre. Ich hab mich zwar auch schon an das Zusi-System gewöhnt, bzw. kann mehr oder weniger was damit anfangen, aber ich persönlich lerne ja auch das Linkssystem, oder verschaukeln mich die Lehrer da in der Schule?
Carsten kennt ja meine Sicht in der Hinsicht schon seit längerem *g* und deswegen stimme ich auch für 2) ab.

Rolands Tools könnten ja intern rechnen wie sie wollen (von mir aus auch ein Diagonal-System *g* oder was weiß ich), letztendlich sollten aber für den 3D-Programmierer die 3D-Koordinaten rauskommen. So ist das ja schon seit ewigkeiten bei "einschlägigen" 3D-Shootern, evtl. auch, weil die Programmierer zu faul waren oder es einfach nicht wussten, ich selbst programmier ja auch das Links-System in meine Progrämmchen ein.

So long,
Max Senft

[Carsten Hölscher]

das System, das ich in der Schule gelernt habe, ging (auf die Tafel bezogen) x nach rechts, y nach oben, z in meine Richtung.
Das wäre dann ähnlich zum DX-System, aber immer noch ein Rechtssystem (bei DX liefe die z-Achse in die Tafel rein).
Das Schulsystem entspricht dem jetzigen Zusisystem, wenn ich quasi senkrecht von oben auf die Landschaft schau, und die Lok nach rechts fährt...

Carsten

[Max Senft]

Döööhm,

wie man's nimmt. Ich mein, wie denn jetz die einzelne Richtung heißt, kann man ja machen wie man will, man kann die jetzige z-Achse auch Gummibärchen-Achse, die jetzige x-Achse Hunde-Achse und die y-Achse ICE-Achse nennen... Is, wie man inner Schule schon gelernt hat nur ne Variable und somit variabel. *g*

Wenn ichs mir grad so überleg is in meinem aktuellen Projekt die Sache so, dass x nach rechts kleiner wird, z in den Monitor rein (und größer) und y nach oben und auch größer wird. Is ein bissele seltsam in OpenGL. (Außer ich hab nen Dreher in die Sache gebracht, was ich eher glaube, aber: Egal, jetz isses scho fest *g*)

Bye
Max Senft

[Thomas Gabler]

Wie wärs denn damit: Von mir aus ein Linkssystem auch für den Streckeneddi, aber um Konfusion mit Zusi 1/2 zu vermeiden, heißen die Dimensionen nicht x, y und z, sondern O(st), H(öhe) und N(ord).

Tom