Bevor ich anfange über meine (wahrscheinlich ziemlich primitiven) Fragen und Probleme zu heulen versuche ich vielleicht erstmal das Projekt grob zu umreissen:
Man stelle sich irgendein Relief vor welches abgetastet wird und dessen X/Y/Z-Koordinaten der Oberfläche in einem File gespeichert werden. Es handelt sich also um einen eher flachen Körper mit geringer Z-Ausdehnung. Die Erstellung dieses Files ist eine andere Baustelle und soll nur den Sachverhalt darstellen.
Es geht nun darum dieses File wieder auszulesen und das Relief zu visualisieren.
Folgende Optionen sind enthalten:
- Darstellung während der Runtime umschaltbar als Punktewolke, als Gitternetzmodell oder als Flächenmodell.
- Darstellung der Z-Werte zusätzlich zur Lage im Raum durch Farbverläufe (von Zmin = blau über Zmittel = grün bis Zmax = rot) oder alternativ Graustufen.
- Die Darstellung kann um die X- und Z-Achse gedreht werden um eine bessere räumliche Darstellung zu ermöglichen.
- Die Darstellung wird mit einem Logo, mit Dateiinfos und Kommentarzeilen versehen und als BMP zu Dokumentationszwecken exportiert.
Es handelt sich meist um mehrere hunderttausend Messpunkte wobei die Oberflächenabtastung zeilenweise erfolgt (wenigstens etwas... ), die äussere Kontur ist stets ein Rechteck. Selbiges kann sowohl im Hochformat wie auch im Querformat oder halt als Quadrat vorliegen.
Da der Bildschirmplatz sowie der Ausdruck (bzw. das BMP) natürlich möglichst optimal ausgenutzt werden soll wird beim Einlesen zunächst geprüft wieviel X- und wieviel Y-Koordinaten vorliegen, entsprechend wird dann ein 2dimensionales Array mit den Z-Werten gefüttert um stets eine Bildschirmdarstellung im Querformat zu erhalten. Beim Zeichnen werden die Bildpunkte gleich so versetzt dass der Mittelpunkt der Worldmatrix dem Mittelpunkt der Zeichnung entspricht, an den sonst notwendigen Transformationen bin ich nämlich schier verzweifelt. So klappt es aber perfekt. Die OGL-Darstellung erfolgt übrigens auf einem Panel, nicht auf dem gesamten Bildschirm.
Bevor jetzt alle aufstöhnen 'was will der denn noch alles von uns?': Ist alles schon soweit fertig und funktioniert prächtig, leider gibt es aber noch ein paar unklare Punkte.

Ich fange mal mit dem einfachsten an: Um das BMP zu erzeugen gehe ich einen etwas unkonventionellen Weg, gewissermassen von-hinten-durchs-Knie-ins-Auge . Im DGL-Wiki gibt es ja eine Screenshotbeschreibung nebst Quellcode - an dieser Stelle vielen Dank an den Autor und alle anderen die ihr Wissen dort und auch hier im Forum zur Verfügung stellen . Damit erstelle ich zunächst eine Dummydatei auf der HDD. Dann erstelle ich ein TBitmap mit Übermass, lese die Datei wieder und kopiere sie dort hinein. Durch das Übermass bekomme ich freie Bereiche die ich ganz simpel mit Textout beschreiben kann...an der Textausgabe unter OGL bin ich nämlich auch verzweifelt . Weiterer Vorteil: So ist ausgeschlossen dass der Text irgendwo mit der Grafik kollidiert, es sind sauber abgegrenzte Bereiche. Wie das Objekt im Raum gedreht ist spielt auch keine Rolle, die Beschriftung ist immer plan. Jetzt kommt aber die erste Frage: Wie umgehe ich den Umweg mit der Dummy-Datei? Ich gestehe ganz offen, ich habe keinen Plan wie ich die Screenshotroutine zu modifizieren habe dass sie mir direkt ins TBitmap schreibt.

Die ganze Mimik hat aber noch eine andere Tücke: Um auf dem Bildschirm eine gut erkennbare und augenschonende Darstellung zu bekommen zeichne ich auf schwarzem Hintergrund. Fürs BMP bzw. den Ausdruck desselben natürlich tödlich, da kann man gleich ein Fass neben seinen Tintenspritzer stellen.
Also wechsel ich vor dem Screenshot den Hintergrund auf weiss, erstelle die Dummydatei und wechsel dann wieder auf schwarz:


