In einem anderen Thread hatte ich bereits zum gleichen Thema Fragen gestellt, da ich allerdings den Thread mit zuviel verschiedenen Problemen überhäuft hatte (Asche auf mein Haupt) und somit das Ganze zu einem Monolog meinerseits wurde greife ich die Bitte von Lossy eX auf und konzentriere mich auf ein Thema.

Ich stehe weiter vor dem Problem dass ich ein Objekt von der Draufsicht im Raum drehe und die Darstellungsgrösse automatisch angepasst an die Panelgrösse benötige.
Um dies zu bewerkstelligen erschien mir gluProject brauchbar, allerdings funktioniert es nicht wie gewünscht.
Statt vieler Erklärungsversuche habe ich mal ein kleines Beispiel erstellt, da sieht man es am besten:



Erstellt wird eine Form 1024*768 Pixel mit drei Scrollbars für die X/Y/Z-Drehung und vier Labels für ein paar Informationen (kann man auch weglassen).

Gezeichnet wird ein Quadrat mit der Kantenlänge X=20 (Wert ist letztlich egal), und zwar zentrisch auf der X-Ebene da eine Drehung um die Z-Achse einer Drehung um den Mittelpunkt des Quadrats entsprechen soll.
Nach zeichnen des Quadrats werden die tatsächlichen Screenkoordinaten der rechten unteren Ecke mittels gluProject ermittelt und der Betrachterabstand entsprechend skaliert damit die Darstellung stets formatfüllend ist.
Um ein Flackern oder Pumpen zu unterdrücken war das fragwürde Konstrukt mit dem Schleifenzähler notwendig, so halbwegs geht es so (obwohl das Quadrat nun nicht immer gezeichnet wird).

Mein Verständnisproblem nun: Die Drehung um Z (dritte Scrollbar) funktioniert exakt wie gewünscht, auch schön am 2.Label (winy-Wert) und am 4.Label (Betrachtungsabstand) nachzuvollziehen.
Die Drehung um Y oder Z aber hat eine stetige Vergrösserung der Betrachterdistanz zur Folge, völlig egal in welche Richtung die zugehörigen Scrollbars verstellt werden. Auch ist die Zunahme zu gross, das Objekt wird nicht formatfüllend dargestellt sondern verschwindet ruckzuck im Nirvana.
Wer sich an der Zeile...
if (winx > (Panel1.Width)) then ZoomFaktor := ZoomFaktor * (Panel1.Width/2)/((Panel1.Width/2) + winx);
...stört: Die ist unschuldig, wenn man sie auskommentiert ist der Effekt der gleiche.

Wer kann mir auf die Sprünge helfen was hier schiefläuft? Und evtl. auch erklären warum das Quadrat mal gerendert wird, mal aber nicht? Langsam verzweifele ich wirklich.

Schöne Grüsse
Toenne

Hallo toenne,
ich versuche mal ein wenig was rauszuarbeiten:

----- procedure TForm1.SetupGL
Hier solltest Du das "glEnable(GL_CULL_FACE); " rausnehmen, es könnte zumindest einen Teil der Probleme unten beim Anzeigen verursachen.

Das
glMatrixMode(GL_PROJECTION);
glLoadIdentity;

brauchst Du hier nicht, es ist hier absolut überflüssig, denn Du hast diesen Code unten beim Rendern ohnehin immer drin. Aber es verursacht auch keinen Fehler.

-----------procedure Tform1.FormCreate(Sender : TObject);
Das "NearClipping := 0;" muß gemäß unserem Wikiartikel über gluPerspective abgeändert werden: es darf nur positiv sein und muss auch größer als Null sein. Auch das könnte die Ursache für Deine Probleme weiter unten sein, weil dieser Wert in die Berechnung der Projektionsmatrix eingeht, und diese Nutzt Du ja für gluProject. Du musst also so etwas wie

NearClipping := 1; oder
NearClipping := 0.1;

schreiben.


------------------procedure TForm1.FormShow(Sender: TObject);

Hier ist mir die Sache mit dem FlagCounter nicht ganz klar; normalerweise sollte SwapBuffers eigentlich gewährleisten, dass Flackern nicht vorkommt. Aber egal.

-----------------procedure TForm1.Render;
Die Einleitung des Rendervorgangs schaut OK aus.

Die Distanzberechnung bzw. die Berechnung des Zoomfaktors weiter unten ist mir absolut unklar, kann ich also nicht beurteilen.

Ich schlage Folgendes vor: Du lässt die Distanzberechnung und den Zoomfaktor zunächst mal weg und versuchst das ganze ohne diese Zusätze soweit zu kriegen, dass Du mit dem Ergebnis zufrieden bist, also die Rotation um die drei Achsen. Dann sehen wir weiter.
Traude

Erstmal danke für deine Antwort .

- Zu 'glEnable(GL_CULL_FACE);': OK, hier kann ich es sicher herausnehmen, allerdings in der eigentlichen Anwendung wofür ich die Drehfunktion benötige eher nicht.
Egal, ich habe die Zeile auskommentiert was aber leider auch nichts bringt.

