Also ich habe mal ein Logisches Mathematikproblem

Und zwar möchte ich den Winkel zwischen zwei Geraden berechnen.
Ich habe dazu mal eine kleine Demo zur veranschaulichung gebastelt

http://shaddow89.sh.funpic.de/Unit1.rar

Rot, gruen, blau sind die Koordinatenachsen. Die beiden liegenden Geraden sind die Geraden, von denen ich den Differenzwinkel bestimmen will. Die bewegenden Geraden sollen die Ebenen verdeutlichen, in denen sie liegen.
Wenn ihr euch etwas im Raum bewegt, wird es sicher klar.


Nun zum Problem:
Klar im Ersten Moment denkt man sich: Winkelberechnung? Skalarprodukt und Zack. Ist in diesem Fall aber nicht so einfach. Ich möchte erreichen, dass ich eine gerade auf der anderen durch Drehung abbilden kann. Dabei kann ich um die X-Achse und die Y-Achse drehen. Wenn ich den Winkel per Skalarprodukt errechne müsste ich um den Normalenvektor der beiden Geraden drehen und das geht bei mir eben nicht.
Deswegen ist meine Idee die folgende Gewesen:

Ich errechne von gerade1 den Winkel zur X-Achse und den Winkel zur Y-Achse
Das selbe mach ich mit gerade2
Dann subtrahiere ich beide Xwinkel und beide YWinkel und muesste die beiden differenzwinkel bekommen.


Soviel zur Theorie.
Leider ist diese Idee schon im Ansatz stecken geblieben. Ich nahm mir ein Blatt papier und dachte mir:

Die Raumdiagonale eines Würfels (in meinem Beispiel Seitenlaenge 3 LE) müsste rein theoretisch von jeder Achse einen Winkel von 45° haben.
Der Wuerfel liegt bei mir genau im Koordinatenursprung
Also errechnete ich den Winkel einfach mal um die Probe aufs Exempel zu machen.

Also Raumdiagonale nahm ich also (3,3,3) an und als eine Seitendiagonale nahm ich (3,0,3).
Der Winkel dazwischen (so auch in der Demo erkenntlich, das sind die beiden ruhenden Geraden) müsste ja rein theoretisch 45° sein.
Die Rechnung (sowohl Manuel als auch durch Prozeduren im PC) ergibt aber immer 35°....

Und da weiss ich partout nicht warum das so ist? Lieg ich denn so derb falsch mit meiner Überlegnung?

Der Winkel ist auch nicht 45 grad, sondern cos^-1(Sqrt(2/3)) <= Sqrt(2/3)<>0.5*Sqrt(2). Warum? Knapp gesagt, weil die Würfeldiagonale Diagonale nicht mit den Seitendiagonalen (etwa (3;0;3) und (3;3;0)) in einer Ebene liegt. Man male sich die 3 in ein Bild. Noch hat man das Gefühl, daß die Diagonale mit den Seitendiags in einer Ebene liegt - das ist ein Fehler der Zeichnung! Verlässlich liegen die Seitendiagonalen in einer Ebene (2 Vektoren tun das immer, wenn sie nicht grad Vielfache sind). Also Verbinde ich die Spitzen miteinander - und habe wieder eine Seitendiagonale eingezeichnet, die natürlich auf einer Seite enlangläuft. Und dann sieht man der Zeichnung plötzlich an, daß die Würfeldiagonale nicht in der gleichen Ebene liegen kann. Es handelt sich also um ein Bild-Problem
Die Beschreibung des eigentlichen Problems habe ich jetzt aber nicht verstanden.

Ja das zu beschreiben ist echt nicht einfach ^^


Und ich glaub du hast die sache mit den Seitendiagonalen auch nich ganz so aufgefasst, wie ich das wollte ^^

Also dass die seitenhalbierenden und die raumdiagonale nicht in einer ebene liegen weiss ich selbst ^^

Aber EINE Seitenhalbierend und EINE Raumdiagonale liegen in EINER Ebene.