Jetzt werdet ihr euch über das ' Delay(1000)' wundern nehme ich an. Damit komme ich gleich zur zweiten Frage: Wenn ich das Programm an dieser Stelle nicht so oder sonstwie ausbremse dann wird der Hintergrund des Screenshots schwarz! Übrigens sind auf verschiedenen PCs auch verschiedene Delays notwendig, daher muss ich hier zu einem Maximalwert greifen der halbwegs eine Kompabilität sicherstellt. Höchst merkwürdig (zumindest für mich...) und höchst unzufriedenstellend - jemand eine Idee was da schiefläuft?


Eigentlich habe ich das Pferd jetzt aber von hinten aufgezäumt, ein grosses Problem beginnt schon viel früher: Das bildschirmfüllende zeichnen des Reliefs.
Ziel soll es wie gesagt sein das Relief möglichst formatfüllend darzustellen (wobei ein kleiner Rand verbleiben sollte...wenn mein grundsätzliches Problem gelöst ist bekomme ich das aber auch noch hin). Zentriert gezeichnet wird es schon, jetzt geht es 'nur noch' darum den korrekten Beobachterabstand zu ermitteln. Dieses Problem ist offensichtlich derart trivial dass im Web nix dazu zu finden ist, nur Kommentare wie 'Es ist Aufgabe des Programms, die Projection und ModelView Matrix so abzustimmen, das der Anwender die Szene aus einem geeigneten Blickwinkel und Entfernung betrachten kann'.
Zunächst kommt der klassische, den Tutorials entnommene weg zur Anwendung:

Dann möchte ich mit 'glTranslatef(0,0,-abc)' den Beobachterstandpunkt einrichten - aber wie berechne ich 'abc'?
Ich habe schon alle möglichen mathematischen Konstrukte durch, das Ergebnis entspricht nie dem geometrisch zu erwartenden Ergebnis.
Wie macht ihr das, ich werde noch wahnsinnig? Vor allem muss ja noch eine Relation zwischen dem Seitenverhältnis des Panels und dem des Rechtecks hergestellt werden: Bei einem Quadrat wird der Grenzwert durch die Höhe definiert, bei einem langgestreckten Rechteck aber durch die Breite (dass wohl eine Fallunterscheidung mit zwei verschiedenen daraus resultierenden Projektionen notwendig ist mir klar).
Es wird ja im weiteren Verlauf auch noch etwas komplizierter, eine Drehung des Objekts verlangt eine Vergrösserung des Beobachterstandorts da sonst die Ecken abgeschnitten werden. Jetzt wäre es natürlich schön wenn diese Vergrösserung erst stattfindet wenn die Ecken auch wirklich mit dem Rand kollidieren. Ein Quadrat z.B. wird dies sofort notwendig machen, ein langgestrecktes Rechteck aber nicht das Y ja nur zu einem geringem Teil ausgenutzt wird. OK, das ist dann fast schon etwas luxuriös und ich wäre auch mit einer grundsätzlichen Lösung zufrieden, aber vielleicht hat ja trotzdem jemand einen Geistesblitz?
Wenn ich nur die erste Frage beantwortet bekäme dann wäre ich schon einen riesen Schritt weiter, gegen weiterführende Hilfe bin ich aber nicht abgeneigt...
Bislang habe ich schon einige Formeln probiert mit denen es bei jeweils einem Objekt perfekt funktionierte (sowohl das reine Drehen um Z als auch das gleichzeitige Schwenken um X bei dem dann wiederum die Abstandsvergrösserung geringer ausfallen kann). Sobald ich dann aber ein Objekt mit deutlich anderen Proportionen geladen hatte kam ziemlicher Mist dabei heraus, langsam bin ich echt verzweifelt.

Schöne Grüsse & schonmal vielen Dank für eure Geduld
Toenne

