Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Jul 18, 2025 12:25

Foren-Übersicht » Programmierung » OpenGL
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 8 Beiträge ] 
Autor Nachricht
BeitragVerfasst: Mo Mai 05, 2008 09:53 
Offline
DGL Member

Registriert: Fr Feb 29, 2008 11:57
Beiträge: 16
Hallo !

Ich will in einer 3D-Szene mit der Maus auf die Eckpunkte der dargestellten Geometrien schnappen.
Dabei soll der User mit der Maus nur in die Nähe eines Eckpunktes fahren und das Programm liefert
den nächstliegenden sichtbaren! Eckpunkt. Bisher mach ich das via FeedBack-Puffer.
Das Rendern in den FeedBack-Puffer ist aber je nach Treiber ziemlich langsam.
Hat jemand einen Ansatz, der ohne FeedBack-Puffer auskommt und die Geometrien irgendwie selber durchscannt ?
Weis jemand ein Tutorial / eine Beschreibung wie man sowas am geschicktesten (und wiklich schnell) macht ?
Zum Finden des naheligensten Punkts unter der Maus habe ich verschiedenste Lösungen gefunden.
Die berücksichtigen aber nicht, das der User natürlich nur die aktuell wirklich sichtbaren Ecken fangen will
und nicht die von verdeckten Objekten.

Bin dankbar für jeden Tip!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mai 05, 2008 13:23 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7810
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Beim Feedbackbuffer könntest du die Pickmatrix größer machen. Allerdings bin ich mir überhaupt unsicher ob deine Nutzer damit sehr glücklich sein werden. Was wenn mehrere Punkte im Bereich sind. Nicht immer ist das nächste auch das was der Nutzer will. ;)

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mai 05, 2008 14:31 
Offline
DGL Member

Registriert: Fr Feb 29, 2008 11:57
Beiträge: 16
Danke für Deinen Tip !

Unsere User sind seit einigen Jahren extrem zufrieden mit der Tatsache, auf den am nächsten liegenden Punkt zu schnappen,
auch wohl deshalb weil ich das bei jedem Mouse-Move mache und den geschnappten Punkt mit einem kleinen Kreischen kennzeichne.
Beim Klicken wird dann der Eckpunkt genommen der gerade gekennzeichnet ist. Ich nenn das "vorausschauendes Fangen"
Das einzige, was stört, ist die ungenügende Geschwindigkeit mit der das abläuft.
( Für den Flächen-Fang verwende ich den Ray-Triangle-Intersection Algorithmus von Tomas Möller. Der ist echt höllisch schnell )
Wenn ich für den Punktfang nur auch sowas schnelles hätte !


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mai 05, 2008 15:18 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7810
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Na wenn der so gut ist, dann machs doch mit dem. Du kannst doch deine Punkte mit einem Rechteckigen "Bounding Volume" umgeben und dann deinen bisherigen Algorithmus benutzen.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mai 05, 2008 17:57 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Zitat:
Hat jemand einen Ansatz, der ohne FeedBack-Puffer auskommt und die Geometrien irgendwie selber durchscannt ?


Mögliche Lösung 1:
--------------------
Man schießt mit gluUnproject eine Gerade von der Kamera aufs Objekt und ermittelt dann das getroffene Polygon. Der Polygonpunkt, der sich dem Geradenschnittpunkt am nächsten befindet, ist der Lösungspunkt. Diese Lösung hat den Vorteil, dass es bei einem geschlossenen Mesh IMMER ein vorderstes (sichtbares) Polygon gibt. Voraussetzung ist natürlich, das das Polygon seine Eckpunkte kennt.

Mögliche Lösung 2:
--------------------
Punkte fangen in einem geraden Korridor (ein Konstrukt aus vier Wänden=Ebenen). Jede Korridor-Wand ist eine "Innenwand" im Sinne von OpenGL; mit jeder Wand kann man prüfen, ob der Punkt "vor" ihr ist; wenn er "vor" allen vier Wänden ist, liegt er im Korridor; das ist der gleiche Test den man beim Backface Culling benutzt: ein Skalarprodukt. Wie Du den Korridor aufbaust, hängt von Deiner Projektion ab. Bei orthogonaler Projektion genügt das gluUnproject, ich nehme an das hast Du schon gefunden. Bei perspektivischer Projektion muss man das anders machen, denn sonst wird der Korridor nach hinten immer größer, genau wie das Frustum (= der Sehkegel). Sollte die Anzahl der gefangenen Punkte größer als 1 sein, so müssen die Punkte nach der Entfernung zur Kamera sortiert sein. Der Punkt mit dem geringsten Abstand zur Kamera ist der Hauptverdächtige. Diese Lösung hat den Nachteil, dass es NICHT IMMER einen sichtbaren Punkt gibt, das hängt nämlich vom Querschnitt des Korridors ab. Es kann also vorkommen, dass alle im Korridor befindlichen Punkte verdeckt sind.

Beide obigen Lösungsmöglichkeiten kann man durch die Kombination mit einer Raum-Verwaltung mittels Octree ungeheuer verbessern. Denn wenn man das nicht hat, muss man eben alle Polygone bzw. Punkte abfragen. Ich glaube sogar, dass es Material zum Octree im Wiki gibt, ich bin mir aber nicht sicher. (Nach Deiner Antwort an Flash bin ich mir aber sicher, dass Du damit was anzufangen weißt).


