zu 1: Du renderst die Szene mit glColorMask(false, false, false, false). Dadurch wird nur in den Z-Buffer geschrieben. Im folgenden zweiten Renderdurchgang in dem die eigentlichen Kanten gerendert werden sind somit nur die Kanten sichtbar die vorne liegen. Durch Rundungsfehler kann es aber nun passieren das Z-Werte die eigentlich gleich sein sollten leicht unterschiedlich sind. Dadurch könnten einige eigentlich sichtbare Pixel nicht sichtbar sein, weil der Wert im Z-Buffer an der entsprechenden Stelle leicht größer ist. Das nennt sich Z-Fighting. Hier hilft z.B. ein glDepthRange(0.01, 1) vor dem ersten Render-Durchgang und ein glDepthRange(0, 1) vor dem zweiten Durchgang. Dadurch werden sämtliche Z-Werte im ersten Durchgang ganz leicht nach hinten geschoben.

zu 1.1: Das Problem wird durch 1. gelöst.

zu 2.: Es ist nicht möglich eine 2D-Cursor-Position in einen 3D-Punkt um zu wandeln. Das Ergebnis ist immer eine Gerade von der Kameraposition durch den von gluUnProject berechneten Punkt. Diese Gerade musst du mit der selektierten Kante schneiden. Dabei kann es natürlich passieren das es keinen exakten Schnittpunkt gibt, daher berechne den Punkt auf der Kante der den kleinsten Abstand zur Geraden hat.
Eine Alternative ist den Z-Wert aus dem FBO auszulesen und den erhaltenen 3D-Punkt durch gluUnProject zu jagen. Da der 3D-Punkt aber quantisiert (gerundet) wird, ist das möglicherweise nicht genau genug. Der Punkt wird also höchstwahrscheinlich nicht genau auf deiner Kante liegen.

_________________
Yeah!

Hallo,
1. Werde ich gleich mal ausprobieren.

2. Ich hatte bereits eine Funktion die den kleinsten Abstand zwischen Punkt/Cursor und Kante ermittelt und daraus den Punkt auf der Kante ermittelt. Die Idee mit der Geraden werd ich gleich mal probieren, ich hatte gestern was ähnliches überlegt, wollte aber eine Schnittebene nehmen. Auf ne Gerade bin ich natürlich nicht gekommen

Gerade bin ich dabei über das FBO den Tiefenpuffer auzulesen. Anstellen tue ich das auf diese Weise:

Die Position hätte ich dann aus der Textur ermittelt und hier den Wert abgefragt. Jedoch scheint es dass ich diese Werte nicht wirklich nutzen kann da sie (ich nehme mal an) durch die Perspektive verzerrt im Puffer liegen. ( Eine rechtwinklige Ecke ist dabei ein verzerrtes V / gerade Kanten in der Textur sind schräg im Puffer).

Grüße

Nimm die Cursorposition und dazu den Z-Wert aus dem Z-Buffer und jage das durch gluUnProject. Die Cursor-Position muss natürlich relativ zum FBO sein...den hatten wir ja so gebaut das der Cursor bei (0,0) ist. Der Viewport sollte dabei von -1 bis 1 gehen, damit 0,0 auch wirklich die Mitte des FBO ist.

_________________
Yeah!

Meinst du dabei den Z-Buffer des FBO?
Wenn ja: Den lese ich mit dem obigen Code bereits aus, die Cursorposition ist dabei ja immer das Pixel bei N/N also genau in der Mitte. Jedoch muss die Cursorposition nicht immer genau auf der Kante sein um eine Kante auszuwählen. Als Ergebnis würde hier ja trotzdem ein Z=0 geliefert werden.
Deswegen wollte ich das Pixel auslesen von dem ich auch die Kanten-ID erhalte, gleiche Position aber halt im Z-Buffer. Hier ist aber wie gesagt das Problem dass die Werte im Buffer scheinbar schräg landen.

Öhm, das sollte eigentlich nicht passieren. Ich vermute du liest nicht aus dem Z-Buffer des FBO.

Es wäre möglich das man mit glReadPixels nicht aus einem FBO lesen kann. Es wäre auch möglich das du den Z-Buffer für den FBO auf eine bestimmte Art erstellen musst.

_________________
Yeah!

Hmm,
soweit ich jetzt mitbekommen habe liegt es an der Größe des Arrays in das gelesen wird. Während man die Textur mit einem array von [0..N*2,0..N*2] komplett auslesen kann, müssen für den Z-Buffer andere Dimensionen genommen werden, derzeit erhält man ein halbwegs brauchbare Ergebnis mit [0..N*2 - 1,0..N*2 - 1]. Da es jedoch nicht komplett fehlerfrei ist, würden mich die richtigen Dimensionen des Z-Buffers interessieren. Theoretisch gesehen lege ich doch mit ein (Range*2+1)/(Range*2+1) großes Array für den Buffer an und müsste ihn in den gleichen Dimensionen auslesen können.

Oder kann es gar sein, dass der angelegte Buffer (mDepthBuffer) nicht der ist, welchen ich mit ReadPixels auslese? (Und wenn, wie komme ich an diesen ran?)

Lese mal meinen Post oben, du liest da irgendwelchen Datenmüll oder einen anderen Z-Buffer
Der Z-Buffer ist genauso groß wie der FBO...jeder Pixel entspricht einem Wert im Z-Buffer an genau der gleichen Stelle, eine Verzerrung gibt es da nicht.

_________________
Yeah!

//Edit: Unfug

Ok, ich habe den Fehler entdeckt:

lieferte stets den Zahlensalat, wobei mir aufgefallen ist dass stets ein Zeichen zu wenig "gelesen" wird. Wenn man sich dann noch überlegt was die Funktion glReadPixels überhaupt macht, hätte ich viel früher drauf kommen müssen

Ich habe vorher immer nur bis zum Range*2n Pixel gelesen aber dieses müsste man schon mit einlesen und dadurch kam diese Verzerrung zu stande :>