Ok,
zur Dummydatei:
Auch wenn ich ungern das Werk einer Person empfehle, die das Werk nur geschrieben hat um mein Werk zu übertrumpfen ( ), kann ich dir die TextSuite von Lossy empfehlen. Mit dieser kannst du wirklich leicht Texten in OpenGL darstellen.
Du musst nur vorher in den Orthomodus wechseln und kannst (bei richtiger Einstellung) pixelgenau agieren.
Mach es wirklich besser so, es ist wesentlich schneller wenn du erst Daten von der Grafikkarte in den Speicher ließt und dann nochmal zurück.

Zu dem Winkel:
Du hast einen FOV sowie einen extremalen Punkt. (Argh, noch kein Grafikprogramm installiert, also kein Bild ).
Du konstruierst ein Dreieck über den Mittelpunkt, dem extremalen Punkt und der Kamera. Jetzt verschiebst du die Kamera solange bis der Winkel kleiner als FOV ist. Und schon hast du den Abstand den du suchst.
(Ja, den extremalen Punkt musst du schon selber finden , notfalls aber einfach indem du alle Punkte durchgehst und den mit der grössten Norm nimmst.)

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Erstmal danke für deine Antwort .
Text direkt in OGL-Panel einzublenden brächte mir nur Nachteile, so wie ich es jetzt mache ist es vom Ergebnis her weitaus sauberer.
Das TBitmap ist etwas breiter und etwas höher als das Panel. Der Screenshot wird rechts oben abgelegt so lass links ein senkrechter Streifen verbleibt der oben ein Logo erhält und darunter tabellarisch mit diversen Werten beschriftet wird. Desweiteren entsteht unten ein horizontaler Streifen in dem der Pfad zu Datendatei, das Systemdatum des Screenshots und darunter einige Kommentarzeilen enthält welche über eine Maske eingegeben werden können. Egal wie der Screenshot ausschaut, es gibt eine klare Trennung ohne Gefahr von Überschneidungen, dadurch sieht das überaus sauber aus. Und simpel ist es letztlich auch...bis auf den Umweg mit der Dummydatei. Wobei die nicht weiter tragisch ist, unmittelbar nach dem Kopieren ins TBitmap wird sie wieder gelöscht. Ist halt nur irgendwie 'unsauber' .

Zu deinen weiteren Ausführungen:


y/2 = sin(a/2) * l <=> l = (y/2) / sin(a/2)

Die Entfernung ist also l * cos(a/2) = (y/2) * cos(a/2)/sin(a/2)

Hier geht es schon los, a ist als vertikaler Blickwinkel beschrieben was nicht stimmen kann - setzt man in die Formel 15° ein so ist nichtmal die Hälfte des Objekts zu sehen. Es handelt sich also um den vertikalen Winkel zur Horizontalen...das ist schonmal ein Unterschied.
Setzt man also statt dessen 30° ein so sieht das Ergebnis schon besser aus, es wird aber dennoch oben und unten ein Streifen abgeschnitten...passt also auch nicht.
Jetzt kann ich natürlich noch irgendeinen willkürlichen Korrekturfaktor einfügen um es hinzubiegen, dieser macht sich aber bei verschiedenen Proportionen verschieden bemerkbar.

Gruss
Toenne

Zur Dummydatei: Entweder du ersetzt das AssignFile, Rewrite, BlockWrite, CloseFile durch durch einen TMemoryStream, der mittels WriteBuffer() und gleichen Parametern (außer F) beschrieben wird. Laden dann halt mittels TBitmap.LoadFromStream.

Oder folgende Variante, die mir auch nicht allzu schlecht erscheint:

Recht bedacht könnte man damit sogar direkt in den Output schreiben, wenn man den Pointer in jeder Zeile ausreichend nach rechts schiebt.

Zum Perspektivenwinkel:
Wenn ich das richtig verstanden habe, glaube ich, du bedenkst nicht, dass deine Viewposition nicht direkt über dem Mittelpunkt schwebt, somit stellt sich auch kein rechtwinkliges Dreieck ein.
Ich persönlich würde zwei Punkte des Rechtecks nehmen, die am weitesten voneinander entfernt sind (sprich sich diagonal gegenüberliegen). Diese dann relativ zur Viewposition berechnen bzw. den Vektor (ViewpositionPunkt) bzw. Punkt - Viewposition. Für diese 2 handelsüblichen Vektoren gilt das Skalarprodukt, also a = arccos( Vektor1*Vektor2 / (|Vektor1| * |Vektor2|) ).
Die einzige trigonometrische Lösung, die mir so einfällt ist ein Cosinussatz, aber dafür bräuchtest du auch noch Vektor3 = (Punkt1 - Punkt2), dann würde a = arccos((|Vektor1|² + |Vektor2|² + |Vektor3|²) / (2*|Vektor1|*|Vektor2|)) gehen.

