maximale anzahl dargestellter punkte
- Ersteller darkfate
- Erstellt am
So weit ich weiß gibt es bei OpenGL keine Begrenzung der Anzahl von Eckpunkten (Vertices) zwischen glBegin() und glEnd(). Aus Performance-Gründen wird man aber eher auf Displaylists und VertexBufferObjects zurückgreifen. Da diese direkt im VRAM liegen wäre dann auch der verfügbare Grafikspeicher das limitierende Element.
Wenn du aber wissen willst wieviele "Punkte" man noch interaktiv darstellen kann ist eine Antwort so leicht nicht möglich.
Wenn du aber wissen willst wieviele "Punkte" man noch interaktiv darstellen kann ist eine Antwort so leicht nicht möglich.
G
Green Mamba
Gast
Displaylists werden bei einer Punktewolke wohl nicht helfen. Diese sind ja eher dazu gedacht viele gleichartige Objekte darzustellen. Ein Punkt ist ja erst mal ein nur ein Punkt den man direkt rendern kann.
Ich verstehe die Aufgabenstellung aber auch nich ganz, da viel zu knapp beschrieben. Aber stimmt schon, es gibt kein Limit für die Darstellung von Punkten.
Ich verstehe die Aufgabenstellung aber auch nich ganz, da viel zu knapp beschrieben. Aber stimmt schon, es gibt kein Limit für die Darstellung von Punkten.
Im Moment habe ich das Problem, dass ich nur etwa 5M Punkte gleichzeitig darstellen kann und bin schon bei ~1 Frames/s obwohl ich eine OpenGL Karte habe. Jetzt wollte ich wissen ob ich zu doof zum progrogrammieren bin oder ob sonstige Gründe nicht gegeben sind.
Kann ich irgendwie die 3D Beschleunigung erzwingen?
Ich habe mal einen Blick auf die Taktraten geworfen und gemerkt dass diese identisch zu den 2D Taktraten sind.
Kann ich irgendwie die 3D Beschleunigung erzwingen?
Ich habe mal einen Blick auf die Taktraten geworfen und gemerkt dass diese identisch zu den 2D Taktraten sind.
G
Green Mamba
Gast
Du meinst 5 Millionen Punkte? Zeig mal deine Renderloop, dann kann man vielleicht was dazu sagen.
Simpson474
Fleet Admiral
- Registriert
- Sep. 2006
- Beiträge
- 12.820
Willst du wirklich Punkte darstellen oder arbeitest du mit Polygonen/Dreiecken? Falls du wirklich jeden Eckpunkt per glVertex3f überträgst, so wäre die Performance sogar noch gut. In diesen Größenordnungen muss mit Vertex Buffer Objects gearbeitet werden, damit die Geometriedaten im Grafikkartenspeicher liegen und nicht jedes mal von der CPU neu übertragen werden müssen. Noch dazu kommt, dass allein 5 Millionen Funktionsaufrufe die CPU wohl ziemlich auslasten - ohne das auch nur irgendetwas in der Funktion gemacht wird.
Ähm, warum nicht? Meines Wissens nach sind DisplayLists nichts anderes als "vorkompilierte" OpenGL-Anweisungen die im VRAM gespeichert werden. Wenn ich nun aus der Punktwolke eine DisplayList generiere, kann ich doch das dadurch entstandene "Objekt" während der Programmausführung effizient rendern (verschiedene Transformationen angenommen), eben dadurch, dass die entsprechenden OpenGL-Calls bereits auf der GPU sind. Viele gleichartige Objekte darzustellen ist dann nur die konsequente Weiterführung des DisplayList-Konzeptes aber imho keineswegs die alleinige Motivation für die Verwendung von DisplayLists. Der Nachteil von DisplayLists liegt darin, dass sie statisch sind => VBOs.
Zurück zum eigentlichen Thema:
Es wäre wichtig zu wissen was du eigentlich machen willst, und das wurde auch im letzen Post angesprochen:
1. (ich glaube das ist dein Problem)
Beschreiben deine Koordinaten (=Punkte) eine (Ober-)Fläche?
Dann approximiere diese Oberfläche (z.B. mittels des MarchingCubes-Algorithmus) mit einer adaptiven Tesselierung (weg von den 5M Punkten). Wird ohne Erfahrung/Wissen sehr schwer.
2.
Haben deine Koordinaten einen zusätzlichen Wert (z.B. Farbe)?
Dann bist du in der Volumenvisualisierung und es wird ohne Erfahrung/Wissen unmöglich
Noch was zu
Da kann ich dir nicht so ganz folgen. Wenn du OpenGL-Commands verwendest hast du automatisch die "3D Beschleunigung"
Simpson474
Fleet Admiral
- Registriert
- Sep. 2006
- Beiträge
- 12.820
Die DisplayLists können grundsätzlich alles sein - es steht dem Grafikkarten-Treiber frei, diese entsprechend zu implementieren. Während nVidia sehr gute DisplayList-Optimizer hatte, hat ATI OpenGL nie wirklich interessiert. Als ATI mit der Radeon 8500 versuchte im HighEnd-Markt Fuß zu fassen, war OpenGL bereits relativ unwichtig geworden (dank DirectX 8.1). Heute ist OpenGL im PC-Spiele-Bereich fast schon ein Exot und auch die heutigen OpenGL-Treiber von ATI sind immer noch dafür bekannt, nur bei speziellen Settings einigermaßen schnell zu sein.