Wenn man Zahlenwerte nimmt:
Raumdiagonale = (3,3,3)
Seitenhalbierend = (3,0,3)

Dann ist die Seitenhalbierend praktisch das selbe wie die Raumdiagonale, nur dass sie senkrecht unter ihr liegt. Deshalb sollte ja da eigentlich zwischen den beiden der Winkel 45% sein, ich wüsste zumindest nicht Warum nicht.

Warum da aber nicht 45% rauskommt, weiss ich nicht ^^

Vllt versuchen wir, erstma das zu klaeren, ehe ich versuche den rest nochma genau zu erklaeren

Okay. Dann betrachten wir die Situation eben auf der Ebene in der eine Seitenhalbierenden und die Diagonale liegt. Die Diagonale hat Länge sqrt(3^2*3) = 3*sqrt(3). Die Seitenhalbierende hat Länge sqrt(3^2+3^2)=3*sqrt(2). Die die beiden Verbindenden Vektoren Verbindende Strecke ist eine der Kanten des Würfels, hat also Länge 3 und steht auf der Seitenhalbierenden Senkrecht. Zeichne die Situation als Dreieck. Kannst du ein Dreieck mit den Geforderten längen und Winkeln zeichnen? Nein, weil die Längen nach Pythagoras nicht zusammenpassen wollen Die Seitenhalbierende müsste nämlich die Gleiche länge haben, wie die Kantenlänge - also 3. Genau dann würde nämlich der Winkel 45 grad werden. Dann haben wir aber nur noch andere Längen im Dreieck, abgesehen von der Seitenlänge des Würfels - es passt also gar nix mehr. Der Winkel ist also nach Pythagoras verlässlich nicht 45 Grad. Mehr fällt mir aber momentan auch nicht ein, wie man einfach vor Augen führen kann, daß die von dir gedachte 45° Eigenschaft nicht zutrifft. (Wenn Du meine Ausführungen nicht verstanden hast schreib das ruhig, dann scanne ich Dir die Zeichnungen dazu ein.). So super schön wie man häufig glaubt sind Würfel halt leider doch nicht Kugeln sind da einfacher zu handhaben

Okay du hast mich überzeugt ^^ (wenn gleich ich einer Zeichnung nicht abgeneigt wäre )

Nun versuche ich einfach nochma das Prob zu schildern:

Ich habe zwei Geraden (in der Demo die still liegenden). In der Demo wurden je noch eine Ebene aufgezeigt, um das Erkennen der Geraden im Raum zu erleichtern (die Ebenen habe ich mal versucht durch die sich bewegenden Geraden zu verdeutlichen)

So den Winkel zwischen den beiden Geraden zu errechnen is ja nun nich so wild. Nun ist es aber mein Ziel, die eine gerade auf der anderen abzubilden. Mithilfe des Winkels, den ich errechnen kann, ginge das natuerlich. Allerdings bräuchte ich dann noch einen Rotationsvektor und der müsste in dem Fall ja ein Normalenvektor zwischen den beiden Geraden sein (kann sein, dass ich mich da grad taeusche, aber wichtig ist es eh nicht ^^)

Auf jedenfall kann ich bei mir keinen anderen Vektor ausser (1,0,0) und (0,1,0) als Rotationsvektor nutzen. Also muss ich praktisch Gerade1 auf Gerade2 durch eine Rotation um die XAchse und durch eine Rotation um die YAchse abbilden.


Bis hierher denk ich, ist alles recht sinnig und ich hoffe da liege ich richtig ^^
Jetzt wirds wackelig und evtl sind die Gedankengaenge jetzt auch derb falsch:

Ich errechne zwischen Gerade1 und der x-z-Ebene einen Winkel. Dieser Winkel gibt dann praktisch an, wie weit die Gerade in Y-Richtung geneigt wurde. Würde man jetzt die Gerade um diesen Winkel*(-1) drehen, müsste sie genau auf der x-z-Ebene liegen. (das nur mal die Theorie nebenbei ^^)
Dann errechne ich noch den Winkel zwischen der Gerade1 und der y-z-Ebene und bekomme den Winkel, um den die Gerade in X-Richtung geneigt wurde.

