Also, ich bin erst letzte Woche über diese Seite und das OpenGL gestoßen.
Ich beschäftige mich das erste mal mit 3D Programmierung und habe folgenden Auftrag bekommen:
Ich soll eine sich drehende Glaskugel programmieren (Bildschirmschoner).
Ich hab mich erstmal bis zu einem bestimmten Punkt durch dieier Tutorials gearbeitet.
Das mit dem Glaseffekt (durchsichtigkeit) das ist derzeit noch nicht mein Problem da ich soweit noch nicht bin...
Aber hier erstmal mein Quelltext:



Nun, da man ja ohne Bezugspunkt zu irgendetwas eine Drehung der Kugel nicht wahrnehmen kann, hab ich die Lichter eingebaut.
Allerdings führt die Berechung dieser zu einer CPU-Auslastung bei nicht ganz so neuen PC's die auch schon mal 100% betragen kann.
Kann man diese Ansprüche an die CPU irgendwie runterschrauben?

Edit...

Das Problem ist halt, es ruckelt...

Das sollte eigentlich ganz leicht sein.

Betrifft: die "Methode TForm1.Render"

Die folgenden Zeilen:


....sind eine Initilaisierung des Lichts und müssen nur einmal gemacht werden, sie gehören daher ANS ENDE der Methode "FormCreate".

Der wirkliche Grund für die Totalbeschäftigung der CPU ist aber m.E. folgende Zeile:


Was geschieht hier? gluSphere zeichnet eine Kugel, das ist OK. gluNewQuadric aber ERZEUGT eine Kugel. Das bedeutet: Du erzeugst bei jedem Renderdurchgang ein Kugelobjekt, nur um es zu zeichnen. Wenn Du 60 Renderdurchgänge pro Sekunde hast (das ist ein schwacher Wert) erzeugst Du 60 Kugeln pro Sekunde, die nirgendwo mehr gelöscht werden und schreibst Deinen RAM damit voll. Vielleicht kommt ein moderner Computer damit zurande (besonders wenn Du das Programm bald abbrichst), aber ein etwas älteres Exemplar ist damit - wie Du ja selbst schreibst - überfordert.

Richtig wäre daher mit "gluNewQuadric" AM ENDE der Methode "FormCreate" eine Kugel zu erzeugen und sie mit "gluSphere" in der Methode "Render" zu zeichnen. Guter Programmierstil wäre es, die Kugel mit "gluDeleteQuadric" AM ANFANG der Methode "FormDestroy" zu löschen.

Übrigens: Das Backface-Culling muss man auch nicht immer aus- und einschalten, es genügt durchaus, es einmal am Anfang (im onCreate)zu setzen.

Viele Grüße
Traude

PS: wenn die CPU-Ausnutzung Deines Programms über 2% hinausgeht, ist immer noch etwas falsch.

PPS: Noch etwas fällt mir auf: Der Befehl "PushMatrix" sichert eventuell vorher gesetzte (Projektions-/Modell-)Matrizen. In diesem Programm ist die Klammer PushMatrix/PopMatrix überflüssig, denn es gibt gar keine vorher gesetzten Matrizen. Wenn Du das aber in ein größeres Programm einbauen möchtest, lies Dir bitte nochmal die Beschreibung dazu durch.

Hab den Code geändert, das ganze sieht jetzt so aus:



Hab aber immer noch 100% CPU-Auslastung...

Schraub mal Deinen Timer runter.

PS: gluSphere zeichnet die Kugel. Das ist im OnCreate fehl am Platz.

Traude da kann ich leider nicht ganz zustimmen. gluNewQuadric erzeugt ein Quadric object welches meines Wissens nach nur so ein paar Einstellungen kappselt. Mit diesem Quadric kann man dann eine Kugel zeichnen. Trotzdem stimmt es vollkommen, dass dieses Quadric auch immer wieder Freigegeben werden müssen oder nur ein mal erstellt und wieder freigegeben werden. Denn sonst läuft irgendwann der Speicher voll. Das sind zwar nur wenige KBs pro Aufruf aber die Anzahl der Aufrufe macht es.

