HI,

ich wollt fragen ob es ne einfache Funktion gibt um herauszufinden
welches Objekt sich gerade unterm Mauszeiger befindet, oder ob ich
das alles selbst berechnen muss?
Schonma Danke für die Hilfe...

MfG & Thx Bergmann.

Gibt es, und nennt sich unter OpenGL "Selektion". Dazu gibts bei uns Tutorials und sehr viele Themen hier im Forum. Allerdings ist diese fast schon ein Relikt und mit so ziemlich allen aktuellen Treiber so langsam dass man die Finger davon lassen sollte. Eine einfach zu implementierende, flexiblere und schnellere Alternative ist die Farbselektion, dazu gibt es hier auch einige Themen im Forum. Prinzipiell rendert man seine Objekte dabei ohne Texturen, Beleuchtung, etc. aber mit einer festen Farbe (pro Objekt eine andere) in den hinteren Puffer, liest dann die Farbe an der Mausposition und kann dadurch ermitteln welches Objekt unter der Maus ist.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

HI,
das mit den Farben wird wohl nix werden: Ich programmier grad an nem
Zauberwürfel, und da hat jedes Würfelelement eine andere Farbe...
Kann man das nich noch irgendwie anders machen?

Hi,

Die Farbselektion nutzt nicht die Farben die schlußendlich ausgegeben werden sondern du legst für jedes Objekt welches selektiert werden kann eine Farbe fest die nichts mit dem aussehen deiner Szene zu tun habt.
Dann Renderst du die Szene ohne Beleuchtung und ohne Texturen. Nach dem Rendern schaust du welche Farbe die Mausposition im Backbuffer hat und vergleichst diese mit den Selektionsfarben deiner Objekte und weist so welches Objekt unter der maus liegt.
Jetzt bereinigst du den Backbuffer wieder und Zeichnest die Szene so wie si aussehen soll, mit Beleuchtung, Texturen und ohne die Selektionsfarben.

Ich hoffe ich konnte dir mit der Erklärung helfen.

_________________
ghost-site.de

OK, jetzt hab ich's verstanden ^^
THX

Ne Überlegung:
Um das noch zu optimieren, kann man bestimmt auch den Viewport ganz klein machen. Bei der Orginal OpenGL Selektion wurde das gemacht, um nur den Teil der Szene neu zu rendern, der direkt unter der Maus liegt.

Denkt ihr, dass das sinnvoll ist, oder machen die Statechanges den Vorteil kaputt?

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

Vom Prinzip her stimmt es. Nur hat die klassische Selektion nicht den Viewport angepasst sondern lediglich die Projektionsmatrix. Der zu selektierende Bereiche (1x1 Pixel) hat sich dann über den gesammten Viewport erstreckt.

Ich würde vermutlich eher die Clipping Planes setzen. Aber frag mich nicht wie das geht. Hab ich noch nie gemacht. Dabei kann man Flächen einstellen an denen die Grafikkarte clipt. Wie der Name ja schon sagt. Dann bleiben die Einstellungen für die Ansicht die Gleiche. Das war bei der klassischen Selektion immer so ein Knackpunkt, da man praktisch blind rendern musste. Jetzt geht es aber ob das Bild sonderlich aussagekräftig ist wage ich trotzdem mal zu bezweifeln.

Ich denke aber schon, dass es etwas bringen dürfte. Besonders bei wirklich vielen Flächen, denn dann werden die Flächen schon recht früh verworfen und nicht erst noch durch den Rasterizer gejagt. Der die dann ja wieder in den Framebuffer schreiben muss etc etc.