Jetzt könnte ich (REEEEIN Theoretisch) eine Gerade mit dem RichtungsVektor (1,0,0) mithilfe der beiden Drehungen genau auf die Gerade1 projezieren.

Nun mache ich oben genannte Rechnungen nochmal komplett mit Gerade2.
Um nun Gerade1 auf Gerade2 abzubilden, müsste ich den XWinkel von Gerade1 vom XWinkel der Gerade2 subtrahieren und genauso den YWinkel d. Gerade1 von YWinkel d. Gerade2.

Mit hilfe der beiden entstandenen Differenzwinkel sollte ich nun Gerade1 auf Gerade2 durch die beiden drehungen projezieren können.



So entweder meine programmiertechnische Umsetzung ist falsch, oder die Theorie ist schon falsch.
Deswegen würd ich gern ma wissen, ob denn wenigstens die Theorie stimmt ^^

Warum nicht?

Weil ich bei mir bei jedem Rendervorgang um die X-Achse und um die Y-Achse drehe und das sind nunmal diese beiden Vektoren. Andernfalls muesste ich immer noch einen zusaetzlichen Vektor zwischenspeichern, abfragen, ob er gespeichert wurde, und wenn ja, dann noch drehen.... und dann geht das nu bei einer Drehung

Wenn ich eine Gerade1 auf Gerade2 und die auf Gerade3 abbilden will, muss ich schon zwei zusaetzliche Winkel und zwei zusaetzliche Vektoren speicher usw usw

Deswegen will ichs in X und Y zerlegen

Vielleicht steh ich grade auf dem Schlauch aber musst Du nicht eigentlich immer nur den nächsten Winkel wissen, wenn Du eine Gerade1 einer Geraden 2 annäherst? Du musst Dir dabei gar nichts merken (OK, die aktuellen Richtungsvektoren der beiden Geraden schon), bloss immer den Winkel zwischen den Geraden messen und Dich annähern. Diese Lösung wäre viel einfacher, deshalb habe ich gefragt, ob Deine Programmvorgaben so sind oder ob Du auch auf eine direkte Drehung umsteigen willst. Die Drehung um mehrere Achsen stelle ich mir höllisch kompliziert vor.

Wenn Du nur X- und Y-Drehungen machen darfst, kannst Du nicht alle angestrebten Ziele erreichen. Dazu braucht man auch eine Z-Drehung, wenn man im gleichen Bezugssystem bleiben möchte. Drehungen einer Gerade sind noch nicht prekär. Komplizierter wird es erst, wenn Du bei einem Modell oben und unten unterscheiden willst, denn die Lösung einer simplen Drehung ist zweideutig: ich hatte das Problem bei einem Modell, da war die Drehung grundsätzlich richtig, leider stand das Modell nach der Drehung aber auf dem Kopf.
Traude

Also da ich ja auch vor dem Rendern immer nur um die X-Achse und die Y-Achse drehe (wenn man noch um die zachse dreht, wird das ziemlich unkomfortabel mit der Steuerung), reicht das im Grunde völlig aus, um ein Objekt zu positionieren.

Ich Poste hier ja nur die Idee, in der hOffnung, dass mir wer sagt: Absoluter Bullshit oder eben: müsste rein theoretisch möglich sein.

So würd ich zb den Winkel ausrechnen für eine Gerade in Bezug auf x und yachse:


Da bekomm ich eben den Cos raus und errehcne dann eben noch den Arccos. Leider kommt da nur schrott raus, deswegen frag ich mich jetz, ob das der Theorie nach überhaupt möglich ist. Mein matheprof meint, es ginge, aber ich bin nich ganz sicher, ob er das Problem verstanden hat ^^