Die Zeile die Traude angegeben hat ist meiner Meinung nach der Auslöser. Allerdings aus einem anderen Grund. Du gibst bei gluSphere an, dass die Kugel aus 700 Slices und 700 Stacks bestehen soll. Das hat zur Folge, dass deine Kugel von Oben nach Unten in 700 Teile zerschnitten wird und dieser Teile jeweils noch einmal in 700 Einzelteile zerschnitten werden. Wenn ich mich nicht verrechnet habe, dann besteht deine Kugel auch 978.600 einzelnen Dreiecken die bei jedem Bild immer wieder und wieder berechnet werden müssen. Entweder benutzt du kleinere Werte (32x32 oder 64x64 sollten für runde kugeln durchaus reichen) oder aber du solltest die Kugel selber berechnen und dann die einzelnen Dreiecke mit so etwas wie einem VBO zeichnen. Dann werden die Daten auf der Grafikkarte abgelegt was dazu führt, dass die Werte nicht ständig neu berechnet werden müssen.

PS: Wenns sein muss würde auch eine Displayliste reichen um die Daten zu speichern. Die ist besonders in deinem Fall vermutlich doch etwas einfacher zu erstellen.

Lossy, er spricht von einem "etwas älteren Computer". Da wäre doch möglich, dass VBO gar nicht zur Verfügung steht.

Ansonsten tschuldigung: ich arbeite normalerweise nicht mit gluSphere. Klar bei einem solchen Kugelobjekt ist das Zeichnen ziemlich umfangreich, daher korrigiere ich mich und sage: schraub mal Deine Kugelausmasse nach Lossys Angaben zurück.

Es ist sicher möglich, eine genügend "smoothe" Kugel zu zeichnen, ohne dass die CPU-Auslastung explodiert. Das Ziel sollte sein, dass das Rauf- oder Runterschrauben des Timers direkt proportional mit der CPU-Auslastung ist.

Ich hab den Interval des Timer's auf 1 Sec. gestellt.
Das hat bereits schon ganz schön was ausgemacht... der stand vorher auf 25 ms...
Ich hab die Kugel jetzt auf 64 x 64 getrimmt.
Das hat dann das ganze abgerundet auch wenn es jetzt ein bischen eckiger ist *lol...
Naja danke für die Hilfe, habt mir da noch mal ein paar Dinge klargemacht.

mfg Cre@or

Ah. Habe ich nicht gelesen, dass es auch für ältere System ist. Aber ja. Auf reichlich älteren Grafikkarten gibt es VBOs nicht in Hardware. Mittlerweile emulieren aber die Hersteller das im Treiber. Und dann würden in jedem Falle die Berechnungen der Punkte wegfallen. Zu was ich so oder so in jedem Falle nur raten kann. Egal ob neu oder alt oder ob die Kugel groß oder klein wäre. Das ist massiver nicht nötiger Rechenaufwand, den man immer vermeiden sollte.

Sollten VBOs nicht existieren könnte man auch VertexArrays benutzen. Sind relativ gleich und werden überall unterstützt. Wobei DisplayListen wie gesagt auch genügen. Dann muss sich der Treiber darum kümmern, dass die Daten dort lange wo es am Schnellsten ist.

PS: Besonders bei älteren System dürfte die Anzahl der Dreiecke schon zu groß werden. Selbst wenn man sie nicht ständig neu berechnen müsste wäre es allein von der Anzahl her schon ein richtiger haufen Arbeit für die Karte.

Der Timer wartet wie lange und dein System ist was für eines ?
Ist der Timer zu niedrig eingestellt, dann ensteht ne menge cpulast, da er ziemlich oft durchläuft und die Szene entsprechend neu zeichnet.

Wenn ein normales 3D Computerspiel nicht bei 100% läuft würde ich mir sorgen machen, dann ist es nicht gut Entwickelt worden.
Das Spiel soll ja alle verfügbaren Ressourcen krallen und soviel wie möglich draus machen und wenn es 500FPS statt 100FPS bei der Physik und KI durchrattert. Das zeichnen kann man auf ein 100FPS Cap beschränken, da setzt das Auge eh schon weit vorher aus und 100Hz ist nur noch für die Monitortechnik wichtig(flimmern bei schlechten Monitoren verschwindet und man will doch auch Full-HD supporten, welches bei 1080P einen 100Hz Modi kann).
Bei Software, die 3D Visualisierung verwendet, ist es der Gegensatz, man will so selten wie möglich zeichnen, rechnen und Ressourcen verbrauchen.

Wenn deine CPU zu den älteren gehört, dann ist eine höhere Last normal und wenn deine Grafikkarte zu alt ist, dann kann deine Anwendung in Softwaremodus laufen und deine CPU ist wieder voll ausgelastet.

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

Projekte: https://github.com/tak2004