MfG

Dummydatei: Der Code den WhiteHunter gepostet hat sollte sicher so funktionieren. Wobei ich nicht weiß ob es evtl länger dauern könnte, weil so viele einzelne Lesebefehle auftauchen. Aber das wäre vermutlich sogar vernachlässigbar. Und ja so sollte es dann auch möglich sein, dass man das Bild gleich größer erstellt und dann sofort einen Rahmen hat. Idealerweise sollte aber das Pixelformat noch vor der Größe gesetzt werden, da sonst das Bild umkonvertiert werden muss.

Ausdrucken: Auch wenn das keine Frage von dir war. Wenn du ein großes weißes Bild ausdruckst dann brauchst du zwar keine übermäßige Tinte aber übermäßig Zeit. Denn ein weißes Pixel ist auch ein Pixel. Auch wenn es auf dem Ausdruck nicht zu sehen sein wird, da die meisten Drucker keine weiße Farbe haben. Es muss dennoch mit zum Drucker übertragen werden. Wenn du das Bild auf die Printer.Canvas zeichnest, dann solltest du dafür sorgen, dass nur Pixel <> Weiß gezeichnet werden. Also TransparentColor und Transparent des Bitmaps setzen.

Sleep: Das ist in der Tat merkwürdig. Was machst du innerhalb von Render? Bzw was sind das für Grafikkarten auf denen größere Werte auftauchen und wie viele Daten stellst du dar? Evtl. klappt es ja, wenn du an der stelle mal glFinish einsetzt. Denn OpenGL arbeitet asynchron. Allerdings sollte das wenn nötig selbst vom Treiber synchronisiert werden. Also wenn noch etwas gezeichnet wird von der Karte dann sollte glReadPixels so lange warten müssen. glFinish sollte da dafür sorgen, dass alle noch austehenden Befehle abgearbeitet werden bevor der nächste Befehl ausgeführt wird. Bei Spielen oder Programmen die auf performance bedacht sind ist dieser Befehl absolutes gift. Und entsprechend wird er eigentlich auch nicht benutzt. Wobei mich da auch ein bisschen die Stelle des sleeps iritiert.

PS: Toenne willkommen im Forum.

Uups...eine Menge Antworten...
Ich fange mal mit dem Ende an:

Vielen Dank


Klingt gut, probiere ich aus!



Hmpf?
Ich war tatsächlich der (irrigen?) Meinung dass 'glTranslatef(0,0,-abc)' den Beobachterpunkt genau senkrecht über die Matrizenmitte mit dem Abstand -abc setzt, wohin denn sonst?
Zur Erinnerung, ich zeichne ja nicht mein Objekt gem. der Objektkoordinaten und verschiebe dann den Beobachterpunkt in XY sondern ich zeichne von vorneherein versetzt.
Kleines Beispiel: In der Datei steht...
0.00, 0.00
5.00, 3.00
Die Punkte sollen mittels einer Linie verbunden werden (die Z-Werte habe ich der Anschaulichkeit halber mal weggelassen).
Zunächst ermittle ich die Anzahl der X- und Y-Werte, hier also WievielX = 2 und WievielY = 2.
Dann berechne ich die Spanne der X- und Y-Werte, also SpanneX = (X1+X2)/WievielX = 2.5 und SpanneY = (Y1+Y2)/WievielY = 1.5
Gezeichnet wird dann nicht von [x1,y1] zu [x2,y2] sondern von [(x1 - SpanneX/2), (y1 - SpanneY/2)] zu [(x2 + SpanneX/2), (y2 + SpanneY/2)].
Der Beobachter verharrt also senkrecht über der Matrizenmitte (oder eben doch nicht?) derweil das Objekt selbst bereits beim Zeichnen auf die Matrizenmitte verschoben wird...das funktioniert auch perfekt.