Warum so kompliziert, wenn es mit dem Scissortest doch ganz einfach zu realisieren ist. Einfach vorm Zeichnen der Szene für die Farbselektion eine Scissorbox rund um den Cursor festlegen (evtl. 4x4 Pixel, dass dürfte reichen) und dann die Szene mit aktiviertem Scissortest zeichnen. Alternative wäre dann evtl. noch das von der Grafikkarte eh ausgeführte Guard Band Clipping, aber ich glaub unter OpenGL geht das nicht bzw. die Reichweite für dieses Clipping ist nicht veränderbar (und erstreckt sich damit über die max. von der Grafikkarte anzeigbare Viewportreichweite, i.d.R. 4k x 4k).

Edit : Ich hab kurz in PjW getestet. Ich nutze dort eigentlich gluPickMatrix um eine Projektionsmatrix für den kleinen Auswahlbereich zu machen, und hab mal gegen den Scissortest gewechselt. Ergebnis : Die von der normalen Selektion her genutzte gluPickMatrix ist schneller.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich dachte Scissor arbeitet auf Fragmentebene wogegen die Clipplanes auf vertexebene arbeiten und somit früher abbrechen dürften wenn sie nicht im gewünschten Bereich liegen.

_________________

Ja, der Scissortest arbeitet auf Fragmentbasis. In modernen 3D-Anwendungen liegt der Schwerpunkt aber eh meist genau dort (z.B. komplexe Shader, Overdraw, etc.).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

HI,

irgendwie find ich kein passendes Tutorial zur Farbselektion. Kein
Beitrag im Forum, kein Thema im DGL Wiki und auch nix bei Google.
Hat jemand n Link dazu oder kann das hier ma kurz posten?

MfG & Thx Bergmann.

Da brauch man kein Tutorial für. Deine Szene mit passenden Farben (halt z.b. für jede Einheit ne andere Farbe) rendern (ohne Puffer tauschen) und dann mit glReadPixels die Pixelfarbe unter dem Cursor auslesen und vergleichen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Colorpicking ist mit Vorsicht zu geniessen und nur für den Anfang geeignet.
Wenn du zu dem Lego Kasten, ab 16Jahren, dann greifst, liegt da raycast intersection drin.
Dafür hat men ein größeren Innitialisierungsaufwand aber ist dafür unabhängig, schneller.
Colorpicking wird mit OpenGL3 zu 99,9% rausfliegen, da es erstens eine langsame Methode ist(ziemlich unwichtig), zweitens ungenau(steigende Auflösungen wirken entgegen) und drittens nicht multi GPU programming erlaubt(der eigentliche Grund).
Wenn dir raycast intersection noch nichts sagt, dann wird folgendes ein bischen helfen.
Raycast ist ein Strahl, den man aus der Sicht der Kamera in die Welt schiesst und alle Objekte, die den Strahl schneiden(intersection) werden auf die Entfernung geprüft. Das Objekt mit der kürzesten Disstanz ist dann dein Objekt.
Das ist natürlich nur ne grobe Beschreibung, da passiert noch ein bischen mehr und es erlaubt auch noch ein paar weitere Features.
In der Regel wird die Funktion von dem Physik Modul übernommen(newton, bullet, ode und einige mehr haben solche funktionen schon drin).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Für einfache Sachen ist Farbselektion doch bestens geeignet, und mit OpenGL 3.0 wird das wohl kaum rausfliegen, denn immerhin implementiert man das ja selber. Jemandem der nur eine einfache Selektion implementieren will gleich Raycasting zu empfehlen halte ich für etwas übertrieben. Klar gibt es ein paar Sachen auf die man achten muss, aber überleg mal wie viele Anwendungen es gibt die gar kein Physikmodul nutzen (z.B. mein Projekt "W") weil schlichtweg keins benötigt wird. Im Endeffekt würde man bei so einer Anwendung mit einem Physikmodul ja jede Menge unnötigen Overhead erzeugen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Nur so aus interesse ist Raycast zu aufwendig um es selber zu implementieren??(sprich Raycast ohne externes Physik Modul)
Wenn nein giebt es irgentwelche Turtorials / Dokumente zu dem Thema??