- 'glMatrixMode(GL_PROJECTION); glLoadIdentity;'
OK, alles klar.

- 'NearClipping := 0;'
Auch klar, sorry. War auch ursprünglich '1', habe allerdings aus lauter Verzweifelung mit allen möglichen Parametern experimentiert und vor posten des Codes vergessen das wieder zu korrigieren. Aber du ahnst es schon: Spielt keine Rolle was ich eintrage, das Verhalten bleibt gleich.

- 'Hier ist mir die Sache mit dem FlagCounter nicht ganz klar; normalerweise sollte SwapBuffers eigentlich gewährleisten, dass Flackern nicht vorkommt.'
Das Problem liegt darin dass gluProject ja nicht hellsehen kann und daher nicht weiss wo der nächste Punkt liegen wird bevor er nicht gezeichnet wurde .
Stellen wir uns das Quadrat in Nullstellung vor, die untere Kante verläuft in Deckung mit der unteren Panelkante. gluProject liefert mir nun winy = 0.
Drehe ich nun das Quadrat, durchlaufe die Renderroutine und lasse das Ergebnis mit SwapBuffers darstellen dann liefert mir gluProject zwar schon einen negativen Wert für winy, für eine Korrektur ist es aber schon zu spät, das Quadrat würde mit abgeschnittener Ecke gezeichnet. Erst im nächsten Durchlauf von Render würde die Perspektive geändert und das Quadrat korrekt skaliert gezeichnet. Das meine ich mit 'Flackern' oder 'Pumpen', es würde immer erst falsch und erst im nächsten Durchlauf korrekt gezeichnet.
Mit dem Counter sorge ich dafür dass zwar - gewissermassen im Hinterkopf - das Quadrat berechnet aber noch nicht gleich wirklich auf dem Panel gezeichnet wird. Erst im nächsten Durchlauf nach Korrektur der Betrachterdistanz wird es dann mit SwapBuffers tatsächlich auf dem Bildschirm dargestellt.
Ich hoffe das war wenigstens halbwegs verständlich .
Allerdings ergibt das den merkwürdigen Effekt dass der Bildschirm alle paar Klicks auf den Scrollbar leer bleibt und erst beim nächsten Klick wieder dargestellt wird. Eine logische Abfolge konnte ich allerdings nicht feststellen...

- 'Die Distanzberechnung bzw. die Berechnung des Zoomfaktors weiter unten ist mir absolut unklar, kann ich also nicht beurteilen.'
Eigentlich völlig simpel, nur muss man eben zwischen den Matrizenkoordinaten und den Bildschirmkoordinaten umrechnen. Der Nullpunkt der Matrize liegt genau auf der Panelmitte, bezogen auf die Bildschirmkoordinaten läge er also bei Panel.Height/2.
Winy darf die Bildschirmkoordinate '0' und somit die Matrizenkoordinate '-Panel.Height/2' nicht unterschreiten, sonst wäre die Ecke abgeschnitten.
Man stelle sich das Quadrat mal um 45° gedreht vor, ywin ist in diesem Fall ohne Korrektur des Betrachterabstands also negativ.
Für eine korrekte Darstellung müsste ymin direkt auf dem Panelrand liegen, bezogen auf die Matrizenmitte also bei -Panel.Height/2.
Diese beiden Strecken setze ich in Relation (wobei die Vorzeichen keine Rolle spielen solange sie bei Nenner und Zähler gleich berücksichtigt werden):
Panel.Height/2 ist der Wert der maximal erlaubt wäre
Panel.Height/2 - winy ist der tatsächliche Wert. Wird winy nun negativ so ergibt sich in Summe ein Wert > Panel.Height/2.
Der Faktor würde also < 1.
Ist winy positiv (der untere Panelrand also noch nicht erreicht) so wäre (Panel.Height/2 - winy) < Panel.Height/2, der Faktor also >1.
Die Distanz dividiere ich nun einfach durch diesen Faktor und erreiche damit (-> Strahlensatz) dass ymin bei der Bildschirmkoordinate 0 liegen würde.
OK, wahrscheinlich wäre es einfacher verständlich wenn ich den Bruch welcher den Faktor definiert einfach umdrehe und dafür die Distanz mit diesem Faktor multipilziere:
winy negativ -> Faktor würde >1 -> Die Distanz würde durch Multiplikation mit diesem Faktor grösser -> winy geht gegen 0.
winy positiv -> Faktor würde <1 -> Die Distanz würde durch Multiplikation mit diesem Faktor kleiner -> winy geht gegen 0.

Ich weiss nicht ob du obigen Code mal ausprobiert hast, ich hatte ihn extra so erstellt dass man ihn mit Copy&Paste direkt verwenden kann. Zumindest was die Drehung um Z angeht wirst du feststellen dass es prima funktioniert.
Nur bei Drehung um X oder Y kommen für winy abstruse Werte heraus. Und was das merkwürdige ist: Der Wert wird stetig kleiner, egal in welche Richtung ich drehe. Wenn ich den entsprechenden Slider hin- und herbewege so 'flattert' das Quadrat Richtung Hintergrund ins Nirvana statt mal näher zu kommen und mal zu entfernen.
Das ist es was ich nicht kapiere, obiger 'Mechanismus' müsste hier eigentlich genauso funktionieren, tut es aber nicht. Wieso liefert gluProject hier andere, stetig fallende Werte als bei Drehung um Z?