Zitat:
Zum Finden des naheligensten Punkts unter der Maus habe ich verschiedenste Lösungen gefunden. Die berücksichtigen aber nicht, dass der User natürlich nur die aktuell wirklich sichtbaren Ecken fangen will und nicht die von verdeckten Objekten.


Mögliche Lösungen:
-----------------------

1) Mit OpenGL:
---------------
Occlusion Query, da weiß ich aber nicht wirklich Bescheid (es gibt im Wiki ein Tutorial dazu)

2) Ohne OpenGL, Version1:
-------------------------------
Die Frage ist doch: wann ist ein Ding verdeckt? Der schnellste Ansatz ist wieder eine gute Raumverwaltung zu haben, eben z.B. einen Octree:
*** Raumabschnitt zwischen gefangenem Punkt und Kamera ermitteln
*** die Polygone dieses Raumabschnitts (oder alternativ alle Polygone) testen ob sie von einer Gerade Punkt=>Kamera geschnitten werden und der Schnittpunkt zwischen dem "gefangenen" Punkt und der Kamera liegt. Das ist stabil und genau, aber wenn man alle Polygone testen muss, ist das sehr langsam

3) Ohne OpenGL, Version 2:
--------------------------------
Unter der Voraussetzung, dass der Benutzer nur EINEN Punkt anklicken will und dabei einen Punkt AUCH SEHEN kann: man beläßt es einfach bei dem Punkt, den man mit einer der beiden oben angeführten Lösungen bereits gefangen hat. Das ist viel schneller, aber schlampiger und bei der Variante mit dem Korridor zuweilen falsch, nämlich dann wennn wie oben schon gesagt, ALLE gefangenen Punkte verdeckt sind. Diese Lösung ist sicher nicht praktikabel, wenn der User einfach mit der Maus über das Objekt fährt, sondern nur wenn er bewusst einen Punkt anklickt.

4) Ohne OpenGL, Version3:
-------------------------------
Wenn der Benutzer ein Viereck aufziehen und daher auch mehrere Punkte "fangen" kann, besteht die Möglichkeit, einen "Region Growing"-Mechanismus zu erstellen, der nur benachbarte Punkte zurückgibt. Voraussetzung: Deine Geometrie muss es zulassen, dass Du im Mesh von Punkt zu Punkt wandern kannst. Die Schnelligkeit dieses Algorithmus hängt davon ab, wie gut Deine Geometrie ihn unterstützt

Jetzt bin ich mit meiner Weisheit am Ende. :wink:
Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mai 05, 2008 18:35 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Okt 07, 2006 16:27
Beiträge: 52
Wohnort: Marbach(bei Chemnitz)
Ich weis nicht, ob ich irgendetwas übersehe, aber man könnte doch das gleiche Prinzip anwenden, wie bei der Selektion mittels Farben.
Heißt:
Man rendert (je nachdem, was man für eine Reaktionszeit haben will) in bestimmten Abständen einen Frame, in dem nur die Eckpunkte dargestellt werden in den Buffer. Dabei wird jeder in einer anderen Farbe dargestellt (sollte schnell gehen). Dann überprüft man, ob in einem bestimmten Bereich um die Maus ein Punkt ist, liest die Farbe aus und überprüft, welcher von den gefundenen Punkten am nächsten ist.
Um zu überprüfen, ob er verdeckt wird kann man ja z.B. mittels Octree die Umgebenden Polygone nochmal Rendern (kann dann ja alles in einer Farbe und ohne Texturen, ... sein) und schauen, ob der Punkt immer noch sichtbar is.

So würde ich das anstellen

_________________
Es gibt eine Theorie, die besagt, wenn jemals irgendwer genau rausfindet, wozu das Universum da ist und warum es da ist, dann verschwindet es auf der Stelle und wird durch etwas noch Bizarreres ersetzt.
Es gibt eine andere Theorie, die besagt, dass das schon passiert ist.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mai 05, 2008 19:17 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Die Lösung ist im gegensatz zum Geometrischen Ansatz aber deutlich langsamer. Schließlich muss man in der gerenderten Textur nochmal eine Menge Pixel abfragen. Dazu kommt das risiko, dass man, bei zu geringer Farbtiefe, möglicherweise zwei Punkte mit gleicher Farbe hat. Da das eine Echtzeitanwendung ist, müsste man zusätzlich bei jeder Mausbewegung einmal alle Punkte rendern. Je nach OpenGL Implementation und anzahl der Punkte kann das böse enden.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Mai 06, 2008 07:08 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Guten Morgen,
Mir ist noch etwas eingefallen, das Tak2004 kürzlich irgendwo erwähnt hat: bei Punkten gibt es auch die Möglichkeit, ebenfalls mit einer Gerade zu arbeiten und den Abstand der Punkte zu dieser Gerade zu messen (Formel findest Du http://nibis.ni.schule.de/~lbs-gym/Vektorpdf/AbstandPunktGerade.pdf). Der Punkt, der am dichtesten dran liegt ist es dann. Hat aber den gleichen Nachteil, dass alle Punkte verdeckt sein könnten.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 8 Beiträge ] 
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.007s | 15 Queries | GZIP : On ]