Hi, Leute,
ich muß 3D-Mesh-Objekte von erheblicher Größe (nur so als Hausnummer: 4096 x 512 Aufpunkte als TriangleStrip => 2.093.056 Vertices) mit der Maus in Realzeit (!) manipulieren, d.h. texturieren, drehen, zoomen, Schnitte bilden etc. Das Ganze soll im Rahmen eines Datenvisualisierungsprojektes stattfinden. Ich stelle wider Erwarten fest, daß der CPU-Aufwand beim Drehen offenbar jeden Rahmen sprengt. Bisher hatte ich angenommen, daß das Programm die Vertices nur einmal auf die Grafikkarte 'runterläd und daß diese als "Spezialistin" dann den Rechenaufwand trägt, wobei immer nur neue Kamerapositionen runtergeladen werden müssen (was die CPU ja nun wirklich nicht überfordern sollte).

Liegt hier ein Denkfehler vor?
Wenn ja, hat jemand einen Tipp, wie ich dem angestebten Ziel näher kommen könnte? (Eigentlich müßte das doch bei der Entwicklung attraktiver Spiele zum "täglichen Brot" gehören, hätte ich vermutet.)

Wäre Euch für sachdienliche Hinweise sehr dankbar.

Ach ja, ich benutze GLScene als Objektkapsel für OpenGL.
Könnte das vielleicht der Performance-Fresser sein?

Gruß,
apo_pq

Sorry, Rechenfehler: es sind ja sogar 4186112 Vertices!

Btw: Ich habe in einem OpenGL Programming Guide gelesen, daß viele strukturbeschreibende Listen auch als Indexlists übergeben werden können, was den Aufwand vielleicht reduzieren könnte. Die Schnittstellen, die ich bisher sah, ließen aber dafür keinen Raum. Kann mir jemand erklären, wie das gemacht wird?

apo_pq

So viele Fragen auf einmal.

Eines vorne weg. Nicht alles ist in Spielen so wie es scheint. Nirgends wird so viel Getrickst wie in Spielen. Eben weil man die meisten Effekte mit simplen Tricks und minimalen Grafikeinschränkungen doch realisieren kann. Bei der visuellen Darstellung von Daten sollte man aber nicht so wirklich Tricksen. Und noch mal ne Hausmarke zu nennen. Wenige Spiele bestehen derzeit aus 1 Mio Dreiecke pro Bild. Wirklich ziemlich wenige. Dafür haben die aber auch rechenintensive Effekte.

Als erstes würde ich persönlich glScene weglassen. Ich hatte auch schon mal ein Projekt zu meiner Anfangszeit und muss gestehen, dass es zwar recht einfach war aber im nachhinein haben sich gewisse Knackpunkte herrausgestellt. Und zwar hat er einige Dinge immer und immer wieder getan die eigentlich nicht notwendig gewesen wären. Und wenn ich versucht hätte diese weg zu optimieren, dann hätte ich es wohl einfacher alles per Hand machen können. Es kann aber sein, dass du eher Dinge verwendest die sich nicht so sehr in der Geschwindigkeit äußern.

Und so wie sich das für mich anhört wirst du um Vertext Buffer Objects nicht herrum kommen. Die VBOs sind die Möglichkeit Vertexdaten (und Farbe, Texturekoordinaten, Normalen etc) direkt in den Speicher der Grafikkarte zu legen. Ähnlich einer DL. Allerdings mit dem geringfügigen Unterschied, dass du später noch die Möglichkeit hast dir den Pointer geben zu lassen und diese Daten zu verändern. Damit solltest du einmal anfangen. Allerdings kann es durchaus sein, dass du von deinem Triangle Strip weg musst. Fakt ist, dass ein Strip nur aus einer Zeile besteht. Und somit hättest du reichlich OpenGL Aufrufe. Dadurch könntest du den Indexbuffer zwar verkleinern aber es kann sich auch negativ äußern. Da musst du mal mit rumspielen und Schauen was sich wie wo am Besten macht.

Dazu gab es von NVidia auch ein Dokument was auf jeden Fall zu deiner Flichtlektüre gehören muss! Das ist bewusst so drastisch geschrieben.

Die Texturtransformationen kannst du im gewissen Rahmen auf mit der Texturmatrix lösen. Oder mit leichten Vertexshadern.

Auf jeden Fall hast du dir da ein nicht unheikles Thema ausgesucht. Und du solltest dich nicht scheuen eine entsprechende Mindestanforderung dafür festzulegen. Oder evtl wird es auch von Nöten sein, dass du immer nur einen gewissen Ausschnitt darstelst und Live bearbeiten kannst.

