Hallöchen,

ich habe vor, für mein Projekt das Selektionsverfahrne zu verwenden, welches auch hier auf der Seite oder im Wiki als Tutorial beschrieben wird. Dabei wird allerdings von einer 3D-Matrix ausgegangen. Ich habe für mein Projekt eine Orthogonale Matrix, diese richte ich wie folgt ein:



Es gibt in meinem Code auch keine gluPerspective(), wie es dann im Selectionscode verwendet wird.

Bisher sieht dieser Code so aus:



Das Ergebnis dieser Selektion ist sehr seltsam. Sobald Objekte vorhanden sind wird als Anzahl der Treffer meist die Anzahl der Objekte ausgegeben. Als wenn sich alle Objekte in der 1 x 1 großen Selektion befanden hätten. Dabei kann ich hinklicken wo ich will, die Objekte übereinander legen, das beeinfluss das Ergebnis nicht. Jetzt hatte ich den Verdacht, das es an der Perspektive liegen könnte, die man nach glPickMatrix() anwendet. Da ich ja praktisch keine 3D-Scene habe sondern einen orthogonalen Modus. Daher wollte ich mal nachfragen, was man da denn ändern muss, damit es damit funktioniert?
Ich hoffe hier kann man mir helfen, ich sitz da schon lange dran aber ohne Ansatz ist die Sache recht kompliziert.

mfg.

Sunny

Die Selection rendert wie gesagt die Szene nocheinmal. Allerdings nur den kleinen bereich, und nicht alles. Dabei "merkt" sich OpenGL welche Namen tatsächlich gerendert wurden, und gibt diese als Ergebnis zurück. Da du sicherlich die Objekte auswählen willst, die du siehst, musst du natürlich auch in beiden Rednerdurchläufen die selbe Projektion verwenden. Sonst isses witzlos.

Allerdings ist in 2D Selektion völlig überflüssig. Wesentlich schneller ist man, indem man vom OnMouseDown Ereignis die X,Y Koordinaten nimmt und testet, ob eins der Eigenen objekte getroffen wurde. Das is im Orthomodus ja kein Problem, wenn die Auflösungen des Rendercontexts Pixelgenau ist. (bei glOrtho wurden die Werte der Form übergeben.)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Überflüssig ist es in sofern nicht, da ich 1. die Tiefen berücksichtigen will. Also der Z-Wert der Objekte spielt eine Rolle. Außerdem sind die Objekte leider nicht nur rechteckig sondern durchaus mal wie eine Raute, ein Parallelogramm oder sonstwie verformt. Eine Selektion soll aber nur stattfinden wenn die Maus tatsächlich einen Pixel des Objects berührt. Und da dort eben auch schiefe Kanten möglich sind will ich nicht erst berechnen, ob die Maus nun innerhalb des Objektrandes liegt oder nicht. Bei Rechtecken wär' das in der Tat keine große Sache, aber so...

Was die Selektion speziell nochmal betrifft, wie muss ich denn vorgehen nach dem glPickMatrix()?
Muss ich dann statt gluPerspective einfach glOrtho nehmen und die Matrix wieder so einrichten wie ich sie zum Rendern der Objekte verwende? Das hatte ich nämlich auch schonmal ausprobiert. Leider kommt dabei nichts besonderes raus.

Ja...eigentlich eifach die selben einstellungen nehmen. Die Selektion hatte noch paar kleine Tücken, musste mal im Forum suchen.

Was auch noch geht ist folgendes:

Im Mouse Down ereignis merkst du dir die Koordinaten und renderst deine komplette szene ohne Texturen und Beleuchtung. Jedem Objekt wird dabei eine eigene individuell einzigartige Farbe zugeordnet. Dann ließt du den Colorbuffer an der klickposition aus, und kannst anhand der Farbe erkenne, was getroffen wurde.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das mit der Farbe klingt auch nicht so unkompliziert, vor Allem weil ich dann jedem Objekt eine Farbe geben müsste. Und es kann vorkommen, dass ich bis zu mehrere tausend Objekte gleichzeitig anzeigen muss.


Öhm, meine Selektion im Codefeld oben? Die ist soweit von der des Tutorials übernommen (mit Anpassungen an eigenen Viewport). Oder ist der Fehler im Tutorial selbst?

Teilweise auch im Tutorial selbst:

Wenn du kein Objekt triffst ist Hit immer noch High(Internet).
Hatte bei mir auch mal komische Ergebnisse unter Linux mit dem Quellcode.

Hier ist mein angepasster Code der auf den Tutorials auf sulaco.co.za basiert:


@Flash:
Könntest du vielleicht den Code anschauen und vergleichen und danach ins Wiki übernehmen?
Ich schau mir dafür nochmal die übertragenen Tutorials an.
In Ordnung?

Selction: Man kann doch ganz simpel und sauberer als High(GLUInt) die Variable benutzen in der die Anzahl der getroffenen Objekte steht. Wenn dort eine 0 drin steht, dann wurde nichts getroffen. Also in etwa so.


Und wusch. Fertig isses.

