Posts by moevenbaer

    Und eben habe ich mal versucht die Positionsdaten in die Block-Koordinaten umzurechnen. Dabei bin ich auf ein kleines "Design-Problem" gestoßen. Denn ich brauche ja auch in den Objekt-Funktionen die Offset-Daten. Jetzt geben die Funktionen nicht nur Texte zurück, sondern eine Tabelle mit den Texten. Und dieser Tabelle kann ich ja dann die Offset-Daten als Einträge mitgeben. Die info-Funktion erzeugt die Tabelle bt={offsetx=999.999,offsety=999.999,info="Info-Text-Zeilen"}. Und die Objekt-Textblöcke werden dann durch bt[#bt+1]="Objekt-Text-Zeilen" angehängt.

    Der neue Entwurf sieht dann so aus:

    Und in den letzten Tagen habe ich mir mal drei Lua-Module geschrieben, die mich auf meinem Weg wieder ein Stück weiter bringen:

    Modul "matrix" mit verschiedenen Matrix-Funktionen

    Modul "rotmat" mit Funktionn zur Ermittlung von Rotationsmatrizen

    Modul "eepblocks" mit dem Untermodul "immo" mit Funktionen zur Texterstellung für Blockdateien (als erster, noch ungetesteter Entwurf)

    Schlussendlich sollen dann die mit Hilfe der Text-Funktionen entstehenden Texte in eine Textdatei als Blockdatei ausgegeben werden. Dazu müssen dann die Wunschpositionsdaten und Wunschrotationsdaten bereitgestellt werden. Und ich habe eben festgestellt, dass die Positionsdaten noch in die Block-Koordinaten umgerechnet werden müssen

    die EEP eigene Funktion zum setzen von Immobilien an Fahrwegen

    Das ist neu für mich. Kannst du oder wer anders mir auf den Weg helfen? Im Online-Handbuch Kapitel 6 habe ich da nichts gesehen oder vielleicht auch übersehen?

    Das Funktioniert auch ganz gut ohne mir mein Hirn zu verbiegen :-)

    :af_1::an_1::co_k: Ich mag mein krummes Gehirn ... und ich lasse es sich ganz gerne winden ... :co_k::aq_1::aa_1:

    Anmerkungen zu Theorie und Mathematik darin

    Es steckt eine Menge Matrix-Mathematik drin. Für die Matrix-Multiplikation gibt es das so genannte "Falksche Schema", das erklärt anschaulich die Werteermittlung bei der Matrixmultiplikation. Und etwas über Winkelfunktionen steckt auch drin in alledem einschließlich der Zusammenhänge zwischen Bogenlänge (Kreisbogen), Grad- und Bogenmaße. Wer da Fragen hat, darf mich gerne auch per PM oder hier befragen.

    Mit Hilfe einer Tabellenkalkulation habe ich mal die Rotation um X mit 60° und Y mit 30° ausrechnenlassen und mit den Werten in der Blockdatei verglichen, einmal unskaliert und einmal so skaliert wie im vorherigen Beitrag:

    Hier ein Bild der Tabellenwerte:

    Die Rotationswerte werden also über Ryx = Ry * Rx errechnet. Die Reihenfolge ist dabei wichtig, weil die Martix-Multiplikation nicht kommutativ ist. Beim normalen Rechnen kann man die Reihenfolge der Faktoren eines Produktes vertauschen, bei der Matrix-Multiplikation nicht, weil die Ergebnisse meistens unterschiedlich sind.


    Die Reihenfolge der Matrix-Multiplikation oben läßßt die Vermutung zu, das für alle drei Rotationen zusammen die Werte über Rzyx = Rz * Ry *Rx ermittelt werden.

    Ein Test dazu folgt noch. Wenn der "positiv" verläuft, lassen sich aus den Wunsch- bzw. Zielwerten die Werte für die Block-Datei softwaretechnisch berechnen. Und damit lässt sich die Blockdatei als Textdatei erstellen.

    Und wie EEP daraus die Werte zurück ermittelt, kann mir ja egal sein. Mein Ziel war ja, einen Block per Script erstellen. Und dem Ziel bin ich näher gekommen. :co_k::aq_1:

    Die gleiche Szene, nur sind die Objekte zusätzlich skaliert Sx=0.3, Sy=0.5 und Sz=0.7. Das ergibt den folgenden Block:

    Man erkennt, dass die Werte in den Zeilen mit der Skalierung multipliziert sind.

    Und die Info-Daten sind immer die eines Quaders, der eine "Bounding Box" für die Objektgruppe ist. Auf Grund der veränderten Rotationen "ragen" die Objekte unterschiedlich weit in den Raum. Deshalb die verschiedenen Info-Werte.


    Dabei hat sich bei mir sofort die Frage ergeben, wie bekommt man die Skalierung wieder heraus, wenn sich Werte aus dem Intervall [0..1] ergeben, die gültige Sinus- bzw. Cosinuswerte sein können? Wieder eine geöffnete Tür, hinter der sich eine neue Tür befindet ... :co_k:


    Und dann frage ich mich auch, warum werden wohl die Daten so "verschlüsselt" und "verpackt" gespeichert? Meine erste Vermutung: Das stammt noch aus der Zeit, wo Speicher sehr knapp war. Allerdings folgt daraus auch, dass deutlich mehr beim Einfügen gerechnet werden muss (und wenn intern die Daten ähnlich gespeichert werden auch im laufenden Betrieb?).


    Und dann ist ja noch die Rotation über mehrere Achsen zu betrachten ... Die nächste Tür ... :co_k::aa_1:

    Nun habe ich die Idee mit der Rotationsmatrix ohne Skalierung doch ein wenig näher untersucht. Dabei bin ich auf ein nun von mir schon fast erwartetes Ergebnis gestoßen.

    Hier habe ich mal drei Objekte als Block gespeichert. Position mit y=z=0, x=0,10,20, Rotation je um 30° auf einer Achse (xyz). Mit den Werten sin(30°) =0.5 und cos(30°)=0.866025. Die drei Rotationsmatrizen ehen wie folgt aus:

    Wenn ich die Werte ansehe, sieht es auf den ersten Blick wieder gut aus. Aber irgendwie passen die Vorzeichen nicht, oder doch? Zeilenweise passen sie nicht, aber spaltenweise. Mathematisch gesehen sind die Ergebnismatriten transponiert (gespiegelt an der Matrix-Diagonalen r11, r22 bis r33).


    Nächster Schritt ist nun zu schauen, wie die Skalierung da rein passt ...

    Das präzise Setzen von Immobilien (hier Pfeilern für einen Fahrweg) ist eine ziemliche Pfriemelei. So habe ich mir gedacht, doch mal zu schauen, was sich da automatisieren lässt. So habe ich mir mal eine Blockdatei vorgenommen und mich zuerst erschrocken. denn im Format 15 sind da Parameter drin, die sich auf den ersten und einige auch auf weitere blicke nicht gleich erschließen. Aber beim Format 3, in dem reine Immobilienblöcke gespeichert werden bin ich fündig geworden.

    Ich habe hier mal einen Ausschnitt aus dieser Datei eingefügt.

    Der Block enthält 3x3 Säulen, die jeweils aus drei Pfeilern und je einer Kappe bestehen. Der Pfeilerabstand ist jeweils in X- und Y-Richtung 12m, die obenern Pfeiler je in einer Höhe von 12.4m bzw. 24.8m und die Kappe bei 36.3m. Die Kappe ist ein skalierter Pfeiler mit Sx=Sy=0.65 und Sz=0.1. (Abbildung aus Screenshot)(Block-Code selbst expoprtiert)

    Die "WorldPos" ist die Position in der kleinen Blockwelt, wobei die scheinbar nur positive Koordinaten kennt, also die Positive Ecke des 3D-Koordinatensystems.

    Die Welt ist 3000x3000 groß, was man dem Info-Abschnitt entnehmen kann, warum da 2999 steht und -3000? Vermutlich software-technisch bedingt.

    Und der Offset liegt in der Mitte. Das ist in der Sprache von Blender der Origin des Blockobjektes. Wenn man beim Einfügen X und Y vorgibt, liegt diese Offset genau da. Name und Layer sind offensichtlich.

    Die Werte sind cm-Werte (z.B. 36.3 wird zu 3630). Ach ja, die 300 deutet darauf hin, dass für die Säule ein Durchmesser von 6m ermittelt wurde. Die Breite/Tiefe des Blocks errechnet sich so: 3000 = 300+1200+1200+300

    Die drei andern Eintragungen scheinen auf ein Dreibein hinzuweisen, oder? Nicht ganz. Die "Dreibein"-Daten enthalten die Skalierung. Das sieht ja etwas nach einer 3D-Transformationsmatrix für das Einzelobjekt aus.

    Für die mathematisch Interessierten: Die Transformationsmatrix beschreibt die räumlichen Transformationen (z.B. Lage- und Größenveränderungen) eines Objektes in einem 3D-Raum.

    Ob das tatsächlich eine ist (World=Welt deutet auch drauf hin), will ich hier nicht weiter untersuchen.


    Das ist mein Ansatz dazu. Also der Dateiaufbau scheint kein Problem zu sein. So wird das nächste Thema für mich sein, die Koordinaten zu errechnen. Wenn ich da weiter gekommen bin, hier etwas mehr ... :co_k:

    Vielleicht entwickele ich erst mal eine Funktion für die einzelnen Objekte ... :aq_1:

    Übrigens klappt das mit den Fahrwegen der Wendel super. Aber da die gestapelten Träger an der Seite zu positionieren ist Pfriemelei.
    Da probiere ich mal, ein Script zu erstellen, dass einen Block zur Wendel erzeugt, den ich dann einfügen kann. Eine Tabelle zur Errechnung der Daten habe ich mir schon mal zusammengestellt. Daraus eine passende csv-Datei erzeugen und dann durch das Script verarbeiten lassen ist eine Variante. Aber warum soll das Script nicht auch gleich rechnen. Mal sehen, ob ich das schaffe. :co_k::aq_1:

    Leider sind meine Konstrukteurserfahrungen so etwa 0.01 von 100. :aa_1: Aber bei den Dockingpunkten kam mir eine Idee. Man kann ja das docke mit und ohne Ausrichtung im Menu einstellen. Wenn nun ein Spline als "zusätzliches" Objekt, dass sich alle zwei drei Splines widerholt, einen Dockingpunkt erhält. Und an passender Stelle dann auch das Tragwerk, so könnte man doch erst den/die Fahrwege frei schebend bauen und dann die Tragwerke andocken. Hat man den Spline waagerecht und dockt mit Ausrichtung an, so müsste die senkrechte Ausrichtung des Tragwerkes doch automatisch da sein. Und wenn das Tragwerk grundsätzlich ersteinmal senkrecht steht, kann es doch ohne Ausrichtung senkrecht unter den Dockkingpunkt gesetzt werden bei der Andockvariante ohne Ausrichtung?


    Und eben als ich das schreibe, fällt mir auf, dass das wohl erstmal nur für gerade Fahrwegstücke so geht.

    Allerdings habe ich festgestellt, dass das scheinbar garnicht soo simpel ist, wenn man zwischendurch noch ein paar Gleise mit niedrigerer ID gelöscht hat.

    Das sagt mir nun, dass eine ID nur ein sehr temporäres Ident ist. Mir fällt dazu dann doch keine wirkliche Lösung ein. :aw_1:


    Und daraus entsteht für mich die Frage: Kann man eigentlich eine Gleis-ID setzen ohne in die Dateidaten der .anl3 einzugreifen?

    Beim Bauen ist mir eine sicherlich nicht wichtige, aber vielleicht für die LUA-Menschen mögliche Fehlerquelle aufgefallen.

    Und dann ist mir dazu auch noch eine kleine Denksportaufgabe eingefallen.

    Ausgangssituation:

    Beim Verlegen von Fahrwegen vergibt EEP eine laufende ID und benutzt eventuell freigewordene Lücken für den nächsten Spline. Soweit so gut.

    Wenn man die Objekt- bzw. Gleiseigenschaften ändert, passiert da nichts überraschendes.:co_k:

    ID-Änderung:

    Aber wenn ich im Objektmenu das Gleis "umstelle" zwischen 2-Wege-, 3-Wege-Weiche, Endgleis bzw. Normalgleis, wird auch die ID mit verändert. Und wenn irgendwo in einem LUA-Script eine Gleis-ID gespeichert wurde für eine spätere Verwendung und man zwischendurch dieses Gleis wie eben beschrieben "umstellt", erlebt man vielleicht eine "Überraschung".:aq_1:

    Denksportaufgabe:

    Eine Gleis soll nach dem "Umstellen" wieder die gleiche ID haben.

    Viel Spaß beim Knobeln. Und ist leichter als man auf den ersten Blick denkt.:ba_1:

    Ein wesentlicher Aspekt war, dass wohl die Gleislänge über Winkel und Kreisbogen aus der Draufsicht ermittelt werden. Wenn man den Zylindermantel aber geometrisch abwickelt erhält man ein rechtwinkliges Dreieck und müsste für die wahre Länge den Pythagoras anwenden mit der EEP-Länge und den anteiligen Höhenunterschied als Kathetenlängen. Aber egal. Vielleicht ist das alles in einer der nächsten Versioen nicht mehr nötig. :co_k:

    Mein Ausgangsziel war die Erstellung einer präzisen mehrgleisigen Wendel. Dazu dachte ich mir, dass der Helix-Typ genau der richtige Typ ist.

    Um den Verlauf einer Helix (Wendel, Schraubenlinie) in EEP zu beschreiben, gibt es unter dem Typ Helix zwei Wertegruppen:

    1. WLSGZ: Winkel Wxy [°], Länge Lxy [m], Steigung SGZ [°]
    2. WRSMZ: Winkel Wxy [°], Radius Rxy [°], Steigung SMZ [m]

    Ich erstellte mir einen Helixbogen und wollte ihn nach vorne fortsetzen. Doch das hat nicht immer präzise geklappt. Meist war die vorgegeben Höhe nicht sauber oder es wurde sogar eine Neigung eingebaut. Manchmal hat es aber geklappt. Also konnte es eigentlich nur an der Reihefolge liegen, wie die Daten eingetragen werden. Nach einigen Experimenten habe ich einen Weg gefunden, der immer sauber funktionierte.

    Ja, ich weiß, es ist nicht wirklich wichtig dieses Thema, aber doch wollte ich zeigen, dass EEP auch präzise kann, zu mindest an einigen Stellen. Und das ist mir gelungen.

    Ziel ist die Erstellung einer Gleiswendel mit dem (Zylinder)-Radius RXY, den Wendelstücken mit dem Wendel-Winkel WXY und einer Seigung um SMZ Meter beieine 360°-Wendel-Windung. Für alle beteiligten Gleisbögen ist die Neigung Null. Der Gleisabstand soll 4.50m sein.


    Beispiele:


    Gleisgruppe

    Wendel-Winkel [°]

    Wendel-Radius [m]

    360°-Steigung [m]

    Beispiel A: eingleisig (Helix-Radius 200m)

    Gleis A1

    30

    200.000

    32.000

    Beispiel B: zweigleisig (Helix-Radius 150m)

    Gleis B1

    30

    147.750

    18.000

    Gleis B2

    30

    152.250

    18.000

    Beispiel C: dreigleisig (Helix-Radius 250m)

    Gleis C1

    15

    245.500

    40.000

    Gleis C2

    15

    250.000

    40.000

    Gleis C3

    15

    254.500

    40.000

    Beispiel D: viergleisig (Helix-Radius 300m)

    Gleis D1

    15

    293.250

    24.000

    Gleis D2

    15

    297.750

    24.000

    Gleis D3

    15

    302.250

    24.000

    Gleis D4

    15

    306.750

    24.000


    Nun der Ablauf:

    1. Ein Gleisstück an die gewünschte Stelle in der gewünschten Ausgangshöhe platzieren.
    2. In den Einstellungen den Kurventyp Helix auswählen
    3. Als Charakteristik Winkel + Radius + Steigung(m) einstellen
    4. Die gewünschten drei Charakteristik-Werte eintragen
    5. Umschalten in die andere Charakteristik und die Steigung(°) der Charakteristik in die Steigung der Startposition kopieren
    6. Zurück schalten in die Charakteristik Winkel + Radius + Steigung(m) und die durch die Umrechnungen leider veränderte Steigung(m) korrigieren
    7. Gleisstück speichern.

    Jetzt funktioniert das Anfügen nach vorne präziese und die prinzipielle Charakteristik bleibt dabei erhalten (bis auf eine Drehung und die Z-Höhe).:co_k:

    Vielleicht ist der Tip hilfreich bei „mystischen“ Helix-Problemen. :aq_1: