red aux (OpenGl)

  • red aux (OpenGl)

    hallöchen, ja ich mal wieder,

    Habe im Web das redbook als PDF gefunden. Die Beispiele dort benutzen die "aux" Bibliothek.
    Das wollte ich durcharbeiten. Google half mir dabei nicht wirklich.

    Ich möchte mich beim Lernen nicht mit viel Schnickschnack belasten. Ganz einfache Umgebung reicht da. ( ich gestehe , ich nehm da die glut :O , ja, jetzt haut mich ruhig mit der Teekanne)

    Kann man für die Beispiele aux installieren (ohne Systemverzeichnisse zu ändern), oder kann man die entsprechenden Funktionen ersetzen, ohne Umdenken zu müssen ?

    Gruß

    Andrea

  • RE: red aux (OpenGl)

    Dann hast Du eine recht alte Version des Red Book erwischt - aux ist ein Vorgänger von glut (in späteren Versionen des Red Book wird stattdessen auch glut verwendet). Ich kann mir nicht vorstellen, dass es irgendwo eine aux-Implementierung für OSX gibt (höchstens von Retro-Fans). Der größte Teil sollte sich fast 1:1 ersetzen lassen, indem man das Prefix von aux auf glut ändert. Einige Details sind bei glut anders, aber dann normalerweise besser gelöst. Wenn der Rahmen erstmal läuft (also ein Kontext zum malen da ist), beschäftigt man sich normalerweise nicht mehr viel mit der Umgebung - das eigentlich Interessante ist ja der OpenGL-Teil, und der ist überall ziemlich gleich.
    Multigrad - 360°-Produktfotografie für den Mac

  • hallo Mattik,

    gilt das auch für Selections ?

    Ich möchte ein Rechteck für Bildschirmkoordinaten berechnen, welches einem von 4 Würfeln zugeordnet ist. Nun möchte ich in der Eventroutine beim Mausklick testen in welchem Rechteck der Klick passiert ist um den entsprechenden Würfel beliebig zu drehen ( per anschließendem Mausmove). ( Kleines Denkspiel soll das werden) Das soll natürlich Kameraunabhängig sein.

    Sind da Selections das Richtige? Wo wird das gespeichert ? Leider finde ich keine einfachen Beispiele für sowas.

    Gruß

    Andrea

  • Original von wolf_10de
    Hier könnte gluProject helfen, Mattik hat doch glaub ich hier mal ein Selection.Project gepostet (musst mal suchen)

    gluUnProject ist ganz gut, um Screenkoordinaten wieder ins Weltkoordinatensystem zu bekommen - damit könnte es auch gehen. Einfacher ist Picking mit GL_SELECT. Eigentlich hat das nichts mit aux oder glut zu tun - von denen bekommt man höchstens die aktuelle Mausposition auf dem Bildschirm. Der Rest ist gl-intern. Das Beispiel in dem alten Thread zeigt die Anwendung von gluUnProject(), aber ich glaube, da war kein Picking im engeren Sinne drin. Kann aber auch sein, dass Du ein anderes Beispiel meintest, ich weiß es nicht mehr genau. Woher soll ich auch wissen, was ich gepostet habe, ich hab's geschrieben, nicht gelesen... ;)

    Sicherheitshalber hab' ich ein neues kleines Beispiel angehängt - das Beispiel mit der Pyramide so aufgebohrt, dass man eine Fläche markieren kann. Ist auch kein glut, aber der Picking-Code ist von der Umgebung getrennt, sodass sich das leicht übertragen lassen sollte.
    Multigrad - 360°-Produktfotografie für den Mac

  • hallo Mattik,

    Respekt ! Und danke für das Programm.

    Sicherheitshalber hab' ich ein neues kleines Beispiel angehäng


    Ui soviel Fachwissen und schnell ein Projekt dazu.

    Da schäme ich mich schon, dass ich hier im Forum mehr "nehmend" bin.

    Aber auch irgendwann ist bei mir der (gl)Frust um, zu mindest wenn ich den gleichnamigen Befehl verstehe.

    Gegen all das empfinde ich den "Foley" als einfache Mickymaus-Literatur. Ok, ich hab da die deutsche Version im Regal stehen.

    Gruß Andrea

  • Danke für die Blumen, aber das Beispiel war keine Kunst, sondern einfach schamlos von mir selbst geklaut. Bei OpenGL ist am Anfang einfach die Menge von tollem Spielzeug überwältigend, aber es bei weitem nicht so wild wie es aussieht. Auf keinen Fall schwieriger als Foleys gesammelte Weisheit (die deutsche Version kenne ich nicht, die soll ja etwas entschärft sein).
    Multigrad - 360°-Produktfotografie für den Mac

  • Ne weitere Möglichkeit wären Selection Buffers, wenn Du die Selektion nicht bis auf ein Dreieck runterbrechen musst, dann wäre das keine schlechte Alternative.
    Im Anhang mal ein Beispiel:

    Ach BTW:
    Da schäme ich mich schon, dass ich hier im Forum mehr "nehmend" bin.

    Na das ist doch der Sinn des Forums, man fragt wenn man was nicht weiß und hilft wann es geht :)
    Aber auch irgendwann ist bei mir der (gl)Frust um, zu mindest wenn ich den gleichnamigen Befehl verstehe.

    Dann solltest Du mal Direct3D sehen, da bekommt man schon Zahnschmerzen wenn man nur ein lumpiges Dreieck rendern will.

  • die deutsche Version kenne ich nicht, die soll ja etwas entschärft sein).


    Habe im Buchladen in beide Versionen hineingelesen damals. Die deutsche Version ist gekürzt, aber hielt ich für mich geeigneter.
    Interessant und wichtig fand ich dort, einen 3D Welt so zu transformieren, dass nach der Parallelprojektion das gleiche Bild entsteht wie eine Zentralprojektion der Ursprungsdaten, dadurch wird vieles performanter und einfacher. Z.B. Tiefenpuffer oder Kappungen in homogenen Koordinaten. Diese Matrix ist ja auch invertierbar.
    Diese Grundlagen verstehe ich.

    Nur weiss ich halt nicht wie OpenGL das macht.
    Da gibt es zig Varianten. Auch den Befehl Matrixmode verstehe ich nicht.
    So kleine beschriftete Zeichnungen würden da da ungemein helfen.

    Das hantieren mit verschiedenen Projektionen scheint da überlebenswichtig zu sein.
    Daher nützt mir ein Beispiel mit vielen Effekten nichts.

    besser finde ich da Beispiele die wenig können und möglchst viele Features bewusst abschalten.

    Denn dann lernt man auch elementare Dinge.
    Das Beispiel mit der Pyramide ist ein gutes Beispiel.

  • Original von Andrea
    Nur weiss ich halt nicht wie OpenGL das macht.
    Da gibt es zig Varianten. Auch den Befehl Matrixmode verstehe ich nicht.
    So kleine beschriftete Zeichnungen würden da da ungemein helfen.

    OpenGL macht das fast genau so. Die MatrixMode-Sache hätte ich im Beispiel noch einfacher machen können, aber das geht so schnell ins Blut, dass ich's schlicht vergessen habe. Also:

    OpenGL kennt u.a. zwei Matrizen: Modelview und Projection (es gibt noch andere, aber die sind optional). Auf jede angegebene Koordinate wird erst die Modelview-Matrix, dann die Projection-Matrix angewendet. Anschließend wird sie geclippt, läuft durch allerhand Tests und wird dann in den Viewport hineingepackt - im Prinzip das gleiche wie immer, nur statt einer Matrix sind es zwei. Die beiden Matrizen kann man im Prinzip beliebig nutzen, niemand verbietet es, z.B. eine als Identitätsmatrix zu belassen und alles mit der anderen Matrix zu tun. Aber es ist so gedacht, dass man die Modelview-Matrix für die Transformation von einem eigenen lokalen System in ein Weltkoordinatensystem (also das Bezugssystem für die 3D-Szene) nutzt, z.B. um einzelne Objekte darin zu verschieben, zu rotieren o.ä. Die Projektionsmatrix beschreibt die Transformation der virtuellen Kamera, also wie aus den Weltkoordinaten Bildschirmkoordinaten werden. Meistens ist das ein glFrustum() für eine Perspektivprojektion oder ein glOrtho() für Parallelprojektion, optional gefolgt von Drehungen und/oder Verschiebungen, um die Kamera in der Welt zu platzieren.

    Es gibt andere Wege, die Projektionsmatrix aufzubauen, aber die sind eigentlich alle optional.

    glMatrixMode() ändert nichts am Rendermechanismus. Es ist einfach nur ein Schalter, welche Matrix mit den nachfolgenden Befehlen geändert werden soll - z.B. setzt ein glLoadIdentity() nach einem glMatrixMode(GL_PROJECTION) die Projektionsmatrix auf die Einheitsmatrix. Auf diese Weise lassen sich alle Matrizen von OpenGL mit den gleichen Befehlen bearbeiten. Meistens setzt man die Projektionsmatrix nur am Anfang des Renderdurchlaufs (oder nur einmal im Programm, wenn sie konstant bleibt). Anschließend schaltet man auf Modelview um und kann diese während des Malens beliebig umsetzen (z.B. um das gleiche Objekt mehrfach an verschiedene Stellen zu malen).

    Wozu die Unterscheidung der beiden Matrizen? Ganz einfach: OpenGL braucht für einige Berechnungen einen einheitlichen Bezugspunkt für Entfernungen, Winkel usw. - insb. für Beleuchtungsberechnungen. Die Beleuchtung wird in Weltkoordinaten vorgenommen, also nach der Modelview- und vor der Projection-Matrix. Solange man sowas nicht benutzt, ist es vollkommen egal, wie man das aufteilt.

    Als Hilfe hat OpenGL für jede Matrix jeweils einen Stack, mit dem man sich die gerade aktuelle Matrix merken und später zurückbekommen kann (glPushMatrix/glPopMatrix), was insb. für verschachtelte Objekte sehr praktisch ist. Das ist aber unabhängig vom Rest - wenn man einen Punkt z.B. mit glVertex3f() angibt, zählt immer nur die gerade aktuelle Modelview- und Projektionsmatrix.

    Ach ja: Eine kleine Skizze zu glFrustum() ist in einem Thread von kressevadder von vor ca. einer Woche.
    Multigrad - 360°-Produktfotografie für den Mac

  • kein Frust um glFrustum

    hallo mattik

    danke für die Hilfe. Hab gleich mal im entsprechenden Thread nachgesehen.

    Meine AHA Erlebnisse:

    Es ist ein rechtshändiges orthogonales Koordinatensyten. Wobei die positive Z Achse zu mir hin zeigt. Also "kleine Z" bedeuten "weiter weg".

    Und Bezugspunkt ist immer die near clippingplane. Deswegen halbe Achsenlänge / 2.
    So technisch gesehen ist die Z=0 Ebene also unwichtig für den Befehl ( Ausser das dort die verzerrungsfreie Darstellung gegeben ist)


    Zu den Matrixmodi:

    meine Koordinaten --> Weltkoordinaten = GL_MODELVIEW
    Weltkoordinaten --> "zentralperspektivische Matrix" = GL_PROJECTION

    d.h. das sind dann die Bildschirmpixelkoordinaten.

    Mit pushmatrix und popmatrix könnte man, wenn man Langeweile hätte, also weitere Zwischenschritte einfügen.
    Müssten meherer Kameras mit push-/ und popmatrix realisiert werden ?


    Stimmt das alles so ?

    Muss man seinen ZBuffer der selbstgewählten near und far plane anpassen, oder passiert das automatisch? Obwohl ja bei konvexen Körpern (Würfel) backfaceculling reichen sollte.

    Viele Grüße

    Andrea

    ps: was mach ich hier? ich wollte doch nie wieder ´progen´

  • Hallo

    Dank für das gut dokumentierte Beispiel.
    initWithFrame wird nie aufgerufen.
    Habe gelesen, dass dies sowieso nicht aufgerufen wird, wenn im Interface-Builder eine NSOpenGLView ausgewählt wird.
    Es soll aber aufgerufen werden, wenn man CustomView verwendet. Da wird die Methode aber auch nicht aufgerufen !?!

    Ich hatte Gestern auch das Problem, dass ich erst nach einer Stunde erkannt habe warum meine Texturen nicht erstellt werden können.
    Dazu passend dies gelesen.
    [NSView] Was kommt nach dem awakeFromNib?

    Wobei ich nicht sicher bin ob applicationDidFinishLaunching jetzt wirklich die saubere Stelle ist.

    Gruss, Oliver

  • RE: kein Frust um glFrustum

    Original von Andrea
    hallo mattik

    danke für die Hilfe. Hab gleich mal im entsprechenden Thread nachgesehen.

    Meine AHA Erlebnisse:

    Es ist ein rechtshändiges orthogonales Koordinatensyten. Wobei die positive Z Achse zu mir hin zeigt. Also "kleine Z" bedeuten "weiter weg".

    Und Bezugspunkt ist immer die near clippingplane. Deswegen halbe Achsenlänge / 2.
    So technisch gesehen ist die Z=0 Ebene also unwichtig für den Befehl ( Ausser das dort die verzerrungsfreie Darstellung gegeben ist)


    Zu den Matrixmodi:

    meine Koordinaten --> Weltkoordinaten = GL_MODELVIEW
    Weltkoordinaten --> "zentralperspektivische Matrix" = GL_PROJECTION

    d.h. das sind dann die Bildschirmpixelkoordinaten.

    nur im OrthoMode, werden Pixelkoordinaten verwendet


    Mit pushmatrix und popmatrix könnte man, wenn man Langeweile hätte, also weitere Zwischenschritte einfügen.

    Das hat nichts mit Langeweile zu tun, sondern alle Objekte die ausserhalb !!
    von Push und PopMatrix gerendert werden, sind nicht von einer Verschiebung, Rotation, Skalierung betroffen, die Du innerhalb dieser beiden Befehlen machst.


    Müssten meherer Kameras mit push-/ und popmatrix realisiert werden ?

    Es gibt nicht DIE Lösung, sondern immer mehrere, in diesem Fall würdest Du den Bildschirm (Scissors) teilen und dann mehrere Ortho-Kameras erstellen die nur einen Ausschnitt anzeigen



    Stimmt das alles so ?

    Muss man seinen ZBuffer der selbstgewählten near und far plane anpassen, oder passiert das automatisch? Obwohl ja bei konvexen Körpern (Würfel) backfaceculling reichen sollte.

    Viele Grüße

    Andrea

    ps: was mach ich hier? ich wollte doch nie wieder ´progen´

    Der ZBuffer hat mit Backfaceculling nichts zu tun, Backfaceculling sagt nur aus das Flächen die auf der Rückseite (also im Uhrzeigersinn definiert sind) nicht gerendert werden sollen.

  • Original von obb
    Hallo

    Dank für das gut dokumentierte Beispiel.
    initWithFrame wird nie aufgerufen.
    Habe gelesen, dass dies sowieso nicht aufgerufen wird, wenn im Interface-Builder eine NSOpenGLView ausgewählt wird.
    Es soll aber aufgerufen werden, wenn man CustomView verwendet. Da wird die Methode aber auch nicht aufgerufen !?!

    Ich hatte Gestern auch das Problem, dass ich erst nach einer Stunde erkannt habe warum meine Texturen nicht erstellt werden können.
    Dazu passend dies gelesen.
    [NSView] Was kommt nach dem awakeFromNib?

    Wobei ich nicht sicher bin ob applicationDidFinishLaunching jetzt wirklich die saubere Stelle ist.

    Gruss, Oliver


    Warum nicht??
    Wenn die Methode aufgerufen wird, weißt Du das alle Objekte instanziert sind, was bei awakeFromNib nicht undbedingt der Fall ist.
    BTW ICh verwende immer die applicationDidFinishLaunching um mein OpenGL-Kram zu initialisieren.

  • Hallo Wolf

    danke für die Antworten.

    teilen und dann mehrere Ortho-Kameras erstellen die nur einen Ausschnitt anzeigen


    Parallelprojection (Ortho) benötige ich nicht. Für meine Anwendungen benötige ich nur Zentralprojektion.



    Der ZBuffer hat mit Backfaceculling nichts zu tun, Backfaceculling sagt nur aus das Flächen die auf der Rückseite (also im Uhrzeigersinn definiert sind) nicht gerendert werden sollen


    Das war und ist mir klar.

    Waren zwei verschiedene Fragen ! der scheinbare Zusammenhang war unbeabsichtigt.


    sondern alle Objekte die ausserhalb !!
    von Push und PopMatrix gerendert werden, sind nicht von einer Verschiebung, Rotation, Skalierung betroffen, die Du innerhalb dieser beiden Befehlen machst.


    Ok, die Aussage war hilfreich.


    nur im OrthoMode, werden Pixelkoordinaten verwendet


    Dann meinen wir vielleicht etwas verschiedenes.

    Das was letztentlich im AusgabeView erscheint kann man in Zeilen und Spalten unterteilen. Diese Koordinaten kenne ich unter der Bezeichnung pixelkoordinaten oder Bildschirmkoordinaten.

    Und die gibt es immer bei allen denkbaren Projectionen. ( sonst würden wir auf einem Rasterdisplay nichts sehen)

    Gruß Andrea

  • Original von wolf_10de
    Warum nicht??
    Wenn die Methode aufgerufen wird, weißt Du das alle Objekte instanziert sind, was bei awakeFromNib nicht undbedingt der Fall ist.
    BTW ICh verwende immer die applicationDidFinishLaunching um mein OpenGL-Kram zu initialisieren.

    Wäre nicht auch prepareOpenGL ein guter Platz für die grundlegende Initialisierungen? Apple sagt:"Used by subclasses to initialize OpenGL state."

    Aber für NSOpenGLPixelFormatAttribute sind doch wohl prepareOpenGL wie applicationDidFinishLaunching nicht der richtige Platz. Oder?

    Gruss, Oliver