Mittlerweile habe ich auch Werte gefunden mit denen ich offensichtlich alle Arten von Objekten in der Draufsicht halbwegs vernünftig darstellen kann:



Zur Erklärung: Sobald das Seitenverhältnis des Objekts das des Panels überschreitet würde eine Betrachtung der Y-Spanne bedeuten dass horizontal Bereiche abgeschnitten würden. Statt dessen wird nun die X-Spanne zur Basis genommen und das Ganze mit dem Kehrwert des Korrekturfaktors multipliziert.
Mit dem Wert '1.15' verbleibt oben und unten ein schmaler Rand, er ist empirisch ermittelt...k.A. wie man ihn mathematisch erfassen könnte? Immer noch sehr unbefriedigend.

Die Ausführungen zu deiner Vektorrechnung muss ich erstmal sacken lassen, meine Schul- und Studienzeit ist doch schon ein paar Dekaden her .
Ich hatte gehofft das Problem mit reiner Geometrie lösen zu können und mich eben nicht mit Vektorrechnung rumplagen zu müssen...


Keine Notwendigkeit, weder für das eine noch für das andere. Die Panelgrösse (welche mit der Bildschirmauflösung skaliert ist, das erwähnte ich noch nicht) definiert einfach die Grösse der BMP-Datei - je höher die Bildschirmauflösung desto grösser das Bitmap. Dann noch ein genau definierter Bereich links und unten drangepappt zwecks Beschriftung und fertig, das passt schon .


Zum Thema drucken: Es wird nicht aus dem Programm heraus gedruckt sondern nur die BMP-Datei erstellt. Selbige kann man dann entweder direkt drucken (IrfanView & Konsorten) oder sonstwie verwurschteln, z.B. Import in Word. Da es aber (korrigiert mich ruhig) in einer BMP-Datei keine Transparentwerte gibt sondern skalvisch jedes Pixel dargestellt wird brächte mir deine Methode keinen Vorteil?
Für andere Anwendungen merke ich mir den Tip aber gerne!


Wie der Name schon vermuten lässt: Rendern...
Es handelt sich um mehrere hunderttausend 3D-Messpunkte die entweder als Punktewolke, als Gitternetzmodell oder Flächenmodell dargestellt werden. Ein langsamer Rechner bzw. eine gemütliche Grafikkarte braucht dafür schon einen Moment.
Wahrscheinlich stelle ich mich auch wieder nur zu blöd an, aber das...

...löscht mir ja den ganzen Bildschirm, der Screenshot wäre also komplett weiss. Daher lasse ich das Objekt (vor dem nun weissen) Hintergrund neu zeichnen.
Das gleiche Spielchen dann natürlich am Schluss, Hintergrund auf schwarz setzen, löschen, neu zeichnen.
Zum Delay habe ich jetzt noch eine etwas elegantere Version gefunden. Das Rendern erfolgt bei mir nicht im Idle-Modus (wozu auch, die Darstellung ist ja praktisch statisch) sondern Timergesteuert (Wert 100).
Also sieht es jetzt so aus:


Ändert zwar erstmal nix am grundsätzlichen Problem, sieht aber irgendwie besser aus .


Genau das dachte ich mir auch, wie kann das Programm sich selbst überholen?
Nach Umstellung des Hintergrunds springt das Prog ja in die Renderroutine und kehrt erst wieder zurück zur Snapshotroutine wenn alles gezeichnet ist.
Selbst wenn die GraKa zu langsam wäre: Wieso dann immer komplett weiss oder komplett schwarz? Da würde ich eher erwarten dass das Bild z.B. bis zur Hälfte schon weiss ist und der Rest noch schwarz.


Habe ich jetzt richtig verstanden: Diesen Befehl muss ich selbst ans Ende der Renderprozedur schreiben? Wäre kein Problem da die Anwendung diesbezüglich absolut nicht zeitkritisch ist...probiere ich mal aus.

Bis hierhin schonmal Danke,

Schöne Grüsse
Toenne

Drucken: Okay. Dachte du würdest in dem Programm drucken. Und nein ein TBitmap kann so etwas nicht. Das kann man nur im TBitmap einstellen. Aber als Datei muss so etwas dann sowieso das jeweilige Programm berücksichtigen. Also vergiss meine Anmerkung für diesen Fall.

glFinish: Müssen musst du gar nicht. Eigentlich wird eben sogar gesagt, dass man glFinish nicht mehr verwenden sollte, da es bewusst CPU als auch GPU anhält. Allerdings klingt dein Problem da doch etwas komisch. Du kannst mal versuchen glFinish dort einzufügen wo die arbeiten der Grafikkarte abgeschlossen sein müssen. Also nach dem Löschen mit Weiß und dem neu Rendern. Bzw. direkt vor dem Auslesen mit glReadPixels. Evtl solltest du vor dem Auslesen noch mal explizit glReadBuffer(GL_BACK) einstellen.

Warum das so komisch erscheint kann ich nicht sagen. Habe ich noch nie erlebt. Ist das bei allen System so oder nur mit einem entschiedenen manchmal? Alternativ setzt mal die OpenGL Farbe nicht ganz auf weiß oder schwarz. Sondern auf Mischfarben. Einfach um ein bisschen zu Testen. Denn ganz Schwarz kann auch sein, dass einfach ein Speicherbereich gelöscht wurde und weiß ist normal die Farbe des ein leeres Bitmap hat.

Überprüfst du auf OpenGL Fehler?

Wie - geht das auch?
Nee, ignoriere ich bislang hartnäckig .
In der Renderroutine wird abhängig vom Status dreier Buttons in jeweilige Funktionen gesprungen welche dann die Punkte, Linien oder Dreiecke zeichnet. Am Ende dieser Funktionen habe ich nun jeweils glFinish eingetragen, bislang läuft es. Ich muss es allerdings noch an anderen Rechnern testen.
Verwendete Rechner waren bislang mein Desktop an dem ich programmiere (Ati X800XT), der Laptop meiner Frau (mit OnBoard-Grafik -> langsam) und der Rechner eines Bekannten für den ich das Programm auch eigentlich schreibe. Er bekommt es jeweils per Mail, daher erfolgt die Rückmeldung auch immer verzögert. GraKa? Keine Ahnung...

Derzeit kaspere ich mit der Skalierung übereinander...mit wiederum merkwürdigen Effekten.

Zunächst einmal habe ich den Code etwas übersichtlicher gestaltet:



Wie man sieht ist beim Aufruf von glTranslate eine Variable 'DrehFaktor' hinzugekommen, mehr dazu gleich.
Erstmal habe ich mich mit ein wenig Geometrie verlustiert, und zwar im 2D-Raum.
Gegeben sei ein Panel dessen Mitte ich mal als [0,0] definiere. Auf diesem Panel liegt zentriert ein Rechteck im Querformat. Nun möchte ich die rechte untere Ecke auf Kollision mit dem Panelrand überprüfen wenn ich das Rechteck um den Panelmittelpunkt drehe.
Zeichne ich einen Vektor von der Panelmitte zur Ecke so hat dieser Vektor der Winkel beta zur Horizontalen. Drehe ich um alpha weiter so ergeben sich neue Koordinaten die ich mit gluProject checke. Im folgenden Code taucht noch eine Variable 'Schwenk' auf, dies ist der Rückgabewert eines Sliders mit dem Wertebereich 0..90. Sobald ich diesen Slider verstelle wird als OnEvent zu 'XY_Werte_testen' gesprungen:



Die oben aufgerufene Prozedur 'XY_Werte_korr' sieht wie folgt aus:



Ich mache also folgendes:
- winy wird auf einen beliebigen grossen wert gesetzt um sicherzustellen dass die folgende Schleife auch wirklich bearbeitet wird.
- Die Werte DeltaX und DeltaY werden für den Start auf Maximalwerte gesetzt, selbige werden dann von gluProject als Koordinaten verwendet.
- Dann wird geprüft ob winy im zulässigen Wertebereich liegt. An dieser Stelle eine Frage die mir unklar ist: Bezieht sich winy auf den gesamten Bildschirm oder nur auf das Panel auf welchem OGL dargestellt wird?
- Wenn ywin ausserhalb des zulässigen Bereichs ist wird der Korrekturfaktor erhöht und die 'XY_Werte_korr'-Prozedur angesprungen.
- Hier wird zunächst der Originalvektor zum Ursprungspunkt berechnet, selbiger dann mit dem DrehFaktor skaliert (durchs Dividieren wird er also kleiner) und dann anhand des Drehwinkels laut Slider ('Schwenk') die voraussichtlichen neuen Koordinaten berechnet.
- Diese neuen Werte werden an gluProject übergeben (der Z-Wert ist hier allerdings erstmal völlig wurscht, wir befinden uns in der Draufsicht). Ist ywin nun im zulässigen Bereich so wird die Schleife verlassen, der Skalierfaktor 'DrehFaktor' ist bestimmt und kann in 'glTranslatef(0,0,Distanz*DrehFaktor)' verwendet werden um die Ansicht zurechtzurücken.
- Ist ywin noch nicht im zulässigen Bereich so wird die Schleife erneut durchlaufen: DrehFaktor erhöhen -> Voraussichtliche Koordinaten ermitteln -> Prüfung durch gluProject usw usw.

Klingt erstmal gut...funktioniert bloss nicht...
Die Perspektive wird bei jedem(!) Klick auf den Slider verschoben - klar, bei jedem Klick wird winy ja auf 999 gesetzt.
Also habe ich eine zusätzliche globale Variable ywinPuffer deklariert welche beim Erstellen der Form auf 999 gesetzt wird und den Code wie folgt geändert:


Somit wird der letztgültige ywin-Wert gepuffert. Der Effekt: Jetzt verschiebt sich gar nix mehr (ausser natürlich beim ersten Anklicken, der aufmerksame zuschauer wird diesen kleinen Schönheitsfehler bemerkt haben ), ergo wird die Schleife nie abgearbeitet.
Ok, also flugs ein Label plaziert und den Code nochmals geändert:


Der Wert ist konstant 332.27669, keinerlei Änderung. Da der Startwert 999 betrug wurde die Schleife also einmal durchlaufen...danach aber nicht mehr da die Panelhöhe > (332.27669 - 30) ist.
Das gibt es doch gar nicht, wo kommt dieser Wert her?

Gruss
Toenne

Wenn du noch "Testrechner" brauchst. Hätte da drei Stück zur Verfügung. GF 8800 GTS, GF 5900 GT, GF2 GTS.
Wenn du dann noch ein Logfile ausgibst, kann ich dir das gerne zurückschicken zwecks Auswertung.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Nett von dir, momentan schlage ich mich aber wie oben beschrieben eher mit anderen Problemen rum, der Ausdruck funktioniert ja weitesgehend und ist daher nicht akut.

Gruss
Toenne, frustriert....

Fehler kannst du mit glGetError erfragen. Sollte der Wert dort ungleich 0 sein so liegt ein Fehler vor. Den passenden Text dazu kannst du mit gluErrorString bekommen. Aber sobald du ein Mal glGetError aufgerufen hast wird der Fehler zurückgesetzt. Also musst du dir den Fehlercode in einer Variable speichern.

Aber der Fehlercode kann irgendwann aufgetretten sein. Wenn du die Fehler am Ende der Render Methode prüfst, dann kann der Fehler am Anfang oder in der Mitte der Methode passiert sein. Für glGetError sieht das vollkommen gleich aus. Du müsstest dann in Zwischenschritten auf Fehler prüfen um die Methode zu finden die den Fehler erzeugt hat. Anschließend kannst im Wikieintrag der Methode dann schauen wann welcher Fehlercode gesetzt werden kann. Gibt leider keinen anderen Weg.

Und noch etwas anderes. Sollte sich irgendwie noch eine andere Frage ergeben, dann sei bitte so gut und tu dir und uns den gefallen und erstelle ein neues Thema. Noch eine Frage hier in dem Thema und man würde vollends den Überblick verliehren.

OK, alles klar...dann würde ich vorschlagen dass wir erstmal bei dem Thema Skalierung bleiben .
Ich frage bereits mit...

...ab ob gluProject einen Fehler meldet, Fehlanzeige.
Dann habe ich das Label mal mit dem neuen Wert DeltaY belegt (bei dem File das ich derzeit zum Üben benutze ist der maximale ab Mitte Y-Wert = 7): Geht brav von 7 bis 39.9 was dann wiederum genau dem maximalen X-Wert entspricht ab Mittelpunkt entspricht -> 90° Drehung.