Gruss
Toenne

Hallo toenne,
Ich habe mir Dein Programm angesehen, und nicht nur das: ich habe es auch bei mir implementiert. Nach langem Hin und her bin ich zu folgendem Schluss gekommen:

1. gluProject liefert offenbar eine Fenster-Y-Koordinate. Das Y muss also umgerechnet werden: WinY:= Panel.Height-WinY;

2. Zoomfaktor:

Die ursprüngliche Distanzberechnung ist OK und funktioniert ganz ausgezeichnet. Aber m.E. ist der Zoomfaktor nicht korrekt. Du berechnest den ZoomFaktor letztendlich aus dem Vergleich der Panelgröße mit den projizierten Koordinaten. Das ist OK. aber Du fütterst ihn in die Berechnung der Objektdistanz hinein, das geht dann in glTranslate ein. Das ist nicht OK. Die Objektdistanz ist die Z-Koordinate des gezeichneten 3D-Objekts (denn es ist ein 3D-Objekt, wenn Du gluPerspective verwendest).

Hiezu kommt noch, dass der Zoomfaktor in seine eigene Berechnung eingeht: Zoomfaktor berechnen, Zeichnen, daraus projizierte Koordinaten errechnen, aus denen der Zoomfaktor wieder berechnet wird. Wenn der Zoomfaktor nicht ganz exakt berechnet wird, liefert das eine sich selbst verstärkende Funktion, was hier soviel bedeutet wie: wenn der Zoomfaktor ausreitet, dann macht er das immer schneller und das ist der Grund für das Verschwinden Deines Objekts.

Eine Möglchkeit, den Zoomfaktor korrekt zu berechnen wäre, auf die ursprüngliche Distanzberechnung zurückzugreifen, und diese auf die transformierten Objektkoordinaten anzuwenden, nicht auf die ursprünglichen.
Traude

Klar liefert gluProject eine Fensterkoordinate, ist ja Sinn und Zweck der Funktion .
Gezählt wird Y aber wie im Karthesischen System von unten nach oben und nicht von oben nach unten.
Siehe auch http://wiki.delphigl.com/index.php/gluUnProject

Matrixmittelpunkt ist panel.height/2. Wenn ich nun die Matrixkoordinaten in Bezug auf die Bildschirmkoordinaten betrachten will muss ich also panel.height/2 als Referenzpunkt nehmen.
Das zweite Label zeigt ja den winy-Wert, wenn man bei glTranslatef 'Distanz' einfach mal durch eine Konstante ersetzt (also die Distanzanpassung 'stillegt') sieht man wie ymin von einem positiven Wert gegen Null geht und im Falle einer abgezwickten Ecke sogar ins Minus.
Wie gesagt, bei der Drehung um Z funktioniert es ja wunneprächtig.


Hmpf? glTranslatef definiert doch die Distanz zur Matrix wenn ich nicht irre? Klar stimmt die Rechnung bei positiven Z-Werten nicht mehr 100%tig (das würde ich ohnehin durch einen zusätzlichen Faktor berücksichtigen welcher einen Rand zum Panelfenster garantiert...im Verhältnis zur Objektgrösse sind die Z-Were auch gering, 1:100 oder weniger), aber der Z-Wert im obigen Beispiel ist ohnehin bewusst Null.

Die eigentliche Frage ist ja die:
Bei Drehung des Quadrats ohne Korrektur geht winy erst gegen Null, dann ins Negative und dann wieder ins Positive (bei Drehwinkel >45°). Das wird auch prima abgefangen und korrigiert.
Nun schauen wir uns aber die Drehung um Y an, wie einen Fensterflügel den man zu sich hinzieht. Hier wird ymin auch negativ, die Korrektur greift aber nicht richtig obwohl mathematisch eigentlich die gleichen Regeln gelten. Schlimmer aber noch: Wenn man den Fensterflügel wieder zuklappt dann müsste ymin wieder Richtung Null bzw. ins Positive gehen, hier aber geht ymin immer weiter ins Negative. Bei X dasselbe.
Man sieht es ja: Zunächst wird die Distanz korrigiert (wenn auch vom absoluten Zahlenwert her zu stark), das Quadrat weicht zurück. Wenn man nun den Slider wieder Richtung Null bewegt müsste die Distanz wieder kleiner werden da die Y-Bildschirmkoordinate ja positiv ist...statt dessen weicht das Quadrat noch weiter zurück.
Das ist es was ich nicht in den Kopf bekomme, wieso wird bei Z-Drehung perfekt korrigiert derweil bei X und Y das Quadrat im Nirvana verschwindet .

Gruss
Toenne