• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Problem HUD-Child-Prims zu drehen

JointVenture Resident

Aktiver Nutzer
Warum funktioniert mein script nicht? Und ist das überhaupt richtig geschrieben?
Das script lässt sich speichern, also gibt keine Fehlermeldung.
Code:
//Es passiert nichts!
list links = ["rotator","buttons","rahmen"];//Namen der verlinkten Prims überhaupt benötigt? , wenn:
integer Linked(string Needle) {
    while(--Prims) if(llGetLinkName(Prims) == Needle) return Prims;//
    return 0;
}
//Globale Var
integer dreh = TRUE;
integer rotationsButtons;
integer Buttons;
integer Rahmen;
///
integer Prims; //??? als global richtig?

Dreh_funktion()//??? funktioniert nicht!
{
    llSay(0,(string)Prims);//Test. geht nicht
    dreh = !dreh;
    rotation prim_rot = llEuler2Rot(<16.4, 0.0, 0.0> * DEG_TO_RAD); // rotation zu dem nächsten Button ca 16.4°
    list get_child_rot = llGetLinkPrimitiveParams(rotationsButtons, [PRIM_ROT_LOCAL,
    PRIM_LINK_TARGET, Buttons, PRIM_ROT_LOCAL,
    PRIM_LINK_TARGET,  Rahmen, PRIM_ROT_LOCAL]);
    list params;
    integer i = 0;
    for(i; i < Prims; ++i) // integer Prims ??
    {
        if(i)
        {
            params += [PRIM_LINK_TARGET, i + Prims];  // Linknummern
            if (dreh)
            {
                params += [PRIM_ROT_LOCAL, prim_rot * llList2Rot(get_child_rot, i)]; // Dreht...
            }
            else
            {
                params += [PRIM_ROT_LOCAL, llList2Rot(get_child_rot, i) / prim_rot]; // ...oder ander herum.
            }
        }
    }
    llSetLinkPrimitiveParams(Prims, params);
}

default
{
    state_entry()
    {
        integer Prims = llGetNumberOfPrims()+1; //Nummern der Prims
        rotationsButtons = Linked("rotator");
        Buttons = Linked("buttons");
        Rahmen = Linked("rahmen");
    }
    touch_start(integer num)
    {
        llSay(0,"klick");//sagt nichts!
        Dreh_funktion();
    }
}

Geklaubt von: http://community.secondlife.com/t5/LSL-Scripting/Basic-HUD-Local-Rotation-problems/td-p/1465401
 
Da sind ein paar Fehler drin:

1. In state_entry: "Prims" muss global sein. (So, wie das Script aufgebaut ist). In state entry legst du
aber mit der typ-zuweisung "integer" eine lokale Variable an. Also nimm einfach das "integer" weg.

2. Der Einsatz der Variable "Prims" ist umständlich. In der Funktion "Linked" wird sie heruntergezählt. Mit der Folge, das sie für die nächsten Einsätze unbrauchbar ist. Ich würde eine unabhängige Var. anlegen.
Um aber bei dem Verfahren hier zu bleiben, musst du im state_entry vor jedem neuen Aufruf der Funktion "Linked" "Prims" neu initialisieren.

3. In der Funktion "Dreh_funktion" sagst du:

params += [PRIM_LINK_TARGET, i + Prims];

Das ist falsch. Richtig ist, statt "Prims" eine 1 zu addieren.

Also:

params += [PRIM_LINK_TARGET, i + 1];
 
super, Du hast es gelöst! vielen Dank.
..nur die rotation ist nicht so wie erwartet :/

Start-rotation des child ist <180, 70, 90>
nach dem ersten mal klicken <180, 86.4, 90> // der prim ist richtig gedreht aber die rotation versteh ich jetzt überhaupt nicht
und zweiter klick <163.6, 70, 90> //
 
Zuletzt bearbeitet:
super, Du hast es gelöst! vielen Dank.
..nur die rotation ist nicht so wie erwartet :/

Start-rotation des child ist <180, 70, 90>
nach dem ersten mal klicken <180, 86.4, 90> // der prim ist richtig gedreht aber die rotation versteh ich jetzt überhaupt nicht
und zweiter klick <163.6, 70, 90> //

Euler-Rotationen sind nicht eindeutig: eine Rotation kann über mehrere Euler-Rotationen dargestellt werden, so dass es zu einer Rotation durchaus mehrere Möglichkeiten gibt, diese in Euler-Notation darzustellen.
<180,86.4,90> bedeutet ja, dass das Objekt um 90° um z, dann um 86.4° um y und dann um 180° um x gedreht wird. Die selbe Drehung würde man aber auch erhalten, wenn man das Objekt erst um 90° um z, dann um 70° um y und dann um 196.4° um x dreht. (Die Reihenfolge der Drehungen in LSL ist z-y-x) Deswegen ist die Euler-Rotation <180,86.4,90> auch identisch mit <196.4,70,90>.
 
Zu Euler Rotationen gibt es auch ein schönes Video, alt aber gut:
(...)

Genau dieses Gimbal Lock Dingens ist der Grund, warum man bei internen Rotationsberechnungen usw. wann immer möglich über Quaternionen arbeiten sollte und eben nicht mit Eulerwinkeln.
Quaternionen sind 4-Dimensional (sie bestehen aus einer realen + 3 imaginären Zahlen, im Gegensatz zu Eulervektoren, die nur aus 3 reellen Zahlen bestehen; Details sprengen aber den Rahmen), dadurch kann jede Drehung im 3D-Raum auch eindeutig beschrieben werden und die Achsen können nicht "ineinander fallen".
 