Wenn ich Deine Formeln anseh:
Du setzt einfach eine Komponente des Richtungs-Vektors der Geraden auf Null und projizierst ihn damit auf eine Ebene und erhältst einen Projektionsvektor. Sollte funktionieren. Weiters benutzt Du das Skalarprodukt, um den Winkel zwischen den beiden Vektoren auszurechnen. Sollte eigentlich auch funktionieren. Wenn ich mich nicht irre, ist dabei nur einer der beiden Vektoren ein Einheitsvektor, es müssen aber beide Vektoren Einheitsvektoren sein (das ist vermutlich der Fehler).

Was Du bei diesen Formeln rauskriegst, ist der Winkel zwischen der Gerade und dem auf die XZ- bzw. YZ-Ebene projizierten Vektor, das kann ich bestätigen.


Kontrollrechnung:

Annahme Richtungsvektor der Gerade = (1 / 1 / 1), der Einheitsvektor ist (0,577 / 0,577 / 0,577)

Projektion XZ = (1 / 0 / 1), Einheitsvektor ist (0,707 / 0 / 0,707)
Projektion YZ = (0 / 1 / 1), Einheitsvektor ist (0 / 0,707 / 0,707)

Cos Winkel Richtungsvektor/Proj XZ = Skalarprodukt der Einheitsvektoren =

= (0,577 / 0,577 / 0,577) Dot (0,707 / 0 / 0,707) = 0,816


*************************************
von 0,816 der ArcCos*180/Pi = 35,26 Grad
*************************************

für den Winkel Vektor/Proj YZ kommt das Gleiche raus.

Ich steig langsam echt nimmer durch, wenn man da zu lang drueber sitzt, leidet die Vorstellunsgkraft enorm...



Wenn ich mir das jetz ma ueberlege:
Translation(3,5,2)
Center(0,1,0);

Dann ist v1 der Richtungsvektor zwischen den beiden, und zwar von Translation auf Center ausgerichtet.
Jetzt rechne ich jetzweils den Neigungswinkel zur x-z-Ebene und zur y-z-Ebene.

Jetzt nehme ich ma an, mein momentaner Blick ist:
Rotation[0] := 30;
Rotation[1] := 50;

Wenn ich das jetz ma kurz durchrechne, komm ich auf:
nX := 0.6695, das entspricht so 48%
nY := 0.8305, das entspricht so 33.8%

So nun kenne ich ja meine momentanen Winkel.
Ich setze also einfach meine Rotation auf die NX und NY. Er dreht sich! nur nicht richtig ^^ Er soll sich ja in diesem Falle bei jedweder Bewegung (die in meinem Fall durch einen Pfad beschrieben wird) zum Punkt (0,1,0) drehen.



EDIT:
Etwas was mich total verwirrt:
Wo ist der Unterschied zwischen

und


Nutze ich ersteres, wird alles schön gezeichnet. Nutze ich zweiteres bleibt der gesamte Bildschirm schwarz.

So im Grunde funkt es bei mir alles schon recht gut. Meine Translation realisiere ich zur Zeit so:


Meine Rotation:


Ich habe hier mal eine kleine Demo gemacht, da Funpic leider nur sehr begrenzte Datenuploads erlaubt, musste ich die Datei splitten:

http://shaddow89.sh.funpic.de/Demo.part1.rar
http://shaddow89.sh.funpic.de/Demo.part2.rar

Dadrin sind nun zwei Demos, bei beiden wird ein und der selbe Bewegungspfad fuer die Camera genutzt
Allerdings unterscheidet sich der Referenzpunkt. Beim ersten Mal ist der Punkt, auf den geblickt wird (0,0,0) und beim zweiten Mal (0,1,0)

Wenn ihr euch die Demos anseht, sehr ihr, wo die Rotation auf einmal springt. Ich denke mal, dass ich im Quellcode der ROtation irgendwo einen Fehler habe, dieser Sprung tritt immer bei einem überschreiten von y=1 oder y=-1 auf..

Habe nun schon ne Menge sachen durchprobiert und irgendwie funkt nix ^^ wäre fuer nen Denkanstoss sehr dankbar