hi, ich möchte an die projezierten koordinaten meines lichtes kommen,
jetzt habe ich das problem das gluProject matrizen erwartet, ich aber bei glGet nur Integer und Doubles bekomme, wie bastel ich das zurecht ? und warum muss ich für den Viewport PInteger anstatt PGLInt nehmen, obwohl im wiki PGLInt steht, geht das net.

Hier Source:


das hier sieht kompliziert aus: http://nehe.gamedev.net/data/lessons/le ... ?lesson=44

mfg und danke schönmal

Du weisst, dass P für Pointer steht?
Da deine Pointer gerade uninitialisiert sind überschreibst du irgendwo im Speicher Daten und kannst dich glücklich schätzen, dass Windows dich nicht abschiesst.

glGet übergibt man die Speicheradressen von Double- oder Integervariablen, damit es dort die Werte speichern kann.
Bei Matrizen erwartet OpenGL nicht nur eine einfache Variable sondern ein Array [0..15] of Variable in das es speichern kann.

Das mit dem PInteger und PGLInt sollte ansich gehen, weil PGLInt = ^TGLInt und TGLInt = Integer. Was für einen Compiler verwendest du denn?

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

ich verwende den normalen delphi compiler, ich probier nochmal biss rum
verstehs aber noch net so ganz, so klappts logischerweise auch net:

PGLInt oder PInteger ist ziemlich egal. Es dürfte beides nicht gehen. Wenn eines davon klappt ist es Zufall! Das sind Pointertypen und deine Pointer zeigen auf sonst etwas aber nicht auf einen sinnvollen Wertebereich. Damit deine Pointer auch sinnvoll funktionieren müsstest du sie mit New/GetMem oder sonst etwas erzeugen und anschließend wieder frei geben. Dispose oder FreeMem. Aber das Ganze geht auch wesentlich einfacher.

Im Selektion Artikel aus dem Wiki wurde es wie folgt gemacht. Eine Variable des Types array[0..1] of Integer wird deklariert und dessen Pointer (operator @) wird an die Methode übergeben.



Das wars schon. So viel zum notwendigen Hintergrund. Im Artikel von gluUnProject ist im übrigen auch ein Beispiel dabei. Viel anders sollte es bei gluProject auch nicht sein.

so ähnlich wie bei den beispielen hatte ich das zuerst auch, ich probier nochmal

so vermutlich:

Kann ich irgendwie prüfen, ob der projezierte Punkt sichtbar wäre oder muss ich auf Raycasting o.Ä. zurückgreifen ?
Wie mache ich das am einfachsten ?

mfg

Ich wollte Dir gerade antworten "den Tiefenpuffer auslesen", aber ich habe vorher die Forensuche angeworfen mit dem Stichwort "Sichtbarkeit" und bin in diesem Thread http://www.delphigl.com/forum/viewtopic.php?t=5493&highlight=sichtbarkeit auf einen Beitrag von LarsMiddendorf gestoßen, der davon abgeraten hat. Er hatte aber eine Alternative anzubieten: Occlusion Queries.

Vor ein paar Tagen wollte jemand das Gleiche wissen wie Du; das ganze hat sich in diesem Thread http://www.delphigl.com/forum/viewtopic.php?t=7483 abgespielt.

NACHTRAG: Immer hab ich noch etwas vergessen
In diesem Thread: http://www.delphigl.com/forum/viewtopic.php?t=6895&highlight=selektion+farbe findest Du im letzten Beitrag von Phobeus die Beschreibung des Farb-Picking-Verfahrens. Und wenn mans recht bedenkt, sollte das Ding doch eigentlich auch gleich eine Art kostenloses Occlusion Query sein. Denn wenn es nicht sichtbar ist, ist die Farbe dort durch ein anderes Objekt überschrieben.

Ans Farbpicking hatte ich auch schon gedacht, aber das fand ich wenig elegant.
Ich schau mir den Rest mal an, danke

Occlusion Querys sehen (laut Tutorial) danach aus als würden sie nur für NVidea Karten funktionieren. Am liebsten wäre mir natürlich eine allround Methode Die Idee mit dem Tiefenpuffer finde ich garnet mal so schlecht. Ich dachte daran, eine Gerade zu schießen und den Abstand zu bestimmen und mit dem Depthbufferwert zu vergleichen. Funktioniert das ?
Ich brauche ja nur ein paar Punkte abfragen, nicht sämtliche Pixel.


mfg

Sollte schon funktionieren, ich hab es selber nur nie ausprobiert. Du musst dann die Entferung, die Du mit Deiner Geraden misst auf den Wert abstimmen, der aus dem Tiefenpuffer kommt, denn der ist ja im Intervall [0,1]. Du weißt schon, 0=NearPlane und 1=FarPlane, aber der Wert den Deine Geometrie liefert, ist von den Werten bestimmt, mit der Du die Projektionsmatrix bestückt hast, also muss es noch umgerechnet werden, damit man es vergleichen kann.

Ähm, und nicht vergessen: der Wert, den Du mit der Geraden zunächst misst, ist nicht etwa der Abstand Kamera=>Punkt, sondern der Normalabstand Punkt=>Gerade. Wenn Du den Punkt mit dem geringsten Abstand zur Gerade ermittelt hastt, musst Du dann erst den Abstand Kamera=>Punkt noch berechnen. Occlusion Culling ist da keines dabei. Das ist ein schwerer Nachteil.

Und deshalb find ich die Farbselektionsmethode eigentlich sogar sehr elegant, denn sie schlägt zwei Fliegen auf eine Klappe: Sie sagt Dir
1. Ob und wenn ja welches Objekt auf dem angeklickten Punkt zu finden ist, und es ist
2) ganz sicher ein sichtbares Objekt.

Gamasutra hat was bezüglich Occlusion Culling: http://www.gamasutra.com/view/feature/3394/occlusion_culling_algorithms.php

Viele Grüße
Traude

Der Nachteil ist, dass ich die ganze Szene zweimal zeichnen muss Zum Glück aber nur ohne alles und den punkt soll ich dann mit GL_POINT einzeichnen ? verschwindet der net ab einer bestimmten Entfernung oder ist der immer 1px ?

Ausprobieren

Ich glaube, dass diese ganzen Funktionen ihre Größe nicht verändern. Auf jeden Fall stimmt das bei Linien - die sind immer genau gleich dick.

Grüße,
Yogu

kann ja aber sein, dass ich durch Rundungsfehler nicht den Pixel treffe, also sollte ich doch besser eine kleine Kugel zeichnen

mfg

Hässlich bei Farbselektion ist, dass man
1. Bei 16 Bit Farbtiefe auch nur diese 16 bit verwenden kann. Falls man unvorsichtig beliebige 24bit Farben verwendet selektiert er einem dann häufig das falsche/gar nichts
2. Anti-Aliasing kann die Farbe verfälschen
3. Das Verhalten des Programms/Spiels ist an die Grafikengine/karte gebunden.
Ich persönlich mag raycasting ganz gerne, ist aber etwas aufwändiger zu Implementieren.

_________________

Wie Raycasting prinzipiell funktioniert weiß ich. Ich würde es auch gerne implementieren, aber das angesprochene Problem mit der Kameraposition etc. verstehe ich noch nichts ganz. Beispielsources wären nützlich.

mfg

Liefert dir Ursprung und Richung des Strahls vom Beobachter durch einen Pixel auf dem Bildschirm.

Für Ray gegen Mesh hätte ich auch noch code. Der ist allerdings relativ ungetested und verwendet noch keine Raumunterteilung(es wird also gegen alle Dreiecke getestet)

_________________