Quaternionen nutzt ja auch Star Trek, um den Weg zu finden ;)

Ohne Quaternionen könntest du nicht mal deinen PC einschalten: ohne Quaternionen keine Maxwellschen Gleichungen, und ohne die weiß das kleine Arbeiter-Elektron nicht, wo es mit den Buchstaben aus der Tastatur hin muss, damit die auf dem Bildschirm erscheinen. ;-)

Und soo kompliziert sind die rot Typen in SL nicht (rot sind ja Quaternionen...), man muss nur auf die Reihenfolge in der Berechnung und die überhaupt zulässigen Berechnungen bei Rotationen achten. Den Rest übernehmen dann die entsprechenden LSL Funktionen.
 
Zuletzt bearbeitet:
Ist doch ein Attachment, probiere es mal so: <x,y,z>*llGetLocalRot()

Das funtioniert:
rotation prim_rot = <0.0, 0.0, 16.4, 0>; // 4 Werte! 3 ergaben immer Fehler.
<180, 290, 270>
und <180, 70, 270> // sind aber keine 16.4°
Eigendlich sollte der Child-Prim nur um die y-Achse drehen, das ganze ist außerordentlich verwirrend und deprimierend.
Denn mache ich mich mal auf die suche nach dem richtigen Winkel. :bahnhof
Danke Euch allen

Ps:Ich hasse scripten -.-
 
Das funtioniert:
rotation prim_rot = <0.0, 0.0, 16.4, 0>; // 4 Werte! 3 ergaben immer Fehler.

(...)

Ein normaler 3D Vektor ergibt deswegen einen Fehler, weil Rotationen in LSL über Quaternionen dargestellt werden. Und Quaternionen bestehen aus (wie der Name schon andeutet) 4 Zahlen. D.h. wenn man dem Variablen-Typ rot eben nur 3 Parameter übergibt, dann merkt der Compiler, dass da was nicht stimmt.

Der Unterschied zwischen 3D-Vektoren und Quaternionen ist dabei vor allem, dass bei Euler-Vektoren 3 reelle Zahlen für die 3 Winkel im Raum angegeben werden.
Bei Quaternionen verlässt man mehr oder weniger den 3D-Raum bzw. erweitert ihn ein wenig, man hat dann eine relle Zahl und eben 3 imaginäre bzw. komplexe Zahlen.
Und da das Ding aus einer rellen und 3 komplexen Zahlen besteht sind eben auch die 4 Zahlen keine einfachen Winkel, das sind mehr oder weniger "aus den Winkeln berechnete komplexe Zahlen + ein Skalar".

[Falls du noch nie mit komplexen Zahlen zu tun hattest: Die liegen im Prinzip nicht nur irgendwo auf der bekannten Zahlengeraden, sondern zusätzlich noch über oder unter der Zahlenhgeraden, entsprechend dem "imaginären Anteil". Das macht aus den "eindimensionalen Zahlen" eben mehr oder weniger "zweidimensionale Zahlen".
Vorstellen kann man sich das ganze nicht wirklich, aber dafür kann man damit eben Gleichungen wie x² = -1 lösen bzw. derartiges in Berechnungen verwenden. Hier:
http://wiki.secondlife.com/wiki/Quaternion ist das Quaternion in SL (wenn auch leider auf Englisch) ganz gut erklärt, so dass man es auch ohne zwei bis drei Semester Höhere Mathematik an einer Uni/FH verstehen kann, Gymnasiale Oberstufe ist das allerdings trotzdem: mit Vektoren, Skalaren und Matrizen sollte man klein bisschen fit sein.
Hier: http://de.wikipedia.org/wiki/Quaternionen sind Quaternionen sehr ausführlich erklärt, allerdings wohl ohne zumindest Technische Mathe and der FH/höhere Mathe für Ingenieure oder gar Analysis und Algebra an der Uni gehabt zu haben kaum verständlich leider.]

Ohne aber jetzt zu sehr auf die Details einzugehen muss man daher einfach beachten, dass eben für Rotationen eben nicht die normalen, gewohnten Rechenregeln gelten.
Rotationen sind bisschen Speziell durch die imaginären Anteile und man kombiniert Rotationen eben nicht über die Operationen "+" und "-", sondern über die Opereationen "*" und "/" - das ist dann aber nicht wirklich eine Multiplikation: Seien rot_1 und rot_2 Rotationen (also Quaternionen), dann gilt: rot_1 * rot_2 != rot_2 * rot_1. Die Reihenfolge gibt einfach an was sich nun wie um was dreht.

Wichtig für dich ist daher vor allem die Funktion llEuler2Rot bzw. llRot2Euler, damit werdn am besten irgendwelche Winkel möglichst früh in Rotationen umgerechnet, intern werden rotationen am besten nur über Quaternionen verarbeitet (entsprechend den Rechenregeln für Quaternionen eben, d.h. zum Drehen eben "*" bzw. "/" verwenden und nicht "+", auf die Reihenfolge achten usw.) und erst dann, wenn man wirklich eine Ausgabe in ° braucht sollte man mit llRot2Euler verwenden - aber eben auch nur für die Ausgabe als verständlicher Text.
 

Users who are viewing this thread

Zurück
Oben Unten