Ich verstehe daher die Funktion gluProject nicht:
- Worauf beziehen sich xwin und ywin, aufs Panel oder auf den ganzen Screen?
- Wende ich es falsch an, kann ich die Funktion nicht mehrfach hintereinander mit jeweils neuen Parametern aufrufen?
Einfaches Beispiel:
Sollte...

...nicht bei jedem Durchlauf neue Werte für winy liefern?

Testweise habe ich den Code nochmals geändert und mir im Label die Werte für winyPuffer angeschaut:


Ich habe also die Schleife entfernt so dass die Winkelberechnung je Slideränderung nur einmal durchlaufen und dann der winy-Wert angezeigt wird: Die einzige Regelmässigkeit ist dass eine Verringerung des Sliderwerts auch ywin sinken lässt und eine Erhöhung ywin steigen lässt.
Aber mal ist ywin bei Slider-Nullstellung ~500, mal ~600. Mal ist ywin bei Slidervollausschlag (=90°) ~700, mal ~900. Jedenfalls ergeben sich keinerlei reproduzierbare Werte, ein totaler Zufallsgenerator.

Gruss
Toenne

Langsam werde ich noch verrückt .

Ich habe beide Prozeduren mal zu einer zusammengefasst:



Grundsätzlich funktioniert es jetzt...aber nur bis zu einem Winkel von 49°, ab 50° keine Korrektur mehr .
Irgendwo ist noch der Wurm drin...bloss wo?

Gruss
Toenne

Und wieder etwas neues...



Zur Erklärung:
Zunächst frage ich die Position des Sliders ab der mir den gewünschten Drehwinkel des Objekts liefert. Da ich 0.5° Auflösung möchte steht der Max-Wert auf 180 und das Ergebnis wird durch 2 dividiert.
Dann berechne ich den Winkel der äussersten Ecke des Objekts zur horizontalen Mittellinie des Panels in Neutrallage, Ergbnis = beta.
Alpha stellt den neuen Winkel nach Addition des Sliderwertes dar.
Nun wird die Länge des Vektors von der Bildmitte bis zu diesem Ursprungs-Eckpunkt (also ohne Drehung) in Bildschirmkoordinaten berechnet.
Zu guter letzt wird geprüft ob der Vektor nach Drehung um alpha die Panelgrösse überschreiten würde (leider brauche ich weiterhin überall den Faktor 1.15, die korrekte Entfernungsberechnung bleibt mir weiterhin ein Rätsel).
Wenn dem so ist dann wird der Skalierfaktor 'Drehfaktor' berechnet welcher notwendig ist damit der Vektor maximal bis zur Panelgrenze reicht. Die Distanz in glTranslatef wird dann durch diesen Skalierfaktor dividiert.
Das Label dient wieder nur zur Kontrolle was für ein Unsinn dabei rauskommt...und es kommt leider teilweise wieder Unsinn raus.

Die gute Nachricht zuerst: Es funktioniert...
Die schlechte: ...solange das Objekt kein Quadrat ist, dann sorgt der Aufruf der Prozedur für einen sofortigen Tiefensprung und der Korrekturfaktor springt auf 0.75614. Je länglicher das Objekt wird desto näher kommt der DrehFaktor der 1...da steckt also definitiv noch der Wurm drin.
Viel verrückter aber: Der Wert findet nicht zu Null zurück, bestenfalls erreicht man 0.99-irgendwas. Ok, könnte ich mit leben. Nicht aber dass dies von der Geschwindigkeit abhängig ist mit der man den Slider zurückbewegt! 'Reisst' man ihn förmlich in die Nullposition zurück so stehn da Werte von ~0.6 (und dementsprechend wird das Objekt viel zu klein dargestellt), obwohl der Slider ja korrekt angezeigt wird und die Sliderposition zu Beginn der Prozedur sogar noch abgefragt wird. Lässt man im Label den Winkel 'Schwenk' anzeigen so sieht man dass er auch brav auf Null zurückgeht...nur gerechnet wird nicht damit bzw. völlig falsch. Je langsamer man den Slider bewegt desto genauer wird es und umgekehrt - das ist doch irre , hat da jemand eine Erklärung dafür?

Gruss
Toenne