...danke für die Hinweise, werde ich mir mal anschauen.

So, das ganze befindet sich jetzt als Beispiel für Rotation & Translation im SVN: Link
Dein Template wird als Basis genannt.

Übrigens ist mir beim Durchgehen und Kommentieren des Quellcodes aufgefallen, dass dein Quader auf jedemfall im 3D-Modus gezeichnet wird:
Der Quader mit 0.2, 0.6, 0.4 wäre ansonsten keinen Pixel gross

Ich glaube da haben wir uns missverstanden. Natürlich werden alle Geometrien mit 3D Koordinaten gezeichnet. Der Unterschied liegt doch nur an der Art der Darstellung. Während ich mit gluPerspective eben eine perspektivische Ansicht, wie es in 3D Spielen wichtig ist, darstellen kann, also einen Blick für die Tiefe bekomme, habe ich in der orthogonalen Ansicht zwar auch 3D aber keine Tiefeninformation. Wenn ich einen Würfel genau mit einer Seite nach vorne drehe, sind die Kanten der Rückseite verdeckt. Mit gluPerspective würde ich sie sehen.

Dein Beispiel ist doch klasse. Ich denke das wird vielen weiterhelfen.

Ich habe übrigens deinen Hinweis weiterverfolgt und bin dabei auf Beispiele von 'Vertex buffer object demo - © 2003 by Sascha Willems' gestoßen. Er hat sich da viel Mühe gegeben und alles verständlich dargestellt. Ich muss jetzt nur mal Prüfen, in wie weit ich das auf mein Programm üertragen kann. Auch die Frage ob man mit Vertex buffer oder Displaylisten anfangen soll. Denn im Vollbild gibt es auf meinem Rechner nur geringfügige Unterschiede in den FPS aber eine deutliche Steigerung zum 'zeilenweisen' Rendern.

Wow...jetzt bin ich aber von den Socken!

Ich habe einfach mal den ganzen Render-Abschnitt als DisplayList gespeichert und dem entspechend gerendert. Was soll ich sagen. Bei einem großen Modell hat sich die FPS mehr als verdoppelt, bei einem kleinen Modell fällt der Unterschied nicht so groß auf.
Der Pferdefuß an der Geschichte ist nur, dass ich nach jeder Anzeigenänderung (Knoten, Lines oder Elemente bzw. nach einer neuen Farbskalierung) die alte Liste Löschen und eine neue erstellen muss. Das Löschen der Liste dauert aber 1 bis 2 Sekunden...also kein Farbwechsel mehr in Echtzeit?

Oder mache ich da was falsch...muss die Liste eigentlich immer gelöscht werden? Oder könnte man sie einfach überschreiben?

Beispiel Code:

Du musst sie nicht löschen, glNewlist erstellt oder ersetzt eine Liste.

displaylisten sind für statische Geometrie, VBOs dagegen für dynamische. Da kannst du gezielt einzelne Werte verändern, ohen das ganze komplett neu aufzubauen.

_________________


"User Error. Replace User and hit Continue."

Ok, habe die Liste jetzt nicht mehr gelöscht, sondern den vorhandenen ersten Index DL verwendet und die Liste parktisch überschrieben.

Aber trotzdem dauert das bei Modellen mit 100000 Knoten bis zu mehreren Sek.!!! Auch wenn meine Hardware hier zuhause nicht mehr die neuste ist (Sempron 2.6+, ATI 9250), so kann das doch nicht sein. Die gleiche Schleife reagiert ohne Displaylisten sofort auf Änderungen, sie ist also relativ schnell und zeigt bei dem genannten Modell etwa 8 FPS. Mit Displaylisten komme ich auf über 20 FPS...aber bis die Liste erstmal generiert ist!!!

Woran kann das liegen?

..habe deine Nachricht beim Schreiben noch nicht gesehen. Dann muss ich mich wohl doch mit den VBO's beschäftigen, denn das ist so kein akzeptabeler Zustand.

du könntest auch mehrere display-listen verwenden, bei denen dann nur der betroffene teil neu kompiliert werden muss. im übrigen kannst du gltranslate und glrotate auch vor dem aufrufen der dl nutzen, damit du ihren inhalt verschieben kannst.

_________________


"User Error. Replace User and hit Continue."

Mehrere Listen bringen glaube ich nur beding was. Man könnte natürlich jeweils die Elemente, die Linie und die Knoten in verschiedene Listen Speichern, das wäre ok. Jedoch ist da immer noch der Pferdefuß mit den dynamischen Skalierungsfarben, die momentan mit einem Schieberegler in Echtzeit angepasst werden können. Wenn man die Farben unabhängig von den Listen steuern könnte, würde das so gehen.

Das mit den Verschiebungen habe ich schon so gemacht. Erst die Verschiebungen und Rotationen sowie der Zoom, dann wird gezeichnet, sonst würde das überhaupt nicht oder nur mit 0 FPS gegen. Funktioniert ja auch.

Das mit den VertexArrays habe ich auch mal probiert, stoße da aber auch noch auf erhebliche Probleme. Muss dafür erst mal ein Konzept entwickeln, damit auch alle Möglichkeiten offen bleiben.

Davon mal abgesehen funktioniert das Programm ja so wie ich es haben möchte, nur eben nicht optimal, da man weiss, was man verschenkt

Also... VBOs sollten da das Mittel zum Zweck sein. Die sind am flexibelsten und schnellsten.

Dass das Erstellen einer Dislpaylist etwas dauert, sollte nicht allzu verwunderlich sein. Immerhin sind diese nunmal für statische Geometrie ausgelegt und nur bedingt für Sachen, die sich ändern. Gerade dann machen sich VBOs bezahlt. Dort bekommst du nämlich einen Pointer, an dessen Position du dann die neuen Daten in den Grafikspeicher schreiben kannst, sofern die VBOs dort abgelegt werden (davon kannst du aber ausgehen).

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

...ja, denke ich auch. Die Implementierung ist aber etwas aufwendiger. Mal sehen wie ich das hinbekomme...

Deshalb empfehle ich erstmal VertexArrays. Die Struktur in die die Daten gespeichert werden ist dieselbe.
Nur entfallen erstmal die Pointer.

du kannst aber auch VBOs so verwenden, als wären sie VertexArrays. Dann fallen die Pointer auch weg. Das ist dann, wenn du die VBOs für statischen Gebrauch optimierst. Die Grafikkarte holt sich einmal die Daten. Du bekommst keine Pointer zu den Daten im Videospeicher, denn du kannst damit eh nichts anfangen. Schließlich kannst du die ja nichtmehr ändern

Alle Angaben wie immer ohne Gewehr!

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."