Das mit den Farben geht natürlich auch. Ist aber im Endeffekt nichts anderes als die Selektion bis auf den Unterschied, dass man bei einer Selektion auch noch einen Stack hat. Und somit hat man noch ein paar zusätzliche Möglichkeiten (Mehr mögliche Werte). Wobei ich gestehen muss das ich so etwas bisher noch nicht gebraucht habe und auch so ohne weiteres nicht weiß wie man das anstellen sollte. Aber es ist möglich.

Hat das nen Grund warum dein zNear und zFar so extrem große Werte sind? In 2D liegt ja eh fast alles auf auf Z = 0.


Sunny nichts gegen dich oder jeden anderen. Passt zwar nicht wirklich hier her aber da gibt es was was ich mich immer wieder frage und mir gerade nicht verkneifen kann. Warum stehen eigentlich immer alle Orthoansichten auf dem Kopf? Zu mindest deren Koordinaten? Ist es nicht einfacher die Koordinaten direkt zu übergeben als immer erst einmal Height - YWert zu rechnen? Ich für meinen Teil finde es so wesentlich praktischer. Ich weiß. Es gibt dabei weder falsch noch richtig sondern alles nur eine persönliche Einschätzung. Dem ein oder anderen mag es vielleicht auf dem Kopf besser gefallen aber ich finde es so halt einfach unnötig umständlich. Ich befürchte viele wissen gar nicht, dass es auch anders geht. Vielleicht bin ich auch einfach nur zu faul und suche ständig nach einem einfacheren Weg.

[edit] Fehler im Quellcode beseitigt.

Weil ich eine Art 2D-Engine entwickle die mittels Z-Wert sortiert und perspektivisch korrekt sein soll. Sie sortiert Pixelgenau und bietet zusätzlich noch mehrere Layer. Daraus resultieren dann viele Abstufungen und recht große Z-Bereiche. Ich hoffe mal, dass OpenGL damit zurecht kommt. Erste Tests damit liefen schonmal, bisher macht das noch keine Probleme.

Ah. Okay. Ich weiß nicht genau ob es immer 100%tig funktioniert. Der Tiefentest ist bei zNear ja immer am genausten und gegen zFar hin wird er ungenauer. Zu mindest wenn man einen zu geringen zNear auswählt kann es sein, dass man arge Probleme bekommt. Wenn ich dieses komische Verhalten noch richtig in Erinnerung habe. Ich weiß nicht ob ein negativer Wert da auch solche Phänomene mit sich bringt. Aber anscheinend funktioniert es ja wunderbar.

Ich verwende speziell für 2D immer ganz gerne den Tiefentest GL_LEQUAL. Dabei werden auch Objekte gezeichnet die auf der selben Position wie andere liegen. So dürfte man dann auch mit wesentlich weniger Ebenen auskommen. Da als Letztes immer noch die Zeichenreihenfolge dafür sorgt, dass die Objekte angezeigt werden. Wobei ich keine Ahnung habe ob das überhaupt in dein Konzept passt. Bin bisher aber immer recht gut damit gefahren.

fast, es muss so heissen:

Stimmt. Jetzt wo du es sagst.
Habe das oben mal angepasst.

@Lossy: Wegen dem Ortho... Ich hätte es auch lieber, wenn ich die Koordinaten direkt angeben könnte, ohne sie vorher von der Formular-Höhe subtrahieren zu müssen. OpenGL zeigt jedoch im Ortho-Modus eine merkwürdige Eigenschaft: Normalerweise ist der Koordinatenursprung ja unten links. Sobald ich im Ortho-Modus aber Texturen aktiviere, wird das Koordinaten-System plötzlich an der X-Achse gespiegelt und der Ursprung wandert nach oben links. Daher die Rechnerei. Wüsste auch gerne, warum das so ist.

Und AFAIK sind die Texturkoordinaten auch irgendwo gedreht. Ganz merkwürdige Sache.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Wenn du dann die Koordinaten einfach nur spiegels ist die Erstellungsreihenfolge (Uhrzeigersinn oder dagegen) der Punkte anders und entsprechend siehst du dann die Rückseite deiner Fläche. Was natürlich dann dazu führt, dass deine Textur auf dem Kopf steht. Das musst du dann auch entsprechend anpassen.

Gleiches lässt sich auch auf die Textur übertragen. Die Textures, glBmp und fast alle Handimplementationen laden die Texturen wie sie auf Platte gespeichert sind. Da die aber in die Datei auf dem Kopf abgespeichert sind, werden die auch auf dem Kopf geladen. Bei der glBitmap ist das anders und ich benutze das so wie ich normal auch die GDI benutzen würde und habe damit bisher noch überhaupt keine Probleme gehabt.

Aber wieso ändert sich das Koordinatensystem, wenn ich Texturen aktiviere?

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Okay. Das entzieht sich meiner Kenntnis. Bzw kann ich so jetzt nicht beurrteilen. Würde aber mal sagen, dass wir das dann in einem neuen Thread besprechen sollte. Und dann auch mit Bilder und Codeschnippsel.