Vielen Dank erstmal für die prompte Antwort! Die gelinkten Dokumente werden wohl demnächst meine Feierabendlektüre bilden.
Für meinen Entwicklungsrechner (und die sind ja meistens etwas sparsamer ausgestattet als die Anwendungsrechner) war die gerade noch praktikable Größe von ca. 512 x 128 Vertices zu ermitteln. Ich denke, im realen Betrieb werden 1024 x 128 auch noch erträglich laufen. Die Maximalforderung scheint aber echt indiskutabel zu sein.

Wegen des Zeitdrucks und des schon weit gediehenen Entwicklungsfortschritts ist ein Ausklinken von GLScene z.Z. wahrscheinlich nicht realistisch. Ich denke aber, daß man das Ganze "schichtweise" optimieren kann und so die wirklich Performance-bestimmenden Passagen direkt in OpenGL re-implementieren kann. Da werden dann wohl die Buffer Verwendung finden, wenn ich nach einigen Fingerübungen den Umgang damit erlernt haben werde. Aber schön immerhin, daß mein Verdacht offenbar Bestätigung erfährt - man kommt sich gleich nicht mehr ganz so doof vor

apo_pq

Also bei solche großen Strukturen die verändert werden müssen wirst du an den VBOs nicht vorbei kommen. Zu mindest nicht, wenn du es nicht halbwegs performamt gestalten möchtest.

In glScene gibt es ein Objekt mit dem du selber OpenGL Code programmieren kannst. Ich denke das solltest du benutzen so lange glScene noch zwingend erforderlich ist. Und ein genereller Tipp. Du solltest auf jeden Fall die Anzahl der in glScene dargestellten Objekte also TCube etc so gering wie möglich belassen. Das war nämlich bei mir das Hauptproblem. Da wurden dann gigantisch viele Eigenschaften gesetzt obwohl sich nichts verändert hatte.

Ich habe gerade mal gerechnet (uhhh) und würde mal darauf tippen, dass du in einer doppelt verschachtelten Schleife renderst. Bzw evtl auch eine DisplayListe aber dann ist die Grafikkarte so etwas in dem Dreh um eine Geforce 1-2 oder Radeon 7x. Grob geschätzt.

Die Geschwindigkeit ist extrem davon abhängig was die Grafikkarte kann (die Busgeschwindigkeit/art ist auch nicht unwichtig) und ganz wichtig ist wie gerendert wird. Es gibt unzählige Möglichkeiten etwas zu rendern. Allerdings sind nur wirklich wenige davon für extreme Datenmengen ausgelegt. Von daher wäre es auch mal interessant zu erfahren was für Grafikkarten du benutzt und wie du bisher dein Mesh renderst?

GLinfo2 meldet:
GeForce4 MX 420/PCI/SSE/3DNOW!
NVidia Corp.
Vers. 6.14.10.9131
OpenGL Vers. 1.5.7
Aber das ist vermutlich nicht das, was Du meintest, oder?
Ich trage aktiv ziemlich wenig zum Rendering bei: Ich versorge die MaterialLib, setze die Kopplungsparameter der Texturkoordinaten und danach disabled auf false... Fehlt was? Wie gesagt, ich bin noch nicht so lange im OpenGL-Geschäft.

Ja doch. Das war ziemlich genau das wonach es mir begehrte. Die Geforce 4 MX ist nicht unbedingt eine Wucht aber könnte/sollte die VBOs in akzeptabler Geschwindigkeit unterstützten.

Und mit deinem Rendern muss ich ehrlich passen. Keine Ahnung was glScene da genau macht. Aber alleine von der Leistung die du dort erwähntst gehe ich davon aus, dass es itteratives Rendern ist. Also alles nur in einer/zwei Schleife/n. Das ist so ziemlich die Schlechteste Art etwas zu Rendern. Ich würde aber in jedem Fall dazu raten, dass du es per Hand mit VBOs erledigst.

Gerade ist mir wieder was eingefallen. Auf www.delphigl.de findest du unter "OpenGL" -> "Demos" eine Demo Namens "Vertexpufferobject". Diese benutzt als Grundlage ein 1024x1024 Pixel großes Bitmap. Wenn du dieses mal bei dir startest dürftest sehen, ob du mit VBOs bei dir eine angemessene Geschwindigkeit erreichen kannst oder nicht.

Hallo apo_pq,

ich könnte dir vielleicht noch das Buch "Level of Detail for 3D Graphics" von Luebke, Reddy, Cohen, Varshney, Watson und Huebner empfehlen.

Viele Grüße
dj3hut1